aka RIoT (Robust | Resilient | Recoverable – IoT)

Introduction

DICE (previously called RIoT) is a family of hardware and software techniques for hardware-based cryptographic device identity, attestation, and data encryption.

DICE hardware requirements are extremely modest: even the tiniest microcontrollers can afford DICE support.  DICE hardware is coupled with DICE software, protocols, and services to provide an exceptionally tiny and robust hardware/software root of trust for foundational management.

DICE is an industry standard, and DICE hardware is available from an increasing number of hardware vendors.  DICE is also supported by Azure IoT and is one of the foundational roots-of-trust in Microsoft’s Azure data centers.

DICE in a Nutshell

Many SOCs contain fuse-banks (or other NV-memory) that can be used to store cryptographic keys for data encryption or device identity.  However, if the code running on the SoC is compromised, the fused secret key value (hereafter called the Unique Device Secret or UDS) can leak.  Securely re-keying such compromised devices may be difficult or impossible.

SoC vendors sometimes minimize the risks of UDS-compromise by limiting the run-time environments that can read the fuse value.  For example, ARM processors that implement TrustZone™ often limit fuse-bank access to Trusted Execution Environments (TEEs) running in secure world.  This certainly reduces the risk of compromise, but modern TEEs contain 10s or 100s of thousands of lines of code, so risks remain.

DICE uses three techniques to drastically limit the amount of code that has access to the Unique Device Secret.  The techniques are:

A Power-on-Latch

DICE hardware must incorporate a latching mechanism that early-boot code (or internal SoC microcode) can use to disable read-access to the UDS before passing control to complex firmware.  Once the device secret is hidden, a platform reset or power-cycle is needed to re-regain access.

Latches can reduce the attack surface for device key compromise enormously because early boot code can be very simple, and early boot code can engage the protection latch before complex functions are performed.  Malware that arrives later in boot or at run-time cannot read the UDS because it is protected by the hardware latch.

Cryptographic One-Way Functions

A read-protection storage latch can be used to protect the UDS, but if boot code simply makes a copy of the UDS in RAM, then compromise of later firmware will still lead to irrevocable key disclosure.

The trick to mitigating this hazard is to use a cryptographic one-way function to transform the UDS.  Then, if later code is compromised, the derived key may be disclosed but the foundational UDS key is still safe.

Tying Key Derivation to Software Identity

The final piece of the puzzle is to transform the UDS with a cryptographic one-way key derivation function that depends on the identity of the early boot code running on the device.

The simplest one-way function is:

CDI = HMAC(UDS, Hash(program))                                                   [1]

Where:

CDI is the Compound Device Identity: A value that depends on both the hardware and the software that booted

UDS  is the latchable Unique Device Secret, held in fuses or other read-only storage

HMAC is a keyed hash function

Hash(program) is the cryptographic hash of the code that starts executing at power-up or reset.

The reason for tying CDI-derivation to the code that is booting on the device is that a firmware update automatically results in the device being re-keyed.  This behavior closely matches the security problems we are trying to solve.  Specifically:

1)      If an attacker can change the code that boots on the device with the intent of stealing keys, the attacking program (with a different hash) obtains a different key than the authorized program.

2)      If authorized code contains a vulnerability that leads to CDI compromise, then the device must be re-keyed.  The CDI derivation function [1] ensures that patching the vulnerable firmware automatically results in a new CDI being provisioned.

The DICE engine behavior given by equation [1] is now an industry standard.

Balancing Cost, Security and Manageability

The DICE behavior given by equation [1] is very simple and can easily be implemented by internal SoC microcode or ROM-based device firmware.  However, if this simple key-derivation algorithm is used, a firmware update leads to new derived CDI-key that cannot be related to the old key.   In some ways, this is a “feature,” because a potentially compromised key has been replaced.  However, if the previous CDI had been used for device identity, then the patched device will no longer be recognized, and if the CDI was used to encrypt data, then the data will no longer be decryptable.  I.e. the DICE behavior in [1] is simple and robust, but manageability falls short.

Manageability problems can be mitigated by building additional management/upgrade machinery into the DICE-engine.  Unfortunately, additional complexity increases the chance of DICE-engine compromise, and different scenarios demand different security/manageability tradeoffs.

A better solution is to arrange boot code into “layers,” with lower-layers optimized for simplicity, and upper-layers adding more complicated manageability functions.  For example, the lowest DICE-Engine layer might use equation [1] to create a CDI; a second device/scenario-specific DICE-Core layer can use the CDI to create additional keys and management functions.  See Figure 1.

Figure 1: A simple SoC-integrated DICE engine with more complex manageability functions in a DICE Core layer.

Microsoft’s DICE Core Reference Implementation

Microsoft has standardized and open-sourced a DICE Core-layer that allows for secure and manageable device update.   See Figure 2.

This DICE Core layer:

• Derives an ECC key pair that will be stable for the life of the device and is never disclosed outside DICE Core. This is called the DeviceID key pair.
• Derives a second key pair, called the Alias Key, that depends on the identity of the next layer. A new Alias Key Pair is created if the main device firmware is ever updated
• Creates a certificate for the Alias Key using the DeviceID private key. The certificate also contains attestation information so that relying parties can find out whether the device firmware is up-to-date
• Creates a certificate signing request (to simplify manufacturing flows where the device is vendor certified)
• Creates a self-signed DeviceID certificate (to support non-vendor certified devices)

The certificates are designed to be used in TLS sessions supporting TLS client-authentication.

More details are in the industry standard and this white paper.

Figure 2: Schematic of a DICE Core Layer that allow for controlled firmware updates and additional certificates to simplify manufacturing.  The Firmware Security Descriptor defines the security characteristics of the remaining device firmware.

Key Resources

• DICE Hardware Specification
• DICE Certificate Standard for TLS
• Microsoft’s version of the certificate standard
• A white-paper describing the DICE/RIoT technology in more detail
• Microsoft’s open-source DICE implementation, containing reference code, ports to specific SoCs, validation code, and DICE simulators
• DICE is part of the Cyber-Resilient Platform Program. CyReP extends DICE to include enhanced firmware protection, compromise detection, secure and reliable remote management, and device recovery.