Skip to main content

TEE Technology Overview

In the SMN suite, the server-side components utilize Trusted Execution Environment (TEE) technology based on Intel SGX to protect core sensitive data, such as key shares. To enhance comprehension of the SMN suite's implementation logic, this section provides a focused overview of the fundamental concepts related to TEE.

Intel SGX & TEE​

In 2015, Intel defined a new set of instructions for the sixth generation CPU called Software Guard Extensions (SGX). Intel SGX ensures the isolation of SGX programs through new instruction set extensions and access control mechanisms, safeguarding the confidentiality and integrity of critical code and data from malicious software. Unlike other security technologies, Intel SGX's trusted root consists solely of hardware, avoiding the potential security vulnerabilities inherent in software-based trusted roots, greatly enhancing system security. It represents a comprehensive solution combining software and hardware, aiming to provide a secure trusted execution environment, primarily including the following features:

  • Program Integrity Measurement
    • Ensures that the running program has not been tampered with, maintaining complete consistency with the program delivered by the user, through signature, hashing, and other measurement methods.
  • Secure Input/Output
    • The data exchange channel between an enclave and the external environment should be secure, typically relying on cryptographic technologies such as DSA (Digital Signature Algorithm), Encryption, and TLS (Transport Layer Security) to ensure the security of data transmission.
  • Memory Curtaining
    • To achieve a trusted cloud environment, it is essential to ensure that even if malicious attackers gain full control over the physical machines and the operating systems within them, they cannot sniff on the running memory of applications. This generally relies on hardware implementation, such as Intel SGX, AMD TrustZone, etc., by partitioning an isolated memory for the trusted environment's enclave to use, thus preventing access from any external privileged programs. For example, in Intel SGX, trusted memory is encrypted, and even if attackers obtain memory through techniques like memory sniffing, they cannot decrypt the memory data.
  • Sealed Storage
    • When the program in the TEE is switched due to interruptions or when its memory pages are swapped, or when there is a need to persistently store data on the host machine's disk, these data will temporarily leave the trusted zone, addressing the encryption issues of securely storing the data.
  • Remote Attestation
    • When user programs run on third-party cloud platforms, users can verify the platform and programs through remote attestation. Remote attestation mainly verifies whether the platform can provide a trusted execution environment and the integrity of the application.

The TEE mainly consists of the following core elements:

  • Data Confidentiality: Data within the TEE cannot be sniffed externally
  • Data Integrity: Data within the TEE cannot be tampered with externally
  • Code Integrity: Code within the TEE cannot be tampered with externally

In summary, TEE involves creating a protected isolated environment within the existing execution environment, where all software, including the operating system, is not authorized to access the data within the TEE.

Intel SGX Attestation​

Attestation verifies whether a program is running on an Intel SGX-protected enclave platform. This includes Local Attestation, Intra-Platform Attestation, and Remote Attestation.

Remote Attestation verifies whether a program is running in a trusted execution environment and ensures the confidentiality and integrity of the program.

The implementation of Remote Attestation is quite complex, involving mechanisms such as the certificate chain mechanism of the Intel SGX Root CA certificate, as well as the authorization mechanism related to PCK in the PCE, and the AK mechanism in the PCE authorized QE. For ease of understanding, we simplify the intermediate process. Intuitively, a developer can create a TEE report in your TEE application, which contains automatically generated data from the Intel SGX SDK, including the MRENCLAVE of the TEE application, which can be used to determine some attributes of the TEE application's environment, as well as 256-bit custom data defined by the developer. Intel SGX officially verifies whether this report is submitted within the TEE and is signed within the TEE.

Upon receiving the TEE report, the verifier verifies the report using the Intel SGX official public key. If the verification passes, it proves that the TEE application corresponding to the report is indeed running in the TEE, and the MRENCLAVE, etc., corresponding to the report can be considered genuine. Developers can fill in the custom data with information that requires attestation, such as a communication key, allowing validators to trust that the key is generated and used within a trusted execution environment.

