AN2604: Unlocking Secure Elements Advantages Beyond Built-in Microcontroller Security

Introduction

Secure elements are dedicated ICs that perform cryptographic functions and provide tamperresistant secure storage for keys and credentials. They are frequently used in embedded applications and in most cases are connected to a host microcontroller through a serial bus such as I²C or SPI.

Secure elements historically were designed to enable the upgrade of a system with minimal design effort. The immediate advantage of secure elements is that one can add security to a system without changing the processor nor the architecture, thus saving the effort that a comprehensive redesign would require.

Are Secure Elements Still Necessary?

With the increased needs for security, the natural path taken by most microcontrollers vendors has been to integrate it in microcontrollers, embedding cryptographic and security functions such as:

• Digital signature computation and verification
• Encryption
• Secure storage
• Random number generation

Based on these integrated security building blocks is a secure element redundant vs. the security features of a general-purpose microcontroller? We will see in this document that there is no simple answer to this question. Let us review the commonalities and differences.

Isolation

In general, it is desirable to have security-critical firmware isolated from the rest of the software, which provides the following advantages:

• Isolation allows implementation of small, security-focused firmware separated from a complex, feature-rich, operating system that would otherwise expose a large attack surface.
• Simple software reduces the chance to carry bugs that could be further exploited by attackers to get access to sensitive assets or bypass security mechanisms.
• Providing higher assurance, code review is feasible for a reasonably small piece of software, while it would probably be very challenging to achieve a code review for the whole firmware.

In microcontrollers, various mechanisms support isolation. Arm TrustZone® is one that is widely used; MMUs and MPUs are also popular. While these mechanisms are valuable, their implementation determines whether they could be defeated using attack techniques such as glitch attacks [1]. Also, to be effective, hardware isolation must be exploited by proper configuration and software implementation. For example, memory boundaries for the secure and nonsecure areas must be carefully defined. An improper configuration would result in exploitable faults.

The benefit of using a secure element is that the isolation is physical and cannot be broken. There is no possibility for the firmware running on the microcontroller to interfere with the firmware running in the secure element. The isolation provided by the dual-chip architecture is more robust than the one supported by mechanisms internal to a microcontroller.

It is also possible to combine the internal isolation mechanisms of the microcontroller with the usage of a secure element. For example, the security-critical software calling to the secure element runs in the Trusted Execution Environment (TEE) created by Arm TrustZone, and the overall level of security is reenforced.

Cryptographic Computation, Functional Aspect

Currently, most implementations are based on crypto algorithms that have been approved by the community of experts or by institutes such as NIST or BSI. If implementations in both microcontrollers and secure elements are compliant with related standards, we can say from a functional point of view that there is no difference. In this case, secure elements do not bring value over security functions implemented in microcontrollers. It could be wise, though, to check for the conformity of implementation. As an example, the NIST Cryptographic Algorithm Verification Program (CAVP) guarantees the conformity of crypto algorithms implemented in an IC. Other certification schemes can also bring similar level of assurance.

Secure Storage of Keys

As explained above, modern cryptography algorithms are public. As it has been proven to be the correct approach over proprietary cryptography, the consequence is that access to the private or secret keys would completely break the security scheme, as keys are the most valuable assets in a secure embedded system.

In microcontrollers, keys are most often stored in flash or OTP. They can benefit from the logical isolation mechanisms described above.

While logical isolation provides a first level of protection, it is not as strong as physical isolation.

• Logical hardware protection mechanisms can be defeated by physical attacks such as fault injection through glitches or laser beam. [1] Glitch attacks do not require costly equipment and do not require strong academic knowledge to be effective, thus they are very harmful.
• Reading flash or OTP content and thus accessing the private or secret key can be achieved with affordable equipment and also does not require expert level knowledge [2].

Reading flash or OTP requires significantly higher investment and time than side-channel or fault injection attacks, but is not out of reach as one would imagine. Equipment such as scanning electronic microscopes are accessible in certain universities or research laboratories, and the techniques are well described in literature. [2] Typically, a motivated hacker would invest the time and money necessary to get access to the keys if the assets have sufficient value compared to the investment.

Secure elements offer secure storage with a much higher level of resistance than standard flash memories. For example, the Analog Devices MAXQ1065 and DS28S60 feature encrypted nonvolatile memory (NVM). Thanks to strong encryption, it is impossible for an attacker to extract the keys even after revealing the NVM content. As the memory encryption key could be itself the target of extraction, rather than storing this key in NVM, it is actually generated by the ChipDNA® physical unclonable function (PUF). Techniques for reading flash or OTP are nonapplicable because the memory encryption key:

• Is not stored in NVM
• Is not stored in NVM

Whenever embedded in the microcontroller or in the secure element, PUF enables the most secure storage for keys or sensitive information. If the risk profile includes a high level of resistance against physical attacks, PUF-enabled secure storage is the best storage to use.

However, if PUF is not present in the microcontroller, adding a secure element would enable the highest level of resistance against physical attacks.

Easily Injecting the Keys in the End Product

Some microcontrollers may feature PUF-enabled highly secure storage. However, injecting the secret keys in the protected memory of the MCU could be a challenge. In general, a physically secured facility is required to manipulate secret keys in order to inject them into the MCU. Not all OEMs can invest in a secure facility, and the situation is even more complex when they rely on contract manufacturers.

