Attestation is the process of securely providing information about a device to external parties through a cryptographically secured token. It enables IoT devices, especially those without user interfaces or in remote locations, to introduce themselves securely to networks and IoT platforms by offering attestation information.
Thus, the attestation service is employed by the device to communicate evidence regarding its credentials and operational state to a remote relying party. The collected information is structured into the Entity Attestation Token (EAT) format.
To ensure security, the EAT is cryptographically protected. The remote relying party can then verify the authenticity of the EAT and make decisions about engaging with the device based on its contents.
The Relying Party sends an Attestation Request (AR) to the device REE with some challenge or nonce (usually a random number).
The device REE forwards the request to the device TEE attestation service through the secure service call interface.
The TEE assembles the Entity Attestation Token (EAT) (the attestation evidence) by gathering all the relevant claim information as outlined in the EAT claim table. It then generates a signature on the claim data, appending it to the token.
The evidence is transmitted back to the remote attestation service (verifier) through the device REE and the relying party. In certain cases, the Relying Party itself may act as the attestation service.
The attestation service assesses the received evidence and, upon successful verification, compares the EAT claim data with the available reference values.
The relying party determines the trustworthiness of the device based on the attestation result and its predefined policy. Subsequently, it communicates this determination to the device.
The Entity Attestation Token (EAT) is a small blob of data that contains claims and is cryptographically signed. The cryptographic signing secures the token, so the means to convey the token does not need to provide any security.
When an attestation request is sent to the device, it generates the EAT in the predefined JSON format as given below. The token contains all the necessary information about the hardware and software entities on device. Here, an ECDSA key-pair from the TEE secure storage is used for signing the EAT, utilizing the slot ID mentioned in the attestation request. The EAT contains the compressed ECDSA public key as well as the R and S components of the signature.
For protection from Reply Attack. If attestation is initiated by the device, it provides the nonce as part of the attestation request to the Relying Party.
Client ID
Relying Party identification
Device ID
Device identification (should be unique)
SHA256 digest of the device MAC address
Device Version
SoC H/W revision from eFuse
Instance ID
Instance identification
Public-key hash (SHA256) from the current secure storage slot for the active session
Certification Reference
PSA certification ID
Device State
Development/Production Mode
Software Measurement
Details of the active firmware components - for e.g. app version, ESP-IDF version, digest, etc. There will be one entry of this type in the EAT for each firmware in the device.
The tee_attestation example demonstrates how to generate an entity attestation token containing validation details for all active firmware components (bootloader, TEE, and REE app).
To use the TEE Attestation APIs in your project, ensure that the tee_attestation component is listed as a local dependency in the component manager manifest file idf_component.yml. Refer to the tee_attestation example for guidance.
