# 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)](#trusted-execution-environments)
and the guarantees they provide. We also go over
TEE attestations and how they are used to
[verify TEE execution](#verifying-tee-execution). Finally, we explain
the TEE attestations produced by Blocky Attestation Service, specifically
[Enclave Attestations](#enclave-attestations) and
[Transitive Attestations](#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](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html)
and
[Google Confidential Spaces](https://cloud.google.com/confidential-computing/confidential-space/docs/confidential-space-overview)
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](https://docs.aws.amazon.com/pdfs/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.pdf)
and Google Confidential Spaces
[here](https://cloud.google.com/docs/security/confidential-space).
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](https://docs.aws.amazon.com/enclaves/latest/user/verify-root.html#doc-def)
and about Google Confidential Spaces attestation structure
[here](https://cloud.google.com/confidential-computing/confidential-space/docs/connect-external-resources#attestation_token_structure).

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](https://aws-nitro-enclaves.amazonaws.com/AWS_NitroEnclaves_Root-G1.zip).
Google publishes their Confidential Spaces public key
[here](https://confidentialcomputing.googleapis.com/.well-known/openid-configuration).

### 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](#enclave-attestations) and
[Transitive Attestations](#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](#verifying-tee-execution) 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.

![Attestations](/assets/attestations.c4eb80e22f262eb6874dcf3417e0f6eefcf8d8791e6d072281c2a380392e4e91.843b636c.png)

- The **red** path
shows that the `tee_pub_key` verifies the Enclave Attestation `signature`
created with the `tee_priv_key`.
- The **blue**
path shows that the `encl_app_pub_key`, attested in the Enclave Attestation,
verifies the Transitive Attestation `signature` created with the
`encl_app_priv_key`.
- Finally, the **green**
path shows that the `output` in the Transitive Attestation is produced by an
image that hashes to the `code_measurement`, attested in the Enclave
Attestation, which represents the program code running in the TEE.