Benefits of an integrated secure element

With the rising number of security incidents impacting the IoT, legislators are increasingly pushing to mandate minimum security levels for certain IoT devices or application areas. An integrated secure element not only helps address these imperatives, but it also delivers additional benefits such as secure software updates and secure debug unlock, features that cannot be easily achieved with an external secure element.

Historically, a secure element (SE) is a physical device implemented on a smartcard or dedicated integrated circuit (IC) providing security-related services such as secure key storage or a secure identity to a host system. Communication with the host system occurs over an encrypted link. The advantage of this approach is that the SE is a bill-of-materials (BOM) option that can be left out to save cost in applications with relaxed security requirements. With a SE in the form factor of a smartcard, a secure device identity can be delivered in a format that can easily be moved from one host to another, a popular scheme with many use cases.

On the other hand, robust security features are not optional for state-of-the art IoT devices. According to a recent article in Forbes, cyber attacks on IoT devices surged 300% in 2019, including 2.9 billion attacks on internet connected IoT devices in the first half of 2019 alone. Looking at smart home devices that are not directly connected to the internet, the numbers of actual attacks are expected to be smaller by orders of magnitude. However, uncovering the vulnerabilities of connected devices has sparked negative news coverage for both the IoT industry and for the manufacturers of the affected devices. Reacting to reports about vulnerabilities of smart devices, regulators as well as consumer rights associations have lobbied for legal frameworks mandating defined security levels for certain IoT devices. For example, California recently implemented a new law aimed at regulating the security of IoT devices, and other state and national governments are following suit.

Above: Figure 1. Choosing the right level of security is imperative to keeping a device secure for the duration of its life

The desire to include some or all of the security features offered by a SE in all connected devices of a given product family eliminates any advantage that comes from running the SE as an optional item on the BOM. Every line of the BOM means adding more cost to the smart device, and this is not just the cost of the SE hardware itself, but also the cost of real estate on the printed circuit board (PCB), pick and place, inspection and testing, etc. Considerable cost savings can be achieved by using an SE that is integrated into the host. In addition to reducing the cost and complexity of the hardware design, an integrated approach also eliminates the attack vector of compromising the communication lines between the host and the SE.

Secure element functionality

Both internal and external secure elements may offer some or all of the following features.

Immutable Device Identity: An immutable device identity comprises a unique, tamper-proof identity by which the device can be identified and also provides security credentials by which the device can be authenticated. This feature may include a unique device identifier, a certificate or other means, e.g. a token-based authorisation. The important point is that the device identity cannot be compromised without an effort that is more costly than the potential reward of hacking the device.

Secure Key Storage: Secure key storage is effectively a protected area of flash memory controlled by and only accessible to the SE. According to Kerckhoffs’s principle, this solves the problem that the best cryptographic algorithm is only secure as long as the secret key data cannot be extracted using a side-channel attack. In this type of attack, the cryptographic algorithm is not compromised or even overcome by brute force, but instead the secret key data is extracted. The SE can ensure that extraction of the secure key data from the device’s debug interface is not possible, and even a potentially compromised application cannot gain access to this data.

Above: Figure 2. The secure debug unlock feature enables easier failure analysis activities for IoT devices

Hardware Crypto Accelerator: Hardware crypto accelerators not only save time and power on complex crypto operations, but they can also implement state-of-the-art countermeasures against side-channel attacks such as differential power analysis (DPA). Combined with a secure key storage, it is possible that a given security key never leaves the SE, but instead the SE is instructed to perform a defined crypto operation using a certain key from the secure key storage. Only the data payload is exchanged between the SE and the application, and the actual key is neither visible nor extractable by the application during this operation.

High-Entropy Random Number Generator: High-entropy random numbers are critical to the cryptographic algorithms and key generation used in the security and encryption of many modern communications and security protocols. Creating a true random number (TRNG) is a complex process as digital algorithms are inherently bad at creating truly random numbers. If any bias in generating a random number can be determined, hackers can use that weakness to reduce the time and effort they need to acquire keys. To counteract this limitation, random number generators are implemented as a hardware peripheral with dedicated on-chip circuits designed to generate random numbers with a very high entropy.

Additional functionality of an integrated SE

An integrated secure element can provide the following additional, unique functionality.

Secure Debug Unlock: If left unlocked, the debug port of any SoC constitutes a significant security vulnerability. Thus, the security best practice is to lock or disable debug access before a product is released to the field. Most SoCs include a debug lock mechanism for this purpose. With an integrated SE, it is also possible to offer a secure debug unlock feature to make it easier to conduct failure analysis activities on devices coming back from the field.

This is particularly useful for field trials and initial product roll-outs to ‘friendly customers’, but also at a later stage it is desirable to conduct failure analysis on devices returned from the field to improve product quality. Access to the debug port can be enabled through the presentation of a unique unlock token. This token is generated by signing a revocable unique identifier with a manufacturer generated private key. The main benefit of secure debug unlock is that device data doesn’t have to be erased when unlocking the device, resulting in reduced troubleshooting time and enhanced root cause failure analysis.

Above: Figure 3: The secure boot process begins with the secure element and leverages first- and second-stage bootloaders

Secure Boot with full Root of Trust and Secure Loader: A common implementation of secure boot consists of storing the public key used for authentication of the program code into one-time programmable memory. As the public key becomes irreversible, only program code signed with the corresponding private key will be authenticated and executed. The authentication step is typically executed by some form of bootloader.

Using an integrated SE, we can take additional steps by following a full chain of trust process as shown in Figure 1. It can be seen that we effectively have a dual-core architecture with the first core being the SE itself with its own dedicated flash memory, ROM, RAM and peripherals. The second core is the potentially more capable application core with all the memories and peripherals offered by a typical SoC designed for the IoT.

The secure boot process starts at the secure element. Booting up starts from secure immutable ROM and confirms authenticity of the first stage bootloader, which is executed by the SE. During this process, checks for updates of the first stage bootloader are also executed through a secure loader. Once the secure element is fully verified and available, the second (application) core initiates, authentication of the second stage bootloader is performed, and updates are applied through a secure loader, if required. In the final stage, the second stage bootloader checks, updates (if applicable) and authenticates the application code. This process is also illustrated in Figure 3.

As a countermeasure against attacks, it is good practice to adhere to a strict policy of only allowing upgrades to new versions of the firmware for any updateable components including the following:

• First-stage bootloader
• Second-stage bootloader
• The application

This approach prevents known vulnerabilities from being exploited by installing older firmware. At the same time, this also prevents repeated decryption of the signed, and encrypted firmware update images can be triggered to extract the keys used in this process using a side-channel attack such as differential power analysis.

Conclusion

Smart IoT devices require state-of-the-art security features not only for good governance, but also to comply with legal obligations required in many regions and vertical markets. An integrated secure element offers excellent value and cost savings to achieve device security in the never-ending arms race between hackers and device manufacturers. Compared to using a dedicated external SE, an integrated SE enables considerably more cost savings. Key features such as secure debug unlock and secure boot with full root of trust are built on prerequisites that only an integrated SE can deliver.