Implementing DICE

This article is intended as an introductory guide for implementing platforms and devices that incorporate DICE technologies for device identity and attestation using the Microsoft DICE/RIoT reference code.  The audience for this document is silicon vendors (e.g. SoC and storage), standards groups (e.g. storage, trusted computing, and resiliency standards), firmware architects, device vendors, and developers.

Background

DICE stands for Device Identifier Composition Engine.  DICE is a new standardized technique for creating secret keys that can be used by devices for authentication, attestation, data encryption, etc.

RIoT stands for Robust IoT.  RIoT is a family of techniques and protocols for using DICE-derived secrets to enable security features.  RIoT includes protocols for device authentication and attestation (secure reporting of the firmware that booted on a device).

DICE and RIoT are part of the Cyber Resilient Platform Program (CyReP), a Microsoft-led industry initiative to improve the security and resiliency of computing devices.

DICE is ideally implemented in hardware or ROM-based firmware by the silicon vendor.  Silicon vendors may also provide storage write-protection capabilities that let the device vendor implement DICE.

The main RIoT functionality is implemented in a component called RIoT Core.  RIoT Core is built on top of DICE.  RIoT Core loads, authenticates, and executes the remainder of device firmware (or a second-stage boot loader that loads additional firmware).  RIoT Core is usually incorporated into the first-stage boot loader by the device vendor.  Figure 1 provides an organizational summary for a simple DICE/RIoT-enabled device.

Figure 1: Schematic of the major hardware, firmware/software components.  DICE is typically implemented by the silicon vendor, and RIoT Core and Device Firmware are implemented by the manufacturer of the final device.

This article is not intended as a comprehensive overview of the DICE and RIoT technologies and is not a standard for DICE/RIoT devices, firmware or protocols.  An overview and the relevant (draft) standards are:

• RIoT – A Foundation for Trust in the Internet of Things: Overview of the technology.
• Device Identifier Composition Engine: Draft standard for DICE behavior.
• Device Identity with DICE and RIoT: Keys and Certificates: Defines the keys and certificates produced by the reference implementation (a standard is forthcoming).
• Link to Implicit Identity Based Device Attestation reference coming soon!

Terminology

DICE and RIoT are foundational technologies for establishing device identity, implementing hardware-based attestation, and key management for other purposes like data-at-rest encryption.  DICE and RIoT are part of the Cyber Resilient Platform Program, which also includes technologies enabling data and program protection, secure boot, recovery, and reliable remote management.

By design, DICE and RIoT are simple technologies, but they have more than their fair share of acronyms and jargon.  The definitions are gathered here.

UDS – Unique Device Secret

The UDS is a statistically unique per-device secret that is installed or created early in the life of the device and is only accessible to DICE.

CDI – Compound Device Identifier

The value created by DICE and revealed to RIoT Core that depends on the UDS and the measurement (digest) of the First Mutable Code.

DeviceID – Device Identity Key

An asymmetric key pair (currently an ECC P256 key) that serves as a long-term identifier for the device. The DeviceID key may be self-certified or may be certified by the device vendor. The DeviceID key is created by RIoT Core, and the private key is never released from RIoT Core.

Alias Key/Alias Cert – Alias key and associated certificate

The Alias Key is an asymmetric key pair created by RIoT and provided to Device Firmware. The Alias Certificate is a DeviceID private key signature over the Alias Public Key and device attestation data.

FWID – Firmware ID

The “identity” of the program code started by RIoT Core (e.g. the second-stage boot loader). The identity is defined as the measurement (digest) of a data structure called the Firmware Security Descriptor, or FSD.

FSD – Firmware Security Descriptor

A vendor-defined data structure that represents the software that is authorized to run on the device. In the simplest case, this will be the hash of Device Firmware. Other options include a manifest of hashes or public keys that identify components or publishers. An FSD may also include security-critical configuration data.

An FSD may directly identify all the components that are to be loaded, or may indirectly identify the next stage loader, which will implement its own security policies.
Modules

DICE – Device Identifier Composition Engine

This “engine” is hardware or ROM-based firmware that executes unconditionally after platform reset or power-on. DICE will create a secret value that depends on, and is made available to, the first-stage boot loader. The First Stage Boot Loader is assumed to incorporate RIoT functions (i.e., RIoT Core).

First Mutable Code

The code that is initialized, measured, and executed by the DICE Engine. This is usually RIoT Core.

