BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

6.2 Remote TEE Attestation

NIST platform security: roots of trust, firmware and secure enclaves IR 8320
All changes in this version
first version loaded 6 Remote Attestation Services part of 6

Title

Remote TEE Attestation

Control

There are instances when the high assurance that the output of the processing in a TEE can be trusted should be conveyed to a relying party. This is achieved thanks to a TEE attestation flow. Remote TEE attestation involves the generation of a verifiable cryptographic evidence by the TEE. The evidence is then sent to a relying party, which can validate the signature of the evidence. If the signature is valid, the relying party concludes that the remote code is running in a genuine TEE.

An evidence usually contains the measurement of the TEE, as well as data related to the authenticity of the TEE and the compliant version of it. The measurement is a digest of the content of the TEE (e.g., code and static data). The measurement obtained at build time is typically known to the relying party and is compared against a measurement contained in the evidence that is actively taken during runtime. This allows the relying party to determine that the remote code has not been tampered with. An evidence may also contain the enclave’s developer signature and platform trusted computing base (TCB) information.

The evidence may also contain the public key part of a key pair generated inside the TEE or a secure hash of the public key if there is a limitation on the size of the evidence. In the latter case, the public key must be communicated along with the evidence. The public key allows the relying party to wrap secrets that it wants to send to the TEE. This capability allows the relying party to provision secrets directly to the TEE without needing to trust any other software running on the server.

Figure 2 shows an example TEE attestation flow. Figure 2: Notional Example of TEE Attestation Flow

Please refer to the following technology example in the appendices for more information:

• Arm Secure Boot and the Chain of Trust (CoT)

• IBM Continuous Runtime Attestation