Breaking the Ice on DICE: scaling secure Internet of Things Identities

In this Spotlight Podcast, sponsored by Trusted Computing Group*, Dennis Mattoon of Microsoft Research gives us the low-down on DICE: the Device Identifier Composition Engine Architectures, which provides a means of  solving a range of security and identity problems on low cost, low power IoT endpoints. Among them: establishing strong device identity, doing device attestation and safe deployment at scale and verifying software updates. 

Secure identities are the foundation of secure ecosystems. At the risk of oversimplifying: without a foundation of strong identity, there can be no real security. We know that intuitively just from our experiences online, where phishing attacks and identity theft are rampant – often taking advantage of weak identities like user names and passwords, or Social Security Numbers.

Sponsored Content

It’s especially true of the Internet of Things, where both the diversity and scale of connected endpoints create endless opportunities for mischief and mayhem. We have seen, for example, how weakly configured IP cameras and routers can be compromised and enrolled in global botnets like Mirai used to siphon sensitive data from corporate and personal networks. Hacks of connected cars and implantable medical devices have been shown to have potentially lethal consequences, while Hacks of point of sale systems have long been the bane of retailers.

The challenge is how to create secure and irrefutable identities on IOT endpoints that aren’t suitable for deployment of a Trusted Platform Module or similar component because they’re resource or cost-constrained – or both.

Dennis Mattoon Microsoft
Dennis is a Principal Software Development Engineer at Microsoft Research

Dennis Mattoon of Microsoft Research says that TPM’s just aren’t practical for the vast majority of IoT endpoints. “In just about every way you can measure the cost of a device, and an element of your IOT ecosystem, the TPM will eat up those resources,” he said. That includes the amount and complexity of code needed to implement a full TPM, as well as the infrastructure and services needed to manage and intermediate TPM interactions. “Its just a big complicated thing,” Mattoon notes. “That’s fine for PCs and servers. We have those libraries and we’ve wrapped our heads around how that works. You have BitLocker working in the background and that’s great on a PC, which has so much room to spare you don’t even know it’s there.”

But the economics of IoT endpoints are the exact opposite. “I can’t afford to waste space in flash on unnecessary code,” Mattoon notes. “I don’t want to take my carefully crafted ROM on a micro contoller and introduce complicated code to deal with the TPM. That’s a big ask.” The practical result of that “big ask” is that lots of connected product designers just say “no,” he said.

One answer is DICE, a new secure architecture designed by Microsoft and the Trusted Computing Group specifically for resource and cost constrained endpoints like those on the Internet of Things.DICE – or the Device Identifier Composition Engine (DICE) Architectures – was released in September, 2017. It provides both security and privacy benefits to IoT and embedded systems unsuitable for traditional Trusted Platform Modules.

But what is DICE and how can connected device and “thing” makers best take advantage of the technology? In this Spotlight Podcast, we sat down with  Mattoon, a senior software development engineer at Microsoft Research to learn more about how the new architecture can help solve problems like establishing strong device identity, device attestation and safe deployment and verification of software updates.

TCG DICE Architectures
Graphic showing Trusted Computing Group DICE Architectures

The key to the DICE Architectures is its ability to breaks up the boot process for any endpoint device into layers and combine unique secrets and a measure of integrity for each layer. Practically, this means if malware is present at any stage of the boot process, the device is automatically re-keyed and secrets protected by the legitimate (pre-infection) keys are protected.

DICE, he told us, is more a set of principles than hard requirements. “What’s critical is that, to be DICE compliant, your hardware needs to have a unique device secret,” he said. That’s not too heavy a lift – most connected hardware already does. But on DICE compliant devices, only the DICE engine gets access to that secret and only during device reset. With that secret in hand, the DICE engine computes a hash value that is then combined with unique measurements at each, new software layer and builds upon that. “We basically took the simple construct of secret and software measurement to build a rich security scenario that leverages device ID and attestation and even things like data at rest security, secure updates, cyber resiliency and so on,” Mattoon said.

If you’re a connected product designer and want to learn more about DICE this is a “must listen.” Trusted Computing Group also has some great developer resources online to learn more about the DICE architecture and how you can implement it in your connected products.

Links for this podcast:

(*) Trusted Computing Group is a paid sponsor of The Security Ledger