Secure Boot: The Cornerstone of Ensuring Device Integrity

Secure Boot: The Cornerstone of Ensuring Device Integrity

Secure Boot: The Cornerstone of Ensuring Device Integrity

There are a variety of security features available to safeguard data against malicious attackers and ensure device integrity and privacy. However, many of the most common security features could be rendered ineffective by an attacker who controls the systems firmware.

Secure boot prevents this by enforcing a secure system state. While most often associated with operating systems, secure boot can be implemented on a range of devices, at all levels, including SSDs, USB drives, and SD cards.

How does secure boot work? 

Secure boot’s main purpose is to prevent attackers from achieving Arbitrary Code Execution (ACE), whereby they can gain unauthorized access to the device, evade security measures, and even take control of the system.

Secure boot shields would-be attackers from gaining ACE by ensuring the device is only ever booted with known and trusted components. To do so, secure boot executes an essential task, verifying digital signatures and establishing links in a Chain of Trust (CoT).

Abstract concepts and concrete actions: CoT, RoT, Signature Verification

Chain of Trust (CoT) and Root of Trust (RoT) refer to abstract concepts of trust. It is important to understand that linking a CoT based of a RoT is an abstract verification of trust. Verifying digital signatures is a concrete implementation of this abstract action.

Establishing a CoT is the abstract solution to the problem and is in its essence nothing more than many components each verifying the trustworthiness of the next. It begins with the Root of Trust (RoT), the first component in the chain. RoT itself, however, cannot be verified, as there is no previous link in the chain to verify it. Thus, RoT must be inherently trusted. This means that RoT should have only limited interfaces and contain only immutable components, e.g., mask-ROM, HW components, eFuse.

The concrete action of verifying the digital signatures to verify the trustworthiness is what prevents attackers from gaining ACE and deploying malware. Therefore, the most integral action of the secure boot feature is to verify the integrity and authenticity of every (mutable) code before executing it. It does so by checking the firmware/software’s digital signature, which is signed with a cryptographic key.

Here’s how secure boot on a flash controller establishes CoT. Note, that each component is only executed after successful verification

  1. RoT checks the signature of the first component (the ROM extension) and verifies its trustworthiness.
  2. Once verified, the ROM extension verifies the firmware.
  3. Once verified, the firmware verifies the firmware extension.
  4. Once verified, the firmware extension verifies the host firmware/software stored on the flash.

And so, this process continues up the chain.

What are the different implementations of secure boot? 

It’s worth noting there are different implementations of secure boot: symmetric and asymmetric.

Symmetric message authentication

  • What it does: Provides a basic level of security against malicious firmware attacks and unauthorized access to the system.
  • How it works: Uses either one global key or device-unique symmetric keys.
  • Risks: If an attacker extracts the key(s), they can run arbitrary firmware on the device(s).

Asymmetric digital signatures

  • What it does: Offers a greater level of security than symmetric.
  • How it works: Stores a public key on all devices. Importantly, this key can only verify signatures—not sign firmware. So, if a bad actor has tampered with the firmware/software, then the signature won’t match—and the firmware/software won’t be run.
  • Risks: If an attacker obtains the manufacturer’s corresponding private key

Why is secure boot necessary for standards compliance? 

Many industries (e.g., finance, healthcare, and government) rely on standards and regulations to ensure their device’s integrity. In some cases, these standards even require that OEMs use secure boot mechanisms.

This is because secure boot is key for preventing attackers from gaining ACE. Thus, by requiring OEMs to use secure boot mechanisms, standards bodies can ensure enforcement of all other security measures and a secure system state, overall.

How to integrate secure boot in NAND flash storage devices

Unfortunately, in today’s tech landscape, many devices lack hardware-based RoT mechanisms to provide security. Some employ Trusted Platform Modules (TPMs), but their PCB footprint and costs can be prohibitive.

For NAND flash storage devices, there’s a better option to achieve security without compromising space or inflating costs. Considering all NAND flash storage devices must have a controller managing the flash, secure boot functionality can be embedded directly into storage devices by integrating a NAND flash controller with a security-geared e-Fuse to serve as the RoT inside the chip.

Products like Swissbits PS-45u DP micro-SD card raspberry edition ensure a secure boot solution for Raspberry Pi and this feature is integrated in an array of other Swissbit modules implementing high-end Hyperstone controllers.

Get in touch with us today to learn more about this feature and the products that support it.

 

返回