TEE Network

While traditional blockchain networks rely heavily on slow and expensive mechanisms like state replication and consensus due to the untrusted nature of validators, a network of fully attested enclaves using Intel SGX can potentially reduce or eliminate the need for constant verification of communication and computation without the risk of collusion by leveraging hardware-based trust and remote attestation.

This opens the space-time for performing confidential general-purpose computation over a trusted network instead of fixed useless tasks. In comparison to a centralized cloud, anybody can contribute to the TEE network and take the profit of sharing their verifiable processing power. This argument shows how TEE is secure, fast, and cheap compared to pure algorithms like ZKP and MPC.

Intel Software Guard Extensions (SGX) is a set of security-related instruction codes that are built into modern Intel CPUs. It allows an application to create private regions of memory called enclaves, which are designed to be protected from processes running at higher privilege levels, such as the operating system, BIOS, SMM, and even other enclaves.

One of the key features of SGX is the ability to remotely attest the enclave’s state to a remote party. This is done through a mechanism called “Remote Attestation.” The process involves generating a quote, which is a cryptographic report that contains essential information about the enclave, including:

1. Measurement/MRENCLAVE: A cryptographic hash of the enclave’s initial memory state, which includes the code and data loaded into the enclave. Any tiny change to the source code or the official binary will cause a different Measurement (Tamper Evidence).

2. UserData: An optional field that can be used to include arbitrary data in the quote, such as a public key or other security-related information.

Report Data

The UserData field in the quote can be used to include the public key of the enclave, which can be used to verify the integrity and authenticity of the enclave’s code and data:

1. Enclave Creation: When the enclave is created, the source code generates a confidential key pair (public and private keys) for the enclave, it is inaccessible to the outside world and is considered as the identity of the enclave, it can be sealed and stored on the disk to have a more persistent identity.

2. Code Signing: We can sign the open-source code using the private key of the enclave.

3. Enclave Initialization: During the enclave initialization process, the public key of the enclave is stored, in the UserData field of the quote. This is an extremely critical step, so we also concatenate the MRENCLAVE and some temporary values including the current block number to the public key and store the hash or signed value in the UserData field. This will help to detect anomalies earlier as well as differentiate between depth and stage of modifications.

4. Remote Attestation: When a remote party wants to verify the integrity and authenticity of the enclave, they request a quote from the enclave.

5. Code Verification: The remote party can then use the public key from the UserData field to verify the signature on the open-source code, ensuring that the code running inside the enclave is the same as the code signed by the developer.

6. Quote Verification: The remote party receives the quote, which includes the measurement (hash of the enclave’s code and data) and the UserData field containing the enclave’s public key. The quote is signed by TEE confidential hardware key. Thus in addition to checking the available fields in the quote, the signature should be verified beforehand.

The quote is a cryptographic report generated by the SGX hardware that contains the measurement (hash) of the enclave’s initial state, including the code and data loaded into the enclave, as well as the UserData field.

Quote Verification

To verify the quote, the remote party needs to perform the following steps:

a. Verify the signature of the quote using Intel’s public key to ensure the quote was generated by genuine SGX hardware.

b. Compare the measurement in the quote with the expected measurement of the enclave’s code and data. This expected measurement is provided by Ternoa for each new release.

c. Verify the UserData field contains the correct public key for the enclave.

If the quote verification succeeds, the remote party can be confident that the enclave is running the expected code and data, and that the public key in the UserData field belongs to that enclave.

Intel Attestation Service (IAS)

• IAS is a cloud service provided by Intel that simplifies the remote attestation process by acting as an intermediary between the enclave and the remote party.

• Instead of verifying the quote directly, the enclave sends the quote to IAS, which verifies the quote’s signature and ensures it was generated by genuine SGX hardware.

• If the quote is valid, IAS generates a report containing the quote and additional metadata, such as the security version and platform information.

• The remote party can then verify the report from IAS using Intel’s public key, rather than verifying the quote directly.

• IAS simplifies the attestation process and offloads some of the cryptographic operations to Intel’s infrastructure.

If the quote verification fails, it could indicate several issues, such as:

a. The quote was not generated by genuine SGX hardware (e.g., spoofed or simulated quote).

b. The enclave’s code or data has been tampered with, resulting in a different measurement than expected.

c. The UserData field does not contain the expected public key for the enclave.

In such cases, the remote party should refuse to establish a trusted channel with the enclave, as its integrity and authenticity cannot be verified.

Additionally, if the report from IAS fails verification, it could indicate that the IAS service itself has been compromised or that the report has been tampered with during transmission.

By including the public key of the enclave in the UserData field of the quote, SGX provides a mechanism for remote parties to cryptographically verify that the code running inside the enclave is the same as the open-source code signed by the developer. This process, combined with the hardware-based protections offered by SGX enclaves, can help ensure the confidentiality and integrity of the enclave’s code and data, even in the presence of a compromised operating system or other privileged software.

It’s important to note that the effectiveness of this approach relies on the integrity of the SGX hardware and firmware, as well as the proper implementation of the remote attestation process by the developer and the remote party.

Due to the complexity, variations of SGX versions, or supporting the AMD SEV enclaves, Ternoa has a (centralized) remote attestation as a service to simplify Quote and Report verification.

We also provide a docker version of each newly released version to help enclave reproducibility. The issue comes from the dependencies of enclave source code to some OS libraries. We have identified and fixed all the dependencies for Ternoa enclaves. We also use the latest update on Ubuntu to create the docker enclave, though there are suggestions to use nixOS which has a reputation for reproducibility.

The security of SGX-based systems relies on the integrity of the SGX hardware and firmware, as well as the proper implementation of remote attestation protocols. Any vulnerabilities or flaws in these components could compromise the overall security of the system. That’s why in Ternoa we have the p2p synchronization of TEE clusters to increase the resilience and fault tolerance of the TEE network.