UEFI Secure Boot on the Raspberry Pi
1–10 of 61 posts
Re: UEFI Secure Boot on the Raspberry Pi
#2I'm probably just missing it, but I'm not seeing a step where the firmware itself is locking itself to an individual RPi, which would mean you can simply change out the USB drive itself and boot whatever you want.
Does it do that transparently, maybe when the keys are enrolled?
Re: UEFI Secure Boot on the Raspberry Pi
#3The 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-bo...
* https://github.com/raspberrypi/usbboot/blob/master/docs/secu... (441KB PDF)
Re: UEFI Secure Boot on the Raspberry Pi
#4The 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…
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?
Re: UEFI Secure Boot on the Raspberry Pi
#5The 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…
[dead]
Re: UEFI Secure Boot on the Raspberry Pi
#6The 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…
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?
[dead]
Re: UEFI Secure Boot on the Raspberry Pi
#7The 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…
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?
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/raspberr...
Re: UEFI Secure Boot on the Raspberry Pi
#8The 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…
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?
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-bo...
Re: UEFI Secure Boot on the Raspberry Pi
#9The 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…
Sooo if you have root on rPi you can permanently brick it by writing invalid key to OTP ?
Re: UEFI Secure Boot on the Raspberry Pi
#10The 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…
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?
[deleted]