{"id":472506,"date":"2018-03-13T11:00:03","date_gmt":"2018-03-13T18:00:03","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/research\/?post_type=msr-project&p=472506"},"modified":"2020-03-13T17:21:20","modified_gmt":"2020-03-14T00:21:20","slug":"dice-device-identifier-composition-engine","status":"publish","type":"msr-project","link":"https:\/\/www.microsoft.com\/en-us\/research\/project\/dice-device-identifier-composition-engine\/","title":{"rendered":"DICE: Device Identifier Composition Engine"},"content":{"rendered":"

aka RIoT (Robust | Resilient | Recoverable – IoT)<\/h3>\n

Introduction<\/h1>\n

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

DICE hardware requirements are extremely modest: even the tiniest microcontrollers can afford DICE support.\u00a0 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.<\/p>\n

DICE is an industry standard<\/a>, and DICE hardware is available from an increasing number of hardware vendors<\/a>.\u00a0 DICE is also supported by Azure IoT<\/a> and is one of the foundational roots-of-trust<\/a> in Microsoft\u2019s Azure data centers.<\/p>\n

DICE in a Nutshell<\/h1>\n

Many SOCs contain fuse-banks (or other NV-memory) that can be used to store cryptographic keys for data encryption or device identity.\u00a0 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.\u00a0 Securely re-keying such compromised devices may be difficult or impossible.<\/p>\n

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

DICE uses three techniques to drastically limit the amount of code that has access to the Unique Device Secret.\u00a0 The techniques are:<\/p>\n

A Power-on-Latch<\/strong><\/p>\n

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.\u00a0 Once the device secret is hidden, a platform reset or power-cycle is needed to re-regain access.<\/p>\n

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.\u00a0 Malware that arrives later in boot or at run-time cannot read the UDS because it is protected by the hardware latch.<\/p>\n

Cryptographic One-Way Functions<\/strong><\/p>\n

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.<\/p>\n

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

Tying Key Derivation to Software Identity<\/strong><\/p>\n

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.<\/p>\n

The simplest one-way function is:<\/p>\n

CDI = HMAC(UDS, Hash(program)) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/em>[1]<\/p>\n

Where:<\/p>\n

CDI<\/strong> is the Compound Device Identity<\/em>: A value that depends on both the hardware and<\/em> the software that booted<\/p>\n

UDS\u00a0<\/strong> is the latchable Unique Device Secret, held in fuses or other read-only storage<\/p>\n

HMAC<\/strong> is a keyed hash function<\/p>\n

Hash(program)<\/strong> is the cryptographic hash of the code that starts executing at power-up or reset.<\/p>\n

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.<\/em>\u00a0 This behavior closely matches the security problems we are trying to solve.\u00a0 Specifically:<\/p>\n

1)\u00a0\u00a0\u00a0\u00a0\u00a0 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<\/em> than the authorized program<\/em>.<\/p>\n

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

The DICE engine behavior given by equation [1] is now an industry standard<\/a>.<\/p>\n

Balancing Cost, Security and Manageability<\/h1>\n

The DICE behavior given by equation [1] is very simple and can easily be implemented by internal SoC microcode or ROM-based device firmware.\u00a0 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. \u00a0\u00a0In some ways, this is a \u201cfeature,\u201d because a potentially compromised key has been replaced.\u00a0 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.\u00a0 I.e. the DICE behavior in [1] is simple and robust, but manageability falls short.<\/p>\n

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

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

\"DICE<\/p>\n

Figure 1: A simple SoC-integrated DICE engine with more complex manageability functions in a DICE Core layer.<\/em><\/p>\n

Microsoft\u2019s DICE Core Reference Implementation<\/h1>\n

Microsoft has standardized<\/a> and open-sourced<\/a> a DICE Core-layer that allows for secure and manageable device update.\u00a0\u00a0 See Figure 2.<\/p>\n

This DICE Core layer:<\/p>\n