3.1.2.6. Secure boot using U-Boot verified boot framework
The complete Secure Boot documentation is available at: Secure Boot. This page specifically covers the authentication and verification of U-Boot image using U-Boot Verified Boot.
On most other K3 devices, signing and verification of all boot binaries takes
place in the Hardware Security Module (HSM). Thereafter, U-Boot hands off the
secure chain of trust to the Linux kernel fitImage.
On AM62Lx, we have transitioned to use the native U-Boot secure boot framework for a part of this chain of trust. The U-Boot documentation covers more theory on this at U-Boot Verified Boot and U-Boot FIT Signature Verification. The thing to note is, we are applying the same concepts to U-Boot Flattened Image Tree (FIT) as the kernel FIT examples in the preceding links.
The HSM still handles the verification of tiboot3.bin and
tispl.bin. However, we hand off the chain of trust to U-Boot just after
this. The u-boot.img is a signed FIT image. The U-Boot Secondary
Program Loader (SPL) binary embeds the public key derived from the private key
used to sign the U-Boot FIT. The U-Boot SPL uses this to verify the
authenticity of the loaded U-Boot binary.
3.1.2.6.1. The FIT source
The U-Boot FIT configuration node contains a signature sub-node.
conf-0 {
description = "k3-am62lx-evm";
firmware = "uboot";
loadables = "uboot";
fdt = "fdt-0";
signature {
algo = "sha512,rsa4096";
key-name-hint = "custMpk";
sign-images = "firmware", "loadables", "fdt";
};
};
It specifies the key name and algorithm to use for signing, and the images to sign.
The public key is similarly embedded into U-Boot SPL by using a binman property
called u-boot-spl-pubkey-dtb. This handles the heavy lifting of calling
the appropriate mkimage commands and packing the public key in the SPL
Device Tree Blob (DTB) correctly.
tispl.bin {
...
spl: section {
u-boot-spl-nodtb {
};
u-boot-spl-pubkey-dtb {
algo = "sha512,rsa4096";
required = "conf";
key-name-hint = "custMpk";
};
};
};
The key-name-hint property in both these nodes searches for the
custMpk.key private key and custMpk.crt public key certificate
in the directories defined in the BINMAN_INDIRS variable. The default
TI dummy keys reside in arch/arm/mach-k3/keys/, and binman copies them
at the start of the build into the build directory:
custMpk-crt {
filename = "custMpk.crt";
custmpk_crt: blob-ext {
filename = "arch/arm/mach-k3/keys/custMpk.crt";
};
};
custMpk-key {
filename = "custMpk.key";
custmpk_key: blob-ext {
filename = "arch/arm/mach-k3/keys/custMpk.key";
};
};
3.1.2.6.2. Runtime verification
At runtime during device boot, U-Boot SPL loads the u-boot.img and then
verifies the FIT signature by using the public key it has in its DTB. If the
verification passes, boot continues. Otherwise, it aborts the boot.
3.1.2.6.3. Changing the dummy keys
The SDKs use the TI dummy key for signing the U-Boot FIT image. But you might
want to use your own key for testing and production. For this, replace the
arch/arm/mach-k3/keys/custMpk.key and
arch/arm/mach-k3/keys/custMpk.crt with your own key and crt files. The
filenames need to be the same.
It is also possible to use your own keys located at a different location. You
need to change the complete path in the filename property above in
custMpk-crt and custMpk-key in
arch/arm/dts/k3-am62l3-evm-binman.dtsi to your .crt and .key files.
After either of the above changes, the U-Boot needs to be built again to get the signed binaries with the updated keys. Refer to SDK Build using Makefile.
Note
Generating a new set of keys:
$ mkdir keys
$ cd keys
$ # Generate an RSA private key:
$ openssl genpkey -algorithm RSA -out custMpk.key \
-pkeyopt rsa_keygen_bits:4096 -pkeyopt rsa_keygen_pubexp:65537
$ # Build your cert template (Enter necessary details in the prompts that follow):
$ openssl req -new -key custMpk.key -out cert.csr
$ # Self-sign the certificate
$ openssl x509 -req -days 3650 -in cert.csr -signkey custMpk.key -out custMpk.crt