Concepts
To help you understand how the Blocky Attestation Service works, we need to explain a few key trusted computing concepts. In this section we give a brief intro into Trusted Execution Environments (TEEs) and the guarantees they provide. We also go over TEE attestations and how they are used to verify TEE execution. Finally, we explain the TEE attestations produced by Blocky Attestation Service, specifically Enclave Attestations and Transitive Attestations and how they work together to speed up the verification process.
Trusted Execution Environments
Trusted Execution Environments (TEEs) are hardened systems that provide the code executing within them certain security and correctness guarantees. Specifically, TEEs provide:
- Confidentiality: TEEs protect the state of a running program from being observed by other software running on the same system. This means that no one, including Blocky, can inspect the state of the program or its memory.
- Integrity: TEEs ensure that the programs they run are not modified, or replaced during execution. This means that the output of a program running in a TEE is the result of the program code and its input.
TEEs such as AWS Nitro Enclaves and Google Confidential Spaces implement these guarantees by running programs in secure virtual machines (VMs), also known as enclaves. An enclave runs on CPU cores and memory isolated from the rest of the underlying system. A key part of a TEE architecture is how it implements this isolation. You can read more about the security architecture of AWS Nitro Enclaves here and Google Confidential Spaces here. An advantage of using TEEs inside cloud providers is the providers' processes for preventing unauthorized physical access to the hardware. Finally, enclaves have access a network interface, which enables their programs to accept user requests, access external data, and emit output.
The way TEEs demonstrate program execution guarantees is through TEE attestations. An enclave program has access to a TEE secure module that can generate TEE attestations. A TEE attestation is a signed data structure that contains a series of hashes representing the enclave software stack and the host environment. An enclave in AWS Nitro Enclaves or Google Confidential Spaces is instantiated from a Docker image, which contains a program executable and its dependencies. One of the hashes in a TEE attestation is the hash of that image - let's call it code_measurement
. When, as is the case with Blocky Attestation Service, that image is created via a reproducible build process, the code_measurement
attests to the program code running in the enclave. A TEE attestation also has space for byte arrays representing program output. That output space can be used by the program to reflect its input, such as a user request, and provide result of the program execution. You can learn more about AWS Nitro Enclave attestation structure here and about Google Confidential Spaces attestation structure here.
Data in an attestation is signed by the TEE secure module using the TEE hardware manufacturer's private key tee_priv_key
. The tee_priv_key
is the root of trust for a TEE attestation. TEE operators publish the corresponding public key tee_pub_key
to allow users to verify attestation signatures. AWS publishes the Nitro Enclaves public key here. Google publishes their Confidential Spaces public key here.
Verifying TEE Execution
Given the TEE execution model, how does a user trust the output of a program running in a TEE? First, a user verifies the authenticity of a TEE attestation by checking its signature with the well-known tee_pub_key
. Next, the user inspects several fields in the attestation to verify the enclave's software stack. This step can vary depending on the TEE architecture, but the good news is that the Blocky Attestation Service CLI does this automatically using source-available code. Finally, the user compares the attestation's code_measurement
against the hash of the image resulting from a reproducible build process that embeds in the image a program executable and its dependencies. When these hashes match, the user can trust that the output in the attestation was produced by code that compiled to the program executable in the image and executed in a TEE enclave.
Attestations in the Blocky Attestation Service
Two challenges of using TEE attestations directly to attest program output are that the TEE attestations can be relatively time-consuming to obtain from the TEE secure module and complex to verify, especially in a smart contract. Blocky Attestation Service solves these challenges by producing two types of attestations: Enclave Attestations and Transitive Attestations.
Enclave Attestations
The Blocky Attestation Service runs a server application inside a TEE enclave. On startup, the application generates a random public/private key pair encl_app_pub_key/encl_app_priv_key
. Since the server runs inside a TEE, the encl_app_pub_key
can be trusted to be generated by the server application's code, not tampered with, and not disclosed to anyone, including Blocky.
In the context of the Blocky Attestation Service, an Enclave Attestation is a TEE attestation produced by a TEE secure module, where one of the attestation byte arrays representing program output is the serialized encl_app_pub_key
generated on enclave startup. Conceptually, you can think of an Enclave Attestation as:
{
"encl_app_pub_key": "0x1234...",
"code_measurement": "0x5678...",
"signature": "0x90ab..."
}
where encl_app_pub_key
is the serialized public key generated by the enclave, code_measurement
is the hash of the enclave image (including the program executable), and signature
is the signature over the encl_app_pub_key
and image_hash
using the tee_priv_key
. An Enclave Attestation also contains other fields that represent the enclave software stack and host environment, but we omit them here for simplicity.
As with any TEE attestation, a user can follow the attestation verification process to trust that the encl_app_pub_key
was generated by the Blocky Attestation Service server application code running in a TEE enclave, which guarantees the confidentiality and integrity of the encl_app_priv_key
.
Transitive Attestations
In the context of the Blocky Attestation Service, a Transitive Attestation is a data structure produced by a program running inside an enclave that contains the program's output signed by the Blocky Attestation Service server application private key encl_app_priv_key
. Conceptually, you can think of a Transitive Attestation as:
{
"output": "0x4897...",
"signature": "0xa78b..."
}
where output
is a serialized data structure representing the program output and signature
is the signature of the hash of the output
signed by encl_app_priv_key
.
You can verify a Transitive Attestation by checking its signature
with the encl_app_pub_key
from the Enclave Attestation.
The advantages of using Transitive Attestations is that they are faster to obtain and are smaller and faster to verify than Enclave Attestations. The Blocky Attestation Service can produce Transitive Attestations in a variety of formats, including signed JSON Web Tokens (JWTs), or ABI-encoded data for verification inside smart contracts.
Mapping Transitive Attestations to TEE Root of Trust
Ultimately, users can trust the output
in a Transitive Attestation because its signature
maps to the tee_priv_key
or the TEE root of trust. The diagram below shows this mapping. We color code the different parts of mapping from output
to tee_priv_key
to make it easier to follow.
- The red path shows that the
tee_pub_key
verifies the Enclave Attestationsignature
created with thetee_priv_key
. - The blue path shows that the
encl_app_pub_key
, attested in the Enclave Attestation, verifies the Transitive Attestationsignature
created with theencl_app_priv_key
. - Finally, the green path shows that the
output
in the Transitive Attestation is produced by an image that hashes to thecode_measurement
, attested in the Enclave Attestation, which represents the program code running in the TEE.