Verified boot and file system integrity

FIT images and verified boot

The Yocto classes uboot-sign and kernel-fitimage sign the kernel FIT and U-Boot's FIT, with keys in files or in the programme's HSM through OpenSSL's pkcs11 engine.

State: modelled with U-Boot 2024.01's mkimage, dumpimage and fit_check_sign, and SoftHSM 2.6.1 through libp11 0.4.12 (OpenSSL 3.0.13): a two-configuration FIT signed with a file key and with the HSM key, checked good, tampered, unsigned, with the wrong key and without a key; signing refused without the PIN; real bitbake -e (BitBake 2.8.1, poky scarthgap, meta-freescale); the running app over a local sshd. Not run with a real kernel and U-Boot build (a stand-in kernel and control DTB were used), on a board refusing an unsigned FIT, with a real HSM, on Windows, against a real build server, on Wind River Linux, with SPL and U-Boot FIT signing or FIT_SIGN_INDIVIDUAL in a real build, or with ECDSA keys. Vendor secure boot chains (NXP HAB and AHAB, TI, AMD, ST) are not built.

Check a FIT image

Open FIT Image picks a kernel or U-Boot FIT from the deploy folder. It is read with dumpimage -l on the build host and every configuration is checked with fit_check_sign against U-Boot's control DTB (UBOOT_DTB_SYMLINK; Check FIT Image Against DTB... picks another). The editor shows:

• per configuration: what it boots, its signature, the verdict, and whether the DTB requires the key (required = "conf");
• the control DTB's keys, read by the module's own device tree reader;
• the images with their hashes;
• How the Build Signs, from bitbake -e virtual/kernel and virtual/bootloader: which key signs what, a key file or the PKCS#11 URI as mkimage forms it (never read, PIN removed), each variable with its file and line;
• findings: no required key, unsigned configurations, a different key, generated keys, a pkcs11: prefix in UBOOT_SIGN_KEYDIR.

Sign a development copy

Sign FIT Image (Development Build)... signs a copy with the build's key as kernel-fitimage does. The confirmation shows the key and the exact command. A PKCS#11 PIN comes from MKIMAGE_SIGN_PIN in the build account's environment, set through the company's secret mechanism, never from the editor; without it, signing fails without asking for a PIN.

Agent tools: three read-only; signing always asks first.

Root file system integrity: dm-verity, IMA and EVM

State: modelled with veritysetup 2.7.0 (the root hash computed equal to veritysetup's; verify good, a tampered block named, a wrong root hash, a mismatching boot script), real bitbake -e (BitBake 2.8.1, poky scarthgap), and a QEMU arm64 board with a verity-mapped root, 32 IMA measurements (6 signed), EVM state, a refused policy read and a tampered disk reported corrupted. meta-security and meta-integrity were never fetched, so their variable names and the .verity.env and .verity-params formats are unchecked against the real layers. No image with dm-verity was built by BitBake; a stand-in initramfs was used. Not run on a real i.MX board, with a TPM, with IMA appraisal enforcement or on Windows.

• Read Root File System Integrity Settings reads the build's dm-verity and IMA and EVM settings from bitbake -e with file and line, naming keys without reading them.
• Open dm-verity Image reads a built image: the verity superblock, the root hash computed independently, veritysetup verify (good, or the failing block named), and every partition, kernel command line, boot script or initramfs that carries the root hash, with a warning when one does not match. Verify dm-verity Image With Root Hash... checks against a root hash you give.
• Show Root File System Integrity of Target reads a board, read-only: dmsetup table, veritysetup status, /proc/cmdline, the IMA measurement list and signing key ids, the IMA policy and EVM state, and what the image lacks.
• Export Root File System Integrity Record... writes Markdown or JSON for the security case (ISO 21434, IEC 62443).

Agent tools: five, all read-only.

Next: SBOM and CVEs.