Trusted Execution Environment (TEE) is a secure area, also known as an “Enclave,” on the CPU that is isolated from the main operating system (OS). It is designed to protect data and ensure that it is stored, processed, and kept secure.

TEE is secured by an isolated, cryptographic electronic structure that is resistant to malicious attacks and unauthorized access. The hardware manufacturer guarantees that no one — not even the system administrator or the operating system — has access to the keys or can read the memory stored within the TEE. This makes it a great choice for executing confidential tasks, such as private token transfers, private smart contracts, and private state channels.

You can think of TEE as a black box in a CPU that is isolated from the rest of the system. Just like a black box, the data within the TEE is invisible from the outside and is protected and only the people with the right key can access it.

What makes a TEE safe?

1. Computation within a TEE is totally invisible from the outside

A TEE manages its own cryptographic keys, and the hardware manufacturer guarantees by design that no one — not even the system administrator or the operating system — has access to those keys or can read its memory. This allows us to execute any state update without having to share our data with the blockchain validator or other users. Private token transfer, private smart contracts, and private state channels can thus be achieved with minimal computational effort. These characteristics enable completely confidential and tamper-proof execution of software.

2. Every TEE has a remote attestation to ensure the code is running on a genuine and secure TEE

After the hardware manufacturer verifies a TEE report, they sign it with their well-known certificate. This attestation confirms:

• The enclave is a genuine TEE of the hardware manufacturer. Intel SGX hardware manufacturing can generate unique key pairs to identify the CPU. The CPU will use its private key to sign the enclave certificate, confirming that the certificate was issued by the CPU. This verifies that the enclave is running on Intel SGX hardware.

• The CPU microcode version indicates the security level of the hardware. Keeping the version up-to-date ensures patches for the latest known security vulnerabilities. This version also helps us gauge the security level of a CPU.

• The specific software running and data stored in the enclave are verified to ensure the code is unmodified and the initial state is determined. Additionally, each program run in a TEE has a hash of the public key in the ISV certificate, which guarantees the program is issued by the Independent Software Vendor (ISV).

3. Encrypted computation input and output

Users will set up a Shielding Key and use the key to encrypt messages/data that are to be sent to a TEE. TEE has a public shielding key that can decrypt the message/data from the user. Shielding key allows a user’s communication with TEE or the blockchain stays confidential.

Why Intel SGX?

TEE technology is highly hardware-dependent, so it is essential to select hardware that has a higher security level. When it comes to SGX services, Intel SGX is an outstanding choice due to its dependable remote attestation service.

Intel SGX was first proposed back in 2015, which makes it one of the earliest TEEs. Additionally, compared to other TEEs such as AMD SEV or ARM CCA, Intel SGX has more robust toolchains and support materials, which makes it a much better choice. Furthermore, Intel SGX also provides its users with greater security guarantees and more reliable performance. Therefore, when it comes to TEE technology, Intel SGX is certainly a great option to consider.

Why IntergriTEE?

TEEs are invisible from the outside, and although this presents a major advantage in terms of security, it also has a downside: if the hardware is ever compromised, all data stored in the TEE is completely lost and unrecoverable. To provide a solution to this issue, IntergriTEE has developed a Layer 2 TEE sidechain and oracle.

This sidechain enables computations to be executed in parallel across multiple TEE workers, allowing for the synchronization and computation of information in multiple TEEs. This ensures that if one of the TEEs is ever compromised, it will not have any negative effects on the functioning of the sidechain. Furthermore, because the computations are divided between multiple TEEs, the data stored within the sidechain is far more secure than it would be if it was stored in a single TEE.

Why TEE, not zero-knowledge proof?

Zero-knowledge Proof (ZKP) is a technology that has been gaining traction in recent years, as it allows for the secure transmission or interaction of information without revealing the underlying data. However, TEE is ultimately a better solution for us than ZKP, after considering the design complexity, scalability, and maturity of the two technologies.

• ZKP only manages the transmission or interaction of information but does not provide protection for information extraction/query, storage, or computation. In contrast, TEE offers a more comprehensive protection across the data workflow.

• The design sophistication of a ZKP system is far more complex than that of a TEE system, which necessitates a more specialized profession, such as polynomial commitment design, from developers. This means that the developers must have a greater level of expertise when working with a ZKP system, as compared to a TEE system.

• ZKP is not scalable enough to handle a wide range of problems, and is usually only developed for one or two common problems. In contrast, TEE allows you to specify any business logic to be executed inside, and is a mature solution with Intel SGX having been in use for around seven years. It will take a long time for ZKP to become performant enough for many business cases.

In conclusion, TEEs provide a secure, reliable way to store and process data, with Intel SGX being the most mature and advanced implementation of the technology. We are using IntergriTEE’s sidechain technology, which an extra layer of security by allowing computations to be run across multiple TEE nodes, ensuring that a single TEE failure does not lead to data loss. Finally, while Zero-Knowledge Proofs provide a way to transmit information securely, they are not suitable for all use cases, as they are complex to design and not as scalable or mature as a TEE system.

Special thanks to Adegoke, Eric Zhang, and Kailai Wang for contributing their knowledge to this article.

If you are interested in reading more about our privacy solutions, you can find the first part of the article here — Privacy in Litentry I: Implication and Design.

In the next article, we will explore the implementation of TEE in Litentry Parachain and how it facilitates data protection and privacy. If you have any questions, please leave a comment below.

