Secure Identification using MCU Device Certificates on Series 2 and Series 3 Devices#

The goal of secure identification is to prove the ownership of a device's unique public key to an external service. It enables the external service to identify the device as legitimate and to authenticate device-generated data or messages.

Chain of Trust#

A certificate chain of trust establishes a verifiable link between a device and a trusted authority by organizing certificates in a hierarchical structure. At the top of the certificate chain is a root certificate authority (CA), which is implicitly trusted by the system verifying the device. The factory and batch certificates, are used to delegate trust while limiting exposure of the root private key. At the end of the chain is the MCU device certificate, which uniquely identifies a device and is cryptographically bound to a private device certificate key securely stored on the device. During authentication, each certificate in the chain is validated by verifying its signature against the issuing certificate, allowing a remote party to confirm that the device identity ultimately traces back to a trusted root authority.

The chain of trust on Silicon Labs Series 2 and 3 devices is illustrated in the following figure. All certificates are in standard X.509 format, conform to RFC-3280, TLS compliant with standard endpoint authentication methods, and use the signature algorithm ECDSA-prime256v1 with SHA256. A certificate can be revoked if required, for example when a private key is compromised or a security issue is identified. When revocation occurs, the certificate’s identifier is added to the Certificate Revocation List (CRL) stored on the Silicon Labs server. During certificate validation, remote devices or services consult the CRL, and any certificate listed as revoked is considered invalid and is no longer trusted for authentication or secure communication.

Storage of the Certificates in the Chain of Trust#

The certificates that make up the certificate chain are stored either in a server or the embedded device. Their storage location depends on the certificate’s purpose and the specific security feature subset enabled on the device. Refer to the table below for more details.

Storage of the Batch and MCU Device Certificates on Series 2 and 3 Devices#

Note: For more information on CPMS, refer to the CPMS User's Guide.

Device Certificate#

The device certificate is an X.509 certificate encoded in DER format, with an approximate size of 0.5 kB. This certificate is programmed into the device during manufacturing, either by default or custom-ordered through CPMS, and is stored in SE OTP or Flash, respectively. Because OTP memory cannot be altered after programming, the device certificate is immutable on HSE Secure Vault High devices, which prevents tampering or replacement after the device leaves the factory, ensuring a unique device identity.

Each device certificate uniquely identifies a device. The certificate’s Common Name (CN) field encodes the device’s 64-bit unique identifier (EUI), cryptographically binding the certificate to that specific device. In addition, the Issuer Common Name includes a batch number that identifies the factory and manufacturing batch in which the device was produced, enabling traceability and auditability across production runs. These fields can be customized via CPMS for further identification of individual products or manufacturers.

The device certificate has a validity period of 100 years starting from the device manufacture date. This extended validity is intentional and aligns with the expected lifetime of long-lived embedded devices, eliminating the need for certificate renewal in the field while still maintaining a unique device identity.

An example device certificate for a Series 2 device is shown in the following figure. The boxes in the image below highlight the following fields, in order they appear from the beginning of the certificate:

• The issuer of the device certificate (in this case, the Batch CA)

• The validity period

• The Common Name and device's EUI number

• The public key stored in the device certificate

• The certificate signature

The device certificate contains a device-specific public key, while the corresponding private key is generated and stored in different locations depending on security feature support of the device. See the table listed below for more details.

Storage of the Private Device Certificate Key#

Protecting the device certificate private key is fundamental to maintaining a secure device identity. The device certificate private key is the cryptographic secret that proves ownership of the device certificate; if it is exposed, copied, or misused, the device identity can be cloned or impersonated, undermining authentication. As a result, the strength of the overall identity is directly tied to how well this private key is protected throughout the device lifecycle—from manufacturing and provisioning to deployment and field operation. This section describes methods available to protect the device certificate private key on Series 2 and Series 3 devices.

Secure Identity Signatures and Verification#

Signing and Verification Process#

The signing and verification processes for the certificate chain are shown in the figures below.

The certificate signing process is done during the manufacturing process in order to establish the certificate chain of trust. The root of trust is the self-signed root certificate. The root certificate private key is used to sign the factory certificate, the factory certificate private key is used to sign the batch certificate, and so on. Once signed, the device certificate and batch certificates are stored on the device, either in flash or the SE depending on device security level, forming the chain that can later be presented during attestation.

The certificate chain verification process is done as the first part of the remote authentication process in order to validate the certificate chain of trust. The verification process begins by verifying the device certificate signature with the batch certificate public key, then the batch certificate signature is verified with the factory certificate public key, and so on. Once validated, this proves the device certificate issued is authentic by a trusted root. The rest of the remote authentication process is covered in detail in (Remote Authentication Process).