Entity Attestation Tokens#
In addition to the MCU Device Certificate identity, some Silicon Labs devices support both MCU device certificates and Secure Engine (SE) device certificates. The SE certificate is signed into the same batch certificate as the MCU device certificate, and is unique per device.
See table below for details on device support:
Device Security Level | SE Device Certificate and Private Key Location | Availability |
|---|---|---|
Series 2 Secure Vault High | Stored in SE OTP | Programmed by default |
Series 2 Secure Vault Mid (VSE and HSE) | Not programmed on SVM devices | Unsupported on SVM |
Series 3 Secure Vault (SixG301) | Stored in SE OTP | Programmed by default |
MCU device certificates are intended for application-level identity authentication through challenge-response authentication.
SE device certificates are intended for PSA-compliant attestation. PSA Entity Attestation Tokens (EAT) must be signed using the SE attestation private key, stored within the SE, to ensure claims are rooted in hardware-enforced security mechanisms. This token can either be a PSA Initial Attestation Token (IAT) or a Silicon Labs Security Configuration Token. Each of these tokens can be used to authenticate different claims of the SE or other security features of the device. These tokens can be used in additon to the MCU Device identity for many use cases, including secure provisioning of assets in an untrusted environment.
PSA EAT#
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.
PSA IAT#
The following tables describe EAT claims that are used in the PSA IAT.
Note: The actual claims returned from the tokens are SE firmware version dependent.
| Key ID | Claim | Description | Value |
|---|---|---|---|
-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)
| Key ID | Type | Description | Value |
|---|---|---|---|
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)
Security Configuration Token#
The following tables describe EAT claims that are used in the Security Configuration Token.
| Key ID | Claim | Description | Value |
|---|---|---|---|
-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:
All custom Silicon Labs claims will have a base of 76000.
Key ID 76000: Refer to the Get Status section in Programming Series 2 Devices using the Debug Challenge Interface (DCI) and Serial Wire Debug (SWD) for the description (HSE-SVH) of the value.
Key ID 76001: Refer to the Read User Configuration section in Programming Series 2 Devices using the Debug Challenge Interface (DCI) and Serial Wire Debug (SWD) for the description (HSE-SVH) of the value.
Key ID 76002 and 76003: Refer to Key Reference for Public Sign Key and Public Command Key.
Key ID 76004: One nibble per tamper source. Refer to the Anti-Tamper Configuration section in Programming Series 2 Devices using the Debug Challenge Interface (DCI) and Serial Wire Debug (SWD) for the description of the value.