The Janitor’s Key Ring of IoT: Every Device Requires Multiple Keys

Remember those key rings on the belt of your high school’s janitor? Keys in all shapes and sizes that together open all the doors of the school. However, the library key does not open the science lab. And that is how the system is intended, because someone that is granted a key to the library might have no business entering the lab. For the person who needs to enter all the rooms, this means lugging around the big key ring.

And that is also how it works for IoT devices. Connecting devices to a network requires many kinds of keys for protecting data at rest as well as the device’s communications. So, the implementation of the security system of an IoT device requires more than a single cryptographic key, because:

• different cryptographic algorithms in the system expect keys with different lengths or different structures that are incompatible with each other.
• different applications require secrets with different lifetimes, e.g., one application of the system needs several short-lived keys, while a second application requires a single long-lived key.
• keys are often associated with identities and used for authentication purposes, which is only meaningful if different users of the system have access to different keys.
• the compromise of a particular key for one application should not affect the security of secrets used by other applications in the same system, which requires that different applications in a system use different keys.

As an example, consider an IoT system with the following requirements:

• The microcontroller of an IoT device has system-level measures for protecting its loaded firmware through encryption and authentication. Up to eight different firmware vendors should be able to deliver their binaries in encrypted and authenticated form using different, device-unique keys. These device-unique keys are system-level secrets that should be configured to be exportable from the device only once, in a secure environment, such that they can be shared with the vendors. When the binaries are loaded, the microcontroller uses the same keys to decrypt and validate the firmware before it is executed.
• The device should be able to provide two different application-level security services to its users (e.g., one application for setting up a secure channel to a cloud service, and one application for protecting user data stored in off-chip storage). Each of the software applications will require secure storage for a certain number of different device-unique keys.

This description shows a real-world example of how a simple IoT device requires multiple different keys that should be completely independent of each other, because they are used for different purposes and even by different vendors and users. In other words, to prevent the system security from being compromised, one vendor’s or one application’s key should reveal no information about other keys of the system. This why it is a well-established best practice in security design to use a single key only for a single purpose and/or a single application.

A system with multiple keys requires key management

However, in many real-world situations, an implementation of a security system only has access to a single root secret, e.g., a securely stored device key, an entered passphrase, or a device-unique secret from a Physical Unclonable Function (PUF). In order to meet the single-key-single-use requirement, a key management component with the ability to generate multiple application keys from that single root secret should be used.

A crucial property of multiple generated application keys is that they are cryptographically separated. This means they should be generated in such a way that the disclosure of a particular derived key does not affect the security strength of any other derived key. Therefore, simplistic generation methods (e.g., applying simple arithmetic operations or using overlapping portions of a secret) are out of the question. Instead, a cryptographically secure key derivation function (KDF) should be used, which uses cryptographic primitives (e.g., AES or SHA-256) to ensure cryptographic separation between its outputs.

In order to derive separated keys from the same root secret, a KDF expects a differentiation on its key context input. The key context typically contains a combination of information about the key to be derived (e.g., its length), meta-information about the purpose of the key to be derived (e.g., the name of its owner), and optionally, additional random data associated with the key’s use (e.g., a protocol nonce). For a well-designed KDF, any differentiation in the key context – even in a single bit – will result in derived keys that are cryptographically separated. The data passed as key context will also not reveal any meaningful information about the value of the key derived from it.

Tackling key management for IoT devices with QuiddiKey^®

Given all these requirements, developing a key management component with a cryptographically sound KDF requires strong security expertise. To ease this burden for its customers, Intrinsic ID provides key management and KDF functionality as a standard component of its QuiddiKey hardware IP solution.

QuiddiKey enables device manufacturers and designers to secure their products with internally generated, device-unique cryptographic keys without the need for adding costly, security-dedicated silicon. It uses the inherently random start-up values of SRAM as a PUF, which generates the entropy required for a strong hardware root of trust. The IP can be applied easily to almost any chip – from tiny microcontrollers (MCUs) to high-performance systems-on-chip (SoCs) and has been deployed and proven in hundreds of millions of devices.

Intrinsic ID has also released an application note that explains how to use QuiddiKey to generate multiple keys for different applications and purposes based on this single, PUF-based root of trust. This application note uses the system example described earlier in this article to illustrate how to use QuiddiKey in your next system design for creating IoT devices that can securely generate and store a multitude of different cryptographic keys. For more information about how to utilize the QuiddiKey key management functionality, you can find this application note here.