VORTEx: Unique identity for IoT devices

A unique identity is a core requirement to secure IoT devices, comply with standards and regulations.

This VORTEx looks at existing solutions so that IoT manufacturers can better secure their products.

storm Explore the VORTEx
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 authorization 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 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 authorization, mitigating security risks associated with unauthorized 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 utilized only by authorized 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:

  1. Genuineness: no counterfeited device nor overproduction
  2. 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.

Unique identity operations throughout the device lifecycle
Unique identity operations throughout the device lifecycle

➀ 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), though they are not recommended.

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 authorized 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).

From the keypair to the X.509 certificate: The CSR workflow
From the keypair to the X.509 certificate: The CSR workflow

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 authorized 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
  • The chipmaker is a chosen partner
  • Very secure. Avoid having to trust contract manufacturers
  • Full customization of the chip with extra features
  • One-time-programmable memory (OTP) security settings (secure boot, anti-rollback, flash page locking…)
  • Specific to the chip manufacturer
  • Sometimes subject to minimum volume conditions
  • Can involve a dedicated third-party (e.g. programming partners) with extra costs
  • Not very flexible
At the device factory
  • Default solution
  • Simpler to have the product manufactured and provisioned in a row
  • Secure programming already requires implementing secure processes, that could be mutualized with identity-provisioning ones
  • Not a safe place, need to assess trustability of contract manufacturers
  • Exposed to overproduction
  • Require dedicated secure process with Hardware Security Modules (‘HSMs’) and/or with a factory connected to the Internet
In a dedicated stage, before shipment
  • Independent from contract manufacturers
  • Decoupled from the manufacturing process
  • Add a step and a contractor to the manufacturing process
Later, in the field
current market trend
  • Very flexible
  • Allow for direct binding to Cloud services (device enrolment to PKI and device provisioning to Cloud services in the same step)
  • Onboarding process independent from manufacturing
  • Usage of a PKI (for certificate renewal and revocation, device ownership)
  • Require the ability to connect at first use
  • Need to extend the device database to Cloud services to confirm authorized devices before they receive their certificate

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.

memory 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 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.

Smart Card Trust Provisioning Flow Diagram (NXP, with authorization)
Smart Card Trust Provisioning Flow Diagram (NXP, with authorization)

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.

SFI process overview (ST Microelectronics, with authorization)
SFI process overview (ST Microelectronics, with authorization)

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.

Recommendations

We propose several recommendations to secure a unique device identity for IoT devices.

security 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 associated with a secret to each device. Additionally, an operational process must be established in continuity with the manufacturing process to assign an operational identity to each device and utilize it throughout its lifecycle.

Risks such as cloning, overproduction, loss of intellectual property, privacy breaches, among others, require protecting these secrets from chip production until product end-of-life.

enhanced_encryption 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 not recommended due to higher operational constraints and/or lower security levels.

supervised_user_circle 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.

recommend 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 customizing 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:

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 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 303 645 v2.1.1

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 individualized 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 organization's certificate policy.

CR 1.9 PKI integration.

CR1.14 For components that utilize 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.

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.