USD | INR

IoT Security Fundamentals—Part 2: Protecting Secrets

By Stephen Evanczuk

Contributed By Digi-Key's North American Editors

Editor’s Note: Despite the proliferation of IoT devices, securing these devices remains an on-going concern, to the degree that security challenges can be a barrier to adoption of connected devices in Industrial IoT (IIoT) and mission-critical applications where corporate and personal data may be compromised in the event of a successful attack. Securing IoT applications can be daunting, as developers must orchestrate multiple security mechanisms, protocols and policies that in combination seem complex. In reality, IoT device security can be built upon a few relatively straightforward principles that are supported by hardware security devices. By following well-established security practices, these concerns can be addressed. This multi-part series provides practical guidance to help developers ensure best practices are followed from the outset. Part 1 discusses the cryptographic algorithms underlying secure designs. Here, Part 2 discusses the role of private keys, key management, and secure storage in secure IoT designs. Part 3 examines the mechanisms built into secure processors to mitigate other types of threats to IoT devices. Part 4 identifies and shows how to apply security mechanisms in advanced processors to help ensure the isolation needed to mitigate attacks on the runtime environment of IoT devices. Part 5 describes how IoT security continues from IoT devices through higher level security measures used to connect those devices to IoT cloud resources.

Although hardware-based cryptographic devices can mitigate Internet of Things (IoT) vulnerabilities, lack of sufficient protection of secret keys and associated data can degrade security, despite use of the most robust cryptographic device. Semiconductor manufacturers address protection of keys and other privileged data through a variety of mechanisms built into specialized security ICs and processors.

This article reviews the critical role keys play in cryptography and describes the different key protection mechanisms built into available devices from Maxim Integrated, NXP, STMicroelectronics, and Microchip Technology.

The role of secret keys in cryptography

As described in Part 1 of this series, a wide range of hardware-supported cryptographic algorithms are available to create unique message hashes or signatures, and an even broader number of ciphers are available to encrypt plaintext to ciphertext and decrypt ciphertext to plaintext. Although these algorithms can harden security in any application, the ability to protect those applications depends fundamentally on the security of the private keys and other secret data used by cryptographic algorithms.

In cryptography, compromised secrets mean compromised security in the security policies, protocols, and mechanisms built on those secrets. As far back as the 19th century, the cryptographer Auguste Kerckhoffs noted that a cryptographic system will remain secure as long as the key remains secure—an axiom now known as Kerckhoffs' Principle. Put more succinctly, “the enemy knows the system," according to Shannon's Maxim, named after the father of information theory, Claude Shannon.

Indeed, developers build secure systems on the top of well-known algorithms so strictly specified that semiconductor manufacturers can confidently use them in hardware-accelerated security devices. What ultimately protects those systems, however, are the secrets used by those algorithms.

The challenge of protecting secrets

Although protecting cryptography secrets is conceptually straightforward, it can be a significant challenge in practice. Implementation of a higher level security policy will inevitably draw on multiple security protocols using different algorithms. These protocols and algorithms, in turn, require some combination of static keys and ephemeral keys created by the protocol itself. For example, a Transport Layer Security (TLS) session uses a static key during authentication and a shared ephemeral session key for secure message exchange.

In fact, the U.S. National Institute of Standards and Technology (NIST) identifies 19 different types of keys plus another 11 types of related information such as elliptic curve domain parameters and intermediate results that need to be protected. NIST further recommends that to achieve more robust security, information associated with key use should be protected for specific periods of time as noted in Table 1, which shows only the first few key types listed in the complete NIST recommendation[1].

