Since the inception of the internet of things, there have been concerns about security breaches. For example, in a report titled “Internet of Things: Privacy and Security in a Connected World,” the Federal Trade Commission stated, “IoT devices may present a variety of potential security risks that could be exploited to harm consumers by: (1) enabling unauthorized access and misuse of personal information; (2) facilitating attacks on other systems; and (3) creating safety risks.” To allay such security concerns, it is desirable that IoT devices are designed with strong security.
IoT endpoints such as sensor nodes are often cost-sensitive and commonly use wireless microcontrollers (MCUs) that are resource-constrained. In other words, their limited on-chip memory and security features may prevent the use of some security standards from desktop or server environments. To provide a security standard that specifically addresses resource-constrained devices, the Trusted Computing Group, which creates open standards and specifications that enable more secure computing in devices ranging from IoT endpoints to cloud servers, developed the Device Identity Composition Engine (DICE) standard.
In this article, I will explore what the DICE standard aims to achieve and how it works, including what’s required on the server side to leverage DICE’s capabilities.
The core goals of the DICE standard
The DICE standard aims to enhance IoT device security in these ways:
- Secure device identity. IoT devices typically authenticate themselves through a cryptographic key. If an attacker can discover the value of this key, they can easily impersonate the IoT device. DICE enables the creation of a device identity that is well protected from unauthorized access.
- Remote re-provisioning. If an IoT device does become compromised through malware or discovery of a private key, it must be possible to remotely update the application firmware image and/or re-key the IoT device. DICE enables IoT vendors to recover an IoT device by pushing a new image to it, which automatically generates a new transport layer security (TLS) client certificate chain.
- Remote software attestation. For optimal performance and security, it’s important for an IoT application to confirm that all connected IoT devices are running the correct and most recent version of the application firmware. DICE includes attestation information such as firmware image measurements (for example, a hash) and version numbers in the TLS certificate, enabling an IoT server to verify that the correct image is running on the IoT device.
Protection of data at rest is not a major focus for DICE because a typical IoT device (such as a moisture or temperature sensor) is not handling data that is particularly sensitive or valuable to hackers. DICE does support the concept of a wrapping key, however, which is a symmetric key used to encrypt important data that needs to persist, such as cryptographic keys or device configurations.
In addition to its security goals, the DICE standard is designed to minimize the resources required to implement its security. DICE requires a hardware-based secret and mechanisms that limit access to it by unauthorized programs. It uses extensions in X.509 certificates to exchange identity and attestation data between the IoT device and server. Because certificates are already part of the standard TLS authentication process through which an IoT device connects to the server, there is minimal overhead in such an implementation. To accommodate the varied nature of IoT applications and give developers flexibility, the DICE standard doesn’t dictate a singular implementation approach but articulates a set of design principles that are attainable in a number of ways.
An additional challenge with applying security to IoT devices is that the learning curve required to understand state-of-the-art security technologies is significant. Many embedded developers lack experience in designing secure systems, which may lead to compromises in product security goals if a project incurs delays. A semiconductor vendor will typically implement the DICE standard for their specific wireless MCU, thereby simplifying the effort required to use DICE in the design of an IoT device.
How DICE works
To effectively support resource-constrained devices, the DICE standard eschews a requirement for complex security hardware. Its principal requirement is a hardware-based secret, which is then used to progressively boot a trusted computing base. In a wireless MCU application, there will typically be three steps to the boot process, as illustrated in Fig. 1. More complex systems that feature high-level operating systems or trusted execution environments would require more boot steps. In this article, I will focus on the boot steps required in a typical wireless MCU application.
Fig. 1: How a DICE-enabled MCU will boot an application when using a self-signed certificate: The first two stages focus on DICE-related functions to minimize complexity, while the third stage boots the main MCU application. (Image: Texas Instruments Inc.) Click image for larger view.
The first boot step results in the generation of the Compound Device Identifier (CDI). I will refer to the software and hardware that execute in this step as the DICE engine. To generate the CDI, the DICE engine requires the Unique Device Secret (UDS). The IoT device manufacturer may directly program the UDS into the hardware. Alternatively, the DICE engine may derive it using another secure preprogrammed unique identity such as a key pair.
The UDS does have some additional security requirements. Only the DICE engine can access the UDS, and there must be appropriate hardware support for the DICE engine to lock out access to the UDS before passing control to the next boot step.
To derive the CDI, the DICE engine measures the code that runs in the second boot step, typically through a one-way secure hash, and then combines the hash with the UDS using a hash-based message authentication code (HMAC) function. Once the CDI calculation is complete, the DICE engine wipes any data in registers, caches, or memory that might help an attacker deduce the UDS. At that point, the DICE engine hands control to the second step in the boot process.
The initial role of the second boot step is to create the device identity key pair (known as the DeviceID) and its associated certificate. This boot step then creates the Alias key pair and associated certificate chain. I will refer to the software that executes in the second boot step as Layer 0. To protect the DICE engine and Layer 0 from attacks, the DICE standard mandates that the DICE implementation code must either reside in on-chip ROM or require a signed firmware update from the semiconductor vendor.
Layer 0 derives the DeviceID key pair from the CDI. To create the DeviceID certificate, Layer 0 follows one of two paths, depending on the user’s configuration. One path is to create a self-signed certificate. The other is to create a certificate signing request (CSR) and sign it externally using the appropriate certificate authority (CA). The DICE standard mandates that external signing operations must execute outside of Layer 0 because it is important to keep Layer 0 simple and free from exploitable bugs.
In addition to creating the Device ID and certificate chain, Layer 0 also creates the Alias key pair and its associated certificate. To derive the Alias key pair, Layer 0 uses a one-way hash to create a firmware identifier (FWID) by measuring the Layer 1 image — the actual application firmware image — and combining the FWID with the CDI. As a result, the Alias key pair value directly relates to the application firmware image. Layer 0 uses the DeviceID certificate to sign the Alias certificate and thus chains them together.
The purpose of the DeviceID (and its associated certificate) is to provide identity attestation for the lifetime of the device. To keep the DeviceID highly secure, Layer 0 erases any traces of the DeviceID private key before the next step in the boot process can begin. Because the DeviceID private key is available only during the boot process, a DICE-based IoT device does not require more complex security mechanisms such as a trusted execution environment to protect the DeviceID during general application execution. If it becomes necessary to update Layer 0, then the DeviceID would need to change because one of its inputs is a hash of Layer 0. However, the Layer 0 software is simple and the intent is to never (or very rarely) update it.
The purpose of the Alias key pair and its associated certificate is to provide attestation for the firmware version running on the IoT device. Unlike the DeviceID, Layer 0 passes the Alias key pair to the next step in the boot process — the application firmware image. The application can then use this key pair as a basis for additional cryptography-related operations, such as creating new key pairs for data sealing.
The IoT device uses the Alias certificate chain for TLS client authentication with the IoT server. Because the Alias key pair and certificate are directly tied to the application firmware image running on the device, an over-the-air (OTA) update that installs a new application image on the IoT device will result in a new Alias key pair and certificate. This is a very powerful aspect of DICE, as it enables IoT vendors to restore a compromised IoT device to a secure state by sending the device a new image that automatically re-keys it.
As I mentioned earlier, DICE uses TLS and X.509 certificates to communicate with the server. Because virtually every IoT device will eventually communicate with the IoT server through a TLS connection (non-IP devices will require a gateway), this approach essentially adds minimal overhead to the IoT device. To assist in identity and attestation, DICE adds new standard extensions to X.509 certificates such as object identifiers (OIDs) and additional fields that hold attestation-related data, such as the hash function used to generate the FWID and version number. The OIDs enable the certificate to state whether it is for device identity or attestation or both.
When the IoT device attempts to connect to the IoT network, the IoT server will need to perform remote attestation in addition to the standard TLS authentication protocol. Remote attestation involves extracting the FWID from the certificate and comparing it to a hash of the image that the IoT server expects to be running on the IoT device. Because the device management system running on the IoT server needs to manage software updates for each connected IoT device, it should already know which software version is running on the IoT device and have access to the relevant firmware image hash.
IoT vendors are not required to maintain a database of UDS values on the IoT server or anywhere else. This further enhances the security of DICE-based IoT applications because it removes the possibility of discovering UDS values by using an attack that successfully penetrates the corporate information technology system of an IoT vendor.
Conclusion
The DICE standard enables developers to implement a more effective level of security in low-cost IoT devices. DICE can provide a secure, long-lasting identity and software attestation that enables IoT servers to verify that an IoT device is running the correct software. DICE also enables secure remote re-provisioning of a compromised IoT device.
IoT device developers can easily adopt the DICE standard because it is already pre-implemented on wireless MCUs, such as the TI SimpleLink Wi-Fi CC323x. The DICE implementation on the TI SimpleLink Wi-Fi CC323x enables IoT device vendors to externally sign DICE certificates either during the manufacturing process or when the IoT device is deployed in the field.
About the author
Sarah Pelosi is a Wi-Fi software applications engineer at Texas Instruments, where she focuses on security and cloud partnerships. Sarah has lead development of the SimpleLink Academy training platform and the SimpleLink Wi-Fi smart thermostat reference design.
Advertisement
Learn more about Texas Instruments
