8 ms·

The Pi4 has true hardware support for secure boot. If set up correctly, you won't be able to boot anything not properly signed. An incomplete overview of how th

The Pi4 has true hardware support for secure boot. If set up correctly, you won't be able to boot anything not properly signed. An incomplete overview of how this works is: * Instead of having all boot related files (start4.elf, kernel.img, ...) on the first partition of the SD card, you instead have a single boot.img FAT image containing those files instead. * You sign that file with your own RSA 2048 key and place a boot.sig containing the signature next to the boot.img file. * You flash the Pi4 EEPROM and include your public key and some additional EEPROM settings. * You instruct the EEPROM to burn the hash of your public key into the Pi's OTP memory. Once that's done, the key cannot be changed and the Pi will not boot into anything not signed with your key. * Optionally you can also place keys for disk encryption into the OTP memory and use that to encrypt everything except the boot files. That way it should be pretty hard to access them as you cannot run a rogue OS to read the OTP memory due to secure boot. References: * https://github.com/raspberrypi/usbboot/blob/master/secure-boot-example/README.md https://github.com/raspberrypi/usbboot/blob/master/secure-bo... * https://github.com/raspberrypi/usbboot/blob/master/docs/secure-boot-train-of-trust.pdf https://github.com/raspberrypi/usbboot/blob/master/docs/secu... (441KB PDF)

synergy20 3y ago
the eeprom is upgradable, someone can just reflash the eeprom and instruct it to ignore the public key in the OTP, thus render the whole crypto chain useless?
- temptemptemp111 3y ago
  [dead]
- dividuum 3y ago
  I think that's what program_pubkey[1] is preventing. While you could still flash other EEPROMs, their then mandatory public key would not match the hash written to the OTP. [1] https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#program_pubkey https://www.raspberrypi.com/documentation/computers/raspberr...
- section_me 3y ago
  This isn't possible. The docs[1] state once revoke_devkey has been set, you can't upgrade to a bootloader not supporting secure-boot and downgrading is disabled. [1] https://github.com/raspberrypi/usbboot/blob/master/secure-boot-recovery/README.md#locking-secure-boot-mode https://github.com/raspberrypi/usbboot/blob/master/secure-bo...
- deleted 3y ago
  [deleted]
temptemptemp111 3y ago
[dead]
adql 3y ago
Sooo if you have root on rPi you can permanently brick it by writing invalid key to OTP ?
- electroly 3y ago
  You'd think there would be some way to burn "disable secure boot" into the OTP bits to protect a machine that you don't intend to use secure boot on, but I don't see it addressed in some brief Google searches. You can burn in a key and you can burn in "force secure boot" but I don't see how you burn in "disable secure boot." I think changing the bootloader setting "revoke_devkey" to 1 and rebooting without doing the other steps would brick it, but I'm not gonna try it!
  - ilyt 3y ago
    IMO permanent locking is just useless feature that increases e-waste unnecessarily. It doesn't stop attacker from dumping whatever is running on the device and just exploiting it then replacing board with unsecured rPi/CM4, it just allows vendors to lock in their stuff even more. I'd rather prefer alternative like say device have private key that can be used to validate device's "authenticity", and that key is: * unavailable if device is not booted via secure boot * resetted if you reset secure boot to turned off Then: * software can use it as "device key/license key" for proprietary applications, acting as mini-HSM akin to TPM; sign the generated public key with company's cert on device production and if it ever gets put out of the secure mode, byebye license. * no total bricking, no landfill, hackable devices.
- section_me 3y ago
  Yes. If you have physical access, as this requires you to pull a GPIO pin down to enter the mode required for the setting on the one time programmable memory. Documentation states: WARNING: Modifications to OTP are irreversible. Once revoke_devkey has been set it is not possible to unlock secure-boot mode or use a different private key.
- josephcsible 3y ago
  Yep. I wish OTP memory, eFuses, etc. were all illegal due to unnecessarily creating e-waste. In places where OTP is actually required for some technical reason, it should have to be on an easily replaceable socketed chip with no other functionality.
WirelessGigabit 3y ago
So these things don't run a BIOS like a 'normal' computer? Because I can just enroll a key in my BIOS that I trust.
- AlotOfReading 3y ago
  No ARM system runs BIOS. There are two keys here, both of which are stored in a finite amount of OTP memory. OTP is simply the cheapest of the allowed storage options for ARM secure boot. Rewritable storage options that allow key migration exist, they're just more complicated and expensive.

synergy20 3y ago

the eeprom is upgradable, someone can just reflash the eeprom and instruct it to ignore the public key in the OTP, thus render the whole crypto chain useless?

temptemptemp111 3y ago
[dead]
dividuum 3y ago
I think that's what program_pubkey[1] is preventing. While you could still flash other EEPROMs, their then mandatory public key would not match the hash written to the OTP. [1] https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#program_pubkey https://www.raspberrypi.com/documentation/computers/raspberr...
section_me 3y ago
This isn't possible. The docs[1] state once revoke_devkey has been set, you can't upgrade to a bootloader not supporting secure-boot and downgrading is disabled. [1] https://github.com/raspberrypi/usbboot/blob/master/secure-boot-recovery/README.md#locking-secure-boot-mode https://github.com/raspberrypi/usbboot/blob/master/secure-bo...
deleted 3y ago
[deleted]

temptemptemp111 3y ago

[dead]

adql 3y ago

Sooo if you have root on rPi you can permanently brick it by writing invalid key to OTP ?

electroly 3y ago
You'd think there would be some way to burn "disable secure boot" into the OTP bits to protect a machine that you don't intend to use secure boot on, but I don't see it addressed in some brief Google searches. You can burn in a key and you can burn in "force secure boot" but I don't see how you burn in "disable secure boot." I think changing the bootloader setting "revoke_devkey" to 1 and rebooting without doing the other steps would brick it, but I'm not gonna try it!
- ilyt 3y ago
  IMO permanent locking is just useless feature that increases e-waste unnecessarily. It doesn't stop attacker from dumping whatever is running on the device and just exploiting it then replacing board with unsecured rPi/CM4, it just allows vendors to lock in their stuff even more. I'd rather prefer alternative like say device have private key that can be used to validate device's "authenticity", and that key is: * unavailable if device is not booted via secure boot * resetted if you reset secure boot to turned off Then: * software can use it as "device key/license key" for proprietary applications, acting as mini-HSM akin to TPM; sign the generated public key with company's cert on device production and if it ever gets put out of the secure mode, byebye license. * no total bricking, no landfill, hackable devices.
section_me 3y ago
Yes. If you have physical access, as this requires you to pull a GPIO pin down to enter the mode required for the setting on the one time programmable memory. Documentation states: WARNING: Modifications to OTP are irreversible. Once revoke_devkey has been set it is not possible to unlock secure-boot mode or use a different private key.
josephcsible 3y ago
Yep. I wish OTP memory, eFuses, etc. were all illegal due to unnecessarily creating e-waste. In places where OTP is actually required for some technical reason, it should have to be on an easily replaceable socketed chip with no other functionality.

WirelessGigabit 3y ago

So these things don't run a BIOS like a 'normal' computer? Because I can just enroll a key in my BIOS that I trust.

AlotOfReading 3y ago
No ARM system runs BIOS. There are two keys here, both of which are stored in a finite amount of OTP memory. OTP is simply the cheapest of the allowed storage options for ARM secure boot. Rewritable storage options that allow key migration exist, they're just more complicated and expensive.