feature article
Subscribe Now

A Roll of the DICE

More Robust IoT Gadgetry

It’s midnight; do you know what your IoT device is doing right now?

You do all the right things when designing your gadget: you do extensive verification; you build in some communication security stuff for secure connections; you even disable the debug port when not in use by an authorized repairperson. But… after you ship it, how do you know that it’s not being compromised?

The answer may be that you don’t know; you just have faith, based on the safeguards you built in, that no one has been able to penetrate the fortress. But what if there was a chink in the wall that you didn’t think of? What if someone is in your system right now plotting world domination and/or ruination?

Without specific added safeguards, you can’t say for certain that this isn’t happening. (OK, fair enough, nothing is certain in this world… yes, it all comes down the number of 9s: how many are you good for?)

If you have the system BOM budget for it, you can include some sort of hardware security ID facility. Computers do this with a Trusted Platform Module, or TPM. If you have a credit card or other small item that absolutely requires security, you may have a Secure Element, or SE. Yeah, kind of the same as a TPM, but, since TPMs are associated with bulky computers, small-gadget folks prefer to use a different name.

But these are extra pieces of hardware. They take space and energy, and they cost money. There are numerous smart (or getting-smart) widgets that have little money, power, or space budget to spare. So what can they do?

Software Device Identity

That’s where the Device Identier Composition Engine, or DICE, comes in. (For once, the correct use of the plural of “die,” only not used as such… <le sigh…>) This is a methodology put forth by the Trusted Computing Group, from whom comes the TPM. The idea is that you don’t have to have dedicated hardware to know that your system hasn’t been compromised.

This topic hit my radar based on a conversation with Microchip at the IoT Security DevCon back in June. They had a microcontroller, the CEC1702, that had been Azure-approved, with secure boot capabilities using DICE, among other things. So I dug in a little to see what this is all about.

DICE applies to boot-up. It helps to prove – or at least to assure – that your system hasn’t been monkeyed with since you booted up last. It’s part of a Robust IoT (RIoT) as proposed by Microsoft. If malware is inserted after boot, then that won’t be detected until the next boot – assuming that malware is persistent. If not persistent, then DICE doesn’t appear to deal with that.

There are a few notions to sort out here. The first is that of a Unique Device Secret. What is this? Well, it’s a secret, so we really can’t tell you. Oh well, OK, since you insist… we actually don’t know because DICE doesn’t specify how that secret is stored or retrieved. You might have a key stored in ROM – weak if it’s the same key for each device. Or you might use a PUF (which we’ll be talking more about shortly). The point is, you can do what makes most sense for your system and your price point.

Critical here is UDS accessibility. The UDS should be accessible only during boot and only by authorized code, and that code should then be able to shut down access to the UDS until the next boot. If the UDS leaks, the security it provides is gone. Yes, we’ll clarify this after the remaining notions.

The next notion is that of immutable vs. mutable code. As the terms suggest, immutable code can’t be changed. But what does that mean specifically? The DICE spec says that either the code cannot be changed ever after manufacturing, or, alternatively, it can be changed or updated only by some manufacturer in the supply chain.

Most code is not immutable. In fact, in our context, we’re talking about boot code. The first code executed must be immutable, after which we start executing regular, or mutable, code that’s still part of the reset sequence. And DICE makes reference to the first such program to be executed: the first mutable code.

Our third notion is the Compound Device ID, or CDI. This is a combination of the UDS and a hash of the first mutable code. What combination might that be? Again, not specified, because it really doesn’t matter – as long as there’s no way to retrieve the UDS from the CDI. Two examples are shown below (where H() indicates a hash, HMAC(K, m) is a cryptographic hash of a message m with a key K, and || indicates concatenation):

H(UDS||H(first mutable code))

HMAC(UDS, H(first mutable code))

But, if you have a better way to do it, great. You just have to use a so-called one-way or trap-door function that works well in one direction but not at all in the reverse direction. As an option, you can include the hardware state and any configuration data in the first-mutable-code hash.


Booting Securely

The idea is that this CDI can then be handed to the first mutable code for it to use. How will that code use the CDI? Again , that’s not specified; you’re free to do with the CDI what you will. But there are some important considerations.

The first mutable code is still part of the boot process. So it’s where you can do things like decrypting code or checking the authenticity of other code. But it has to do something to ensure that the system can’t operate correctly if the first mutable code has been monkeyed with.

