Secure Boot on the Raspberry Pi CM4

I very often tackle things top down. I don't learn all the underpinnings first. I tend to get familiar with those as I go and to whatever extent they matter. This was definitely the case for secure boot on the CM4.

Raspberry Pi provide a decent bit of tooling for setting up your CM4 for their Secure Boot scheme. There are scripts and things. And as you try to get a Buildroot build to do what they do in the examples you get to know a bunch of random tools. The job to be done includes generating a boot.img and signing that with the private key mathcing the public key you've squirreled away in the bootloader to get a boot.sig. To generate the boot.img the example I found used a tool called genimage. It is not Raspberry Pi-specific but it takes a config of which files to grab and what filesystem format to use and it generates images. It is fine, seems to do the job. While I was working on this I assumed I would need to use genimage. Because certainly it does something importantly special?

Probably not. From where I am now it seems to just put files in a vfat filesystem image. With the Nerves tooling, which I'm doing this work for, I already have a tool for making filesystem images. It is fwup. For this use-case fwup actually requires two steps and is mildly more verbose. But I think the trade-off of lowering the number of tools required to set this up is a win.

Then we have the signing. Initially I had looked at what the script rpi-eeprom-digest did. My eyes glazed over and I left treating it as a black box. I knew it would calculate a digest and if provided a key sign it but the script was rough to follow. Reading the docs later it is exactly what you'd expect. SHA256 digest of the data file (boot.img) and an RSA (2048 bits required) signature.

Can fwup do that for us as well? Unfortunately, no. fwup signs the .fw metadata, not the .img file as far as I know. And it uses ED25519 rather than RSA. Much like it uses Blake2 instead of SHA. Slightly more modern choices.

But you know what can do RSA and SHA for us? Erlang. Well, Erlang might use OpenSSL. The good bit is that if we can line things up right we should not need to use the specific script because what they are doing is plugging together basic cryptographic building blocks anyway.

There are cases where I will definitely use the default tooling just to ensure I get updates and future support, fixes and whatnot. I think for this case I'll be tweaking things to see if I can do it with what we already have.

I should write up the mind-bending process of generating a trusted firmware image at some point and all the wrong assumptions I had about the order of operations for building a Nerves system. Learned a lot. Was not right very much initially.

I am actually gearing up to make a best-practice fully locked-down industrial grade device (not a Raspberry Pi, very likely an NXP iMX8 board) integration for Nerves to make checking those requirements easier. Verified Boot all the way to Nerves, ARM TrustZone managing secrets, encrypted data partition (protects data), encrypted root filesystem (protects IP). If you need this there is a chance to join the companies that are looking to fund this work and get your opinions considered as I build it. The result will be open source. I have a proposal ready to go if your company should consider this I'm happy to have a meeting about it.

If you are interested in securing embedded devices or just enjoy when others are you can let me know on the Fediverse where I'm @lawik@fosstodon.org or by responding to this email to lars@underjord.io.

Thank you for reading. I appreciate you.