.. include:: /keyword.rst ==================================== Secure Boot ==================================== Secure boot is a mechanism that establishes a Chain of Trust (CoT) on all system boot images. Secure boot relies on cryptography to verify image signatures before their execution. - Root of Trusted Boot - The RoT (Root of Trusted) is MediaTek BootROM on MediaTek platform - The BootROM verifies TF-A (BL2 image) with BROM secure boot mechanism - Chain of Trusted Boot - TF-A (BL2) verifies the BL3x image (``fip.bin``) which includes TF-A (BL31), OP-TEE (BL32) and U-Boot (BL33) with TF-A Trusted Board Boot mechanism - U-Boot (BL33) verifies the system boot with UEFI Secure Boot mechanism - GRUB provides digital signatures checking of Linux Kernel .. figure:: /_asset/sw_yocto_secure-boot_workflow.png :align: center :width: 900px This document explains how to secure each boot transition. .. contents:: Sections :local: :depth: 1 Secure Boot: BL1 to Download Agent ================================== The Download Agent (DA) is important to complete the flashing process. If the device is hard bricked, you will need the Download Agent binary (``lk.bin``) to access the internal storage and download process via USB interface. You can ensure trusted Download Agent (DA) through MediaTek BootROM secure boot. On the secure boot mechanism, Download Agent Authentication would be enabled to support download agent verification by BL1 (BootROM) through the following sequence of steps. - 1. First, BL1 loads auth file (``auth_sv5.auth``), Download Agent binary (``lk.bin``) and the signature (``lk.sig``) into SRAM. - 2. BL1 will verify the auth file based on root of trust public key (`ROTPK`). - 3. And then BL1 will use the auth file to authenticate the Download Agent binary with the signature. .. note:: DAA has been supported on all platforms. Currently, the platforms include |G350-EVK|, |G510-EVK|, |G700-EVK| and |G1200-EVK|. Since DAA relies on secure boot, please follow the section **Secure Boot: BL1 to BL2** to make sure that secure boot is enabled for DAA enablement. .. _secure-boot-bl1-to-bl2: Secure Boot: BL1 to BL2 ======================= .. figure:: /_asset/sw_yocto_secure-boot_rot.png :align: center :width: 900px When we power-up the device, the BL1 (ROM code) is the first code run. The BL2 (TF-A) is verified through the following sequence of steps for |G1200-EVK|. - 1. BL1 loads a hash based on root of trust public key (ROTPK) from the eFuse and calculates the SHA-256 hash of that ROTPK in BL2 image. - 2. The hash of ROTPK is compared with the one from the eFuse. If the comparison passed, BL1 would do signature verification in the next steps. If any failure, the system will halt. - 3. & 4. BL1 loads the BL2 loader and calculates the SHA-256 hash from the BL2 loader. In the meantime, BL1 decrypts the signature of BL2 loader based on RSA-3072. - 5. & 6. If the comparison succeeds, the system jumps to BL2 loader. Otherwise, the system halt. .. note:: This ROM code cannot be modified, however we can enable secure boot feature through eFuse settings. Secure Boot: BL2 to FIP images ============================== The TF-A (BL2) image contains the RSA public key and will use TF-A Trusted Board Boot mechanism to authenticate FIP images (signed with the private key), which includes TF-A (BL31), OP-TEE (BL32), and U-Boot (BL33). Secure Boot: BL33 to Device Tree ================================ The U-Boot image contains the RSA public key and U-Boot will use FIT Verified Boot mechanism to verify the device tree (signed with the private key). Only valid device tree will be installed as the UEFI table, which is the runtime structure that can be accessed by services during boot or operation. Secure Boot: BL33 to System Boot ================================ Genio supports the UEFI Secure Boot to meet the requirements described in the Unified Extensible Firmware Interface Specification. UEFI Secure Boot ensures that all software components are authenticated before they are launched during the boot process. When UEFI Secure Boot is enabled, the process from U-Boot to Linux kernel is divided into the following stages: - U-Boot will verify the first system boot (Shim). If Shim authentication succeeds, U-Boot will transfer control to Shim. - Shim will verify the GRUB (GRand Unified Bootloader) binary using its own embedded certificates or keys loaded from the Machine Owner Key (MOK) list. When GRUB is verified successfully, Shim transfers control to GRUB. - GRUB then tries to load the Linux kernel. Shim itself does not directly verify the Linux kernel. Instead, it configures the verification mechanism via GRUB. GRUB uses its own configuration (usually in ``/boot/grub/grub.cfg``) to load the kernel and initramfs. GRUB verifies the kernel binary using keys installed in the MOK list or embedded in GRUB itself. When the Linux kernel is verified successfully, GRUB will load the kernel and transfer control to it. .. note:: The `Unified Extensible Firmware Interface Specification` requires that UEFI variables related must be stored in non-volatile storage, and Genio supports RPMB partition of eMMC called `Secure Storage` for this purpose. RPMB partition of eMMC is designed to access data in an authenticated method. Genio provides a consistent interface for secure storage implementations, which supports read, write, delete and update UEFI keys functions. Secure Boot: Linux Kernel to Kernel Module ========================================== The Linux kernel provides an optional `module signature verification` feature that will check signatures when loading kernel modules. When `module signature verification` is enabled, this ensures the security of Linux kernel by disallowing the loading of invalid kernel modules during the boot process. For further information and full specification about `module signature verification`, please refer to the page: `Linux Kernel Documentation `_ This documentation explains the processing of kernel module signatures.