DICE offers enhanced security and unique device identification

By Dennis Mattoon

software engineer


January 22, 2018


DICE offers enhanced security and unique device identification

DICE relies on a combination of simple silicon capabilities and software techniques that work together to provide a cryptographically strong device identity.

With the prevalence of connected devices, especially in Internet of Things (IoT) applications, embedded systems designers increasingly must contend with the types of trust and security issues that computing systems engineers have had to cope with for years.

The Trusted Computing Group (TCG) has a long history of developing standards-based trust technology to address these trust and security issues. And recently, the TCG has expanded its focus to include embedded systems. TCG’s newly released Device Identity Composition Engine (DICE) architecture aims to provide enhanced security and unique device identification and attestation for the embedded space.

DICE relies on a combination of simple silicon capabilities and software techniques that work together to provide a cryptographically strong device identity. Improvements over software-only security are based, in part, on breaking the boot process into layers. Secrets unique to each layer and hardware configuration are created using a Unique Device Secret (UDS) known only to the DICE (and, optionally, manufacturer).

The device secrets and keys, unique to the device and each software layer, ensure that if code or configuration is modified, the secrets and keys will be different. With this approach, each software layer keeps the secret it receives completely confidential to itself. If a secret is disclosed through a vulnerability, patching the code will automatically re-key the device.

Figure 1 shows how trusted code in DICE provides a hardware-based root of trust for the platform. In the DICE boot model:

  1. Power-on unconditionally starts the DICE
  2. DICE has exclusive access to the UDS
  3. Each layer computes a secret for the next layer (via a cryptographic one-way function)
  4. Each layer protects the secret it receives
[Figure 1 | Using new secrets at each layer, the DICE model builds upon trusted immutable code to build a trust chain and provide strong device identity.]

Hardware, with features to limit access to the UDS only to the DICE, performs the initial step for DICE security. Both the UDS and the measurement of the first mutable code that runs on the DICE platform, where DICE provides the root of trust for the measurement, are used to compute the Compound Device Identifier (CDI). Starting with the CDI, each successive software layer uses the secret and a measurement of the next layer to derive a new secret for the following layer. Each layer must erase its own secret before transferring control. This process continues during startup, resulting in a measurement chain that is rooted in the device’s identity and based on measured code.

For a real-world look at this technology, Microsoft’s Robust Internet of Things (RIoT) architecture provides a reference implementation for leveraging DICE. This is the same architecture that underpins the Device Provisioning Service in Azure IoT. In the RIoT reference, a DICE-enabled processor runs a first-stage bootloader called RIoT Core. RIoT Core is responsible for deriving the device identity based on measurements performed by the DICE. RIoT Core then combines its own measurement of device firmware with the CDI it received form the DICE and passes this secret value to firmware so it may further derive its secrets and keys.

In this architecture, device firmware relies on attestation (the cryptographic reporting of the security configuration of a device) elements encoded in a cryptographic hash value called the Firmware Identity (FWID). The FWID is the hash of the Firmware Security Descriptor (FSD) that together with the UDS are simulated inputs to a function that derives the DICE-based identities and certificates.

There are three basic requirements for implementing a DICE platform. These include:

  1. The ability to compute a hash (ideally in hardware or ROM),
  2. A UDS of at least 256 bits,
  3. A protection mechanism that limits access to the UDS to the DICE exclusively and only resets on platform reset

These characteristics are typically found in available microcontrollers (MCUs) used in embedded applications, but MCUs specifically designed for the DICE architecture can optimize their implementation. Hardware available to implement the DICE architecture includes existing MCUs: STMicroelectronics’ STM32L0\L4 family of MCUs, Micron Technology’s Authenta-based flash memory. New MCUs specifically designed for DICE include Microchip Technology’s CEC1702 with a SecureIoT1702 Demo board and flash memory from WinBond.

With the DICE specification nearing finalization, even more design-in tools and support will be available from a broader range of suppliers.

Dennis Mattoon is a Senior Software Development Engineer for Microsoft Research. As one of the founding members of the Security and Privacy Research and Engineering team in MSR, Dennis and his team have spent the last 10 years focused on advancements in trusted computing and system security. His most recent work has been on the creation of the Device Identifier Composition Engine Specification and Architectures (TCG DiceArch), Robust and Resilient IoT (RIoT), and the Cyber-Resilient Platform Initiative.