Skip to main content

Trusted Execution Environment



Data breaches in the financial services industry can result in immediate revenue loss and significantly impact business, user trust, and corporate reputation. Ensuring data confidentiality and integrity in the computing environment will be a significant challenge for enterprises, especially in the public cloud environment.

The proposal for Trusted Execution Environment is to meet this demand. By separating an isolated space at the chip level, it can establish an isolated execution environment that runs in parallel with the local operating system to ensure the code and data inside are protected in terms of confidentiality and integrity. It also protects sensitive code and data from a privileged attack coming from the potential vulnerability of the local operating system. An instance can be the typical scenario of wallets: we can use and handle Private Key in an isolated and secured environment while preventing users and applications on the parental side from viewing and obtaining these keys.

Common trusted execution environment technologies in the industry include Intel SGX and ARM TrustZone, as well as the AWS Nitro Enclave we use.

The advantages are as follows:



• Isolated and secure operating environment: Based on Nitro Hypervisor, we can accomplish a wholly isolated CPU and memory computing environment. There is no persistent storage and interactive access to the host and external network.

• Cryptographic Attestation: The Attestation document allows users to authorize access to the Enclave in the Parent OS and to verify the integrity of the business code in the Enclave to prevent malicious tampering.

• Flexible: No need to bind CPU manufacturers; it supports Intel, AMD chips, and any programming language.

• Cost savings: Nitro Enclave runs in EC2 without any additional cost. • Cloud-native security integration: Direct integration with cloud-native KMS and ACM security services to provide a better user experience and security.



Transaction signature


The above figure is a brief process of Private Key generation, encryption, decryption, and signature, based on AWS Nitro Enclaves and KMS.

  1. The Client App sends and receives MPC protocol messages and bidirectionally transmits them to the Nitro Enclave's Server App through Vscok for calculation. Then, the Private Key fragments are finally generated.

  2. In Nitro Enclave, the Server App obtains the plaintext DataKey and the KMS-encrypted DataKey through the KMS: GenerateDataKey API. Then, the app uses the plaintext DataKey combined with the user information to perform Private Key encryption on the Client-side.

  3. In Nitro Enclave, the Server App sends the encrypted Private Key and DataKey to the Client App through Vsock.

  4. In Parent OS, the Client App stores the encrypted Private Key, DataKey, and user information received from Vsock into the database.

  5. In Parent OS, the Client App reads a piece of data from the database and sends the encrypted Private Key, DataKey, and message to be signed to the Server App of Nitro Enclave through Vsock.

  6. In Nitro Enclave, the Server App receives data from Vsock, decrypts the encrypted DataKey through the KMS: Decrypt API, and obtains the plaintext DataKey.

  7. In Nitro Enclave, the Server App decrypts the encrypted Private Key using the plaintext DataKey combined with the user information.

  8. The Client App sends and receives MPC protocol messages and bidirectionally transmits them to the Nitro Enclave's Server App through Vscok for calculation. Then, it finally completes the message's signature through the Private Key.

  9. In Nitro Enclave, the signature information is discarded. Only the signature result is sent to the Client App through Vsock because the users of collaborative computing can also get the same signature information.



Here are some more safety points to concern:

  1. The generated KMS key must be unexportable to prevent leakage.

  2. KMS Key can use AWS CloudHSM to customize storage isolation and meet higher security requirements.

  3. The KMS key must be subject to permission control, and only specific EC2 Instances can access it.

  4. The EC2 Instance that has access to KMS cannot have permission to modify the Private Key policy.

  5. AWS Nitro Enclave must enable Attestation Document to bind Nitro Enclave image hash to Private Key policy. Doing this means each KMS API request must be sent from the internal Nitro Enclave and carry the correct image hash to complete Private Key encryption and decryption. Anyone trying to modify the image code or decrypt the Private Key directly from Parent OS is not allowed. In this case, your Private Key is still safe even if the server is compromised.