RIoT Core – Robust IoT Core module

RIoT Core creates a set of keys and certificates based on the CDI and FWID.

Device Firmware

The system and application code that performs the main functions of the device. Device Firmware may be a monolithic module or may be a collection of modules that are progressively loaded. If vendors implement attestation, then all security-relevant device firmware should be cryptographically represented in the FWID via the FSD.
Entities

Silicon Vendor

The manufacturer of the SoC and/or or other hardware. The Silicon Vendor will either implement DICE, or provide hardware mechanisms that allow the Device Vendor to implement DICE. Silicon Vendors should provide ports of RIoT Core that are suitable for their device (and popular system firmware). If DICE is not built-in, then Silicon Vendors should also provide an implementation of DICE for Device Vendors to incorporate into their system software.

Device Vendor

The manufacturer of the device. The Device Vendor will incorporate RIoT Core (and other functions) into the early boot code of the device. If DICE is not built-in to the device, then the Device Vendor will also incorporate DICE using an implementation provided by the Silicon Vendor.

DICE and RIoT Reference Architecture

The DICE and RIoT reference architecture can be found on GitHub in the following repository: DICE and RIoT Reference.  This repository contains a reference implementation for a canonical DICE Architecture providing cryptographically strong device identity and attestation.  This is described in the TCG reference publication Implicit Identity Based Device Attestation.

The repository is organized as follows:

• Emulator – A software emulator for DICE/RIoT. The emulator code can be used by developers to simulate inputs to DICE hardware and create RIoT keys and certificates based on those inputs. The emulator is useful during dev/test to provide user-controlled inputs in a more developer-friendly environment. The DICE/RIoT emulator enables a much faster development cycle than working only with real hardware.
• Reference – A simulated DICE/RIoT-based MCU software stack. The RIoT device-reference presents a simulated DICE device, the RIoT reference code itself, and very simple device firmware layer. These three self-contained elements represent the basic components of a simple DICE-based MCU.
• Pkgs – The packages directory contains the metadata and source code for supporting DICE/RIoT development in other languages. In addition to the C-language reference, DICE/RIoT emulators and tests are also provided in Java (Maven), C# (NuGet), and javascript (npm).
• Tools – Sources, tools and tests enabling DICE and RIoT development and validation.

Feedback and contributions are encouraged.  For more information on DICE and to learn how you can contribute, we encourage you to check out the DICE Architectures workgroup (DiceArch) in the Trusted Computing Group.

Implementing DICE

DICE is a (draft) standard for creating a secret value called the Compound Device Identifier, or CDI, which is provided to early boot code in a device.  The CDI depends on a per-device secret called the Unique Device Secret, or UDS, and the cryptographic hash of the first stage boot-loader, which is called the First Mutable Code.

The DICE engine only executes on power up and immediately following a platform reset, and it does so unconditionally.  The CDI produced by DICE is a combination of a device’s UDS and the measurement of First Mutable Code.  The DICE engine must calculate the hash of the First Mutable code to derive the CDI.

An essential characteristic of the UDS is that it is only available to the DICE at boot time and is never accessible to any other software or hardware functions that might disclose the secret to unauthorized entities.  This usually requires special hardware: for example, if the UDS is in e-fuses, then the device needs a hardware latching mechanism that the DICE Engine can use to make the fuse-value unreadable before any other code is executed.  This read-protection “latch” must only be opened by power-on or platform reset.  Vendors may also store the UDS in general purpose non-volatile storage if latches (or other protection technology) are used to ensure that the UDS is only available to DICE at boot time.

The CDI value must be made accessible to the First Mutable Code: for example, the CDI can be stored in memory or registers.  In either case, the First Mutable Code must be able to read and then either delete or hide the CDI so that later executing code can never access it.

The CDI may, for example, be passed in RAM as an “argv-style” parameter to the First Mutable Code.  The CDI may also be passed in a device register if the register can be cleared or mutated cryptographically to obscure the original value (e.g. using a TPM-style “Extend” operation).

DICE is ideally implemented by silicon vendors (e.g. SoC vendor or storage vendor) in ROM firmware.  Alternatively, the silicon vendor can provide hardware mechanisms and a DICE implementation that can be incorporated by Device Vendors.

Important Considerations for implementing DICE:

