Despite the increasing number of network attacks on IoT devices, firmware security is often placed in a secondary position. As attackers penetrate the system stack and target the boot process and underlying hardware configuration, the choice of memory architecture has become a key decision in establishing a verifiable trust chain.
Therefore, ensuring firmware security requires each component to undergo encryption verification before execution. This path begins with an immutable boot loader, which is responsible for loading and verifying the main firmware. However, the memory technology used in each step may result in firmware vulnerability to unauthorized modifications.
Internal and external flash memory
The physical location of non-volatile memory used to store firmware is one of the most critical factors in device threat models. Firmware engineers need to make a choice between on-chip embedded flash (eFlash) and external flash modules connected through serial interfaces such as SPI or QSPI.
Embedded flash memory is usually directly integrated onto microcontrollers or SoC chips. This architecture provides the highest level of physical security as there are no external buses available for attackers to manipulate. Even access to internal flash memory is controlled by dedicated registers and lock bits.
In addition, embedded flash memory supports permanent read protection. By short circuiting specialized safety fuses, developers can disable JTAG or SWD debugging interfaces to prevent hackers from modifying firmware images. However, as SoCs move towards smaller nodes, this technology faces significant scalability challenges.
In contrast, external flash memory is placed outside the main processor and communicates through a high-speed serial interface. This architectural choice makes storage capacity easy to scale, but also expands the attack surface of the system. Any data transmitted between the processor and external flash memory is inherently vulnerable to threats such as eavesdropping, man in the middle attacks, and physical tampering.
To address these risks, firmware engineers must implement sound hardware and software protection measures. Many external NOR flash memory devices are equipped with a physical write protection pin. When the pin is placed at a specific voltage, the internal logic of the chip will prevent any erase or write commands from being executed.
Figure 1: Winbond Electronics' W77Q32JWSSIR TR secure serial NOR flash memory has complex communication channel encryption capabilities. (Image source: Winbond Electronics)
However, if the data can be read, simply locking the flash memory is not enough. During execution, attackers can still access the address and data bus. This vulnerability has prompted the development of specialized secure flash devices, including hardware based root of trust mechanisms, encrypted communication channels, and monotonic counters to prevent rollback attacks.
However, if the wrong storage architecture is chosen, the device will leave fundamental defects that cannot be completely fixed by software patches. For example, designs that store firmware on external EEPROM without encryption or verification are always vulnerable to hardware attackers. On the contrary, choosing a memory with excessive restrictions may affect its functionality.
Therefore, engineers must understand best practices and design techniques to maximize firmware security through memory architecture.
Best Practices for Secure Firmware Storage Design
When designing a secure firmware storage path from startup to runtime, firmware engineers must follow the following principles:
1. Hardware based root of trust
Execution must always start from immutable memory areas. For example, the boot ROM or permanently secure flash sector should contain code to verify all other firmware. This will ensure that attackers cannot bypass verification by tampering with the initial password.
2. Use encrypted signatures
Configure the secure boot loader to only run firmware images signed with trusted private keys. In this way, even if attackers can access memory and modify bits, they can prevent unauthorized code. If confidentiality is required, the stored firmware can be encrypted.
3. Utilize hardware security features
If the system architecture uses external storage, engineers should choose devices that support hardware security, such as built-in password protection or simple encryption. Although these devices may not be as robust as complete security components, they add another layer of protection.
Figure 2: Macronix supports MX25L3233FM2I-08Q 32 Mb serial NOR flash memory with serial peripheral interface. (Image source: Macronix)
4. Isolate firmware and data
Organize the memory area and separate the most sensitive code. In MCU, place critical routine instructions in a secure memory area. Even firmware, if supported by hardware, can mark certain flash memory banks as executable only or read-only.
5. Security firmware update plan
Ensure that the update process itself is validated (e.g. requiring the update package to be signed). If the design uses external storage for temporary updates, the same security measures as the main firmware storage should be adopted.