Security architecture

This page provides a high-level conceptual architecture overview of how Raspberry Pi devices protect themselves during boot and storage access. It summarises:

  • The chain of trust used in Raspberry Pi’s secure (verified) boot process.

  • How disk encryption integrates into the boot process, when enabled.

  • The software components available in Raspberry Pi OS that offer security functionality.

To implement secure boot and encryption, we recommend using our Secure Boot Provisioner, which can configure and deploy secure boot and disk encryption on multiple devices. For more information and instructions, see Secure Boot Provisioner.

Secure boot chain of trust

Edit this on GitHub

Like all computers, when a Raspberry Pi starts up, it goes through a boot process: it first runs low-level firmware, then loads the operating system (OS).

Secure boot ensures that only authenticated software runs during this process by establishing a chain of trust. Each stage (link) in the chain cryptographically verifies the next stage before it runs. This ensures that only code signed by a trusted source can run during startup.

We recommend provisioning your devices with secure boot using Raspberry Pi’s Secure Boot Provisioner, with optional disk encryption enabled. For information and instructions, see Secure Boot Provisioner.

Cryptographic components

The secure boot chain starts in immutable hardware and extends to customer software. It consists of the following cryptographic components:

  1. Boot ROM public key. The boot ROM is the immutable hardware root of trust that contains a Raspberry Pi public key burned into silicon. This key is used to authenticate Raspberry Pi-signed firmware.

  2. Customer-generated RSA key pair. Before provisioning your Raspberry Pi devices, you, the customer, generate your own RSA public-private key pair. The private key signs your OS boot image. Using Raspberry Pi’s Secure Boot Provisioner, you define which key is trusted for boot by storing the identity (a hash) of the public key in the device OTP.

  3. Device-unique disk secret. Secure Boot Provisioner generates a device-unique secret, used to unlock the encrypted root filesystem at boot. The key is stored in OTP and protected by software mechanisms.

Bootflow timeline

Raspberry Pi’s Secure Boot Provisioner establishes a chain of trust that begins in immutable hardware and extends through to the OS. If all verification steps succeed, the kernel starts to run, and then mounts the root filesystem, decrypting it first if disk encryption is enabled with the Secure Boot Provisioner tool.

If any verification steps fail, the chain of trust is broken and the EEPROM bootloader proceeds to your next configured boot method, for example, another partition, image, or recovery mode.

First stage: boot ROM root of trust

The first stage is the boot ROM embedded in each Raspberry Pi’s SoC. Because it’s permanently burned into silicon, it can’t be modified after manufacturing and is trusted by design; it thus forms the hardware root of trust for the secure boot process.

The boot ROM reads a hash of your RSA 2048-bit public key stored in One-Time Programmable (OTP) memory. On Raspberry Pi devices using the BCM2712 SoC, this key pair is also used to sign the EEPROM bootloader, described in Second stage: EEPROM bootloader verification. This extends the BCM2711 SoC check by also requiring a customer key signature to authenticate the EEPROM bootloader.

Second stage: EEPROM bootloader verification

The second stage is the EEPROM bootloader, which is stored in the Raspberry Pi device’s SPI flash EEPROM and updated by Raspberry Pi’s Secure Boot Provisioner. The digital signature of this bootloader is verified using Raspberry Pi’s public key embedded in the boot ROM. The EEPROM bootloader then checks the customer’s public key against the hash stored in OTP, ensuring that only an authorised customer key is trusted for subsequent stages.

Third stage: kernel and OS

The third stage is kernel and OS verification and loading. The EEPROM bootloader loads a boot image (boot.img) from local storage or over the network, and verifies its signature (boot.sig) using the customer public key. The verified boot image typically contains the kernel, initramfs, device tree, and, on devices with the BCM2711 SoCs, the GPU firmware (start.elf). If verification succeeds, the bootloader runs the kernel.

The kernel then initialises the hardware and mounts the root filesystem. If disk encryption is enabled, the initramfs retrieves the device-unique secret stored in OTP and uses it to decrypt the root filesystem before mounting it, after which the normal OS startup process continues. For more information, see Disk encryption boot flow.

Disk encryption boot flow

Disk encryption on Raspberry Pi devices protects the root filesystem by encrypting it with LUKS and binding the unlock key to the device using OTP, described in Bootflow timeline.

By default, Raspberry Pi OS doesn’t support encrypted root file systems; if you want disk encryption, you must either build your own encrypted storage or use the Raspberry Pi Secure Boot Provisioner tool to enable encryption during provisioning. For information about this tool, see Secure Boot Provisioner.

Disk encryption is configured during provisioning. For operating system images created with rpi-image-gen, the root filesystem and any number of additional partitions may be encrypted. For images created with pi-gen, only the root filesystem can be encrypted. Regardless of the image generation method used, a trusted but unencrypted pre-boot authentication environment is required to allow the device to start and unlock the encrypted storage. This environment includes the Raspberry Pi firmware, Linux kernel, Device Tree files, and a minimal user space, and is authenticated through digital signatures using a customer signing key rather than through encryption.

For Raspberry Pi devices provisioned with disk encryption, the boot process continues from Third stage: kernel and OS in the bootflow timeline and so is essentially the fourth step in establishing a full chain of trust. The bootloader loads the (unencrypted) Linux kernel and initramfs (a temporary root filesystem) from the pre-boot authentication environment into RAM. Because the real root filesystem is still encrypted and can’t be accessed yet, the kernel initially runs from initramfs. Early boot scripts in initramfs invoke rpi-fw-crypto to derive the disk-specific passphrase, unlock the LUKS volume, and mount the real root file system. The kernel then switches to this unlocked root filesystem and normal Linux boot continues.

The initramfs must include the kernel modules that implement the encryption ciphers you choose to use. To optimise performance, default cipher recommendations vary depending on the Raspberry Pi chip, shown in the following table.

Default LUKS encryption ciphers by Raspberry Pi SoC
Chip LUKS encryption Notes

BCM2712 devices

AES (aes-xts-plain64)

The BCM2712 SoC has hardware acceleration for AES encryption, which means there is faster encryption, lower CPU load, and greater storage throughput on devices with the BCM2712 chip.

BCM2711 devices

AES (aes-xts-plain64)

The BCM2711 SoC can also handle AES encryption efficiently.

BCM2837, BCM2837B0, and RP3A0 devices

Adiantum (ChaCha20)

Adiantum is recommended for better performance on older Raspberry Pi models that use the BCM2837 and BCM2837B0 SoCs, and the RP3A0 SiP.

Software components in Raspberry Pi OS

Raspberry Pi OS, a derivative of Debian, offers a range of free and open source security components that you can use to secure your device. Standard Debian packages include:

  • OpenSSL, a secure sockets and cryptography library.

  • PAM, the Pluggable Authentication Module system.

  • LUKS, the Linux Unified Key Setup system for configuring and using storage encryption.

  • AppArmor, a Mandatory Access Control system for constraining programs and users.

  • UFW, the Uncomplicated FireWall, for configuring a network firewall.

In addition to the array of components offered from the Debian project, Raspberry Pi OS also offers rpi-fw-crypto, which is a library and program for using the VideoCore co-processor to encrypt and sign data with a device-unique secret.