Analog Devices offers key provisioning services and can program keys on behalf of OEMs. Keys and certificates are programmed in our factory and sent locked to the OEMs or authorized contract manufacturers. Preprogrammed secure elements are an easy way to provide keys and credentials in final products.

Robustness of Cryptographic Computation

While the implementation of a cryptographic algorithm might be functionally correct, it might be sensitive to side-channel or fault attacks.

Side-channel attacks consist of monitoring involuntarily emitted signals during cryptographic operations and by further applying signal processing techniques to extract the keys used during computation.

In unprotected implementations, it is generally admitted that an attacker with even moderate skills (such as a university student) and affordable equipment (a digital oscilloscope) would be able to extract a key from a microcontroller in less than a day.

Side-channel attacks apply to both hardware and software implementations of cryptographic algorithms, and several successful attacks have been reported on both types of implementations. A software cryptographic library running on an MCU is not necessarily unsafe, but rather an implementation that is not secured by design is vulnerable. Levels of resistance vary greatly, but microcontrollers vendors do not always disclose the level of resistance they support.

Another vulnerability is cryptographic key recovery due to fault injection. Injecting a fault consists of intentionally changing the behavior of an IC by means such as glitches, laser beam, or electromagnetic pulse. For example, a glitch on the power pin could generate a timing violation, thus resulting in an error in cryptographic computation. A skilled attacker can apply glitches during specific cryptographic computations steps. By collecting several samples of faulty computations and analyzing the differences with an adequate computation, an attacker could retrieve the secret keys, such as AES keys [3]. This approach is known as differential fault analysis (DFA).

Because they are dedicated, specialized ICs, secure elements in general benefit from a combination of hardware and software mechanisms to ensure a high level of resistance against side-channel and fault attacks aimed at retrieving secret or private keys.

Control Execution Flow

Cryptographic and security-enabled applications implement decision mechanisms. A simple example is granting access to a resource such as a memory content after a successful user authentication. Rather than attacking the cryptographic algorithms implementations, which requires advanced cryptographic knowledge, attackers might rather try to force the decision so that the program behaves as they expect. Injecting a fault to force the result of a test to execute wrong branching is a frequent attack path.

Other attacks consist of:

• Skipping instruction or a set of instructions
• Manipulating the program counter
• Corrupting address or data on the bus

Consequences could be as serious as obtaining privileged access, unauthorized disclosure of keys and secrets, malware injection, and unexpected behavior in general, with the worst case being to put human safety at risk.

Countermeasures against control flow manipulation exist. They mainly consist of implementing redundancy, which can take different forms. In software it could be branching test duplication, redundant instruction insertion, or dedicated function calls with counter [4]. In hardware, countermeasures could consist of the specific coding of state machines or redundant registers. Typically, if an attacker generates a flaw, a redundant branch operation or test would compensate for it or put the microcontroller in a safe state.

The drawback of such software countermeasures is that their implementation requires specialized skills and is in general not automated, thus requiring additional R&D effort. The countermeasures also increase code size and negatively impact performance. Secure elements most often embed hardware and software protection against control flow manipulation. Therefore, by delegating the most sensitive operations to such devices, application developers can enforce strong resistance against control execution flow attacks.

Conclusion

This document has listed the most common attacks against embedded systems and provided an overview on the possible countermeasures that can be supported by a microcontroller or a secure element, or both. But finally, is a secure element needed for my design?

There is no single answer.

Embedded product security is a risk mitigation strategy that consists of protecting against the risk of various types of losses, such as product intellectual property, customer data or information, reputation, or revenue. The embedded product security must provide this protection for the life of the product in an ever-evolving threat landscape. Some products have a useful life of a few months to many decades, which is why the “one size fits all” approach is not valid. Therefore, product designers must be conservative in their security solution implementations to ensure the longevity of product security against ever-evolving threats. Adding a discrete secure element is just another tool in the product security arsenal to be leveraged by product developers.

References

[1] G. F. O. f. I. S. (BSI), "A Study on Hardware Attacks against Microcontrollers," 17 03 2023. [Online]. Available: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/HardwareAttacks/Hardware-Attacks-Microcontroller.html. [Accessed May 28, 2024].

[2] S. S. a. C. W. Franck Courbon, "Reverse Engineering Flash EEPROM Memories Using Scanning Electron Microscopy," CARDIS 2016: Smart Card Research and Advanced Applications, 2016.

[3] Limited Results, "Nuvoton M2351 MKROM," 12 January 2020. [Online]. Available: https://limitedresults.com/2020/01/nuvoton-m2351-mkrom-armv8-m-trustzone/. [Accessed May 31, 2024].

[4] K. H. P. B. Jean-Fran¸cois Lalande, "Software countermeasures for control flow integrity of smart card C codes," in 19th European Symposium on Research in Computer Security, Wroclaw Poland, 2014.

[5] J. Fruhlinger, "Threat modeling explained: A process for anticipating cyber attacks," CSO, April 2020. [Online]. Available:https://www.csoonline.com/article/569225/threat-modelingexplained-a-process-for-anticipating-cyber-attacks.html. [Accessed July 25, 2024].