Key Type Security Service Security Protection Association Protection Assurances Required Period of Protection
Private signature key Source authentication
Integrity authentication
Support non-repudiation
Integrity
Confidentiality
Usage or application
Domain parameters (when used)
Public signature verification key
Possession From generation until the end of the cryptoperiod
Public signature verification key Source authentication
Integrity authentication
Support non-repudiation
Integrity Usage or application
Key pair owner
Domain parameters (when used)
Public signature verification key
Validity From generation until no protected data needs to be verified
Symmetric authentication key Source authentication
Integrity authentication
Integrity
Confidentiality
Usage or application
Other authorized entities
Authenticated data
From generation until no protected data needs to be verified
Private authentication key Source authentication
Integrity authentication
Integrity
Confidentiality
Usage or application
Public authentication key
Domain parameters (when used)
Possession From generation until the end of the cryptoperiod
Public authentication key Source authentication
Integrity authentication
Integrity Usage or application
Key pair owner
Authenticated data
Private authentication key
Domain parameters (when used)
Validity From generation until no protected data needs to be verified
Symmetric data-encryption/decryption key Confidentiality Integrity
Confidentiality
Usage or application
Other authorized entities
Plaintext/Encrypted data
From generation until the end of the lifetime of the data or the end of the cryptoperiod, whichever comes later
Symmetric key-wrapping key Support Integrity
Confidentiality
Usage or application
Other authorized entities
Encrypted keys
From generation until the end of the cryptoperiod or until no wrapped keys require protection, whichever comes later

Table 1: This selection from the complete NIST recommendation lists a few of the different types of keys as well as associated information that should be protected for the specified period. (Table source: Digi-Key Electronics, from NIST)

The need to protect keys and associated data means that developers need to exercise meticulous care in using secrets within an IoT application. For IoT devices, a greater challenge can lie in protecting this data in each of its multiple states: at rest, in transit, and in use. Securing data at rest requires secure storage mechanisms; securing data in transit requires methods to protect secrets while being transferred across a network or across a system bus; securing data in use requires mechanisms to prevent exposure while they are being used in execution of cryptographic algorithms. Fortunately, developers can find a broad array of security devices able to protect secret data using a number of different mechanisms.

How to secure secrets in cryptography-enabled semiconductors

Advanced cryptography-enabled semiconductor solutions typically provide some type of secure non-volatile memory for storing keys and other secret data, but the nature of the overall approach differs markedly in the two main classes of secure devices: specialized security ICs and cryptography-enabled processors.

Security ICs are designed to serve as self-contained subsystems that offload algorithm execution from a host processor that typically communicates through a serial bus. For example, Maxim Integrated's DS28C36 secure authenticator provides I2C ports as well as two general purpose I/Os (GPIOs) that can be used to provide an authentication success or failure signal to the host processor (Figure 1).

Diagram of Maxim Integrated DS28C36 secure authenticatorFigure 1: Security devices such as the Maxim Integrated DS28C36 secure authenticator provide complete subsystems that simplify integration while enhancing protection of internal keys and operations. (Image source: Maxim Integrated)

Software integration is typically just as straightforward. For example, NXP's Plug & Trust Middleware library abstracts the hardware functionality of its SE050 and A71CH secure element devices to a few function calls (Figure 2).

Image of NXP's Plug & Trust MiddlewareFigure 2: Software libraries such as NXP's Plug & Trust Middleware allow developers to use a few intuitive function calls to create keys (left), access keys (right), and otherwise take full advantage of underlying functionality in NXP's SE050 and A71CH secure element devices. (Image source: NXP)

Creation of a new key (Figure 2 again, left) returns a keyId. To use the key later, developers refer to the key by its keyId (Figure 3, right) rather than exposing the actual key value across the system bus. Using NXP's Plug & Trust Middleware, developers can rapidly implement secure applications using an Arduino-compatible NXP Kinetis Freedom K64F eval board with an NXP OM-SE050ARD expansion board for SE050 development, or an NXP OM3710/A71CHARD board for AC71CH development.

Dedicated security ICs such as Maxim Integrated's DS28C36, NXP's SE050, NXP's AC71CHTK2/TOBC2VJ, and other devices in this class offer several distinct advantages. Besides offering a relatively simple approach for adding secure functionality to a design, the integration of functionality in a dedicated security IC limits exposure of secret data and operations. For example, the Maxim Integrated DS28C36 integrates hardware cryptography accelerators, a true random number generator, and 8 kilobits (Kb) of secured EEPROM, along with other functional blocks. When the DS28C36 authenticates an Elliptic Curve Digital Signature Algorithm (ECDSA) firmware signature, it ensures protection of data at rest, in transit, and in use because the private key, the associated data (see Figure 1), and the operations that use those secrets remain confined within the device (Figure 3).

