Secure Flash - The answer to security issues in connected cars and industrial applications

By Sandeep Krishnegowda

Flash Product Director

Cypress Semiconductor

San Jose, California

Summary

As the automation and connectivity revolution advances in the automotive and industrial markets, edge nodes are quickly becoming targets for cyberattacks. Software updates, remote capture of diagnostic data, and communication between remote endpoints and infrastructure are becoming more common, making them vulnerable to cyberattacks and other security threats. 

As semiconductor technology advances and process geometries continue to shrink, it becomes increasingly difficult to embed flash memory into MCUs that include hardware security modules (HSMs), so the demand for external flash memory continues to increase. When flash memory is external to the MCU, the stored code and data will be more vulnerable to attacks, so the device must design a secure boot process and other infrastructure to ensure that the stored and retrieved content can be trusted.

This article explores the challenges and security requirements of designing next-generation secure devices when the flash memory is external to the MCU with an HSM module, but still maintains a hardware root of trust. Other topics covered in this article include: cryptographic secure storage, fast secure boot, secure firmware remote updates, and management compliance. 

I. Introduction

In an increasingly embedded and connected world, security issues are becoming increasingly important. Every embedded system expands the attack surface, making everything from devices and vehicles to offices and factories more vulnerable to attacks. In applications such as automotive electronics and industrial systems, functional safety has risen to a critical position.

Design engineers know that the growing concern for security and privacy has become a major factor in purchasing decisions. Gone are the days when consumers and businesses easily adopted new technologies. Today, caution has replaced trust, forcing every vendor to guarantee the security of their products and services to some extent. Governments share these concerns and have introduced regulations requiring vendors to implement security provisions, and sometimes penalties for failure to do so.

Design engineers also realize that it will become increasingly difficult to secure embedded systems. The reason is that as SOC/MCUs become more powerful in handling complex real-time applications, they are beginning to transition to smaller CMOS technologies (e.g., 16nm or 7nm) to increase speed and reduce power consumption. However, there is currently no reprogrammable non-volatile memory (NVM) technology available at smaller sizes. This has led to the de-integration of eFlash (the embedded flash memory of the MCU), requiring a naturally secure architecture and support for external flash memory. This requires special rules to ensure its secure operation.

Chapters II and III of this paper also analyze the challenges of designing secure embedded systems, including the challenges posed by the de-integration of embedded flash memory. Chapter IV explores the next generation architecture for protecting embedded systems using secure flash memory.

II. Embedded Flash memory faces de-integration

In response to growing security concerns, chip vendors have integrated hardware security module (HSM) functionality into MCUs. The HSM resides in a secure processing environment that contains a hardware-based root of trust to protect sensitive data, processor state, bootloader, encryption keys, and application security service code. Embedded storage (eFlash and RAM) is also an important part of the trusted boundary of the secure processing environment, making it sufficiently resistant to common threats.

Off-chip storage (e.g., external flash) is not inherently trustworthy and is vulnerable to persistent attacks. The general countermeasure is to encrypt the data in the external flash and then download it from the external flash to the MCU's internal RAM for decryption and verification before executing the code. Although this approach is strong enough to resist most attacks, it will result in reduced performance (possible problems at boot time) and increased cost (requiring more internal RAM and higher power), and it may even still be vulnerable to persistent attacks (e.g., rollback attacks).

As MCUs are gradually applied to advanced technology nodes to improve performance, improve cost-effectiveness and reduce power consumption, the de-integration of flash memory may bring greater threats, and some trusted storage challenges that were previously fully or partially overcome by eFlash may return. In addition, the threat environment caused by the popularity of embedded systems will also bring new challenges, and the use of external flash memory will make these challenges more difficult to overcome.

To ensure the security of external flash storage, the main threats that need to be addressed include:

• Emulate authorized data access to flash memory chips

  
  

• Tampering with the contents of flash memory chips

  
  

• Replay the communication instructions to parse the contents of the flash chip

  
  

• Setting up in an insecure environment to obtain a key

  
  

• Eavesdropping (man-in-the-middle) attacks on flash memory chips during communication

  
  

• Expose (obtain or observe) the contents and keys of the flash chip through side-channel attacks or fault injection 

  
  

• Electronically compromise the integrity of the flash memory chip

  
  

• Clone Flash Chip 

To address these and other threats to external flash memory and effectively make it part of the trusted boundary of a secure processing environment, the device must provide the following three capabilities:

• Hardware-based root of trust that prevents attacks from modifying, manipulating, copying, or otherwise potentially affecting stored code and/or data

  
  

• Secure updates are provided via the MCU or the cloud, with end-to-end protection utilizing a combination of measures including cryptographic authentication via the bus, secure enclaves via read/write access methods, secure key storage space, and a non-volatile anti-rollback counter  

  
  

• Low cost, no additional security equipment (e.g. Trusted Platform Module) required, and no board changes required, including support for x4 SPI and x8 HyperBus standards.

Figure 1 shows how a specially designed secure Flash memory (see Chapter IV) can provide the three functions described above. In effect, the secure Flash memory externally extends the HSM functionality of the MCU embedded Flash memory through a standard bus. Also note that Figure 1 also shows how the secure Flash memory can replace the ordinary NOR Flash memory, allowing the existing circuit board to continue to be used.

It is worth mentioning that using external flash memory has some other advantages. The first is that it can more easily adapt to the increasing code length. The standard flash memory capacity specifications commonly used in embedded systems can support 1Gbit or even larger storage space, which is much higher than eFlash. External flash memory can also accommodate more CPU cores/loads to cope with the more intensive and real-time processing required by complex technologies such as machine learning and artificial intelligence. These changes help simplify design work and speed up product launch, providing different models to better meet the needs of price, performance or other standards.

III. Designing Secure Embedded Systems Using External Flash

Whether using eFlash or external Flash, designing secure embedded systems is an increasingly arduous task. This chapter highlights some important considerations to help guide the design and development effort.

In general, a system designed for end-to-end security must have three major elements:

• Protection mechanisms to protect the integrity of code and critical data from being deleted, altered, or destroyed in various ways  

  
  

• Detection mechanisms to reveal when code and/or critical data has been altered in some unauthorized way

  
  

• Recovery mechanisms to restore the integrity of code and/or critical data that has been altered in some unauthorized way 

Engineers should design systems that are able to handle all threats that have been validated by the STRIDE model. The following table summarizes this model, which provides a practical way to understand the various potential threats and how to use various security measures to counter each threat.

Secure product design requires the establishment of a trusted execution environment (TEE) based on a root of trust. TEE provides a way to verify authenticity and integrity before all components and subsystems are used. Some of the best practices for creating such a secure design are as follows:

• Implementing a hardware root of trust to create a secure foundation

  
  

• Strengthening this foundation with authentication and encryption

  
  

• Securing the end-to-end value chain of all connected, network and cloud components

  
  

• Provides protection against side-channel attacks and fault injection techniques

  
  

• Conduct independent vulnerability and risk assessments of your system

  
  

• Continuous real-time monitoring of abnormal situations

  
  

• Implement response processes (e.g. security updates)

Figure 2 shows how risk and cost are weighed when implementing a root of trust in a system. As might be expected, a software-based design has the lowest cost and is also the least secure. Figure 2 does not show the indirect costs of an insecure embedded system, and these very real costs easily justify the hardware-based design that maximizes security.