“I care about my data. It’s crucial to be able to hide certain aspects.” — an anonymous web3 user.

Privacy plays a crucial role in the design of the Litentry Protocol. However, this isn’t always the case in web3 projects, as people often conflate anonymity with privacy, or misunderstand that we must compromise privacy for trust.

In this article we will talk about the philosophical foundations of privacy in Web3, and how that informs the privacy preserving designs in the Litentry Protocol.

What privacy means in the Web3 space

In 1993, Cypherpunk Manifesto laid out the statement “Privacy is necessary for an open society in the electronic age.” Indeed, the Cypherpunk movement advocates the use of cryptography and other privacy-preserving technologies to facilitate social and political change.

Privacy is hard to define, which makes legal policy-making and privacy paradigms difficult to design and implement. In “the Right to Privacy”, one of the most influential privacy-focused essays in the history of American law, privacy is defined as “the right to be alone.” In the aforementioned Cypherpunk Manifesto, privacy is “the power to selectively reveal oneself.” GDPR adopts the “informed consent” model, where users must be given sufficient information and understanding before making decisions about their data.

Maybe one of the most prevailing theories of privacy in Web3 is the theory of Contextual Integrity. As defined by Helen Nissenbaum in her book Privacy in Context, privacy concerns an appropriate information flow, where appropriateness, in turn, is defined as conformance with legitimate, informational norms specific to social contexts.

Based on Nissenbaum’s work, the authors of Decentralized Society: Finding Web3’s Soul (DeSoc) proposed seeing privacy as a “programmable, loosely coupled bundle of rights to permission access, alter or profit from information.” rather than simply as a right to private property. Despite the intersected, shared nature of data ownership, the design of blockchain allows data to be transparent, for which we’ll never fully possess our on-chain data. We never had full control over who can see, access, or leverage our data, and it is questionable to say it is desirable to achieve this level of data control.

Privacy in the Litentry Protocol

Our philosophy of privacy

To us, ownership or self-sovereignty of data represents the right to

• View and manage data,

• Define permissions, and

• Profit from or exchange value with data

The above rights don’t guarantee that your data is fully concealed, but they restrict others from any unwarranted access or use. This speaks to the difference between secrecy and privacy: while secrecy conceals a part of yourself completely, privacy allows you to reveal yourself selectively. Such that others can still see you, but in a way that you are comfortable with and have consented to.

In the spectrum of public, private, and secret, we are dedicated to enabling the user control of** the** flow, the preservation, and the computation of private data, which is the part of data you’d wish to selectively reveal to others. As you can see in the graphic below, at one end of the spectrum, we have blockchain’s radical transparency; making data open to view for the public. On the other end, we have complete anonymity, making it hard to accumulate reputation or trust online. We operate in the ‘private’ area of the spectrum, hoping to unlock the benefits of pseudo-anonymity, and in the process, enabling new identity-based markets in the process.

Our Technological Approach to preserving privacy

During data’s lifespan, they usually go through the path of generation, storage, query, computation, transmission, verification, and more. The ‘privacy problem’ can happen at any stage of the data’s lifespan.

Keeping this in mind, Litentry’s privacy designs aim to preserve privacy during the query, computation, transmission, and verification stages. Given that the nature of blockchain determines that on-chain data is public and attainable, it means that the generation and storage of raw data are not our concern. However, it is worth mentioning that some processed forms of data, under a data owner’s request, will be stored in a trusted environment. At the same time, it is difficult for us to control if the verifier will subsequently expose the information received by the verifier to unwanted third parties. Thankfully, our technology ensures that only a minimum, or rather context-specific information is provided to the verifier.

We believe that it is important to achieve a programmable, retro-manageable revelation of private data. Amid the absence of data sharing standards, data owners remain the ultimate judge to decide how, where, when, and to whom the flow of personal data is appropriate. To achieve this, we use the following design:

• Trusted Execution Environment (TEE) Sidechain/Off-chain. The TEE sidechain/off-chain ensures that private data can be stored, computed, and transported in a secure and private manner.

• The separation of local storage and central storage. Making good use of local storage from the user end gives users authority over the management of their data, as well as eschewing potential data leaks from traditional central storage.

• Verifiable Credentials (VC). A W3C standard for verifying a personal claim to a third party by revealing a selective piece of information. The VC standard is flexible and can be encrypted. It is used to prove a private statement or grant access to a certain scope of information to facilitate trust between the VC sender and receiver.

Let’s wrap up this article with a summary:

• Based on Nissenbaum’s privacy-in-context theory, the DeSoc paper proposed seeing privacy as a “programmable, loosely coupled bundle of rights to permission access, alter or profit from information.”

• We believe that self-sovereignty does not give you full control over data, but rather the right to view, manage, permission access and exchange value with data.

• Litentry’s privacy designs aim to preserve privacy during the query, computation, transmission, and verification stages of the data lifespan.

• We believe that it is important to achieve a programmable, retro-manageable revelation of private data. Our current privacy design is constituted of the TEE sidechain/offchain, separation of local and central storage, and use of verifiable credentials.

Special thanks to Patrick Cajina Cortez for reviewing and contributing to this piece! In the next article, we will take a closer look at one of the most widely discussed privacy technology in web3 — Trusted Execution Environment.

What do you think about privacy in Web3? Why do you care about privacy? Let us know in the comments!