Diagram of Maxim Integrated DS28C36Figure 3: The integrated functionality of security devices such as the Maxim Integrated DS28C36 means that private keys and associated data remain confined within the chip. (Image source: Maxim Integrated)

Processor-based secret key protection

Not every IoT design can accommodate a dedicated security IC. Requirements might dictate use of other cryptographic methods or design constraints related to footprint, bill of material (BOM), cost, or customer specifications. For these designs, security enabled processors such as STMicroelectronics' STM32WB55 and Microchip Technology's ATSAML11 provide a combination of cryptographic algorithm hardware acceleration engines and secret data protection mechanisms. Although this article focuses on key protection, these and other processors provide a number of additional sophisticated security features that will be discussed in Part 3 of this series.

In STMicroelectronics' dual-core STM32WB55 wireless device, an Arm® Cortex®-M4 CPU (CPU1) serves as the host processor, communicating with the radio subsystem's dedicated Arm Cortex-M0+ microcontroller (CPU2) through a dedicated inter-processor communication controller (IPCC) and semaphore mechanism (HSEM). Within the CPU2 subsystem, secure memory provides a customer key storage (CKS) area for keys used by the Advanced Encryption Standard (AES) hardware accelerator (Figure 4).

Diagram of dual-core STMicroelectronics STM32WB55 processorFigure 4: The dual-core STMicroelectronics STM32WB55 processor allows direct access to keys only by the radio subsystem core (CPU2) but allows trusted applications running on the host core (CPU1) to use them indirectly. (Image source: STMicroelectronics)

The STM32WB55 architecture protects the CKS keys from access through the debug port or access by non-secure routines running the host CPU1 processor. At the same time, trusted applications running on the host CPU1 can use specific CKS keys in AES cryptography by referencing them using a key index. The AES hardware block receives the desired key from the CKS area through an internal bus, ensuring that key transport remains protected within the CPU2 subsystem.

For its Arm Cortex-M23-based ATSAML11 processors, Microchip Technology relies on security features built into Arm TrustZone technology. TrustZone uses hardware-based mechanisms to enforce isolation between trusted and untrusted resources.

In its ATSAML11 processors, Microchip uses the TrustZone Implementation Defined Attribution Unit (IDAU) to enforce security policies, including differential access control to subregions of memory by secure and non-secure application code. A 256-byte security random access memory (RAM) area, called TrustRAM, provides additional secure storage for ephemeral keys.

Secure provisioning

Dedicated security ICs and processors provide mechanisms developers need to protect secret keys and associated data in an IoT device. Security vulnerabilities often arise, however, due to failures in the process used to initially load, or provision, a security IC or processor with secret keys or certificates, exposing the secret keys to theft. Cybercriminals quickly sell such stolen keys and compromised certificates through black markets, allowing hackers to penetrate secure networks with seemingly valid credentials.

Part 4 of this series discusses security devices and development kits pre-provisioned by manufacturers with keys and certificates for specific IoT cloud services, including Amazon Web Services, Microsoft Azure, Google Cloud, and others. For production deployments, however, developers will most typically prefer or need to use their own custom keys and certificates.

To support custom provisioning, most semiconductor manufacturers offer provisioning through their own facilities or in collaboration with a provisioning partner. For example, Microchip provisions devices with custom secrets created using a secure wrapping tool included in provisioning kits offered by third party partners including Trustonic and IAR Systems' Secure Thingz (Figure 5).

Diagram of secure wrapping toolFigure 5: Original equipment manufacturer (OEM) developers can use a secure wrapping tool to protect secrets used later in a manufacturing partner's secure programming facility to provision secure microcontrollers such as the Microchip SAML11. (Image source: Microchip Technology)

When ready for production, the OEM developer uses the secure wrapping tool to provide keys and certificates to the Microchip factory in an encrypted form that can be decrypted only by a hardware security module located within the partner's secure programming facility. This approach satisfies the need for exchange of production information over unsecure networks, while ultimately yielding production ready devices with securely provisioned keys and firmware.

Self provisioning with PUF technology

The growing use of physical unclonable function (PUF) technology in security enabled processors and dedicated ICs offers perhaps an even more secure approach for provisioning. Rather than explicitly loading a secret key into a device, PUF technology enables security devices to use a secret key derived from each device's unique characteristics.

