Table of contents
Introduction
One of the most difficult requirements in IoT product security is to assign devices a unique and secure identity. A unique device identity is a pre-requisite for trusted systems, from authentication and authorisation mechanisms to secure communications with their ecosystem.
The objective of the VORTEx is to give an overview of Valid Options to Reduce Threat Exposure. For that purpose, this VORTEx presents the steps to provision a unique device identity before focusing on solutions to implement.
For product manufacturers focusing on compliance, Annex 1 explains how a unique device identity fulfills the requirements of IoT security standards: EN 18031, EN 303 645, NIST IR 8259A, CSA IoT Device Security Specification and ISA/IEC 62443-4-2.
Scope and objectives
This VORTEx focuses on existing solutions for attributing a unique device identity to better respond to cyber threats. A unique device identity is an essential requirement of a secure-by-design approach. It is a pre-requisite for several objectives:
- Authentication: a unique identity enables robust authentication and authorisation, mitigating security risks associated with unauthorised access, data breaches, and malicious activities.
- Secure communication: a unique identity is required to establish secure communication channels, ensuring that only authenticated devices can interact with networks and systems.
- Data protection: assigning a unique identity aids in maintaining the privacy and confidentiality of data handled by IoT devices. Proper authentication mechanisms ensure that data is accessed and utilised only by authorised devices, safeguarding sensitive information.
- Compliance: standards and regulations mandate the use of unique and secure identities for IoT devices.
- Accountability and traceability: a unique identity facilitates traceability and accountability in the IoT ecosystem.
- Prevention of device spoofing or cloning: an attestable identity shall help prevent device spoofing or cloning. By leveraging unique cryptographic keys or identifiers embedded within hardware, it becomes difficult for malicious actors to replicate or impersonate legitimate devices.
- Improved operational efficiency: with each device having a unique identity, it becomes easier to manage and track devices across networks, enhancing operational efficiency in device provisioning, management, and maintenance.
- Interoperability and trustworthiness: With a unique identity, devices from different manufacturers can securely communicate and collaborate. This interoperability is built upon a foundation of trust established through verifiable identities.
All these features require that device identity can ensure two characteristics:
- Genuineness: no counterfeited device nor overproduction
- Uniqueness: trusted authentication, device cloning not possible
Key concepts
To provision a unique identity securely, it is important to distinguish several key concepts: the two types of identity and their provisioning process.
Hardware-based root identity vs Operational identity
In this VORTEx, the term unique identity means an attestable unique identity that cannot be easily usurped. This constitutes a means of authenticating the device.
Two distinct notions are at the foundation of the concept of identity for an electronic device: ➀ hardware-based root identity and ➁ operational identity.
➀ Hardware-based root identity
The hardware-based root identity ensures the authenticity and uniqueness of the hardware. A set of hardware and software security mechanisms ensures the uniqueness of this identity by making it verifiable through cryptographic methods that leverage an inviolable device-specific secret. This is the hardware root-of-trust.
Technically, the hardware identity is held by the main chip or by a companion secure element. It often comprises a unique identifier, the Unique Device ID (UDID), and a pair of asymmetric keys. The private key must never be exposed outside of the devices secure memory.
The hardware-based root identity can take the form of a digital (long-life) certificate. It will remain the same throughout the entire product lifecycle. This identity is used to retrieve the first operational certificates and upon device reset.
Note: this is the Initial Device Identifier (IDevID) in the IEEE 802.1AR standard.
➁ Operational identity
The operational identity is associated with a service and is typically used to identify the device at the level of third-party systems (Cloud platform, other devices, etc.). Beyond identification, authenticating this identity is crucial to guarantee genuineness and uniqueness of the device. Robust authentication can only be ensured through a hardware-based identity (especially to forbid cloning). Therefore, the operational identity must be anchored in the devices hardware-based identity.
This operational identity is preferably carried by an X.509 operational certificate (aka on-field certificate, application certificate, or lifecycle certificate) within a Public Key Infrastructure (PKI) framework.
When a device is exchanging with multiple independent services, it is preferable to use one operational certificate per service. Operational certificates are injected and/or used by the service provider (which can be distinct from the OEM). They must remain short-lived.
Note that the management of operational certificates can become more complex with multiple actors (due to transfer of ownership, certificates hierarchies, etc.). To keep things simple, this VORTEx does not distinguish service operators from OEMs.
Identity provisioning in the supply chain
Several identity provisioning and related operations take place throughout the device lifecycle, from the manufacturing stage to its end of life. They rely on both ➀ hardware-based root identity and ➁ operational identity.
➀ Set a hardware-based root identity into the secure chip
The hardware-based root identity is set at the chip manufacturing stage. The objective is to provide an identity that can be attested through cryptographic means: the device must be able to authenticate that it is the legitimate owner of its ID.
The device must be equipped with a tamper-resistant hardware such as a secure element (aka hardware root of trust) to store cryptographic keys securely. This root of trust should be seen as a vault, holding the device unique identity and protecting against cloning.
Usually, the chip identification is used for device identification. As the root of security lies in the silicon, chipmakers have a crucial role to play. The hardware-based root identity has to be given at the chip factory. Basically, a unique asymmetric keypair is put in every chip, either generated by the chip itself or inserted by the chipmaker, through a rigorous process ensuring true randomness and that the private keys are never exposed outside of the silicon pieces.
More precisely, the hardware root identity typically takes the form of a set composed of UDID + device public key (pub_key) + device private key (priv_key, kept secret in the chip), where the UDID can be defined as a hash of the device public key.
Symmetric schemes (aka pre-shared keys) can be an alternative in some specific cases (e.g., highly constrained devices, quantum-proof). They are generally not recommended, although specific solutions may apply (e.g., SandGrain).
There are still remaining issues about part tracking, to prove their authenticity and avoid overproduction. This can be done with the chipmaker sharing the device database (list of devices UDID and public keys) with the OEM in a secure manner. Note that the integrity and the authenticity of that list must be trusted, whilst the confidentiality is less of an issue.
However, if the supply chain cannot be trusted, it is possible to guarantee the chip genuineness with a birth certificate. In this case, the parts are provided with a (X.509) birth certificate (aka factory certificate or bootstrap certificate) that contains the UDID and public key, signed with the silicon vendors private key.
In some specific cases, birth certificates can be used for operational certificate provisioning. However, they are not sufficient to avoid overproduction by a contract manufacturer at the product manufacturing stage, or by a counterfeiter using authentic chips.
To avoid overproduction or counterfeited parts, the UDID list of authorised chips must be controlled by the OEM, at least until it can lock an operational identity into the product. This is done by issuing an operational certificate anchored into the hardware-based root credentials.
➁ Anchor operational identity into the hardware-based root identity
The operational certificate setup can take place at any stage in the timeline. The objective is to set a robust device operational identity enforced by the hardware security of the chip.
In the device lifecycle, its operational identity will be held by an X.509 certificate stored in a PKI. This VORTEx explains the certificate enrolment process without going into further discussions on PKI and device management operations. The figure below details the workflow to bind a device certificate to the hardware-based root identity: this is the certificate signing request (CSR).
The device includes its UDID and public key in a CSR issued to a certificate authority (CA), that returns the device certificate (signed with the private key of the CA) to be stored on the device.
The pre-requisites for this second step are:
- a hardware-enforced keypair was securely set in the chip;
- a certification authority was chosen;
- a device database containing the list of authorised devices (ID, pub_key) can be used to allow for certificate signature.
The operational identifier can be either the UDID or a unique value bound to it. The UDID is bound to the device public key thanks to the device database.
The device private key binds the device to its corresponding public key (through standard asymmetric authentication workflow, where a challenge is solved).
The CA can be the OEM itself or a trusted third-party company, especially if the device has to authenticate with external entities.
For mutual authentication (i.e., for the devices to be able to authenticate other parties, e.g., on the head-end side), the CA public key must be stored in all devices securely to protect its integrity and authenticity (this is a key requirement for verifying the authenticity of firmware update signature, though it might use a different public key).
A device could possibly be granted several operational identities, one per service.
When to setup device identity?
Depending on the provisioning solution, identity binding can take place at various stages of the device lifecycle, with pros and cons for each solution.
Operational device certificate provisioning
| Identity setup stage | Pros | Cons |
|---|---|---|
| Early, at the chip factory |
|
|
| At the device factory |
|
|
| In a dedicated stage, before shipment |
|
|
| Later, in the field current market trend |
|
|
Solutions on the market
Solutions for identity provisioning generally involve several components and actors. This VORTEx explores different technological bricks from multiple players: chipmakers, Cloud service providers, PKI pure players as well as solutions from other ecosystems.
This list is not exhaustive. The information was collected from public sources and through discussions with industry professionals. The solutions presented in this VORTEx are valid at the time of publication. They require secure implementation, taking into account the entire system.
Note: cetome remains fully independent of these solutions and their vendor.
Explore the VORTEx
Chipmakers
Chipmakers are moving towards providing chip/device unique operational identities. However, there are differences in their technical solutions and in which stage of supply chain they perform operational provisioning.
NXP
NXP make secure elements as well as Arm-based MCUs with embedded security, for which they provide two distinct provisioning schemes:
NXP EdgeLock 2GO
EdgeLock 2GO is the NXP service platform for provisioning and managing IoT devices based on the EdgeLock SE05x secure element.
Three options are proposed:
- Ready: secure element pre-provisioned with default keys and certificates.
- Custom: custom provisioning, download device certificates.
- Managed: OTA management of device identities, revocation, overproduction control.
With this platform, NXP handle the overall provisioning process (keys and certificates), from the silicon to the PKI. Certificate provisioning could be made at the chip factory, device factory, or in the field.
NXP extended the EdgeLock 2GO scope in March 2024:
- To let programming partners (e.g., Arrow Electronics, Avnet Silica, EBV Elektronik, EPS Global, Future Electronics) offer secure provisioning services based on the EdgeLock 2GO solution;
- By supporting not only secure elements, but also a series of NXP MPUs and MCUs.
NXP MCUXpresso Secure Provisioning Tool
Alongside their new generation of Arm-based MCUs (Cortex M33), NXP offers a dedicated provisioning tool. The MCUXpresso Secure Provisioning Tool allows for secure firmware, keys and certificates injection. Two options are available: Smart Card Trust Provisioning and Device HSM Trust Provisioning.
NXP Smart Card Trust Provisioning is a turnkey solution for OEMs to securely delegate device provisioning to contract manufacturers without a trusted environment. It also provides production limit control and a record of all device-unique certificates.
ST Micro
STM32 microcontrollers are provisioned at factory with a unique hardware identity, in the form of a device dedicated public/private keys (unique ECDSA key pair per device) and an X.509 certificate signed by STMicroelectronics.
STMicroelectronics have a strong focus on protecting OEMs against untrusted manufacturing environments: firmware IP protection, avoiding counterfeited or clone products as well as overproduction. This is the main objective of their STM32 Secure Firmware Installation framework, that rely on the chip unique keypair to individually pass the AES secret key encrypting the firmware.
However, STMicroelectronics do not propose secure provisioning services: they rely on partnerships with third-party pure players to assist OEMs on this topic and PKI, such as Kudelski IoT keySTREAM for their latest Arm Cortex M33-based MCU with STM32Trust TEE Secure Manager.
On the other hand, ST Microelectronics launched chip to Cloud initiatives (development of dedicated software packages) to plug their STM32H5 series MCUs into Microsoft Azure IoT Hub (Azure RTOS port) and Amazon AWS IoT Core (Amazon FreeRTOS integration). This should accelerate the provisioning of unique identity by relying on the device hardware security key. This feature was first introduced to work with the STSAFE-A110 Secure Element, and was then extended to the latest STM32 MCUs.
Infineon
Infineon have developed the Cirrent Cloud ID service to provision devices with a unique identity at scale. Cirrent is based on the Optiga Trust M Express secure element:
- The secure elements are pre-provisioned with certificates (Infineon act as a Certificate Authority).
- A QR code (on the reel of chips) enables binding of the chip to an OEM, establishing ownership.
- The OEM can import these certificates into a Cloud or can interface with a certificate authority.
Silicon Labs
Silicon Labs advertise a chip that received a PSA level 3 certification. Their view is to allow for early personalization of the chips. Therefore they have developed the Custom Part Manufacturing Service (CPMS), a secure provisioning service to allow device manufacturers to customise the hardware at the chip factory, from a dedicated web portal at the time of order.
With this approach, OEMs can provision their own certificates directly at the birth of the MCUs, among other useful personalisation services (see above), thus no longer needing to trust their contract manufacturers. Unlike other chipmakers who may propose custom services for high volume orders, Silicon Labs make these advanced personalisation features available to all.
Microchip
Microchip have a large portfolio of secure elements, especially the ATECC608 for IoT applications. These components can be personalised thanks to the Trust Platform Design Suite, that comes with four possible levels of customisation:
- Trust&GO: pre-configured and pre-provisioned secure element for Cloud authentication with generic certificates.
- TrustFLEX: pre-configured secure element with custom provisioning (including customer unique credentials as PKI, symmetric keys).
- TrustCUSTOM: Fully customisable secure element including custom provisioning.
- TrustMANAGER: a partnership with Kudelski to enable in-field provisioning and lifecycle management.
Trust&GO
Trust&GO generic certificates allow for (later) Cloud provisioning with Azure IoT or AWS IoT Core. But OEMs that want to setup their own PKI should use Trust Flex to provision dedicated certificates instead.
TrustMANAGER
TrustMANAGER combines Microchip ECC608 secure authentication IC with Kudelski IoT keySTREAM services. The main advantages for the OEM are the easy onboarding of the Root CA of its choice without having to deal with key materials, and the in-field provisioning feature.
Technically, Kudelski provide a dedicated agent that integrates in the MCU. This allows the IoT device to retrieve its operational certificate from the keySTREAM SaaS at the first connection in the field. Optionally, further PKI services can be seamlessly offered, such as certificates renewal or transfer of ownership.
Espressif
Espressif ESP32-xx chips and modules are widely used in various IoT sectors.
Nevertheless, we found no explicit procedure for identity provisioning at scale of their components, nor public information regarding the custom pre-provisioning services they provide upon request.
NXP
NXP make secure elements as well as Arm-based MCUs with embedded security, for which they provide two distinct provisioning schemes:
NXP EdgeLock 2GO
EdgeLock 2GO is the NXP service platform for provisioning and managing IoT devices based on the EdgeLock SE05x secure element.
Three options are proposed:
- Ready: secure element pre-provisioned with default keys and certificates.
- Custom: custom provisioning, download device certificates.
- Managed: OTA management of device identities, revocation, overproduction control.
With this platform, NXP handle the overall provisioning process (keys and certificates), from the silicon to the PKI. Certificate provisioning could be made at the chip factory, device factory, or in the field.
NXP extended the EdgeLock 2GO scope in March 2024:
- To let programming partners (e.g., Arrow Electronics, Avnet Silica, EBV Elektronik, EPS Global, Future Electronics) offer secure provisioning services based on the EdgeLock 2GO solution;
- By supporting not only secure elements, but also a series of NXP MPUs and MCUs.
NXP MCUXpresso Secure Provisioning Tool
Alongside their new generation of Arm-based MCUs (Cortex M33), NXP offers a dedicated provisioning tool. The MCUXpresso Secure Provisioning Tool allows for secure firmware, keys and certificates injection. Two options are available: Smart Card Trust Provisioning and Device HSM Trust Provisioning.
NXP Smart Card Trust Provisioning is a turnkey solution for OEMs to securely delegate device provisioning to contract manufacturers without a trusted environment. It also provides production limit control and a record of all device-unique certificates.
ST Micro
STM32 microcontrollers are provisioned at factory with a unique hardware identity, in the form of a device dedicated public/private keys (unique ECDSA key pair per device) and an X.509 certificate signed by STMicroelectronics.
STMicroelectronics have a strong focus on protecting OEMs against untrusted manufacturing environments: firmware IP protection, avoiding counterfeited or clone products as well as overproduction. This is the main objective of their STM32 Secure Firmware Installation framework, that rely on the chip unique keypair to individually pass the AES secret key encrypting the firmware.
However, STMicroelectronics do not propose secure provisioning services: they rely on partnerships with third-party pure players to assist OEMs on this topic and PKI, such as Kudelski IoT keySTREAM for their latest Arm Cortex M33-based MCU with STM32Trust TEE Secure Manager.
On the other hand, ST Microelectronics launched chip to Cloud initiatives (development of dedicated software packages) to plug their STM32H5 series MCUs into Microsoft Azure IoT Hub (Azure RTOS port) and Amazon AWS IoT Core (Amazon FreeRTOS integration). This should accelerate the provisioning of unique identity by relying on the device hardware security key. This feature was first introduced to work with the STSAFE-A110 Secure Element, and was then extended to the latest STM32 MCUs.
Infineon
Infineon have developed the Cirrent Cloud ID service to provision devices with a unique identity at scale. Cirrent is based on the Optiga Trust M Express secure element:
- The secure elements are pre-provisioned with certificates (Infineon act as a Certificate Authority).
- A QR code (on the reel of chips) enables binding of the chip to an OEM, establishing ownership.
- The OEM can import these certificates into a Cloud or can interface with a certificate authority.
Silicon Labs
Silicon Labs advertise a chip that received a PSA level 3 certification. Their view is to allow for early personalization of the chips. Therefore they have developed the Custom Part Manufacturing Service (CPMS), a secure provisioning service to allow device manufacturers to customise the hardware at the chip factory, from a dedicated web portal at the time of order.
With this approach, OEMs can provision their own certificates directly at the birth of the MCUs, among other useful personalisation services (see above), thus no longer needing to trust their contract manufacturers. Unlike other chipmakers who may propose custom services for high volume orders, Silicon Labs make these advanced personalisation features available to all.
Microchip
Microchip have a large portfolio of secure elements, especially the ATECC608 for IoT applications. These components can be personalised thanks to the Trust Platform Design Suite, that comes with four possible levels of customisation:
- Trust&GO: pre-configured and pre-provisioned secure element for Cloud authentication with generic certificates.
- TrustFLEX: pre-configured secure element with custom provisioning (including customer unique credentials as PKI, symmetric keys).
- TrustCUSTOM: Fully customisable secure element including custom provisioning.
- TrustMANAGER: a partnership with Kudelski to enable in-field provisioning and lifecycle management.
Trust&GO
Trust&GO generic certificates allow for (later) Cloud provisioning with Azure IoT or AWS IoT Core. But OEMs that want to setup their own PKI should use Trust Flex to provision dedicated certificates instead.
TrustMANAGER
TrustMANAGER combines Microchip ECC608 secure authentication IC with Kudelski IoT keySTREAM services. The main advantages for the OEM are the easy onboarding of the Root CA of its choice without having to deal with key materials, and the in-field provisioning feature.
Technically, Kudelski provide a dedicated agent that integrates in the MCU. This allows the IoT device to retrieve its operational certificate from the keySTREAM SaaS at the first connection in the field. Optionally, further PKI services can be seamlessly offered, such as certificates renewal or transfer of ownership.
Espressif
Espressif ESP32-xx chips and modules are widely used in various IoT sectors.
Nevertheless, we found no explicit procedure for identity provisioning at scale of their components, nor public information regarding the custom pre-provisioning services they provide upon request.
Cloud
Some Cloud service providers now propose services dedicated to IoT. They offer ways to provision IoT devices to Cloud services using X.509 certificates. They support PKI to manage operational identities and for on-field identity provisioning (device enrolment to PKI).
AWS IoT Core
AWS offer several options for device identity provisioning, allowing the device manufacturer to use its own (self-signed) PKI, a third-party CA or AWS Private CA.
Every device connected with AWS IoT Core is associated with:
- An IoT Thing: a Cloud-based representation of the physical device.
- An X.509 Certificate: containing the public key and identifier of the device.
- An IoT Policy: defining device authorisations.
More details are available in AWS whitepaper.
AWS architecture schemes are:
- Just-in-Time Provisioning (JITP) & Just-in-Time Registration (JITR)
- Multi-Account Registration without a CA
- Fleet Provisioning with CSR
- Zero-Touch Provisioning (ZTP)
JITP and JITR
For devices that are already provisioned with certificates signed with the OEMs designated CA and private keys before onboarding to AWS IoT. The CA must be registered in AWS IoT, and the target region must be known in advance.
Just-in Time Registration process (AWS)
With JITP the device is automatically registered at the first connection (according to a policy template), whereas JITR allows some custom logics (such as CRL check or association of a user to a device) before granting device activation.
Multi-Account Registration without a CA
Instead of registering a CA, every device certificate is individually registered in AWS IoT. This can be used for devices with chipmaker certificates pre-provisioned in the main chip or secure element. Certificates signatures are not checked.
Devices can be registered in one or many regions with the corresponding policy before the first connection.
Fleet Provisioning with CSR
AWS recently updated their architecture to integrate device hardware-based root identity (embedded asymmetric keypair) using the CSR workflow shown in the picture below. This is particularly interesting in the general case where devices are manufactured with a UDID and a keypair but do not contain an X.509 certificate.
Under this scheme, the provision by claim is the preferred sub-option, for which the device manufacturers must provision the UDID list of authorised devices into AWS IoT.
Fleet Provisioning with CSR process (AWS)
The choice of the CA is left open as explained by AWS: “The new self-managed certificate signing capability allows you to integrate with an external certificate authority, your own public key infrastructure, or popular CA services such as AWS Private CA, to sign certificate signing requests (CSRs) when provisioning your fleet.”
Zero-Touch Provisioning (ZTP)
AWS define a ZTP service provider as a third-party actor to whom the device manufacturer delegates key provisioning and PKI. ZTP vendors can interface with AWS IoT to support the certificate lifecycle management services through the customer AWS account.
Fleet Provisioning with CSR process (AWS)
This option presents several advantages:
- No need to know where the device will be connected at manufacturing.
- Automatic onboarding & registration per batch.
- Simplifies multiple AWS accounts.
The ZTP service provider is a trusted authority, responsible for registering devices to the OEMs AWS account and for other critical lifecycle operations such as factory reset, transfer of device ownership, or decommissioning.
Azure IoT
The Azure IoT Hub Device Provisioning Service (DPS) is Microsoft’s proposal for device provisioning into the Azure IoT platform. However, the DPS does not set a robust device unique identity: it considers that device authentication credentials (X.509 certificate) have been set upstream by the device manufacturer.
Note that zero trust provisioning of IoT devices at scale remains difficult to address with this solution.
Can you provision device certificates with Azure?
To be provisioned into Azure IoT Hub, an IoT device should already have an X.509 certificate installed. Microsoft do not provide an explicit way to start from a simple root identity UDID + asymmetric key pair (where the private key never leaves the secure hardware).
The Xboot open source project bridges this gap. It is not an end-to-end solution to use in production, but a reference client-server implementation to allow a device to generate an X.509 CSR. The client SDK sends a CSR with the device UDID and public key to the Azure server part that acts as a PKI server.
The server-side uses Azure KeyVault to handle the PKI root certificate (and to keep secret the private key used to sign device certificates).
Another open-source project offers a lightweight PKI for IoT using Azure KeyVault.
With this kind of development, a device manufacturer could generate and install individual X.509 certificates at scale on IoT devices without requiring a dedicated third-party PKI player. However, it seems less straightforward than with AWS Fleet Provisioning.
AWS IoT Core
AWS offer several options for device identity provisioning, allowing the device manufacturer to use its own (self-signed) PKI, a third-party CA or AWS Private CA.
Every device connected with AWS IoT Core is associated with:
- An IoT Thing: a Cloud-based representation of the physical device.
- An X.509 Certificate: containing the public key and identifier of the device.
- An IoT Policy: defining device authorisations.
More details are available in AWS whitepaper.
AWS architecture schemes are:
- Just-in-Time Provisioning (JITP) & Just-in-Time Registration (JITR)
- Multi-Account Registration without a CA
- Fleet Provisioning with CSR
- Zero-Touch Provisioning (ZTP)
JITP and JITR
For devices that are already provisioned with certificates signed with the OEMs designated CA and private keys before onboarding to AWS IoT. The CA must be registered in AWS IoT, and the target region must be known in advance.
Just-in Time Registration process (AWS)
With JITP the device is automatically registered at the first connection (according to a policy template), whereas JITR allows some custom logics (such as CRL check or association of a user to a device) before granting device activation.
Multi-Account Registration without a CA
Instead of registering a CA, every device certificate is individually registered in AWS IoT. This can be used for devices with chipmaker certificates pre-provisioned in the main chip or secure element. Certificates signatures are not checked.
Devices can be registered in one or many regions with the corresponding policy before the first connection.
Fleet Provisioning with CSR
AWS recently updated their architecture to integrate device hardware-based root identity (embedded asymmetric keypair) using the CSR workflow shown in the picture below. This is particularly interesting in the general case where devices are manufactured with a UDID and a keypair but do not contain an X.509 certificate.
Under this scheme, the provision by claim is the preferred sub-option, for which the device manufacturers must provision the UDID list of authorised devices into AWS IoT.
Fleet Provisioning with CSR process (AWS)
The choice of the CA is left open as explained by AWS: “The new self-managed certificate signing capability allows you to integrate with an external certificate authority, your own public key infrastructure, or popular CA services such as AWS Private CA, to sign certificate signing requests (CSRs) when provisioning your fleet.”
Zero-Touch Provisioning (ZTP)
AWS define a ZTP service provider as a third-party actor to whom the device manufacturer delegates key provisioning and PKI. ZTP vendors can interface with AWS IoT to support the certificate lifecycle management services through the customer AWS account.
Fleet Provisioning with CSR process (AWS)
This option presents several advantages:
- No need to know where the device will be connected at manufacturing.
- Automatic onboarding & registration per batch.
- Simplifies multiple AWS accounts.
The ZTP service provider is a trusted authority, responsible for registering devices to the OEMs AWS account and for other critical lifecycle operations such as factory reset, transfer of device ownership, or decommissioning.
Azure IoT
The Azure IoT Hub Device Provisioning Service (DPS) is Microsoft’s proposal for device provisioning into the Azure IoT platform. However, the DPS does not set a robust device unique identity: it considers that device authentication credentials (X.509 certificate) have been set upstream by the device manufacturer.
Note that zero trust provisioning of IoT devices at scale remains difficult to address with this solution.
Can you provision device certificates with Azure?
To be provisioned into Azure IoT Hub, an IoT device should already have an X.509 certificate installed. Microsoft do not provide an explicit way to start from a simple root identity UDID + asymmetric key pair (where the private key never leaves the secure hardware).
The Xboot open source project bridges this gap. It is not an end-to-end solution to use in production, but a reference client-server implementation to allow a device to generate an X.509 CSR. The client SDK sends a CSR with the device UDID and public key to the Azure server part that acts as a PKI server.
The server-side uses Azure KeyVault to handle the PKI root certificate (and to keep secret the private key used to sign device certificates).
Another open-source project offers a lightweight PKI for IoT using Azure KeyVault.
With this kind of development, a device manufacturer could generate and install individual X.509 certificates at scale on IoT devices without requiring a dedicated third-party PKI player. However, it seems less straightforward than with AWS Fleet Provisioning.
PKI Providers
OEMs will often consider delegating their PKI to a specialist unless they have strong in-house expertise. PKI management begins with issuing certificates to all entities involved in the system. An IoT device certificate must be bound to the hardware root identity through a CSR workflow to embed the device hardware public key in the certificate.
Many PKI providers offer a service for IoT certificates provisioning for locking the operational identity. This operation can occur at different stages:
- Early at chip manufacturing,
- At OEM facility,
- Just before shipping, or
- Later in the field at the device first connection.
This choice has no major impact on the overall security provided that the device hardware root keypair is set at chip manufacturing. If a device is present in the database containing authorised device IDs and corresponding public keys, then the device CSR is accepted and the CA can generate and send back the device certificate.
PKI protocols
Several protocols are generally supported by PKI providers for certificate request transmission, including EST (EST-CoaP for constrained devices), CMP, SCEP, ACME, and others. It should be noted that most of these protocols require the device public key to be embedded in a factory certificate.
Certificate management can be more complex involving intermediate certificates that can be used to differentiate production lines and/or to facilitate certificate batch revocation in case of future breach. Depending on the project needs, device certificates can be signed by the OEM (aka self-signed) or by a trusted Root Authority.
Note that this VORTEx does not detail the principles of hierarchical PKI nor certificate lifecycle management.
Some actors in the IoT field
Keyfactor
- PKI: EJBCA
- Certificate Lifecycle Management (CLM): Command for IoT
Nexus
Digicert
- IoT Trust Manager
- Commscope Sentry,
Kudelski
- IoT keyStream with a slightly different model to connect IoT devices to Cloud platforms. It provide an end-to-end solution with a secure client library and a server. Device identity provisioning and PKI management are completely delegated to Kudelski.
Ecosystems
Several ecosystems exist for provisioning a unique device identity on a specific context, including LwM2M, the GSMA IoT SAFE standard, non-cellular LPWAN specific cases, the offers from PUF IP providers, Matter, SandGrain and CryptoQuantique's QuarkLink.
LwM2M
The Open Mobile Alliance designed the Lightweight Machine-to-Machine (LwM2M) protocol for managing lightweight and resource-constrained devices in IoT deployments. LwM2M is a standardised way for device communication with management platforms, enabling functionalities such as remote device management, firmware updates, or data reporting.
LwM2M is mostly used in industrial IoT contexts, involving millions of battery-constrained cellular LPWAN devices such as water meters.
The Enrollment over Secure Transport (EST) protocol is used for securely provisioning and managing cryptographic credentials (e.g., X.509 certificates) in IoT devices. The Constrained Application Protocol (COAP) is a lightweight web transfer protocol designed for IoT scenarios with constrained nodes and networks.
When combining LwM2M with EST over CoAP, it is possible to establish a secure mechanism for retrieving unique device identities (X.509 certificates) anchored to public key pairs stored in the secure hardware of IoT devices.
A LwM2M implementation involves a server (LwM2M server) and a client (SDK or library). There are many commercial solutions available on the market today:
GSMA IoT SAFE
What is IoT SAFE?
The GSMA IoT SIM Applet For Secure End-2-End Communication (IoT SAFE) is a standard focused on managing device identities. It enables IoT device manufacturers and service providers to use the SIM (including the newest eSIM and iSIM form factors) as the hardware root of trust, The SIM can now serve to perform mutual (D)TLS authentication to any applicative service, through standardised APIs. The GSMA IoT SAFE standard should simplify provisioning and credential lifecycle management according to their whitepaper.
Kigen
Beyond IoT SAFE, Kigen have defined the Open IoT Safe zero-trust architecture as an extension of the GSMA standard with IETF Enrolment over Secure Transport (RFC 7030). Their goal is to simplify device provisioning and end-to-end integration from any device to any Cloud.
However, these initiatives do not seem to have gained much traction on the market yet.
LoRaWAN
LoRaWAN uses a symmetric authentication scheme. There are two methods for provisioning a device onto a LoRaWAN network: Activation by Personalisation (ABP) and Over-The-Air Activation (OTAA). The difference between these two methods is how the keys are handled. OTAA is more secure and should be preferred.
With OTAA, an activation workflow allows the device and the network to generate new security keys. The device is uniquely identified with a 64-bit globally-unique identifier (DevEUI) assigned by the manufacturer, and a device secret key (AppKey) must be shared with the head-end prior to the initial activation. This shared key will be used at both sides to derive an authentication key (NwkSKey) and an encryption key (AppSKey).
Each device must therefore be provisioned with a unique (DevEUI, AppKey) couple at manufacturing. A secure process must be defined to keep these secret keys confidential until devices are provisioned on a LoRaWAN network.
Sigfox
Device credentials in Sigfox are similar to LoRaWAN. They are defined by Unabiz (Sigfox owner since 2022). Manufacturers (chip or device) must pass the Sigfox certification and request device credentials to a Central Registration Authority who sends them back an encrypted file containing (device ID, key) pairs for the required number of devices. This information must then be provisioned at (chip or device) manufacturing, similarly to LoRaWAN.
PUF
Synopsys (Intrinsic ID)
The SRAM Physical Unclonable Function (PUF) is a cryptographic primitive that leverages the inherent variations in Static Random Access Memory (SRAM) cells to generate unique, device-specific keys. These keys are derived from the subtle manufacturing differences that exist between individual SRAM cells, making them impractical to replicate or predict.
SRAM PUF is adaptable to any SRAM. Unlike other key storage methods, SRAM PUF does not store keys in non-volatile memory. Instead, it generates them dynamically at boot time. This approach significantly reduces the risk of key exposure.
Synopsis proposes PUF-based security solutions for IoT devices. They offer two product lines: hardware and software IP.
- Quiddikey: a hardware IP family used by several silicon vendors (NXP, Microchip, Silicon Labs) in their secure chips to build a strong hardware root-of-trust and a hardware unique identity. Moreover, Quiddikey 300 obtained a PSA level-3 certification for the root-of-trust component.
- Zign: a software IP family targeting specific use-cases, such as late provisioning of hardware-based root identity. Zign makes it possible to fully separate IoT device identity provisioning from the chip manufacturing process. The setup process can take place later in the supply chain or on deployed devices (remote retrofit).
Intrinsic ID white paper provides more information on key provisioning with SRAM PUF.
Crypto Quantique
Crypto Quantique is another player in the PUF field. Instead of being based on SRAM, their PUF technology QDID PUF is based on quantum tunnelling and requires dedicated hardware. Unlike SRAM PUF, it cannot apply to existing chips.
Matter
Matter is a unified standard designed by the Connectivity Standard Alliance (CSA) to enhance interoperability and security of smart home devices, enabling seamless communication and integration within the IoT ecosystem.
Matter is conceived to be secure by design, requiring authentication of every device in the ecosystem via a certificate attesting their authenticity and identity.
In Matter, the PKI ensures secure communication between devices. Each Matter device must be provisioned at factory with a Device Attestation Certificate (DAC), that enforces its unique identity and genuineness. The Matter certification authority role is held by the CSA, who delegates the status of Product Attestation Authority (PAA) to selected organisations who become root certificate authorities, and in turn delegate the charge of issuing DACs to the devices to entities named Product Attestation Intermediate (PAI).
The Distributed Compliance Ledger (DCL) is a blockchain-based database that allows the CSA to update devices compliance state, and manufacturers to publish public information about their devices.
A dozen of organisations are certified as PAA, mainly PKI providers and silicon vendors. Matter identity provisioning is ideally realised at the chip factory and most vendors propose a dedicated service:
- NXP are an approved PAA and provide Matter DAC provisioning through their EdgeLock 2GO service infrastructure.
- ST Microelectronics delegate the Matter identity provisioning to a third-party PKI provider.
- Silicon Labs partner with Kudelski to generate DAC certificates within their CPMS provisioning infrastructure.
- Infineon also partner with Kudelski.
- Espressif claim to be an authorised PAA and propose a dedicated Matter pre-provisioning service.
Sandgrain
Unlike all other solutions presented in this VORTEx, SandGrain secures the unique device identity with a symmetric scheme.
The SandGrain solution has two components that work together:
- An original integrated circuit (IC), physically unique, that contains a unique identifier and a hardcoded authentication function.
- A server-side platform (CyberRock) that authenticates devices using their unique secret keys, through a back-end process based on HSMs.
The principles of the solution are the following:
- There is no key logistics to manage, as SandGrain generates and inserts a globally unique ID and private key in every IC, and doesn’t have to share these secrets with any other party.
- Every SandGrain IC is physically unique, with hardcoded key materials, as opposed to market secure elements, that are programmed with software keys. Hacking one device is necessarily destructive and doesn’t put the others at risk.
- The IC is connected to the MCU/MPU using a standard SPI bus offering two functions:
- What is your ID?
- Solve this challenge.
- Device authentication is delegated to the SandGrain authentication server (CyberRock), that connects to any service platform designed to interact with the devices, through a simple API.
- The design of the solution removes the need to set up a PKI, because the same symmetric key can be securely used for the entire product life.
In addition to providing a post-quantum resilient solution, using SandGrain might replace the need to deal with a series of partners such as PKI providers, manufacturing partners, chip vendors, integrators, etc.
Quarklink
Crypto Quantique QuarkLink is a client-server solution that can directly connect IoT devices to cloud-based applications from their root hardware public key. It includes device certificate generation and management.
Setting up and managing devices identities is a complex topic that requires a strong expertise, often involving several actors and suppliers throughout the product lifecycle. QuarkLink improves this status-quo on two fronts:
- In devices, the QuarkLink SDK acts as an abstraction layer to implement native hardware-based security functions, in partnership with several well-known chip vendors.
- In the cloud, the QuarkLink platform supersedes traditional Public Key Infrastructure (PKI) systems for device provisioning, on-boarding with third-party cloud services, and key management.
Devices are registered in the cloud-based QuarkLink platform before shipping. This platform uses individual certificates to manage authorisations throughout the whole product lifecycle (delivery, renewal, revocation).
Devices typically retrieve appropriate application certificates (e.g., AWS, Azure, MQTT) at first connection. It is also possible to issue short-lived certificates to force the renewal of trust.
Demos are available with STM32 and with Renesas.
LwM2M
The Open Mobile Alliance designed the Lightweight Machine-to-Machine (LwM2M) protocol for managing lightweight and resource-constrained devices in IoT deployments. LwM2M is a standardised way for device communication with management platforms, enabling functionalities such as remote device management, firmware updates, or data reporting.
LwM2M is mostly used in industrial IoT contexts, involving millions of battery-constrained cellular LPWAN devices such as water meters.
The Enrollment over Secure Transport (EST) protocol is used for securely provisioning and managing cryptographic credentials (e.g., X.509 certificates) in IoT devices. The Constrained Application Protocol (COAP) is a lightweight web transfer protocol designed for IoT scenarios with constrained nodes and networks.
When combining LwM2M with EST over CoAP, it is possible to establish a secure mechanism for retrieving unique device identities (X.509 certificates) anchored to public key pairs stored in the secure hardware of IoT devices.
A LwM2M implementation involves a server (LwM2M server) and a client (SDK or library). There are many commercial solutions available on the market today:
GSMA IoT SAFE
What is IoT SAFE?
The GSMA IoT SIM Applet For Secure End-2-End Communication (IoT SAFE) is a standard focused on managing device identities. It enables IoT device manufacturers and service providers to use the SIM (including the newest eSIM and iSIM form factors) as the hardware root of trust, The SIM can now serve to perform mutual (D)TLS authentication to any applicative service, through standardised APIs. The GSMA IoT SAFE standard should simplify provisioning and credential lifecycle management according to their whitepaper.
Kigen
Beyond IoT SAFE, Kigen have defined the Open IoT Safe zero-trust architecture as an extension of the GSMA standard with IETF Enrolment over Secure Transport (RFC 7030). Their goal is to simplify device provisioning and end-to-end integration from any device to any Cloud.
However, these initiatives do not seem to have gained much traction on the market yet.
LoRaWAN
LoRaWAN uses a symmetric authentication scheme. There are two methods for provisioning a device onto a LoRaWAN network: Activation by Personalisation (ABP) and Over-The-Air Activation (OTAA). The difference between these two methods is how the keys are handled. OTAA is more secure and should be preferred.
With OTAA, an activation workflow allows the device and the network to generate new security keys. The device is uniquely identified with a 64-bit globally-unique identifier (DevEUI) assigned by the manufacturer, and a device secret key (AppKey) must be shared with the head-end prior to the initial activation. This shared key will be used at both sides to derive an authentication key (NwkSKey) and an encryption key (AppSKey).
Each device must therefore be provisioned with a unique (DevEUI, AppKey) couple at manufacturing. A secure process must be defined to keep these secret keys confidential until devices are provisioned on a LoRaWAN network.
Sigfox
Device credentials in Sigfox are similar to LoRaWAN. They are defined by Unabiz (Sigfox owner since 2022). Manufacturers (chip or device) must pass the Sigfox certification and request device credentials to a Central Registration Authority who sends them back an encrypted file containing (device ID, key) pairs for the required number of devices. This information must then be provisioned at (chip or device) manufacturing, similarly to LoRaWAN.
PUF
Synopsys (Intrinsic ID)
The SRAM Physical Unclonable Function (PUF) is a cryptographic primitive that leverages the inherent variations in Static Random Access Memory (SRAM) cells to generate unique, device-specific keys. These keys are derived from the subtle manufacturing differences that exist between individual SRAM cells, making them impractical to replicate or predict.
SRAM PUF is adaptable to any SRAM. Unlike other key storage methods, SRAM PUF does not store keys in non-volatile memory. Instead, it generates them dynamically at boot time. This approach significantly reduces the risk of key exposure.
Synopsis proposes PUF-based security solutions for IoT devices. They offer two product lines: hardware and software IP.
- Quiddikey: a hardware IP family used by several silicon vendors (NXP, Microchip, Silicon Labs) in their secure chips to build a strong hardware root-of-trust and a hardware unique identity. Moreover, Quiddikey 300 obtained a PSA level-3 certification for the root-of-trust component.
- Zign: a software IP family targeting specific use-cases, such as late provisioning of hardware-based root identity. Zign makes it possible to fully separate IoT device identity provisioning from the chip manufacturing process. The setup process can take place later in the supply chain or on deployed devices (remote retrofit).
Intrinsic ID white paper provides more information on key provisioning with SRAM PUF.
Crypto Quantique
Crypto Quantique is another player in the PUF field. Instead of being based on SRAM, their PUF technology QDID PUF is based on quantum tunnelling and requires dedicated hardware. Unlike SRAM PUF, it cannot apply to existing chips.
Matter
Matter is a unified standard designed by the Connectivity Standard Alliance (CSA) to enhance interoperability and security of smart home devices, enabling seamless communication and integration within the IoT ecosystem.
Matter is conceived to be secure by design, requiring authentication of every device in the ecosystem via a certificate attesting their authenticity and identity.
In Matter, the PKI ensures secure communication between devices. Each Matter device must be provisioned at factory with a Device Attestation Certificate (DAC), that enforces its unique identity and genuineness. The Matter certification authority role is held by the CSA, who delegates the status of Product Attestation Authority (PAA) to selected organisations who become root certificate authorities, and in turn delegate the charge of issuing DACs to the devices to entities named Product Attestation Intermediate (PAI).
The Distributed Compliance Ledger (DCL) is a blockchain-based database that allows the CSA to update devices compliance state, and manufacturers to publish public information about their devices.
A dozen of organisations are certified as PAA, mainly PKI providers and silicon vendors. Matter identity provisioning is ideally realised at the chip factory and most vendors propose a dedicated service:
- NXP are an approved PAA and provide Matter DAC provisioning through their EdgeLock 2GO service infrastructure.
- ST Microelectronics delegate the Matter identity provisioning to a third-party PKI provider.
- Silicon Labs partner with Kudelski to generate DAC certificates within their CPMS provisioning infrastructure.
- Infineon also partner with Kudelski.
- Espressif claim to be an authorised PAA and propose a dedicated Matter pre-provisioning service.
Sandgrain
Unlike all other solutions presented in this VORTEx, SandGrain secures the unique device identity with a symmetric scheme.
The SandGrain solution has two components that work together:
- An original integrated circuit (IC), physically unique, that contains a unique identifier and a hardcoded authentication function.
- A server-side platform (CyberRock) that authenticates devices using their unique secret keys, through a back-end process based on HSMs.
The principles of the solution are the following:
- There is no key logistics to manage, as SandGrain generates and inserts a globally unique ID and private key in every IC, and doesn’t have to share these secrets with any other party.
- Every SandGrain IC is physically unique, with hardcoded key materials, as opposed to market secure elements, that are programmed with software keys. Hacking one device is necessarily destructive and doesn’t put the others at risk.
- The IC is connected to the MCU/MPU using a standard SPI bus offering two functions:
- What is your ID?
- Solve this challenge.
- Device authentication is delegated to the SandGrain authentication server (CyberRock), that connects to any service platform designed to interact with the devices, through a simple API.
- The design of the solution removes the need to set up a PKI, because the same symmetric key can be securely used for the entire product life.
In addition to providing a post-quantum resilient solution, using SandGrain might replace the need to deal with a series of partners such as PKI providers, manufacturing partners, chip vendors, integrators, etc.
Quarklink
Crypto Quantique QuarkLink is a client-server solution that can directly connect IoT devices to cloud-based applications from their root hardware public key. It includes device certificate generation and management.
Setting up and managing devices identities is a complex topic that requires a strong expertise, often involving several actors and suppliers throughout the product lifecycle. QuarkLink improves this status-quo on two fronts:
- In devices, the QuarkLink SDK acts as an abstraction layer to implement native hardware-based security functions, in partnership with several well-known chip vendors.
- In the cloud, the QuarkLink platform supersedes traditional Public Key Infrastructure (PKI) systems for device provisioning, on-boarding with third-party cloud services, and key management.
Devices are registered in the cloud-based QuarkLink platform before shipping. This platform uses individual certificates to manage authorisations throughout the whole product lifecycle (delivery, renewal, revocation).
Devices typically retrieve appropriate application certificates (e.g., AWS, Azure, MQTT) at first connection. It is also possible to issue short-lived certificates to force the renewal of trust.
Demos are available with STM32 and with Renesas.
Chipmakers
Chipmakers are moving towards providing chip/device unique operational identities. However, there are differences in their technical solutions and in which stage of supply chain they perform operational provisioning.
NXP
NXP make secure elements as well as Arm-based MCUs with embedded security, for which they provide two distinct provisioning schemes:
NXP EdgeLock 2GO
EdgeLock 2GO is the NXP service platform for provisioning and managing IoT devices based on the EdgeLock SE05x secure element.
Three options are proposed:
- Ready: secure element pre-provisioned with default keys and certificates.
- Custom: custom provisioning, download device certificates.
- Managed: OTA management of device identities, revocation, overproduction control.
With this platform, NXP handle the overall provisioning process (keys and certificates), from the silicon to the PKI. Certificate provisioning could be made at the chip factory, device factory, or in the field.
NXP extended the EdgeLock 2GO scope in March 2024:
- To let programming partners (e.g., Arrow Electronics, Avnet Silica, EBV Elektronik, EPS Global, Future Electronics) offer secure provisioning services based on the EdgeLock 2GO solution;
- By supporting not only secure elements, but also a series of NXP MPUs and MCUs.
NXP MCUXpresso Secure Provisioning Tool
Alongside their new generation of Arm-based MCUs (Cortex M33), NXP offers a dedicated provisioning tool. The MCUXpresso Secure Provisioning Tool allows for secure firmware, keys and certificates injection. Two options are available: Smart Card Trust Provisioning and Device HSM Trust Provisioning.
NXP Smart Card Trust Provisioning is a turnkey solution for OEMs to securely delegate device provisioning to contract manufacturers without a trusted environment. It also provides production limit control and a record of all device-unique certificates.
ST Micro
STM32 microcontrollers are provisioned at factory with a unique hardware identity, in the form of a device dedicated public/private keys (unique ECDSA key pair per device) and an X.509 certificate signed by STMicroelectronics.
STMicroelectronics have a strong focus on protecting OEMs against untrusted manufacturing environments: firmware IP protection, avoiding counterfeited or clone products as well as overproduction. This is the main objective of their STM32 Secure Firmware Installation framework, that rely on the chip unique keypair to individually pass the AES secret key encrypting the firmware.
However, STMicroelectronics do not propose secure provisioning services: they rely on partnerships with third-party pure players to assist OEMs on this topic and PKI, such as Kudelski IoT keySTREAM for their latest Arm Cortex M33-based MCU with STM32Trust TEE Secure Manager.
On the other hand, ST Microelectronics launched chip to Cloud initiatives (development of dedicated software packages) to plug their STM32H5 series MCUs into Microsoft Azure IoT Hub (Azure RTOS port) and Amazon AWS IoT Core (Amazon FreeRTOS integration). This should accelerate the provisioning of unique identity by relying on the device hardware security key. This feature was first introduced to work with the STSAFE-A110 Secure Element, and was then extended to the latest STM32 MCUs.
Infineon
Infineon have developed the Cirrent Cloud ID service to provision devices with a unique identity at scale. Cirrent is based on the Optiga Trust M Express secure element:
- The secure elements are pre-provisioned with certificates (Infineon act as a Certificate Authority).
- A QR code (on the reel of chips) enables binding of the chip to an OEM, establishing ownership.
- The OEM can import these certificates into a Cloud or can interface with a certificate authority.
Silicon Labs
Silicon Labs advertise a chip that received a PSA level 3 certification. Their view is to allow for early personalization of the chips. Therefore they have developed the Custom Part Manufacturing Service (CPMS), a secure provisioning service to allow device manufacturers to customise the hardware at the chip factory, from a dedicated web portal at the time of order.
With this approach, OEMs can provision their own certificates directly at the birth of the MCUs, among other useful personalisation services (see above), thus no longer needing to trust their contract manufacturers. Unlike other chipmakers who may propose custom services for high volume orders, Silicon Labs make these advanced personalisation features available to all.
Microchip
Microchip have a large portfolio of secure elements, especially the ATECC608 for IoT applications. These components can be personalised thanks to the Trust Platform Design Suite, that comes with four possible levels of customisation:
- Trust&GO: pre-configured and pre-provisioned secure element for Cloud authentication with generic certificates.
- TrustFLEX: pre-configured secure element with custom provisioning (including customer unique credentials as PKI, symmetric keys).
- TrustCUSTOM: Fully customisable secure element including custom provisioning.
- TrustMANAGER: a partnership with Kudelski to enable in-field provisioning and lifecycle management.
Trust&GO
Trust&GO generic certificates allow for (later) Cloud provisioning with Azure IoT or AWS IoT Core. But OEMs that want to setup their own PKI should use Trust Flex to provision dedicated certificates instead.
TrustMANAGER
TrustMANAGER combines Microchip ECC608 secure authentication IC with Kudelski IoT keySTREAM services. The main advantages for the OEM are the easy onboarding of the Root CA of its choice without having to deal with key materials, and the in-field provisioning feature.
Technically, Kudelski provide a dedicated agent that integrates in the MCU. This allows the IoT device to retrieve its operational certificate from the keySTREAM SaaS at the first connection in the field. Optionally, further PKI services can be seamlessly offered, such as certificates renewal or transfer of ownership.
Espressif
Espressif ESP32-xx chips and modules are widely used in various IoT sectors.
Nevertheless, we found no explicit procedure for identity provisioning at scale of their components, nor public information regarding the custom pre-provisioning services they provide upon request.
NXP
NXP make secure elements as well as Arm-based MCUs with embedded security, for which they provide two distinct provisioning schemes:
NXP EdgeLock 2GO
EdgeLock 2GO is the NXP service platform for provisioning and managing IoT devices based on the EdgeLock SE05x secure element.
Three options are proposed:
- Ready: secure element pre-provisioned with default keys and certificates.
- Custom: custom provisioning, download device certificates.
- Managed: OTA management of device identities, revocation, overproduction control.
With this platform, NXP handle the overall provisioning process (keys and certificates), from the silicon to the PKI. Certificate provisioning could be made at the chip factory, device factory, or in the field.
NXP extended the EdgeLock 2GO scope in March 2024:
- To let programming partners (e.g., Arrow Electronics, Avnet Silica, EBV Elektronik, EPS Global, Future Electronics) offer secure provisioning services based on the EdgeLock 2GO solution;
- By supporting not only secure elements, but also a series of NXP MPUs and MCUs.
NXP MCUXpresso Secure Provisioning Tool
Alongside their new generation of Arm-based MCUs (Cortex M33), NXP offers a dedicated provisioning tool. The MCUXpresso Secure Provisioning Tool allows for secure firmware, keys and certificates injection. Two options are available: Smart Card Trust Provisioning and Device HSM Trust Provisioning.
NXP Smart Card Trust Provisioning is a turnkey solution for OEMs to securely delegate device provisioning to contract manufacturers without a trusted environment. It also provides production limit control and a record of all device-unique certificates.
ST Micro
STM32 microcontrollers are provisioned at factory with a unique hardware identity, in the form of a device dedicated public/private keys (unique ECDSA key pair per device) and an X.509 certificate signed by STMicroelectronics.
STMicroelectronics have a strong focus on protecting OEMs against untrusted manufacturing environments: firmware IP protection, avoiding counterfeited or clone products as well as overproduction. This is the main objective of their STM32 Secure Firmware Installation framework, that rely on the chip unique keypair to individually pass the AES secret key encrypting the firmware.
However, STMicroelectronics do not propose secure provisioning services: they rely on partnerships with third-party pure players to assist OEMs on this topic and PKI, such as Kudelski IoT keySTREAM for their latest Arm Cortex M33-based MCU with STM32Trust TEE Secure Manager.
On the other hand, ST Microelectronics launched chip to Cloud initiatives (development of dedicated software packages) to plug their STM32H5 series MCUs into Microsoft Azure IoT Hub (Azure RTOS port) and Amazon AWS IoT Core (Amazon FreeRTOS integration). This should accelerate the provisioning of unique identity by relying on the device hardware security key. This feature was first introduced to work with the STSAFE-A110 Secure Element, and was then extended to the latest STM32 MCUs.
Infineon
Infineon have developed the Cirrent Cloud ID service to provision devices with a unique identity at scale. Cirrent is based on the Optiga Trust M Express secure element:
- The secure elements are pre-provisioned with certificates (Infineon act as a Certificate Authority).
- A QR code (on the reel of chips) enables binding of the chip to an OEM, establishing ownership.
- The OEM can import these certificates into a Cloud or can interface with a certificate authority.
Silicon Labs
Silicon Labs advertise a chip that received a PSA level 3 certification. Their view is to allow for early personalization of the chips. Therefore they have developed the Custom Part Manufacturing Service (CPMS), a secure provisioning service to allow device manufacturers to customise the hardware at the chip factory, from a dedicated web portal at the time of order.
With this approach, OEMs can provision their own certificates directly at the birth of the MCUs, among other useful personalisation services (see above), thus no longer needing to trust their contract manufacturers. Unlike other chipmakers who may propose custom services for high volume orders, Silicon Labs make these advanced personalisation features available to all.
Microchip
Microchip have a large portfolio of secure elements, especially the ATECC608 for IoT applications. These components can be personalised thanks to the Trust Platform Design Suite, that comes with four possible levels of customisation:
- Trust&GO: pre-configured and pre-provisioned secure element for Cloud authentication with generic certificates.
- TrustFLEX: pre-configured secure element with custom provisioning (including customer unique credentials as PKI, symmetric keys).
- TrustCUSTOM: Fully customisable secure element including custom provisioning.
- TrustMANAGER: a partnership with Kudelski to enable in-field provisioning and lifecycle management.
Trust&GO
Trust&GO generic certificates allow for (later) Cloud provisioning with Azure IoT or AWS IoT Core. But OEMs that want to setup their own PKI should use Trust Flex to provision dedicated certificates instead.
TrustMANAGER
TrustMANAGER combines Microchip ECC608 secure authentication IC with Kudelski IoT keySTREAM services. The main advantages for the OEM are the easy onboarding of the Root CA of its choice without having to deal with key materials, and the in-field provisioning feature.
Technically, Kudelski provide a dedicated agent that integrates in the MCU. This allows the IoT device to retrieve its operational certificate from the keySTREAM SaaS at the first connection in the field. Optionally, further PKI services can be seamlessly offered, such as certificates renewal or transfer of ownership.
Espressif
Espressif ESP32-xx chips and modules are widely used in various IoT sectors.
Nevertheless, we found no explicit procedure for identity provisioning at scale of their components, nor public information regarding the custom pre-provisioning services they provide upon request.
Cloud
Some Cloud service providers now propose services dedicated to IoT. They offer ways to provision IoT devices to Cloud services using X.509 certificates. They support PKI to manage operational identities and for on-field identity provisioning (device enrolment to PKI).
AWS IoT Core
AWS offer several options for device identity provisioning, allowing the device manufacturer to use its own (self-signed) PKI, a third-party CA or AWS Private CA.
Every device connected with AWS IoT Core is associated with:
- An IoT Thing: a Cloud-based representation of the physical device.
- An X.509 Certificate: containing the public key and identifier of the device.
- An IoT Policy: defining device authorisations.
More details are available in AWS whitepaper.
AWS architecture schemes are:
- Just-in-Time Provisioning (JITP) & Just-in-Time Registration (JITR)
- Multi-Account Registration without a CA
- Fleet Provisioning with CSR
- Zero-Touch Provisioning (ZTP)
JITP and JITR
For devices that are already provisioned with certificates signed with the OEMs designated CA and private keys before onboarding to AWS IoT. The CA must be registered in AWS IoT, and the target region must be known in advance.
Just-in Time Registration process (AWS)
With JITP the device is automatically registered at the first connection (according to a policy template), whereas JITR allows some custom logics (such as CRL check or association of a user to a device) before granting device activation.
Multi-Account Registration without a CA
Instead of registering a CA, every device certificate is individually registered in AWS IoT. This can be used for devices with chipmaker certificates pre-provisioned in the main chip or secure element. Certificates signatures are not checked.
Devices can be registered in one or many regions with the corresponding policy before the first connection.
Fleet Provisioning with CSR
AWS recently updated their architecture to integrate device hardware-based root identity (embedded asymmetric keypair) using the CSR workflow shown in the picture below. This is particularly interesting in the general case where devices are manufactured with a UDID and a keypair but do not contain an X.509 certificate.
Under this scheme, the provision by claim is the preferred sub-option, for which the device manufacturers must provision the UDID list of authorised devices into AWS IoT.
Fleet Provisioning with CSR process (AWS)
The choice of the CA is left open as explained by AWS: “The new self-managed certificate signing capability allows you to integrate with an external certificate authority, your own public key infrastructure, or popular CA services such as AWS Private CA, to sign certificate signing requests (CSRs) when provisioning your fleet.”
Zero-Touch Provisioning (ZTP)
AWS define a ZTP service provider as a third-party actor to whom the device manufacturer delegates key provisioning and PKI. ZTP vendors can interface with AWS IoT to support the certificate lifecycle management services through the customer AWS account.
Fleet Provisioning with CSR process (AWS)
This option presents several advantages:
- No need to know where the device will be connected at manufacturing.
- Automatic onboarding & registration per batch.
- Simplifies multiple AWS accounts.
The ZTP service provider is a trusted authority, responsible for registering devices to the OEMs AWS account and for other critical lifecycle operations such as factory reset, transfer of device ownership, or decommissioning.
Azure IoT
The Azure IoT Hub Device Provisioning Service (DPS) is Microsoft’s proposal for device provisioning into the Azure IoT platform. However, the DPS does not set a robust device unique identity: it considers that device authentication credentials (X.509 certificate) have been set upstream by the device manufacturer.
Note that zero trust provisioning of IoT devices at scale remains difficult to address with this solution.
Can you provision device certificates with Azure?
To be provisioned into Azure IoT Hub, an IoT device should already have an X.509 certificate installed. Microsoft do not provide an explicit way to start from a simple root identity UDID + asymmetric key pair (where the private key never leaves the secure hardware).
The Xboot open source project bridges this gap. It is not an end-to-end solution to use in production, but a reference client-server implementation to allow a device to generate an X.509 CSR. The client SDK sends a CSR with the device UDID and public key to the Azure server part that acts as a PKI server.
The server-side uses Azure KeyVault to handle the PKI root certificate (and to keep secret the private key used to sign device certificates).
Another open-source project offers a lightweight PKI for IoT using Azure KeyVault.
With this kind of development, a device manufacturer could generate and install individual X.509 certificates at scale on IoT devices without requiring a dedicated third-party PKI player. However, it seems less straightforward than with AWS Fleet Provisioning.
AWS IoT Core
AWS offer several options for device identity provisioning, allowing the device manufacturer to use its own (self-signed) PKI, a third-party CA or AWS Private CA.
Every device connected with AWS IoT Core is associated with:
- An IoT Thing: a Cloud-based representation of the physical device.
- An X.509 Certificate: containing the public key and identifier of the device.
- An IoT Policy: defining device authorisations.
More details are available in AWS whitepaper.
AWS architecture schemes are:
- Just-in-Time Provisioning (JITP) & Just-in-Time Registration (JITR)
- Multi-Account Registration without a CA
- Fleet Provisioning with CSR
- Zero-Touch Provisioning (ZTP)
JITP and JITR
For devices that are already provisioned with certificates signed with the OEMs designated CA and private keys before onboarding to AWS IoT. The CA must be registered in AWS IoT, and the target region must be known in advance.
Just-in Time Registration process (AWS)
With JITP the device is automatically registered at the first connection (according to a policy template), whereas JITR allows some custom logics (such as CRL check or association of a user to a device) before granting device activation.
Multi-Account Registration without a CA
Instead of registering a CA, every device certificate is individually registered in AWS IoT. This can be used for devices with chipmaker certificates pre-provisioned in the main chip or secure element. Certificates signatures are not checked.
Devices can be registered in one or many regions with the corresponding policy before the first connection.
Fleet Provisioning with CSR
AWS recently updated their architecture to integrate device hardware-based root identity (embedded asymmetric keypair) using the CSR workflow shown in the picture below. This is particularly interesting in the general case where devices are manufactured with a UDID and a keypair but do not contain an X.509 certificate.
Under this scheme, the provision by claim is the preferred sub-option, for which the device manufacturers must provision the UDID list of authorised devices into AWS IoT.
Fleet Provisioning with CSR process (AWS)
The choice of the CA is left open as explained by AWS: “The new self-managed certificate signing capability allows you to integrate with an external certificate authority, your own public key infrastructure, or popular CA services such as AWS Private CA, to sign certificate signing requests (CSRs) when provisioning your fleet.”
Zero-Touch Provisioning (ZTP)
AWS define a ZTP service provider as a third-party actor to whom the device manufacturer delegates key provisioning and PKI. ZTP vendors can interface with AWS IoT to support the certificate lifecycle management services through the customer AWS account.
Fleet Provisioning with CSR process (AWS)
This option presents several advantages:
- No need to know where the device will be connected at manufacturing.
- Automatic onboarding & registration per batch.
- Simplifies multiple AWS accounts.
The ZTP service provider is a trusted authority, responsible for registering devices to the OEMs AWS account and for other critical lifecycle operations such as factory reset, transfer of device ownership, or decommissioning.
Azure IoT
The Azure IoT Hub Device Provisioning Service (DPS) is Microsoft’s proposal for device provisioning into the Azure IoT platform. However, the DPS does not set a robust device unique identity: it considers that device authentication credentials (X.509 certificate) have been set upstream by the device manufacturer.
Note that zero trust provisioning of IoT devices at scale remains difficult to address with this solution.
Can you provision device certificates with Azure?
To be provisioned into Azure IoT Hub, an IoT device should already have an X.509 certificate installed. Microsoft do not provide an explicit way to start from a simple root identity UDID + asymmetric key pair (where the private key never leaves the secure hardware).
The Xboot open source project bridges this gap. It is not an end-to-end solution to use in production, but a reference client-server implementation to allow a device to generate an X.509 CSR. The client SDK sends a CSR with the device UDID and public key to the Azure server part that acts as a PKI server.
The server-side uses Azure KeyVault to handle the PKI root certificate (and to keep secret the private key used to sign device certificates).
Another open-source project offers a lightweight PKI for IoT using Azure KeyVault.
With this kind of development, a device manufacturer could generate and install individual X.509 certificates at scale on IoT devices without requiring a dedicated third-party PKI player. However, it seems less straightforward than with AWS Fleet Provisioning.
PKI Providers
OEMs will often consider delegating their PKI to a specialist unless they have strong in-house expertise. PKI management begins with issuing certificates to all entities involved in the system. An IoT device certificate must be bound to the hardware root identity through a CSR workflow to embed the device hardware public key in the certificate.
Many PKI providers offer a service for IoT certificates provisioning for locking the operational identity. This operation can occur at different stages:
- Early at chip manufacturing,
- At OEM facility,
- Just before shipping, or
- Later in the field at the device first connection.
This choice has no major impact on the overall security provided that the device hardware root keypair is set at chip manufacturing. If a device is present in the database containing authorised device IDs and corresponding public keys, then the device CSR is accepted and the CA can generate and send back the device certificate.
PKI protocols
Several protocols are generally supported by PKI providers for certificate request transmission, including EST (EST-CoaP for constrained devices), CMP, SCEP, ACME, and others. It should be noted that most of these protocols require the device public key to be embedded in a factory certificate.
Certificate management can be more complex involving intermediate certificates that can be used to differentiate production lines and/or to facilitate certificate batch revocation in case of future breach. Depending on the project needs, device certificates can be signed by the OEM (aka self-signed) or by a trusted Root Authority.
Note that this VORTEx does not detail the principles of hierarchical PKI nor certificate lifecycle management.
Some actors in the IoT field
Keyfactor
- PKI: EJBCA
- Certificate Lifecycle Management (CLM): Command for IoT
Nexus
Digicert
- IoT Trust Manager
- Commscope Sentry,
Kudelski
- IoT keyStream with a slightly different model to connect IoT devices to Cloud platforms. It provide an end-to-end solution with a secure client library and a server. Device identity provisioning and PKI management are completely delegated to Kudelski.
Ecosystems
Several ecosystems exist for provisioning a unique device identity on a specific context, including LwM2M, the GSMA IoT SAFE standard, non-cellular LPWAN specific cases, the offers from PUF IP providers, Matter, SandGrain and CryptoQuantique's QuarkLink.
LwM2M
The Open Mobile Alliance designed the Lightweight Machine-to-Machine (LwM2M) protocol for managing lightweight and resource-constrained devices in IoT deployments. LwM2M is a standardised way for device communication with management platforms, enabling functionalities such as remote device management, firmware updates, or data reporting.
LwM2M is mostly used in industrial IoT contexts, involving millions of battery-constrained cellular LPWAN devices such as water meters.
The Enrollment over Secure Transport (EST) protocol is used for securely provisioning and managing cryptographic credentials (e.g., X.509 certificates) in IoT devices. The Constrained Application Protocol (COAP) is a lightweight web transfer protocol designed for IoT scenarios with constrained nodes and networks.
When combining LwM2M with EST over CoAP, it is possible to establish a secure mechanism for retrieving unique device identities (X.509 certificates) anchored to public key pairs stored in the secure hardware of IoT devices.
A LwM2M implementation involves a server (LwM2M server) and a client (SDK or library). There are many commercial solutions available on the market today:
GSMA IoT SAFE
What is IoT SAFE?
The GSMA IoT SIM Applet For Secure End-2-End Communication (IoT SAFE) is a standard focused on managing device identities. It enables IoT device manufacturers and service providers to use the SIM (including the newest eSIM and iSIM form factors) as the hardware root of trust, The SIM can now serve to perform mutual (D)TLS authentication to any applicative service, through standardised APIs. The GSMA IoT SAFE standard should simplify provisioning and credential lifecycle management according to their whitepaper.
Kigen
Beyond IoT SAFE, Kigen have defined the Open IoT Safe zero-trust architecture as an extension of the GSMA standard with IETF Enrolment over Secure Transport (RFC 7030). Their goal is to simplify device provisioning and end-to-end integration from any device to any Cloud.
However, these initiatives do not seem to have gained much traction on the market yet.
LoRaWAN
LoRaWAN uses a symmetric authentication scheme. There are two methods for provisioning a device onto a LoRaWAN network: Activation by Personalisation (ABP) and Over-The-Air Activation (OTAA). The difference between these two methods is how the keys are handled. OTAA is more secure and should be preferred.
With OTAA, an activation workflow allows the device and the network to generate new security keys. The device is uniquely identified with a 64-bit globally-unique identifier (DevEUI) assigned by the manufacturer, and a device secret key (AppKey) must be shared with the head-end prior to the initial activation. This shared key will be used at both sides to derive an authentication key (NwkSKey) and an encryption key (AppSKey).
Each device must therefore be provisioned with a unique (DevEUI, AppKey) couple at manufacturing. A secure process must be defined to keep these secret keys confidential until devices are provisioned on a LoRaWAN network.
Sigfox
Device credentials in Sigfox are similar to LoRaWAN. They are defined by Unabiz (Sigfox owner since 2022). Manufacturers (chip or device) must pass the Sigfox certification and request device credentials to a Central Registration Authority who sends them back an encrypted file containing (device ID, key) pairs for the required number of devices. This information must then be provisioned at (chip or device) manufacturing, similarly to LoRaWAN.
PUF
Synopsys (Intrinsic ID)
The SRAM Physical Unclonable Function (PUF) is a cryptographic primitive that leverages the inherent variations in Static Random Access Memory (SRAM) cells to generate unique, device-specific keys. These keys are derived from the subtle manufacturing differences that exist between individual SRAM cells, making them impractical to replicate or predict.
SRAM PUF is adaptable to any SRAM. Unlike other key storage methods, SRAM PUF does not store keys in non-volatile memory. Instead, it generates them dynamically at boot time. This approach significantly reduces the risk of key exposure.
Synopsis proposes PUF-based security solutions for IoT devices. They offer two product lines: hardware and software IP.
- Quiddikey: a hardware IP family used by several silicon vendors (NXP, Microchip, Silicon Labs) in their secure chips to build a strong hardware root-of-trust and a hardware unique identity. Moreover, Quiddikey 300 obtained a PSA level-3 certification for the root-of-trust component.
- Zign: a software IP family targeting specific use-cases, such as late provisioning of hardware-based root identity. Zign makes it possible to fully separate IoT device identity provisioning from the chip manufacturing process. The setup process can take place later in the supply chain or on deployed devices (remote retrofit).
Intrinsic ID white paper provides more information on key provisioning with SRAM PUF.
Crypto Quantique
Crypto Quantique is another player in the PUF field. Instead of being based on SRAM, their PUF technology QDID PUF is based on quantum tunnelling and requires dedicated hardware. Unlike SRAM PUF, it cannot apply to existing chips.
Matter
Matter is a unified standard designed by the Connectivity Standard Alliance (CSA) to enhance interoperability and security of smart home devices, enabling seamless communication and integration within the IoT ecosystem.
Matter is conceived to be secure by design, requiring authentication of every device in the ecosystem via a certificate attesting their authenticity and identity.
In Matter, the PKI ensures secure communication between devices. Each Matter device must be provisioned at factory with a Device Attestation Certificate (DAC), that enforces its unique identity and genuineness. The Matter certification authority role is held by the CSA, who delegates the status of Product Attestation Authority (PAA) to selected organisations who become root certificate authorities, and in turn delegate the charge of issuing DACs to the devices to entities named Product Attestation Intermediate (PAI).
The Distributed Compliance Ledger (DCL) is a blockchain-based database that allows the CSA to update devices compliance state, and manufacturers to publish public information about their devices.
A dozen of organisations are certified as PAA, mainly PKI providers and silicon vendors. Matter identity provisioning is ideally realised at the chip factory and most vendors propose a dedicated service:
- NXP are an approved PAA and provide Matter DAC provisioning through their EdgeLock 2GO service infrastructure.
- ST Microelectronics delegate the Matter identity provisioning to a third-party PKI provider.
- Silicon Labs partner with Kudelski to generate DAC certificates within their CPMS provisioning infrastructure.
- Infineon also partner with Kudelski.
- Espressif claim to be an authorised PAA and propose a dedicated Matter pre-provisioning service.
Sandgrain
Unlike all other solutions presented in this VORTEx, SandGrain secures the unique device identity with a symmetric scheme.
The SandGrain solution has two components that work together:
- An original integrated circuit (IC), physically unique, that contains a unique identifier and a hardcoded authentication function.
- A server-side platform (CyberRock) that authenticates devices using their unique secret keys, through a back-end process based on HSMs.
The principles of the solution are the following:
- There is no key logistics to manage, as SandGrain generates and inserts a globally unique ID and private key in every IC, and doesn’t have to share these secrets with any other party.
- Every SandGrain IC is physically unique, with hardcoded key materials, as opposed to market secure elements, that are programmed with software keys. Hacking one device is necessarily destructive and doesn’t put the others at risk.
- The IC is connected to the MCU/MPU using a standard SPI bus offering two functions:
- What is your ID?
- Solve this challenge.
- Device authentication is delegated to the SandGrain authentication server (CyberRock), that connects to any service platform designed to interact with the devices, through a simple API.
- The design of the solution removes the need to set up a PKI, because the same symmetric key can be securely used for the entire product life.
In addition to providing a post-quantum resilient solution, using SandGrain might replace the need to deal with a series of partners such as PKI providers, manufacturing partners, chip vendors, integrators, etc.
Quarklink
Crypto Quantique QuarkLink is a client-server solution that can directly connect IoT devices to cloud-based applications from their root hardware public key. It includes device certificate generation and management.
Setting up and managing devices identities is a complex topic that requires a strong expertise, often involving several actors and suppliers throughout the product lifecycle. QuarkLink improves this status-quo on two fronts:
- In devices, the QuarkLink SDK acts as an abstraction layer to implement native hardware-based security functions, in partnership with several well-known chip vendors.
- In the cloud, the QuarkLink platform supersedes traditional Public Key Infrastructure (PKI) systems for device provisioning, on-boarding with third-party cloud services, and key management.
Devices are registered in the cloud-based QuarkLink platform before shipping. This platform uses individual certificates to manage authorisations throughout the whole product lifecycle (delivery, renewal, revocation).
Devices typically retrieve appropriate application certificates (e.g., AWS, Azure, MQTT) at first connection. It is also possible to issue short-lived certificates to force the renewal of trust.
Demos are available with STM32 and with Renesas.
LwM2M
The Open Mobile Alliance designed the Lightweight Machine-to-Machine (LwM2M) protocol for managing lightweight and resource-constrained devices in IoT deployments. LwM2M is a standardised way for device communication with management platforms, enabling functionalities such as remote device management, firmware updates, or data reporting.
LwM2M is mostly used in industrial IoT contexts, involving millions of battery-constrained cellular LPWAN devices such as water meters.
The Enrollment over Secure Transport (EST) protocol is used for securely provisioning and managing cryptographic credentials (e.g., X.509 certificates) in IoT devices. The Constrained Application Protocol (COAP) is a lightweight web transfer protocol designed for IoT scenarios with constrained nodes and networks.
When combining LwM2M with EST over CoAP, it is possible to establish a secure mechanism for retrieving unique device identities (X.509 certificates) anchored to public key pairs stored in the secure hardware of IoT devices.
A LwM2M implementation involves a server (LwM2M server) and a client (SDK or library). There are many commercial solutions available on the market today:
GSMA IoT SAFE
What is IoT SAFE?
The GSMA IoT SIM Applet For Secure End-2-End Communication (IoT SAFE) is a standard focused on managing device identities. It enables IoT device manufacturers and service providers to use the SIM (including the newest eSIM and iSIM form factors) as the hardware root of trust, The SIM can now serve to perform mutual (D)TLS authentication to any applicative service, through standardised APIs. The GSMA IoT SAFE standard should simplify provisioning and credential lifecycle management according to their whitepaper.
Kigen
Beyond IoT SAFE, Kigen have defined the Open IoT Safe zero-trust architecture as an extension of the GSMA standard with IETF Enrolment over Secure Transport (RFC 7030). Their goal is to simplify device provisioning and end-to-end integration from any device to any Cloud.
However, these initiatives do not seem to have gained much traction on the market yet.
LoRaWAN
LoRaWAN uses a symmetric authentication scheme. There are two methods for provisioning a device onto a LoRaWAN network: Activation by Personalisation (ABP) and Over-The-Air Activation (OTAA). The difference between these two methods is how the keys are handled. OTAA is more secure and should be preferred.
With OTAA, an activation workflow allows the device and the network to generate new security keys. The device is uniquely identified with a 64-bit globally-unique identifier (DevEUI) assigned by the manufacturer, and a device secret key (AppKey) must be shared with the head-end prior to the initial activation. This shared key will be used at both sides to derive an authentication key (NwkSKey) and an encryption key (AppSKey).
Each device must therefore be provisioned with a unique (DevEUI, AppKey) couple at manufacturing. A secure process must be defined to keep these secret keys confidential until devices are provisioned on a LoRaWAN network.
Sigfox
Device credentials in Sigfox are similar to LoRaWAN. They are defined by Unabiz (Sigfox owner since 2022). Manufacturers (chip or device) must pass the Sigfox certification and request device credentials to a Central Registration Authority who sends them back an encrypted file containing (device ID, key) pairs for the required number of devices. This information must then be provisioned at (chip or device) manufacturing, similarly to LoRaWAN.
PUF
Synopsys (Intrinsic ID)
The SRAM Physical Unclonable Function (PUF) is a cryptographic primitive that leverages the inherent variations in Static Random Access Memory (SRAM) cells to generate unique, device-specific keys. These keys are derived from the subtle manufacturing differences that exist between individual SRAM cells, making them impractical to replicate or predict.
SRAM PUF is adaptable to any SRAM. Unlike other key storage methods, SRAM PUF does not store keys in non-volatile memory. Instead, it generates them dynamically at boot time. This approach significantly reduces the risk of key exposure.
Synopsis proposes PUF-based security solutions for IoT devices. They offer two product lines: hardware and software IP.
- Quiddikey: a hardware IP family used by several silicon vendors (NXP, Microchip, Silicon Labs) in their secure chips to build a strong hardware root-of-trust and a hardware unique identity. Moreover, Quiddikey 300 obtained a PSA level-3 certification for the root-of-trust component.
- Zign: a software IP family targeting specific use-cases, such as late provisioning of hardware-based root identity. Zign makes it possible to fully separate IoT device identity provisioning from the chip manufacturing process. The setup process can take place later in the supply chain or on deployed devices (remote retrofit).
Intrinsic ID white paper provides more information on key provisioning with SRAM PUF.
Crypto Quantique
Crypto Quantique is another player in the PUF field. Instead of being based on SRAM, their PUF technology QDID PUF is based on quantum tunnelling and requires dedicated hardware. Unlike SRAM PUF, it cannot apply to existing chips.
Matter
Matter is a unified standard designed by the Connectivity Standard Alliance (CSA) to enhance interoperability and security of smart home devices, enabling seamless communication and integration within the IoT ecosystem.
Matter is conceived to be secure by design, requiring authentication of every device in the ecosystem via a certificate attesting their authenticity and identity.
In Matter, the PKI ensures secure communication between devices. Each Matter device must be provisioned at factory with a Device Attestation Certificate (DAC), that enforces its unique identity and genuineness. The Matter certification authority role is held by the CSA, who delegates the status of Product Attestation Authority (PAA) to selected organisations who become root certificate authorities, and in turn delegate the charge of issuing DACs to the devices to entities named Product Attestation Intermediate (PAI).
The Distributed Compliance Ledger (DCL) is a blockchain-based database that allows the CSA to update devices compliance state, and manufacturers to publish public information about their devices.
A dozen of organisations are certified as PAA, mainly PKI providers and silicon vendors. Matter identity provisioning is ideally realised at the chip factory and most vendors propose a dedicated service:
- NXP are an approved PAA and provide Matter DAC provisioning through their EdgeLock 2GO service infrastructure.
- ST Microelectronics delegate the Matter identity provisioning to a third-party PKI provider.
- Silicon Labs partner with Kudelski to generate DAC certificates within their CPMS provisioning infrastructure.
- Infineon also partner with Kudelski.
- Espressif claim to be an authorised PAA and propose a dedicated Matter pre-provisioning service.
Sandgrain
Unlike all other solutions presented in this VORTEx, SandGrain secures the unique device identity with a symmetric scheme.
The SandGrain solution has two components that work together:
- An original integrated circuit (IC), physically unique, that contains a unique identifier and a hardcoded authentication function.
- A server-side platform (CyberRock) that authenticates devices using their unique secret keys, through a back-end process based on HSMs.
The principles of the solution are the following:
- There is no key logistics to manage, as SandGrain generates and inserts a globally unique ID and private key in every IC, and doesn’t have to share these secrets with any other party.
- Every SandGrain IC is physically unique, with hardcoded key materials, as opposed to market secure elements, that are programmed with software keys. Hacking one device is necessarily destructive and doesn’t put the others at risk.
- The IC is connected to the MCU/MPU using a standard SPI bus offering two functions:
- What is your ID?
- Solve this challenge.
- Device authentication is delegated to the SandGrain authentication server (CyberRock), that connects to any service platform designed to interact with the devices, through a simple API.
- The design of the solution removes the need to set up a PKI, because the same symmetric key can be securely used for the entire product life.
In addition to providing a post-quantum resilient solution, using SandGrain might replace the need to deal with a series of partners such as PKI providers, manufacturing partners, chip vendors, integrators, etc.
Quarklink
Crypto Quantique QuarkLink is a client-server solution that can directly connect IoT devices to cloud-based applications from their root hardware public key. It includes device certificate generation and management.
Setting up and managing devices identities is a complex topic that requires a strong expertise, often involving several actors and suppliers throughout the product lifecycle. QuarkLink improves this status-quo on two fronts:
- In devices, the QuarkLink SDK acts as an abstraction layer to implement native hardware-based security functions, in partnership with several well-known chip vendors.
- In the cloud, the QuarkLink platform supersedes traditional Public Key Infrastructure (PKI) systems for device provisioning, on-boarding with third-party cloud services, and key management.
Devices are registered in the cloud-based QuarkLink platform before shipping. This platform uses individual certificates to manage authorisations throughout the whole product lifecycle (delivery, renewal, revocation).
Devices typically retrieve appropriate application certificates (e.g., AWS, Azure, MQTT) at first connection. It is also possible to issue short-lived certificates to force the renewal of trust.
Demos are available with STM32 and with Renesas.
Recommendations
We propose several recommendations to secure a unique device identity for IoT devices.
R1. Keep secrets... secret
The attestability of identity relies on the confidential preservation of a secret by the device and its non-clonability. Both hardware and software means are necessary to ensure these properties (hardware root of trust).
A rigorous manufacturing process is required to assign a unique identifier…
R2. Use best practice cryptography
The universally recommended solution is to use asymmetric cryptography, where a unique key pair is defined for each device, with the private key never leaving the device. The corresponding public key, associated with an identifier, authenticates the device without needing to entrust a dedicated secret to each entity needing to communicate with the device (e.g., Cloud service).
The first step, during manufacturing, is to provision a unique private key into the secure chip of each device along with the corresponding public key and identifier.
The CSR mechanism subsequently allows the device to request a trusted authority to return a signed certificate attesting its identity, based on its identifier and associated public key.
Various protocols implement this certificate generation mechanism (EST, EST-CoaP, ACME, CMP, SCEP) and can be implemented by PKI service providers.
The use of best practice cryptography is a key requirement of IoT security regulations. For that purpose, symmetric cryptographic schemes (e.g., pre-shared keys) are generally not recommended due to higher operational constraints and/or lower security levels.
R3. Define roles and responsibilities around identity provisioning
Identity provisioning can be performed at various levels depending on the use case: at the chipmaker, the contract manufacturer, just before shipping, or even upon the device first use. Before the certificate is created on the device, the integrity of the list of identifier/public key pairs of valid devices ensures its authenticity.
Market evolution opens up safer, operationally simpler, and less costly solutions, from device manufacturing to its deployment on the Cloud. The partners to consider for constructing the solution primarily include chipmakers, PKI service providers, and Cloud service providers.
Device manufacturers must define the responsibilities of their partners throughout the device lifecycle according to their use case and security requirements.
R4. Leverage external expertise to secure unique device identity
Most issues with device identity arise due to insecure processes or inadequate protection of secrets. To reduce these risks, product manufacturers should avoid reinventing the wheel with home-made solutions. This VORTEx has listed several commercial solutions available on the market to assign and manage unique device identities throughout the product lifecycle.
We strongly recommend customising the chip before product manufacturing, at least to insert the signature key in OTP and lock the immutable bootloader. It is straightforward and inexpensive to take advantage of this step to inject the identity certificate at this level. Furthermore, chipmakers now offer services to streamline these operations, even for low volumes. This requires the ability to interface with the trusted authority at this level for certificate signing.
On the other hand, if there is a need for decoupling production and deployment, it is preferable to wait for shipment or initial deployment to assign an operational certificate to the device. For instance, when chips or devices have different destinations or are not intended to be connected to the same platforms and/or services. The architectures proposed by Cloud providers allow for these scenarios, with or without an external PKI provider. In the absence of advanced PKI requirements, this approach still allows for simple and rapid implementations.
Acknowledgements
We would like to acknowledge all experts who helped us with their insight and their review of this VORTEx.
Future work
To continue this study, it would be interesting to keep track of the market offering on unique device identity. This includes new chips, new protocols and potentially new business models.
Another point of interest is the rise of post-quantum cryptography, and the ways it could help securing the unique device identity.
Additionally, the results of this study could contribute to assessing the maturity level of IoT products and of their manufacturers.
Conclusions
In this first VORTEx, we explored several options to assign a unique identity to IoT devices. Identity provisioning remains a difficult task: it is important to select and use security components securely throughout the device lifecycle. This requires a secure architecture and robust processes, in particular for initial device provisioning and for secure updates.
For that purpose, device manufacturers must implement the following pre-requisites:
- Select secure components: devices must rely on a secure chip with a built-in unique hardware root identity (embedded private key, associated ID + public key provided).
- Define component programming and provisioning needs: this requires an immutable bootloader and public key for firmware signing, and possibly specific keys and configuration. Modalities depend on the chipmaker offerings.
- Secure critical manufacturing processes: in particular for firmware loading, setting to production state after tests, etc. This requires investment in people, policies, processes and tools.
- Choose a PKI ecosystem: it could be in-house or via the integration of a third-party certificate authority. This choice should be based on targeted services and consider the complete device lifecycle (including second-hand and end-of-life).
- Define the modalities for issuing the operational identity certificates: according to the desired decoupling between manufacturing and deployment, and provisioning flexibility. This will depend on the partners chosen for the previous pre-requisites: chipmaker (available options), contract manufacturer (trust, complexity, factory connectivity, cost), PKI (proposed modalities, online/offline, Cloud integration, production line HSM integration) and target Cloud platform (available options).
In conclusion, once a secure chip with a hardware root identity is chosen, the critical point is to maintain control over the chip list (ID, public key) used for tracking products until they are provided with an operational certificate signed by the chosen trusted authority. The key is to embed an identity certificate into the hardware, with differences between solutions lying in cost, simplicity, and flexibility.
Annex 1: compliance mapping with IoT cyber security standards
This annex presents how the solutions presented in this VORTEx can enable compliance with the requirements of IoT product cyber security standards: EN 18031, EN 303 645, NIST IR 8259A (used by the US Cyber Trust Mark) and ISA/IEC 62443-4-2.
Having a unique device identity is a core requirement in these standards. It can also serve as a pre-requisite to comply with other requirements of these standards.
Unique device identity: mapping with EN 18031
| EN 18031 | Core requirement | Pre-requisites |
|---|---|---|
| [ACM] Access control mechanism | [ACM-1] A unique identity allows efficient access control of devices communicating with service platforms. | [ACM-2] In some cases, a unique device debug key could be provisioned together with the device unique identity, that could contribute to restricting access to selected assets to authorised personnel (e.g., for RMA). |
| [SUM] Secure update mechanism | - | [SUM-2] A unique identity enables authenticating the source of a firmware update and ensuring the update is meant for the specific device, supporting a secure update trust chain. |
| [SSM] Secure storage mechanism | - | [SSM-3] Provisioning a unique identity usually involves secure key/certificate storage, using a unique encryption key. This supports the protection of confidentiality and integrity for sensitive data at rest. |
| [SCM] Secure communication mechanism | [SCM-1] A unique identity enables negotiation of secure protocols like TLS/DTLS and ensures mutual authentication. | - |
| [CCK] Confidential cryptographic keys | [CCK-3] A unique identity typically comes with a unique key pair, which directly answers the requirement of no static/default preinstalled values. | [CCK-1] A unique identity is expressed via securely provisioned CCKs, uniquely bound to each device. |
| [CRY] Cryptography | - | [CRY-1] The concept of unique identity is based on cryptographic best practices. |
Unique device identity: mapping with EN 303 645 v3.1.3
| EN 303 645 | Core requirement | Pre-requisite |
|---|---|---|
| 5.3 Keep software updated | - | 5.3-10 Device authentication allows to only deliver firmware updates to valid devices, thus ensuring IP confidentiality. 5.3-16 Individual identification of the device goes beyond the requirement of model designation. |
| 5.4 Securely store sensitive security parameters | 5.4-2 Hardware root identity resists tampering by design. 5.4-4 Unique identity derives into unique critical security parameters. |
5.4-1 Root identity shall be securely stored in the device. 5.4-3 An individualised device key can be efficiently derived to protect any critical security parameters. |
| 5.5 Communicate securely | 5.5-1 Secure communications require mutual authentication (e.g., mTLS). 5.5-6 Mutual authentication allow to securely set encryption keys used to protect the communication channel. 5.5-7 Confidentiality of remotely-accessible critical security parameters can only be ensured with authenticated devices. 5.5-8 Identity provisioning is at the core of secure management processes for critical security parameters. |
5.5-2 Strong hardware and software implementations are required for assigning a robust unique identity. |
| 5.9 Make system resilient to outages | - | 5.9-3 Allowing only authenticated devices to communicate with a service reduces the risk of DdoS. |
| 5.12 Make installation and maintenance of devices easy | - | 5.12-1 Uniquely identified devices can be more securely and simply maintained. |
Unique device identity: mapping with NIST IR 8259A
| NIST IR 8259A | Core requirement | Pre-requisite |
|---|---|---|
| Device Identification | The IoT device can be uniquely identified logically and physically. | - |
| Device Configuration | - | A fleet of well-identified devices can be more easily controlled and configured. |
| Data Protection | - | Mutual authentication is essential to secure data exchanges. |
| Logical Access to Interfaces | - | Device identification allows per device user access control policy enforcement. |
| Software Update | - | Device authentication allows to only deliver firmware updates to valid devices, thus ensuring IP confidentiality. |
| Cybersecurity State Awareness | - | Device identification helps with incident management and troubleshooting. |
Unique device identity: mapping with CSA IoT Device Security Specification (PSWG) Version 1.0
| CSA IoT | Core requirement | Pre-requisite |
|---|---|---|
| 5.1.1.1 Unique Identity | The device can be uniquely identified logically and physically. | - |
| 5.2.2.1 Configuring IoT System Components | - | The unique identity can be used to attribute an operational identity (using CSR). |
| 5.2.3.1 Uniqueness | Unique identity derives into unique critical security parameters. | - |
| 5.2.3.2 Security Best Practices | The unique device identity is a core requirement for best practice cryptography. | - |
| 5.2.3.5 Changing Authentication Values | - | For updating the CSR. |
| 5.3.1.1 Secure Storage of Persistent Data | Root identity is necessary for securing persistent data. | - |
| 5.4.1.3 Remote Trust Relationships | The unique identity is used as a basis for device authentication. | - |
Unique device identity: mapping with ISA/IEC 62443-4-2
| ISA/IEC 62443-4-2 | Core requirement | Pre-requisite |
|---|---|---|
| FR1 Identification and authentication control | CR 1.2 Components shall provide the capability to identify itself and authenticate to any other component. CR 1.4 Components shall provide the capability to integrate into a system that supports the management of identifiers. CR 1.5 ln addition to an identifier, an authenticator is required to prove identity. CR 1.8 The selection of an a propriate PKI should consider the organisation’s certificate policy. CR 1.9 PKI integration. |
CR1.14 For components that utilise symmetric keys, establish the mutual trust using the symmetric key. |
| FR3 System integrity | CR3.12 Provisioning product supplier roots of trust requirements. CR3.13 Provisioning asset owner roots of trust. |
CR3.11 Physical tamper resistance and detection requirements. |
| FR4 Data confidentiality | - | CR4.1 Confidentiality may rely on mutual authentication. |
What is the cetome VORTEx?
Most recommendations, regulations and standards define what must be done to reduce threat exposure and associated risks. However, manufacturers and end-user need to understand how they can align with these requirements. For that purpose, cetome VORTEx provides a neutral and independent evaluation of existing solutions available on the market.
VORTEx stands for Valid Options for Reducing Threat eXposure. We assess how existing solutions can reduce cyber threat exposure effectively. We consolidate our assessment through consultations with several relevant actors.
We hope that you enjoy our new VORTEx collection!
About this study
The study took place between September 2023 and April 2024. It was entirely self-funded.
We updated the study in March and April 2025 with new solutions and to include a mapping with EN 18031.
About cetome
cetome is an independent cyber advisory with a recognised expertise in IoT security. We work with IoT manufacturers to embed security-by-design in their products, train their teams and improve their cyber resilience. This includes securing the selection and usage of IoT building blocks.
About the Author
Sylvain DELAGRANGE is an IoT product security consultant at cetome. Sylvain has expertise in building secure IoT products. He previously worked as a CTO and as an R&D engineer for various product manufacturers.