This is because a successful attack could lead to the leakage of corporate and personal data. Securing IoT applications can be a very challenging task, as developers must carefully coordinate multiple security mechanisms, protocols, and strategies, which can seem incredibly complex when combined. In reality, the security of IoT devices can be built on a few relatively simple principles and supported by hardware security devices. These problems can be solved by following sound security practices. This series of articles consists of several parts, providing practical guidance to help developers ensure they follow relevant best practices from the outset. Part 1 explores the cryptographic algorithms used in the underlying security design. Part 2 (this article) discusses the role of private keys, key management, and secure storage in secure IoT design. Part 3 examines the built-in mechanisms of security processors to mitigate other types of threats faced by IoT devices. Part 4 clarifies and demonstrates how to apply security mechanisms in advanced processors to help ensure the necessary isolation to mitigate attacks on the runtime environment of IoT devices. Part 5 introduces how to achieve continuous IoT security for IoT devices by adopting higher-level security measures when connecting them to IoT cloud resources.
While hardware-based encryption devices can reduce vulnerabilities in the Internet of Things (IoT), even the strongest encryption devices will compromise security if keys and related data lack adequate protection. Semiconductor manufacturers address the protection of keys and other privileged data by using dedicated security ICs and various security mechanisms built into processors.
This article reviews the crucial role of keys in encryption technology and introduces the different key protection mechanisms built into devices offered by Maxim Integrated, NXP, STMicroelectronics, and Microchip Technology.
The role of keys in encryption technology
As described in Part 1 of this series, a variety of hardware-supported encryption algorithms can be used to create unique message hashes or signatures. Even broader encryption methods can be used to encrypt plaintext into ciphertext and decrypt ciphertext back into plaintext. While these algorithms can enhance application security, the security of these applications fundamentally depends on the security of the private keys used by the encryption algorithms and other confidential data.
In encryption, key leakage means that the security of security policies, protocols, and mechanisms built upon those keys will be compromised. As early as the 19th century, cryptographer Auguste Kirkhoffs pointed out that as long as the key is secure, the encryption system will remain secure—this axiom is now known as the Kirkhoffs principle. More simply, "the enemy knows the system," a saying named after Claude Shannon, the father of information theory.
In fact, it is precisely because developers build security systems based on such rigorously defined and well-known algorithms that semiconductor manufacturers can confidently use them in hardware-accelerated security devices. However, what ultimately protects these systems is the key used by these algorithms.
Challenges in protecting keys
While protecting encryption keys is conceptually quite simple, it can present significant challenges in practice. Implementing higher levels of security inevitably involves various security protocols employing different algorithms. These protocols and algorithms, in turn, require a combination of static 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 National Institute of Standards and Technology (NIST) has identified 19 different types of keys and 11 other types of related information that need to be protected, such as elliptic curve domain parameters and intermediate results. NIST further recommends that, for stronger security, information related to key usage should be protected for specific periods, as shown in Table 1. This table only shows the first few key types listed in the complete NIST recommendations [1].
Keys and related data need to be protected, which means developers must be extremely careful when using keys in IoT applications. For IoT devices, an even greater challenge lies in protecting this data in different states (at rest, in transit, and in use). Protecting data at rest requires secure storage mechanisms; protecting data in transit requires methods to protect keys when transmitted over networks or system buses; and protecting data in use requires mechanisms to prevent key disclosure when the key is used to execute encryption algorithms. Fortunately, developers can find a wide variety of security devices using various mechanisms to protect confidential data.
How to protect keys in semiconductors with encryption technology
Semiconductor solutions that enable advanced encryption typically provide some form of secure, non-volatile memory for storing keys and other confidential data, but in terms of the nature of the overall approach, there are two distinct categories of security devices: dedicated security ICs and encryption-enabled processors.
Security ICs are designed as self-contained subsystems that can offload algorithm execution tasks from the host processor (typically via a serial bus). For example, Maxim Integrated's DS28C36 security authenticator provides an I2C port and two general-purpose I/O (GPIO) ports that can be used to send signals to the host processor indicating success or failure of authentication (Figure 1).
Figure 1: Maxim Integrated's DS28C36 security authenticator and other security devices provide a complete subsystem that simplifies integration while enhancing protection for internal keys and operations. (Image source: Maxim Integrated)
Software integration is usually quite straightforward. For example, NXP's Plug & Trust middleware library abstracts the hardware functionality of its SE050 and A71CH secure element devices into a few function calls (Figure 2).
Figure 2: NXP's Plug & Trust middleware and similar software libraries allow developers to create keys (left), access keys (right), and fully utilize the low-level functionality of NXP's SE050 and A71CH secure element devices using intuitive function calls. (Image source: NXP)
Creating a new key (see also Figure 2, left) returns a keyId. To use this key later, developers can reference it via its keyId (Figure 3, right), instead of exposing the actual key value via the system bus. Using NXP's Plug & Trust middleware, developers can quickly implement security applications by pairing the Arduino-compatible NXP KineTIs Freedom K64F evaluation board with the NXP OM-SE050ARD expansion board to develop the SE050, or with the NXP OM3710/A71CHARD board to develop the AC71CH.
Dedicated security ICs such as Maxim Integrated's DS28C36, NXP's SE050, and NXP's AC71CHTK2/TOBC2VJ, as well as other devices in this category, offer several distinct advantages. Besides providing a relatively simple way to add security features to a design, integrating functionality into a dedicated security IC restricts the release of confidential data and operations. For example, Maxim Integrated's DS28C36 integrates a hardware encryption accelerator, a true random number generator, an 8-kilobyte (Kb) secure EEPROM, and other functional modules. When verifying Elliptic Curve Digital Signature Algorithm (ECDSA) firmware signatures, the DS28C36 ensures protection of data at rest, in transit, and in use because the private key, associated data (see Figure 1), and operations using these keys are all enclosed within the device (Figure 3).
Figure 3: The integrated functionality of security devices such as Maxim Integrated's DS28C36 means that the private key and related data are all contained within the chip. (Image source: Maxim Integrated)
Processor-based key protection
Not every IoT design can accommodate a dedicated security IC. Certain requirements may necessitate the use of alternative encryption methods, or there may be design constraints related to packaging, bill of materials (BOM), cost, or customer specifications. For these types of designs, security-enabled processors, such as STMicroelectronics' STM32WB55 and Microchip Technology's ATSAML11, offer a combination of hardware acceleration engines for encryption algorithms and confidential data protection mechanisms. While this article focuses on key protection, these and other processors offer a variety of other sophisticated security features, which we will cover in Part 3 of this series.
In STMicroelectronics' dual-core STM32WB55 wireless device, the Arm® Cortex®-M4 CPU (CPU1) serves as the host processor, communicating with the dedicated Arm Cortex-M0+ microcontroller (CPU2) of the wireless electronics system via a dedicated inter-processor communication controller (IPCC) and semaphore mechanism (HSEM). Within the CPU2 subsystem, secure memory provides a client key store (CKS) area for the keys used by the Advanced Encryption Standard (AES) hardware accelerator (Figure 4).
Figure 4: STMicroelectronics' STM32WB55 dual-core processor only allows direct access to the key by the wireless electronic system core (CPU2), but allows trusted applications running on the host core (CPU1) to use the key indirectly. (Image source: STMicroelectronics)
The STM32WB55 architecture protects the CKS key from access by the debug port or insecure routines running on the host CPU1 processor. Meanwhile, trusted applications running on host CPU1 can use specific CKS keys in AES encryption by referencing the key using a key index. The AES hardware module receives the required key from the CKS area via the internal bus, ensuring that key transmission remains protected within the CPU2 subsystem.
In the Arm Cortex-M23-based ATSAML11 processor, Microchip Technology relies on the security features built into Arm TrustZone technology. TrustZone uses a hardware-based mechanism to enforce the isolation of trusted and untrusted resources.
In the ATSAML11 processor, Microchip uses TrustZone to implement a defined Ownership Unit (IDAU) security policy, including differentiated access control for memory sub-regions based on secure and non-secure application code. A 256-byte secure random access memory (RAM) region, called TrustRAM, provides additional secure storage for temporary keys.
Secure configuration
Dedicated security ICs and processors provide developers with the mechanisms needed to protect keys and related data in IoT devices. However, security vulnerabilities frequently arise due to malfunctions during the initial loading or configuration of the security IC or processor using keys or certificates, making keys susceptible to theft. Cybercriminals rapidly sell these stolen keys and compromised certificates on the black market, allowing hackers to infiltrate secure networks using seemingly valid credentials.
Part 4 of this series will discuss the security appliances and SDKs that manufacturers use pre-configured with keys and certificates for specific IoT cloud services, including Amazon Web Services, Microsoft Azure, Google Cloud, etc. However, in production deployments, developers typically prefer or need to use their own custom keys and certificates.
To support custom configurations, most semiconductor manufacturers offer configuration services either through their own facilities or in partnership with configuration partners. For example, Microchip's custom keys for device configuration are created using secure wrapper tools included in configuration kits provided by third-party partners, such as Trustonic and IAR Systems' Secure Thingz (Figure 5).
Figure 5: Original Equipment Manufacturer (OEM) developers can use secure packaging tools to protect keys that will later be used in secure programming tools at manufacturing partners to configure secure microcontrollers (such as the Microchip SAML11). (Image source: Microchip Technology)
Once production is ready, OEM developers use secure packaging tools to provide keys and certificates to the Microchip factory in encrypted form. These keys and certificates can only be decrypted by hardware security modules within the partner's secure programming facility. This approach addresses the need to exchange production information over insecure networks, ultimately resulting in production-ready devices with securely configured keys and firmware.
Self-configuration using PUF technology
The increasing use of Physically Unclonable Function (PUF) technology in security-enabled processors and application-specific integrated circuits (ASICs) may offer an even more secure configuration method. Utilizing PUF technology, secure devices can use keys derived from the unique characteristics of each device, rather than explicitly loading keys into the device.
PUF technology relies on manufacturing variations and other physical processes to ensure that the value is unique to the device itself and repeatable under normal system operation. As described below, this resulting value can be used as a unique cryptographic private key, essentially providing a built-in key for each PUF-enabled device.
In addition to enabling self-configuration, PUF technology adds another layer of security. If an attempt is made to penetrate a device to expose its unique value, the characteristics used to generate that unique value will be altered, thus changing the generated value.
Despite the existence of different PUF mechanisms, the basic approach for devices that enable PUF technology is largely the same. For example, the ChipDNA PUF function used by Maxim Integrated in its MAX32520 security microcontroller and some security ICs relies on a series of analog PUF elements and control logic to generate keys (Figure 6).
Figure 6: In Maxim Integrated's ChipDNA PUF technology, on-chip control logic uses a series of random states of PUF elements to generate a consistent device-specific key. (Image source: Maxim Integrated)
In Maxim Integrated's DS28C39 ECDSA security authenticator, the ChipDNA PUF output is used as the private key for ECDSA operations, as well as the private key for protecting related data (Figure 7).
Figure 7: Maxim Integrated's DS28C39 ECDSA security authenticator uses a private key generated by its on-chip ChipDNA PUF circuitry. (Image credit: Maxim Integrated)
In the LPC55S processor series with PUF technology enabled, NXP uses PUF technology based on the output generated according to the initial random state of the SRAM array (Figure 8).
Figure 8: In the PUF implementation, NXP's LPC55S processor series uses boot data in SRAM to generate a digital fingerprint and associated activation code, which can then be used to recover the digital fingerprint, perform encryption, or generate a private key. (Image source: NXP)
In these devices, the use of PUF begins with a registration process that generates a unique digital fingerprint and an associated activation code. These fingerprints and activation codes remain valid until a new registration process is performed. The activation code is stored in the device's protected flash memory, and the device uses this activation code to reconstruct the digital fingerprint using SRAM boot data generated in a consistent manner upon power-up.
With a digital fingerprint, developers can encrypt their own keys or generate keys. In this process, the device returns a key code. By providing an activation code, key code, and index, developers can instruct the device to decrypt the required private key from the appropriate on-chip key slot and deliver it to the cryptographic software library. Key slot 0 provides a special key decryption method that delivers the key directly to the processor's AES hardware encryption engine via the internal bus (Figure 9).
The LPC55S's PUF digital signature acts as a key encryption key (KEK) in key encryption and decryption, a key traditionally used to enhance the protection of confidential data at rest or in transit. Using a KEK helps alleviate the need for larger secure storage and related internal mechanisms required to protect confidential data.
Figure 9: NXP's LPC55S processor series uses its digital fingerprint as a KEK to decrypt the key protected in its key store using a programmable method with associated activation code, key code, and index reference key. (Image source: NXP)
Developers can use a KEK to encrypt custom keys and related data, storing the encryption results in insecure, non-volatile memory. This approach allows developers to protect various types of keys and related data even on devices with limited secure storage. With a PUF-generated KEK, developers can implement secure IoT devices that protect applications throughout the entire development lifecycle.
Summarize
The advent of dedicated security ICs and security processors with cryptographic accelerators has greatly enhanced developers' ability to build secure systems. However, secure systems heavily rely on the security of private keys and other data related to cryptographic mechanisms and protocols. Security devices can protect confidential data at rest, in transit, and in use by employing a variety of different mechanisms. Using these devices, developers can build more secure IoT solutions without compromising other design requirements.