PUF technology relies on manufacturing variation and other physical processes that result in a value that is unique to the device itself and repeatable under normal system operation. As described below, the resulting value can serve as a unique private key for cryptography, essentially providing each PUF-enabled device with a built-in secret key.

Besides enabling self provisioning, PUF technology adds another layer of security. Attempts to penetrate the device to expose that device-unique value alters the characteristics used to generate it, thus altering the generated value.

Although different PUF mechanisms exist, the basic approach remains largely the same across PUF-enabled devices. For example, Maxim Integrated's ChipDNA PUF feature used in its MAX32520 secure microcontroller, as well as and some security ICs, relies on an array of analog PUF elements and control logic to generate a key (Figure 6).

Diagram of Maxim Integrated's ChipDNA PUF technologyFigure 6: In Maxim Integrated's ChipDNA PUF technology, random states of an array of PUF elements are used by on-chip control logic to generate a consistent device-specific key. (Image source: Maxim Integrated)

In Maxim Integrated's DS28C39 ECDSA secure authenticator, the ChipDNA PUF output is used as the private key for ECDSA operations and as a private key to secure associated data (Figure 7).

Diagram of Maxim Integrated's DS28C39 ECDSA secure authenticatorFigure 7: Maxim Integrated's DS28C39 ECDSA secure authenticator uses a private key generated by its on-chip ChipDNA PUF circuit. (Image source: Maxim Integrated)

For its PUF-enabled LPC55S processor family, NXP uses PUF technology based on the output generated by the initial random state of an SRAM array (Figure 8).

Diagram of NXP's LPC55S processor familyFigure 8: In its PUF implementation, NXP's LPC55S processor family uses the startup data from SRAM to generate a digital fingerprint and associated activation code, which is used later to restore the digital fingerprint and encrypt or generate private keys. (Image source: NXP)

In these devices, use of PUF begins with an enrollment operation that generates a unique digital fingerprint and associated activated code that remain valid until a new enrollment operation is executed. Stored in the device's protected flash, the activation code allows the device to reconstruct the digital fingerprint from the SRAM startup data consistently generated at power up.

With the digital fingerprint in place, developers can encrypt their own keys or generate keys. In this process, the device returns a key code. By providing the activation code, key code, and index, developers can cause the device to decrypt the desired private key from the appropriate on-chip key slot and deliver it to a cryptography software library. Key slot 0 provides a special key decryption method that delivers the key through an internal bus directly to the processor's AES hardware cryptography engine (Figure 9).

In its role in key encryption and decryption, the LPC55S's PUF digital signature serves as a key encryption key (KEK) traditionally used to enhance protection of secret data at rest or in transit. Use of a KEK helps relieve requirements for larger secure storage and associated internal mechanisms needed to protect secret data.

Diagram of NXP's LPC55S processor familyFigure 9: NXP's LPC55S processor family uses its digital fingerprint as a KEK to decrypt keys protected in its key store and referenced programmatically using the associated activation code, key code, and index. (Image source: NXP)

Developers can use a KEK to encrypt custom keys and associated data and store the encrypted results in non-secure, non-volatile memory. This approach permits developers to protect the diverse types of keys and associated data even in devices with limited secure storage. With the availability of PUF-generated KEKs, developers can implement secure IoT devices able to protect applications across the entire development cycle.

Conclusion

The availability of dedicated security ICs and secure processors with cryptography accelerators has dramatically enhanced developers' ability to build secure systems. Yet, secure systems depend critically on the security of private keys and other data associated with cryptography mechanisms and protocols. Employing a number of different mechanisms, security devices provide protection of secret data at rest, in transit, and in use. Using these devices, developers can build more secure IoT solutions without compromising other design requirements.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Stephen Evanczuk

Stephen Evanczuk has more than 20 years of experience writing for and about the electronics industry on a wide range of topics including hardware, software, systems, and applications including the IoT. He received his Ph.D. in neuroscience on neuronal networks and worked in the aerospace industry on massively distributed secure systems and algorithm acceleration methods. Currently, when he's not writing articles on technology and engineering, he's working on applications of deep learning to recognition and recommendation systems.

About this publisher

Digi-Key's North American Editors