• The UDS must be exclusively accessible to DICE, and only immediately following a platform power-on or reset. If DICE functionality is spread across multiple subsystems – e.g. a processor and storage controller or other components – then reset of the cooperating subsystems must be coordinated.
• It is crucially important that DICE prevents (i.e., locks out) access to the UDS before passing control to the First Mutable Code.
• DICE must also ensure that no data is left in registers, caches, etc. that might help an attacker deduce the UDS
• If a UDS leaks, or if a DICE implementation allows the UDS to be extracted, or if the calculated CDI value does not accurately reflect the First Mutable Code, then the security provided by the DICE technology is lost. Vendors may consider extenuations for such catastrophic failures, but no mitigations are provided by the DICE reference implementation.
• Cyber-attackers attack systems by creating malformed program inputs. DICE (or similarly privileged early boot code) must measure the hash of the first Mutable Code and may process other data structures.  All data structures processed early in boot should be as simple as possible to decrease the chances of exploitable parsing errors. Input validation code should carefully verify any inputs.  File system management code is complex, so file systems should not be used in early boot code.
• If an improper input data structure is detected then a CDI value of zero (or a value unrelated to the UDS or First Mutable Code) should be returned
• Vendors should employ technologies to guard against simple hardware attacks, e.g. glitching, or exposure of the CDI value on easy to probe buses, use of power-analysis to deduce the UDS, etc.

Leveraging DICE

The RIoT reference code is an example implementation of DICE-based identity and device attestation.  It provides a family of cryptographic techniques for establishing device identity, attestation, sealed storage, and other security functions.  The Microsoft Research RIoT reference implementation creates keys and certificates that are compatible with the new reference from the DICE Architectures WG: Implicit Identity Based Device Attestation.

The specific keys and certificates produced by the reference implementation are:

DeviceID (always created): An ECC P-256 key pair that serves as a long-term identifier for the device. The DeviceID public key is exported from RIoT Core. The DeviceID private key is used in the operations described in this table. The DeviceID key pair is deterministically generated from the CDI: i.e. if the device boots the same RIoT Core, then the same DeviceID key pair will be created each time the device boots. If new First Mutable Code is installed, then a new device identity that is not relatable to the original device identity will be created.

Alias Key Pair (always created): An ECC P-256 key pair that serves as an identifier for a particular firmware version on the device.  The Alias Key Pair is deterministically generated from the CDI the firmware ID (the FWID.) If the device boots the same RIoT Core and firmware with the same FWID, then the same Alias Key pair is generated. If the firmware (hence FWID) is updated, then the Alias Key pair will be different.  Both the public and private parts of the Alias Key Pair are exported from RIoT Core.

Alias Key Certificate (always created): An X.509 certificate containing the Alias public key signed by the DeviceID private key.

Device Certificate (compile-time option): A self-signed X.509 certificate for the DeviceID key. The reference implementation either produces a Device Certificate, or a Device ID Certificate Signing Request (CSR), based on a build-time switch.

Device CSR (compile-time option) A PKCS#10 compliant Certificate Signing Request for the DeviceID key pair. The reference implementation either produces a Device Certificate, or a Device ID Certificate Signing Request (CSR), based on a build-time switch.

The RIoT Core emulator produces all keys and certificates in a single function CreateDeviceAuthBundle.  The input to the function is the CDI (length, and pointer to the data.)  PEM-encoded keys and certificates are returned.

The reference implementation does not require an entropy source: all keys and certificates are deterministically generated from the CDI and FWID using cryptographically secure one-way key derivation functions.

Vendors may consider deriving or randomly generating additional keys for device authentication or data encryption.

Cloud Infrastructure and Silicon Integration

Finally, for device firmware to benefit from the identity and attestation capabilities enabled by DICE and RIoT, it needs a connection to the outside world.  One of the goals of the DICE Architectures WG in TCG is the broad adoption of DICE for security in the Internet of Things and, in fact, any connected device or component.  Therefore, it’s important that the underlying use cases, references and specifications are not specific to any one (or paricular set of) infrastructure providers.

Further, since broad availability in silicon for systems that support DICE Architectures is also a goal, hardware specifications supporting DICE Architectures need to be flexible.

Next Steps

This article has been an introduction to implementing DICE and RIoT.  The DICE and RIoT reference architectures, developer tools, and samples provide a great starting point for developers new to DICE technology.  And for silicon vendors interested in implementing support for DICE in their hardware, the best resource is the DICE Architectures WG in TCG.  You can learn more here: https://trustedcomputinggroup.org/work-groups/dice-architectures