Attestation Token
Format of Token
The attestation token takes the format of what is becoming an industry standard: an entity attestation token (EAT).
For the purposes of this sample code, a variant of the Arm Platform Security Architecture attestation token has been chosen to provide the basic structure. More information is available at: https://www.psacertified.org/blog/what-is-an-entity-attestation-token/.
An EAT is a small blob of data that includes information items and is cryptographically signed. The signing secures the token itself, so that the mechanism that is transmitting the token does not have to provide any security. This allows IoT devices to securely introduce themselves to networks and to IoT platforms. The EAT is wrapped into a compact binary object representation (CBOR)-type message.
Each information item in this token in known as a claim, as shown in the "Items Included in Token" table. A claim is a data item, which is represented as a key-value pair.
The size of the attestation token is governed by the fields outlined in the "Items Included in Token" table, and by how these values are encoded into a CBOR data stream. In addition, the EAT is wrapped into a signed format which includes a hash of the CBOR data, as well as a signature based on the size and type of the attestation key.
The "Example Token Sizes" table provides some example token sizes for different challenge and key sizes. All values are in bytes.
An example calculation can be found in the sample application source code in bl_eat.c.
NOTE: Some items in the EAT are provided as placeholder default values in the secure bootloader sample application. They are intended to be replaced as needed in a final product implementation.
EAT Additional Details
EAT has the capabilities to provide the source of trust, using a cryptographically signed piece of data containing claims that are generated in the device Root of Trust (RoT). The main use is for the relying party to verify the claims made by the device, such as the following:
- The unique identity of the device
- Installed firmware on the device and its integrity status
- Security assurance and certification status (such as a PSA Certified level)
- Manufacturer of the device hardware
Using this information, the relying party can make informed decisions, such as whether the device is legitimate and should be trusted, or what services to enable based on the information it receives. This is shown in the "Relying Party Decision Diagram" figure.
Attestation Token Request
The "Attestation Token Request" figure shows the process of requesting an attestation token.