MRENCLAVE can be considered as a hash of the trusted portion of a TEE application's code and metadata. If any changes occur in the TEE application code, the MRENCLAVE will change accordingly. Therefore, MRENCLAVE can be used to identify the version of a TEE application. SMN extensively leverages remote attestation features to address trust authorization issues between TEE applications and administrators.

Intel SGX Sealing​

Before introducing sealing, let's first understand the Author Enclave Signing Key. The key is used to sign the trusted part of the TEE application when building. The MRSIGNER register stores the public key identifier of the Author Enclave Signing Key. After a TEE application is signed with the same key, the MRSIGNER value remains unchanged after startup. MRSIGNER is also included in the TEE report, allowing the determination of the TEE application's publisher through the report.

Sealing refers to the process of encrypting data. Intel SGX offers two sealing methods, each with a corresponding unsealing process.

Seal to the Current Enclave (Enclave Measurement)​

Seal data using the measurement value MRENCLAVE of the current version of the enclave, and bind this value with the key used for sealing. Only the enclave with the same MRENCLAVE measurement value can unseal data sealed in this manner. If the enclave's dynamic library or shared object file is tampered with, the measurement of the enclave will change, causing the sealing key to change as well, and the data will become unrecoverable.

In practical terms：

  • On the same CPU, an identical version of the TEE application can encrypt and decrypt data using this method.
  • If the CPU is changed, even with the same version of the TEE application, it is not possible to decrypt (unseal) data encrypted previously.
  • If the TEE application code is modified on the same CPU (resulting in a change in MRENCLAVE), the new version of the TEE application also cannot decrypt data encrypted previously.

Seal to the Enclave Author​

Seal data using the Author Enclave Signing Key of the enclave developer. During enclave initialization, the CPU stores it in the MRSIGNER register and binds this value with the key used for sealing the data. This binding is executed by the hardware through the EGETKEY instruction. The key used for the data sealing is also bound to the product ID of the enclave. Only enclaves with identical MRSIGNER values and Product IDs can unseal data sealed in this manner.

In practical terms：

  • On the same CPU, different versions of TEE applications (or different TEE applications) can encrypt and decrypt data using this method as long as they are signed by the same Author Enclave Signing Key (having the same MRSIGNER).
  • If the CPU is changed, even using the same version of the TEE application or signed by the same Author Enclave Signing Key, it is not possible to decrypt (unseal) previously encrypted data.

Sealing Summary​

In both sealing methods, once the CPU running the TEE application is changed, it becomes impossible to decrypt previously encrypted data. This aligns with the requirement of hardware-based data protection, where data is bound to the hardware.

If using the Seal to the Enclave Author method to seal data, there is no need to migrate encrypted data when the same version of the TEE application is shut down and restarted on the same CPU. Moreover, as long as the application is signed by the same Author Enclave Signing Key, updating the TEE application version on the same CPU allows for the decryption of previously encrypted data. Although updating the TEE application on the same CPU is convenient and user-friendly, it also means that if someone gains control of the Author Enclave Signing Key and acts maliciously, they can export sensitive information from the enclave by upgrading the TEE application.

If using the Seal to the Current Enclave method to seal data, it is necessary to consider how to migrate encrypted data for each version of the TEE application. However, on the same CPU, there is no need to migrate encrypted data if the same version of the TEE application shuts down and restarts.

Therefore, the choice between the two sealing methods also needs to consider a balance between security and the user experience of the TEE application. In the context of managing cryptographic keys (private keys or key shares) for blockchain assets, Safeheron chooses the Seal to the Current Enclave method to reduce the attack surface and enhance security. By designing the SMN CA (Certification Authority) component, developers gain complete control over the sealing and unsealing operations within the Trusted Execution Environment (TEE). Through the architecture of automated authorization technology, management and operational costs are reduced.

Summary​

SMN suite maximizes using TEE features to safeguard the entire lifecycle of sensitive data generation, utilization, and destruction in the cloud. Even if a hacker gains access to server permissions, they would be unable to steal plaintext private key shares.

Last updated on by xigaoku