Entity Attestation Token (EAT)#

The device attestation service creates a token that contains a fixed set of device-specific data when requested from the caller. The device must contain an attestation key pair, which is unique per device, to sign the token. The HSE-SVH device uses the Private Device Key (aka attestation key) to sign the token, and the caller uses the Public Device Key to verify the token's authenticity.

An Entity Attestation Token (EAT) is a mini-report that is cryptographically signed. An EAT is encoded in either one of two standardized data formats: a Concise Binary Object Representation (CBOR) or in the text-based format JSON. A digital signature is then used to protect its content. The technical specification defining the content of the EAT, which are claims about the hardware and the software running on a device, is specified by the Internet Engineering Task Force (IETF).

An EAT is a collection of Key ID-Value pairs relating to device pedigree or any other information one wants the device to attest. Collected data can originate from the Root of Trust (RoT), any protected area, or non-protected areas.

The EAT must be signed following the structure of the CBOR Object Signing and Encryption (COSE) specification. For asymmetric key algorithms, the signature structure must be COSE-Sign1. A COSE-Sign1 is a CBOR encoded, self-secured data blob that contains headers, a payload, and a signature.

The primary need for EAT verification is to check correct formatting and verify signatures as for any token. In addition, though, the verifier can operate a policy where values of some of the claims in this profile can be compared to reference values, registered with the verifier for a given deployment, to confirm that the device is endorsed by the manufacturer supply chain.

The HSE can generate the PSA attestation token or security configuration token when requested from the caller with a challenge (Auth challenge claim below). The following tables describe EAT claims that are used in the PSA attestation token and security configuration token.

Note: The actual claims returned from the tokens are HSE firmware version dependent.

Claims of PSA Attestation Token
Key IDClaimDescriptionValue

-75000

Profile definition

Name of a document that describes the profile of the report.

PSA_IOT_PROFILE_1

-75001

Client ID

Represents the Partition ID of the caller.

See note below

-75002

Security lifecycle

Represents the current life cycle stage of the PSA RoT.

Device dependent

-75003

Implementation ID

Uniquely identifies the underlying immutable PSA RoT.

Device dependent (32 bytes)

-75004

Boot seed

Represents a random value created at system boot time.

Random bytes (32 bytes)

-75006

Software components

A list of Software components represents all the software loaded by PSA RoT.

See the software components table below.

-75008

Auth challenge

Input object from the caller. For example, this can be a cryptographic nonce or a hash of locally attested data. The length must be 32, 48, or 64 bytes.

Random bytes or hash (32/48/64 bytes)

-75009

Instance ID

Unique identifier of the instance.

Device EUI-64 unique ID with type byte 0x06 (9 bytes)

Note:

  • Key ID 75001: Client ID if present. Otherwise the value 1 for a token requested by a secure bus master and -1 for a non-secure master.

  • Key ID 75002 (For the definitions of these lifecycle states, please refer to the ARM Platform Security Model):

    • UNKNOWN (0x0000)

    • ASSEMBLY_AND_TEST (0x1000)

    • PSA_ROT_PROVISIONING (0x2000)

    • SECURED (0x3000)

    • NON_PSA_ROT_DEBUG (0x4000)

    • RECOVERABLE_PSA_ROT_DEBUG (0x5000)

    • DECOMMISSIONED (0x6000)

  • Key ID 75003:

    • Word[0]: Die revision

    • Word[1]: HSE OTP version

    • Word[2]: Bit indicating it is an HSE-SVH device

    • Word[3]: Production version

    • Word[4:7]: Reserved (zeros)

Software Components
Key IDTypeDescriptionValue

1

Measurement type

A short string represents the role of this software component.

See note below

2

Measurement value

Represents a hash of the invariant software component in memory at startup time.

See note below

4

Version

The issued software version is in the form of a text string.

See note below

Notes:

  • Key ID 1:

    • HSE always exists — PRoT

    • If secure booted Gecko Bootloader exists at flash starting address — BL

    • If secure booted application exists at flash starting address — ARoT

  • Key ID 2: SHA-256 hash (32 bytes) of the firmware (HSE, Gecko Bootloader, or application)

  • Key ID 4: Version of the firmware (HSE, Gecko Bootloader, or application)

Claims of Security Configuration Token
Key IDClaimDescriptionValue

-75000

Profile definition

Name of a document that describes the profile of the report.

SILABS_1

-75008

Auth challenge

Input object from the caller. For example, this can be a cryptographic nonce or a hash of locally attested data. The length must be 32 bytes.

Random bytes or hash (32 bytes)

-75009

Instance ID

Unique identifier of the instance.

Device EUI-64 unique ID with type byte 0x06 (9 bytes)

-76000

SE status

Device HSE status.

Device dependent (36 bytes)

-76001

OTP configuration

Device HSE OTP configuration if provisioned.

Device dependent (24 bytes)

-76002

Sign Key

Public Sign Key in HSE OTP if provisioned.

Device dependent (64 bytes)

-76003

Command Key

Public Command Key in HSE OTP if provisioned.

Device dependent (64 bytes)

-76004

Tamper settings

Current applied tamper settings.

Device dependent (16 bytes)

Notes: