Renesas — Implement Hardware Security in IoT Devices

How To Implement Integrated Hardware-Based Security in IoT Devices

By Renesas

While many microcontroller vendors focus on extracting and isolating security into a secondary chip, often referred to as a Secure Element, Renesas recognizes IoT trends, knowing this architecture has some fundamental weaknesses. Renesas focuses on integrating hardware security functionality directly into its MCUs, enabling efficient, cost-effective security solutions for IoT devices.

Renesas has a long history of producing high-quality, certified hardware security products, going back as far as 1999 with its certified smartcard platforms. This technology was then introduced into Renesas’s automotive devices in 2012, with industrial and consumer products following in 2014.

The current Trusted Secure IP (TSIP) and Secure Crypto Engines (SCE) included in the Renesas RA Family, Renesas RX Family and Renesas Synergy™ devices are the result of more than a decade of evolution of integrated security technology, with continuing development addressing the ever-increasing range of security threats.

The Renesas security engines are isolated sub-systems on the MCU, managed and protected by dedicated control logic (see Figure 1). A Renesas-provided driver handles the proper access sequence. Improper access via either the CPU or the debugger locks the Access Management Circuit until the MCU is reset. All cryptographic operations are physically isolated within the security engine, which contains its own dedicated RAM for internal operation. Coupled with Renesas’s advanced key handling capabilities, this prevents plaintext key exposure on any CPU-accessible bus.

Fig. 1: Renesas’s integrated security engines

Regardless of the choice of integrated or detached security functions, the decision to include hardware security features in a product must be made at the beginning of a product’s definition and design. It is nearly impossible to add security to something which already exists, simply because the necessary low-level supporting infrastructure and architecture will not be available.

It is also vital to determine exactly which security threats need to be mitigated before jumping to a specific solution. The solutions for firmware IP protection are quite different from the solutions for protecting data stored on the device, which in turn are very different from those which protect data in flight.

Table 1: cryptographic features of Renesas MCUs with a hardware security engine

Many IoT security solutions, however, do have a common core of required functionality involving cryptographic algorithms. While it is tempting to focus on the cryptographic algorithms and debate their relative merits, it is vital to remember that the protection provided by the algorithms is only as good as the protection of the keys that are used with those algorithms. Using plaintext keys in an MCU application is similar to locking the front door but leaving the key under the mat – it only takes a curious passer-by looking in the right place at the right time to expose the capability to open the door.

Since the identity of an IoT device is often represented by a cryptographic key, it is even more vital that the device have a strong, secure key storage mechanism which cannot be compromised, duplicated or transferred.

Secure Elements have been promoted as the easy solution to this problem: program your keys and certificates on to a discrete chip, mount that chip on a board, connect it to your host processor, and you are done. Unfortunately, it is not quite that simple. Let’s take a look at some specific points.

Provisioning

Because a Secure Element has a fixed number of keys and certificates, provisioning it is reasonably straightforward: it is a matter of generating keys and certificates, and transferring them to a secure programming facility. The Secure Element will then be shipped with those keys and certificates locked inside them.

While this works well for identity provisioning, it does not take care of the programming of the valuable application firmware, which will need to be done in an additional step, potentially in a secure environment. Isolated identity can be adequate if an application’s identity can be completely provisioned at the time of manufacture, but what if the identity needs to be provisioned in the field, during deployment? If a product needs to be connected to a specific infrastructure in the field and provisioned as part of that infrastructure, most likely at least the last aspect of identity will be provisioned during the installation. Whereas a Secure Element might require the entire provisioning infrastructure to install keys and certificates, Renesas MCUs support flexible use cases, from enabling secure storage of plaintext keys, to secure key installation performed by either the device programmer or the application, to the creation of an MCU-unique cryptographic identity on the MCU itself with the private key never exposed anywhere outside the MCU (see Table 1).

These capabilities enable one-stop secure provisioning and programming of the application firmware. The fixed number of keys and certificates on a Secure Element can also be a problem. If the application calls for certificate chaining, key rotation, or multiple keys for failure recovery or fine-granularity access authentication, a Secure Element might not offer enough slots. Renesas MCUs allow applications to store all keys securely, no matter the physical location of the key, by using an MCU-unique key wrapping algorithm. Key wrapping involves encrypting the key with the addition of an integrity check. Renesas expands on this concept by incorporating MCU-unique information into the derived key-encryption key. The resulting wrapped key can then be unwrapped and used only by the individual MCU that wrapped it, and more specifically, only by the security engine within that individual MCU. This capability enables not only unlimited key storage, but it also forms the foundation of anti-cloning solutions which are tied directly to the MCU containing valuable firmware IP.

In addition, a Secure Element’s identity is physically located in a separate component which could theoretically be removed from the circuit board or have its communication lines connecting it to the host processor tapped. In this case, any external MCU can use the information held in the Secure Element. If these sorts of physical attacks are included in a product’s threat model, the physical separation of identity from the IP could be a concern.

High-Speed Communication

One of the main use cases of cryptography is to enable confidential communication by encrypting the exchanged data. The price of confidentiality, however, is speed: the data must be encrypted before it is transmitted, and it must be decrypted when it is received. This process can take a substantial amount of time, even forcing some applications to eliminate this protection simply because communication speed was deemed to be more important than data confidentiality.

Hardware-accelerated cryptography can solve this problem by providing an increase in processing speed of over 100x the speed of a software implementation. This speed gain is somewhat negated, however, if the operation needs to be performed on a separate processor. This architecture requires the primary communication stack to use a secondary communication interface, send the information to the separate processor for encryption/decryption, and then receive the resulting data. The primary communication stack must be designed to manage the added complexity of shuffling data back and forth. This also exposes the plaintext data outside the MCU, on that secondary communication interface.

If the hardware-accelerated cryptographic functions are performed on the same device as the primary communication stack, no extra data movement is required. The encryption/decryption step can simply be added at the relevant point in the data flow, with no plaintext data ever exposed outside the MCU. When combined with Renesas’s secure key storage, both optimum throughput and ultimate confidentiality are achieved.

Updating Security Functionality

Security attacks are constantly evolving. Hackers continually increase both their skills and their ingenuity. Systems that were considered practically unbreakable a few years ago have now been retired, as their protection has been deemed to be too weak. It is vital, therefore, that devices with a lifespan that is measured in years are updateable, so that they can be updated to respond to the evolving threat landscape.

Unfortunately, many Secure Elements are simply not updateable. If a weakness or error is discovered in their implementation, that vulnerability will remain with the product for its entire lifetime. A small selection of Secure Elements are field-updateable, but this adds complexity to the product, as the product itself has to include the capability to manage and perform the update of the Secure Element.

When the security features are integrated into the main MCU, a security feature update can be included with the primary application update, backed by appropriate authentication checks to ensure the validity of the update. This enables the product to keep pace with emerging security trends.

Product Cost

In nearly all cases, a two-chip solution is going to cost more than a single-chip solution. Renesas MCUs offering integrated, advanced security features are priced competitively against MCUs that are lacking in critical features, particularly secure key storage for anti-cloning protection. The use of a second device to provide this functionality will not only increase the product’s bill-of-materials cost, but it will also require additional board space and consume more power, all of which are extremely sensitive points for IoT devices.

Certification

Certification requirements are industry-specific. Most certifications, however, pertain to the product as a whole, not simply the individual chips inside the product. It is vital to determine which regulations apply to a product, and which individual device certifications can assist the product certification effort.

One of the most commonly required certifications is National Institute of Standards and Technology’s (NIST) Cryptographic Algorithm Verification Program (CAVP). This certification assures that the cryptographic algorithm is functionally and operationally correct. The easiest way to check for this certification is to search the NIST database for the device vendor, at csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation. Most Secure Elements have multiple certified algorithms, as do Renesas MCUs and security engines.

Additional certifications, such as NIST Cryptographic Module Verification Program (CMVP), also known as FIPS 140-2, add more evaluation criteria, most notably tamper detection and tamper response. These certifications are more difficult for a general-purpose MCU, not because they do not have the required capabilities, but because some of the capabilities require application implementation. It is important here to study the specific requirements of the applicable regulations and determine whether the device certification or device capabilities are required.

Integrated Security for IoT

IoT devices serve a wide range of applications and adopt various architectures, from simple battery-powered sensors which use low-bandwidth wireless protocols, to mains-powered controllers with graphical user interfaces and Wi-Fi^® or cellular connectivity. Just as there is no such thing as a typical IoT device, security for IoT devices is never a one-size-fits-all proposition.

Security means different things to different people, and it is always a question of protecting valuable assets against viable threats at a reasonable cost. It is crucial to use a flexible security platform that can be scaled both up and down depending on the threat model for each product. The integrated security offerings of Renesas MCUs featuring NIST-certified cryptographic algorithms and MCU-unique key-storage capabilities are the perfect foundation on which to build secure IoT devices in today’s connected world (see Table 2).

Table 2: comparison of detached and integrated security features