One obvious way to attempt some protection would easily be thwarted. Let’s say that, upon installation, you compute and store the CDI. Now, with each boot, you compare the newly calculated CDI against the stored one, and, if it passes, you simply start the next boot steps. Well, all an attacker would have to do would be to replace the entire first mutable code with something that doesn’t check the CDI, and now you have no protection.

If, on the other hand, the first mutable code then decrypts the following code using the CDI, then the attacker can’t replace the first mutable code outright – because it won’t be able to decrypt the next code, and the boot-up can’t continue.

But what if other code is compromised? Well, the first mutable code could run checks on hashes of other applications as well. But this is all part of the “you’re on your own” nature of this spec. The first mutable code – as long as it catches changes to itself – can handle all other attestations. That’s why it’s so important to make sure that it’s protected – the role of the CDI.

The process, then, for boot-up looks something like this:

Mutability and Updates

The DICE engine is supposed to be immutable; the first mutable code is, well, <duh!>, mutable. What are the practical implications? There are two key things:

  • Making the DICE engine updatable is a vendor option. But if you do change the engine, it can’t result in a new CDI. The CDI calculated by the old engine must be the same as that calculated by the updated engine.
  • It’s the exact opposite with updates to the first mutable code. Since that code figures in the CDI, then changes to the code will – indeed, must – result in a new CDI.

For this reason, for example, if the CDI accidentally gets leaked, then you can fix it by updating the code (and changing it in a minor way that results in a new hash, even if nothing functionally changes in the code). That’s a pain for the manufacturer to have to do, so there’s still plenty of motivation to protect the CDI. The only difference with the UDS is that, if the UDS is leaked, there’s no way to unleak it. If the CDI is leaked, you can unleak it via the update.

Hopefully, then, this provides a more cost-effective way to trust your cost-and-security-sensitive IoT device.


More info:

DICE hardware requirements specification

Microchip CEC1702

Robust IoT description

2 thoughts on “A Roll of the DICE”

Leave a Reply

featured blogs
Jun 1, 2023
In honor of Pride Month, members of our Synopsys PRIDE employee resource group (ERG) share thoughtful lessons on becoming an LGBTQIA+ ally and more. The post Pride Month 2023: Thoughtful Lessons from the Synopsys PRIDE ERG appeared first on New Horizons for Chip Design....
Jun 1, 2023
It's been 40 years since Jim Solomon, Richard Newton and Alberto Sangiovanni-Vincentelli co-founded SDA Systems, a physical IC design tools company that became Cadence. Most want to measure this year as the 35 th birthday of Cadence, marked by the merger of SDA Systems and EC...
May 8, 2023
If you are planning on traveling to Turkey in the not-so-distant future, then I have a favor to ask....

featured video

The Role of Artificial Intelligence and Machine Learning in Electronic Design

Sponsored by Cadence Design Systems

In this video, we talk to Paul Cunningham, Senior VP and GM at Cadence, about the transformative role of artificial intelligence and machine learning (AI/ML) in electronic designs. We discuss the transformative period we are experiencing with AI and ML and how Cadence is revolutionizing how we design and verify chips through “computationalizing intuition” and building intuitive systems that learn and adapt to the world around them. With human lives at stake, reliability, and safety are paramount.

Learn More

featured contest

Join the AI Generated Open-Source Silicon Design Challenge

Sponsored by Efabless

Get your AI-generated design manufactured ($9,750 value)! Enter the E-fabless open-source silicon design challenge. Use generative AI to create Verilog from natural language prompts, then implement your design using the Efabless chipIgnite platform - including an SoC template (Caravel) providing rapid chip-level integration, and an open-source RTL-to-GDS digital design flow (OpenLane). The winner gets their design manufactured by eFabless. Hurry, though - deadline is June 2!

Click here to enter!

featured chalk talk

PIC32CX-BZ2 and WBZ451 Multi-Protocol Wireless MCU Family
Sponsored by Mouser Electronics and Microchip
In this episode of Chalk Talk, Amelia Dalton and Shishir Malav from Microchip explore the benefits of the PIC32CX-BZ2 and WBZ45 Multi-protocol Wireless MCU Family and how it can make IoT design easier than ever before. They investigate the components included in this multi-protocol wireless MCU family, the details of the software architecture included in this solution, and how you can utilize these MCUs in your next design.
May 4, 2023