The need for electronic embedded systems to be safe and secure have never been higher. As cars become more autonomous, greater security is required to prevent them from being hacked. The same is true for factories employing more robots and Internet of Things (IoT) equipment handling sensitive data.
Non-volatile flash memories are essential in all of these embedded systems. Flash can be used for code storage, file system storage, or as a microcontroller unit (MCU) memory on which code directly runs. If a system needs to be secure, the flash memory it uses must be secure first. This article discusses flash-memory security requirements to enable developers to build safe and secure embedded systems in automotive, industrial, and communication applications.
Flash-Memory Usage Models
If we take a close look into a modern car’s electronic systems, we can find that flash is used from bumper to bumper. As the complexity of the system increases, more code and data storage are needed. All subsystems inside a car—including advanced driver-assistance systems (ADAS), custer (trending to be combined with infotainment), powertrain, and body—need embedded systems to operate in real time.
All of these embedded systems require some kind of flash memory for code and data storage. For example, Figure 1 shows an example of an ADAS sub-system that uses multiple NOR Flash devices.
1. This ADAS subsystem utilizes multiple NOR flash.
In today’s ADAS applications, complex algorithms and artificial-intelligence processes rely on the stored code and data in flash memory to operate. The storage must be fail-safe and secure because a malfunction of the system or a malicious attack could cause serious injury or death.
In industrial and networking applications, similar safety and security requirements for storage solutions also exist. With the ever-increasing connectivity, attackers can attempt to penetrate any entity connected to the Internet, either to steal sensitive information or use the device as a springboard to launch attacks elsewhere in the overall system. Therefore, building a secure system to prevent such attacks has never been more important.
Secure Flash Storage
Flash-memory vendors have been providing pure data storage for many years. For these applications, endurance and retention are the two main measures for the quality of flash memories. Security isn’t a part of these flash devices, meaning that data on the flash either isn’t protected at all or protected with commands that have no authentication.
For example, some flash devices provide basic protection functions through normal command sets, such as non-volatile and volatile protection of sectors against program or erase operations, password protection for program or read, etc. These features are good but not sufficient enough to prevent sophisticated attacks. If attackers can access the bus interface of the flash device, they can easily extract or modify data on the device.
To be secure, a flash device must protect stored code and data from being attacked by multiple means. The following summarizes the attacks that a flash storage device needs to be secure against.
Man-in-the-middle (MIM) attacks
Hackers in MIM attacks often imitate the sender of the communication channel to send commands or messages to the other side in order to steal or modify data (Fig. 2). Therefore, it’s necessary to authenticate each message between the host and the flash device. Authentication can be done using a common secret key on both the host and the flash to generate a message authentication code (MAC) along with the actual message. The receiver can then verify the MAC before acting upon the message.
2. A man-in-the-middle attack often involves imitating the sender of the communication channel to send commands or messages, with the end goal being to steal or modify the data.
To prevent a system from being permanently broken if a secret key is compromised, it’s often desirable to use an ephemeral key. An ephemeral key expires within a certain time frame or after a set number of transactions. Doing so minimizes attacks to decrypt the key using differential power analysis (DPA) or other iterative attack methods.
Another type of MIM attack is to replay an intercepted legitimate message after a certain time. To prevent replay attacks, the host and the flash device must use a monotonic counter—whose value is incremented upon every message—to generate the MAC. Therefore, if the same message is replayed, the MAC verification will not pass because the current monotonic counter value would have been different from the previous message.
Cloning
Some hackers can use sophisticated technology to read out the entire contents of a flash device for illegal cloning to make profit. To prevent such attacks, each flash device must have a unique device secret (UDS) that can’t be read by anyone. The UDS value is a unique and true random value in each of the devices. There’s no association between the UDS in one device and in another.
The UDS can be used to derive a compound device identifier (CDI) that’s the basis for generating a Device ID Certificate as defined in the TCG (Trusted Computing Group) DICE (Device Identifier Composition Engine) specification. Typically, the device also generates an Alias Private and Public key pair based on the CDI for all key derivations with the host. As a result, the Device ID private key needn’t be exposed.
With the UDS and the DICE processes, it’s impossible for hackers to clone the device because the UDS is physically unclonable.
Eavesdropping
One form of attack is known as passive listening. By eavesdropping on the bus, the attacker may collect sensitive information or intelligent secrets from the data conveyed over the bus. To protect important data, users may choose to encrypt it before sending it over the bus to store on the flash device. When the host retrieves the data out of the device, the data should also be encrypted so that it’s never exposed to potential hackers.
One may argue that the encryption method doesn’t require a secure storage flash solution, because the host can encrypt the data and store it in the flash directly. Only the host can decrypt the data.
However, there are certain disadvantages to doing so. One of them is that the host will not be able to easily deprecate the encryption key. For example, say the data was encrypted with KeyA and stored in flash. Later on, the user finds out that KeyA has been compromised. It’s necessary to use a different key on the system, i.e. KeyB.
Now, the host has a dilemma: It can’t simply discard KeyA because it still needs to keep it to decrypt the data read from the device. Moreover, if KeyA is compromised, the user may not want to keep it forever. If a new key for the data encryption is needed, the user will have to take more disruptive actions that erase the original encrypted data on the flash and program the flash again with the new encrypted data. This operation is often not an easy task to do in the field and poses certain risks.
On the other hand, if a secure flash can provide encryption and decryption capabilities, it can safely store plain text in its secure storage and encrypt the data before sending back to the host. If the current encryption key is compromised, the host can simply exchange a new key with the device. The data in the storage remains intact and secure, which is a much simpler approach than storing encrypted data.
Protective Measures
The following offers different steps to take to develop secure flash storage:
Provide flexible memory structure
In modern multicore embedded systems, multiple MCUs or HSMs (hardware secure module) may have access to the same flash storage. It’s desirable for the flash device to provide a flexible memory structure that can be partitioned and provisioned so that different regions are manageable via different cores. These different regions can provide different levels of security, or no security at all if not needed.
We can certainly see the trend of supporting multiple secure regions by looking at the eMMC and UFS standards. The current eMMC standard specifies one Replay Protected Memory Block (RPMB) block. The latest UFS (v3.0) standard smartly supports four RPMB partitions that can be managed by four different keys. Such a memory structure flexibility is more suitable in multicore SoC environments.
Provide fast secure-boot capability
Many embedded systems store boot code in flash. Some of them require a very fast boot-up time; for example, an automotive subsystem is required to handle CAN messages within 100 ms upon power-on reset (POR). The system needs to boot-up not only securely (i.e., verifying the boot code), but also fast. This presents a major challenge to embedded designers.
Typically, when using a store-and-download (SnD) model, the host reads out the bootloader from the flash and shadows it to RAM for execution. However, to boot up securely, the entire bootloader code needs to be checked and authenticated to make sure that it’s trustworthy. This process requires time on the MCU. A secure flash storage that can provide boot load authentication will substantially help shorten boot time.
A secure flash device can use an internal secure hash function to check the bootloader and provide the hash value for the host to verify. If the hash value didn’t change, it means the bootloader hasn’t been tempered with and is thus safe to boot with.
Provide secure firmware over-the-air (FOTA) update
Field upgrades are a necessary capability in modern embedded applications. By remotely upgrading the firmware or software of the system, manufacturers can quickly fix issues, provide additional features, and enhance the user experience. However, remote upgrades pose a security threat to systems. No one wants a hacker to use the established update channel to cause the system to run malicious firmware or software.
Rather than relying solely on the CPU to provide such security, a secure engine inside the flash device make FOTA processes much more secure (Fig. 3). With the secure engine, the flash device that provides the boot code storage can authenticate the firmware provider not only with the host next to the flash, but potentially also with the remote cloud far away. In this way, end-to-end channel security can be established to update the firmware or software inside the flash.
3. A secure engine inside the flash device makes for a more secure firmware-over-the-air process.
Modern embedded systems in automotive, industrial, and communications require highly secure data storage. Embedded designers are facing challenges to build safe and secure systems that are resilient to cyberattacks. Flash with integrated security like Cypress’ Semper Flash enable greater overall system security by protecting against the numerous types of attacks that can be made on embedded systems.
Zhi Feng is Senior Principal Applications Engineer in Cypress’ Flash group.
