Establishing Unique Identity and Security for Cost-Sensitive Embedded Products
Since the 1950s, fuzzy dice hanging from a car’s rearview mirror have been a favorite accessory for drivers that want to make their car “unique,” or at least easily recognizable. Now, not-so-fuzzy DICE (Device Identifier Composition Engine) Architectures have been developed to deliver unique device identity and protect a vehicle’s digital content and access to its control systems and sensitive data.
Automotive is just one example, though. Any embedded system, especially those that are highly cost sensitive but still require enhanced security and a unique identification, can benefit by implementing the DICE architecture.
System-Level Vs Embedded Trust
While many companies and organizations have only begun to face the reality of hackers, vulnerabilities, and unauthorized access, the Trusted Computing Group (TCG) has been addressing trust and security issues for more than a decade. The concept of established trust and the related security benefits for PCs, servers, and networking gear has been built on international standards defining hardware roots of trust based on TCG’s Trusted Platform Module (TPM).
While TPMs were initially implemented in application-specific ICs (ASICs), the TPM has since evolved to address the requirements of different applications and markets. The most recent embodiment is TPM 2.0 and the accompanying library specification describing all of the commands/features that could be implemented—and might be needed—in platforms from servers to laptops, even to embedded systems. Today, discrete, integrated, firmware and software TPMs (in decreasing security order) offer different tradeoffs between cost, features, and security.
However, despite this evolution, including a TPM in many IoT and embedded systems may still be impractical due to constraints around cost, power, physical space, design efficiency, etc. In response to the need for increased security, especially in these constrained environments, TCG, in partnership with member companies, has developed the DICE Architecture. DICE offers many of the same security benefits without a corresponding increase in silicon requirements (see “TPM vs. DICE” below).
Replacing Fuzziness with Predictability
Part of the foundation for DICE’s improvements over software-only based security is its approach to device startup. In a DICE Architecture, startup (boot) is organized into layers, creating secrets unique to each layer and hardware configuration starting with a Unique Device Secret (UDS) known only to the manufacturer and DICE. The secrets or keys created are unique to the device and each layer and configuration.
This derivation method ensures that if different code or configuration is booted on a particular device, the secrets on the device will be different. Each software layer keeps the secret it receives completely confidential to itself. If a vulnerability exists and a secret is disclosed, patching the code automatically creates a new secret, effectively re-keying the device. In the DICE boot model:
- Power-on unconditionally starts the DICE .
- DICE has exclusive access to the UDS.
- Each layer computes a secret for next layer via a cryptographic one-way function.
- Each layer protects the secret it receives.
Figure 1 shows how the immutable (unchangeable) code in the DICE (typically in ROM) is used to measure subsequent mutable (changeable) code. A further explanation is shown in (see “Deriving the Compound Device Identifier” below).
1. The DICE model combines measured code and a statistically unique device secret to build a device’s unique identity.
The initial step for DICE security is unconditionally performed by hardware (HW) with features to keep the UDS safe from later layers (Fig. 2a). Figure 2b shows how each successive software layer generates a new secret for the next layer and erases its own secret before passing control. Each layer’s secret depends on the device’s identity and a measurement of code (and optionally configuration data).
2. The DICE architecture calculates secrets in both hardware (a) and firmware/software (b).
The first production implementation of a DICE Architecture is Microsoft’s Robust Internet of Things (RIoT) (Fig. 3). This diagram illustrates the difference in approach between a traditional security processor and the one-way path forward for establishing trust.
3. Here, a traditional security processor is compared to a DICE Architecture. In a DICE architecture, secrets exist only as long as they’re needed. In a traditional security processor, secrets are typically long lived.
Three hardware requirements for implementing the DICE platform include:
1. Protected device initialization code, ideally in ROM or otherwise write-protected
2. A unique device identity of at least 256 bits, ideally stored in one-time programmable (OTP) memory 3. A Device Identity lockout mechanism that is only cleared during power-on reset.
These characteristics can be found in existing microcontrollers (MCUs) that would typically be used in embedded applications.
DICE Implementations
Some of the initial implementations of the DICE architecture demonstrate its ability to provide secure access control to the IoT. For example, Figure 4 shows a modified DICE + RIoT architecture that enables access to Microsoft’s Azure enterprise cloud services and the newly announced Device Provisioning Service from Azure IoT.
4. The DICE + RIoT architecture for Device Identity also offers options for self-signed certificates and CSRs. (Source: Microsoft)
The DICE-enabled hardware runs a first-stage bootloader called RIoT Core that measures and executes the remaining device firmware (Layer 1), which relies on certain attestation elements. Attestation, the cryptographic reporting of the security configuration of a device, is encoded in a cryptographic hash called a Firmware Identity (FWID). In this case, it’s the hash of the Firmware Security Descriptor (FSD). Both FWID and FSD meet the DICE specification requirements.
In addition to the Alias Key and certificate generation required by this DICE architecture, the RIoT Core can also generate a manufacturer or self-signed DeviceID certificate, or a Certificate Signing Request (CSR) for the DeviceID public key.
Another DICE implementation is the result of a partnership between Micron Technology and Microsoft. It takes advantage of Micron’s new Authenta technology and Microsoft’s Azure IoT cloud. The Authenta-based flash memory and its associated software enable device onboarding and management by the Azure IoT cloud (Fig. 5). The strong cryptographic identity from this DICE implementation becomes the basis for interacting with provisioning services like the Microsoft Azure IoT Device Provisioning Service (DPS).
5. Micron’s Authenta technology enables direct connection to Microsoft Azure Cloud Services. (Source: Micron Technology)
In the boot process, a cryptographic measurement is securely monitored by Microsoft’s DPS that attests to the health of the firmware on IoT devices. Additional functionality from this approach includes administrative provisioning, remediation, and secure updates directly to the flash memory.
Other Available Hardware
Some of the initial Proof of Concept (PoC) devices for the DICE Architecture were from the STM32 L0 and L4 families of microcontrollers from STMicroelectronics. These developer-friendly MCUs offer functionality than exceeds the minimal requirements for implementing DICE.
For example, in the L0 PoC, the hardware AES-128 engine was used to calculate cipher-based message authentication codes (CMACs) as 128-bit digests. Then, permanently disabling hardware debugging and blowing the read-only fuses for the flash memory hosting the DICE code and Device Identity, makes the DICE code immutable.
In the demo:
1. The Factory programs the DICE bootloader and provisions the DeviceID and the ManufacturerID.
2. The Application Developer creates the application payload and provides it to the manufacturer.
3.The manufacturer encrypts the OperatorID and completes the signed application payload header.
4. The vendor (or customers) receives the device and flashes the firmware package
5. For application payload updates, the process continues at step 2.
Lots of other embedded MCUs can also be used to implement the DICE architecture. One seemingly tailor-made for DICE is Microchip Technology’s CEC1702, a Microsoft Azure for IoT-Certified microcontroller with DICE hardware capability. The 32-bit Arm Cortex-M4-based microcontroller provides a complete hardware-based cryptography solution in a single package. Its integrated security functionality implementing easy-to-use encryption, authentication, private and public key capabilities, etc., includes:
- 5K bits of user programmable OTP
- Multi-purpose AES Cryptographic Engine (HW support for ECB, CTR, CBC and OFB AES modes)
- Support for 128-bit, 192-bit and 256-bit key lengths
- Cryptographic Hash Engine (SHA-1, SHA-256, SHA-512)
- Public Key Cryptographic Engine, which maintains hardware support for RSA and Elliptic Curve public key algorithms, RSA keys length from 1024 to 4096 bits, and ECC Prime Field and Binary Field keys up to 640 bits.
Rolling Your Own DICE
Even though the DICE architecture is yet to be completely finalized, there are already references and tools available now because of the support of the companies whose experts are part of developing the DICE Architecture standard. Microsoft has already established hardware partnerships with STMicroelectronics, Micron Technology, and Microchip.
The GitHub repository for Microsoft’s RIoT contains an emulator, tools, and a reference that serves as a very early software-development kit (SDK) for DICE.
The DICE/RIoT Emulator can be used by developers to simulate the presence of DICE hardware. In it, the UDS and Firmware Identity (the hash of the FSD) values are simulated inputs to a function that derives DICE-based identities and certificates. To support the emulator, the tools tree provides a set of utilities for DICE/RIoT development and test.
Finally, the reference implementation of DICE/RIoT simulates an end-to-end implementation of a DICE architecture. Each simulated component: DICE hardware, Layer 0, and Device Firmware are each implemented as self-contained elements, similar to how this would be structured on a real device.
In addition to its Authenta-based flash memory (hardware) and associated software, Micron will soon offer SDKs so that users can easily provide secure device management and connectivity for new platforms and devices, and simplify the retrofitting of legacy systems.
6. Microchip Technology’s SecureIoT1702 Demo Board utilizes processing and the hardware capabilities of the CEC1702 cryptography-enabled ARM Cortex-M4-based microcontroller. (Source: Microchip Technology)
To support its CEC1702 Microsoft Azure for IoT-Certified MCU with DICE, Microchip has the SecureIoT1702 Demo board, a small-form-factor evaluation board that can be used for development, evaluation, and demos (Fig. 6). Designed to utilize the processing and the hardware capabilities of the CEC1702 cryptography enabled ARM Cortex-M4-based microcontroller, the demo board has its own user’s guide in addition to several third-party development tools that are available for the CEC1702.
Of course, when the DICE specification is finalized, even more design-in tools and support will be available from a broader range of suppliers. This will provide system designers and integrators with the tools and resources they need to provide sophisticated, connected, and secure IoT and embedded solutions in any consumer, commercial, or industrial application.
TPM vs. DICE
While both the well-established TPM and new DICE Architecture seek to provide enhanced security and protection, there are distinct differences between the two approaches. The table below compares the key properties of the TPM and the DICE Architecture. Note how the DICE Architecture addresses the embedded-system designer’s need to specifically reduce power, space, and cost, while achieving design efficiency and providing high device security.
The DICE architecture offers another alternative to TPMs for enhanced security by establishing a unique ID and a foundation for attestation, secure update, and other security-critical functionality in connected embedded products.
Deriving the Compound Device Identifier
Both the UDS and the measurement of the first mutable code that runs on the DICE platform are used to compute the Compound Device Identifier (CDI) (Fig. 7). DICE is the root of trust for the measurement. This step can also include measurements of hardware state information and configuration data that influences the execution of the first mutable code. Any revision or change in the UDS or any of the measured components results in a different value for the CDI.
7. The Compound Device Identifier derivation process is based on both the UDS and first mutable code measurement.
The UDS and the measurement of mutable code are cryptographically mixed so that the CDI and the code measurement can’t be used to recover the UDS. One way to do this can be performed by the DICE using a secure hash algorithm to hash the concatenation of the two values.
Resources
Trusted Computing Group, “Device Identifier Composition Engine (DICE) Architectures.”
Trusted Computing Group, “Device Identifier Composition Engine (DICE) specification: TCG Trusted Platform Architecture Hardware Requirements for a Device Identifier Composition Engine, Family “2.0”” Level 00 Revision 69, December 16, 2016
Microchip Technology, CEC1702
Microchip Technology, SecureIoT1702 Demo Board
Micron Technology Authenta Technology
Microsoft Azure IoT
Microsoft, “RIoT – A Foundation for Trust in the Internet of Things.”
Microsoft, “Announcing new functionality to automatically provision devices to Azure IoT Hub.”
Microsoft, “Cyber-Resilient Platform Initiative.”
Microsoft, https://github.com/Microsoft/RIoT
