UEFI Secure Boot on the Raspberry Pi(linux.it)
linux.it
UEFI Secure Boot on the Raspberry Pi
https://www.linux.it/~ema/posts/secure-boot-rpi/
60 comments
Sooo if you have root on rPi you can permanently brick it by writing invalid key to OTP ?
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.
I think it has a real place on industrial equipment which the Compute Module 4 is expressly designed for, and I cannot deny that for smartphones it has a very large security value. On iPhone, for example, there has been no exploit since iOS 9 that can persist between reboots. A reboot allows the system to start from a guaranteed-secure state, see something is out of place, and repair it, at least until the same bug is exploited again.
However, that does still have value. Let's say (one dramatic example) that I'm imprisoned. The government so generously agreed to let me use my phone for an hour, but managed to use an exploit to install a keylogger for when I enter in my PIN code (an actual marketed feature of GrayKey). I can simply forcibly reboot the phone using the hardware reset, and then enter my PIN code knowing that their attempts to log my PIN code have failed.
However, that does still have value. Let's say (one dramatic example) that I'm imprisoned. The government so generously agreed to let me use my phone for an hour, but managed to use an exploit to install a keylogger for when I enter in my PIN code (an actual marketed feature of GrayKey). I can simply forcibly reboot the phone using the hardware reset, and then enter my PIN code knowing that their attempts to log my PIN code have failed.
Most phones that allow you to root them just display message about it on the start, I think that's far better solution if you still want to keep the "trusted chain" but not make device into a landfill when user wants to do something else with it. At very least for devices with user-facing UI
What do eFuses have to do with exploits on iOS? Afaik Apple does not use eFuses to prevent downgrades. iOS downgrades are prevented via verification of shsh2 blobs.
E-fuses enforce Secure Boot. Secure Boot, which cannot be disabled, are used to ensure that no exploit, no virus, no modification, can last beyond a reboot. If I want to put my device back into a guaranteed-secure state (at least for the moment), a reboot will always do the trick. I don't need to reinstall the operating system every time I'm uncertain.
This is especially important for things like smartphones. Yes, you can't boot other Operating Systems on your iPhone and there's no way to disable that. On the other hand, there's no way for a hostile government, or just your crazy ex, to permanently bug your device either. They can, of course, use various methods to try to re-infect your device after each reboot but it's hit-or-miss, especially as the bugs get fixed.
This is especially important for things like smartphones. Yes, you can't boot other Operating Systems on your iPhone and there's no way to disable that. On the other hand, there's no way for a hostile government, or just your crazy ex, to permanently bug your device either. They can, of course, use various methods to try to re-infect your device after each reboot but it's hit-or-miss, especially as the bugs get fixed.
> E-fuses enforce Secure Boot. Secure Boot, which cannot be disabled, are used to ensure that no exploit, no virus, no modification, can last beyond a reboot. If I want to put my device back into a guaranteed-secure state (at least for the moment), a reboot will always do the trick. I don't need to reinstall the operating system every time I'm uncertain.
That may work in case of Android or iOS as a whole package (or not) but all e-fuses achieve is that some fixed boot ROM bootloader loads and checks the next stage of boot code against some key and runs it. That's all. All the rest of the verification rests on the mountain of buggy code down the road.
It doesn't guarantee anything else you mentioned. If you ever signed and published a bootloader stage that has bug/fetaure allowing the attacker to bypass signature checking on any code further down, the whole scheme becomes completely useless.
For guaranteeing clean code, all you need to do is to boot clean code. :) Hardware has to reliably allow you to force boot from external storage without running any code that the attacker could have modified. That's all. Very simple and reliable. Some phones allow this. Some SBCs do allow this, too.
[Hopefully] "secure boot" is strictly less reliable and less optimal and much more complicated than this, with way more opportunities to be bitten by bugs in its implementation.
That may work in case of Android or iOS as a whole package (or not) but all e-fuses achieve is that some fixed boot ROM bootloader loads and checks the next stage of boot code against some key and runs it. That's all. All the rest of the verification rests on the mountain of buggy code down the road.
It doesn't guarantee anything else you mentioned. If you ever signed and published a bootloader stage that has bug/fetaure allowing the attacker to bypass signature checking on any code further down, the whole scheme becomes completely useless.
For guaranteeing clean code, all you need to do is to boot clean code. :) Hardware has to reliably allow you to force boot from external storage without running any code that the attacker could have modified. That's all. Very simple and reliable. Some phones allow this. Some SBCs do allow this, too.
[Hopefully] "secure boot" is strictly less reliable and less optimal and much more complicated than this, with way more opportunities to be bitten by bugs in its implementation.
A main purpose of the investment into it for iPhone is to protect their os and drm media interests, not the user. The incentive on laptops is more aligned with users for now, since you can turn it off.
Or actually make use of it as a security feature, instead of just scoffing at it and disabling it, by enrolling your own key.
E-fuses are commonly used to prevent downgrade attacks, where a system that only boots signed content can be tricked in to booting older versions with known vulnerabilities that can then be chained in to a full exploit.
Many of us first encountered them on the Xbox 360, where their use is documented in detail here: https://free60.org/Hardware/Fusesets/
The short version is a signed firmware can be programmed to not boot if more than X amount of fuses are burned, so when a change occurs that the vendor wants to ensure can't be downgraded they just increase that number and burn fuses as part of the update process. Older versions fail the check and crash themselves. There is a hardware modification that can be done to prevent fuses from being burnt but that obviously has to be done before the update.
Many of us first encountered them on the Xbox 360, where their use is documented in detail here: https://free60.org/Hardware/Fusesets/
The short version is a signed firmware can be programmed to not boot if more than X amount of fuses are burned, so when a change occurs that the vendor wants to ensure can't be downgraded they just increase that number and burn fuses as part of the update process. Older versions fail the check and crash themselves. There is a hardware modification that can be done to prevent fuses from being burnt but that obviously has to be done before the update.
That kind of defeats how secure boot works.
No. You'd still lose access to the encryption keys so the data would still be safe. But it would allow you to start over without throwing the entire device in the trash and buying a new one.
This is similar to how MCU read protection usually works --- once you set it, you can't (easily, at least --- but still possible with the right equipment or $$$) read out the firmware, but you can still do a "full erase" which clears the device to an entirely clean blank state.
Many STM32 MCUs don't even allow this, you have to physically replace the device if it's set to full protection, as it cannot be reversed. Yes, built in self-destruct.
See page 5 of the following document, it is the Level 2 protection that's irreversible: https://www.st.com/resource/en/product_training/STM32F7_Secu...
The PIC32 MCUs I use always allow you to reverse the protection, after erasing the device.
See page 5 of the following document, it is the Level 2 protection that's irreversible: https://www.st.com/resource/en/product_training/STM32F7_Secu...
The PIC32 MCUs I use always allow you to reverse the protection, after erasing the device.
Secure boot doesn't require disk encryption of any sort, that's simply a common additional feature that the RPi happens to support. Being able to change the public keys without a verified key update inherently violates the ARM security model here.
That's only relevant for device manufacturers who want to prevent the device owners from controller their hardware. This is evil and not a use case worth supporting.
Normal users care about secure boot because it protects their disk encryption.
Normal users care about secure boot because it protects their disk encryption.
I'm the IoT node design space and this is what we use. There is no sales or use case to repurpose the device one it's at the end of life, and we don't want people to do as such.
The point of secure boot is to make sure it's only our firmware running, and only our firmware connecting to our backend with the appropriate keys. Anything else is a security nuisance at best and an company killing problem at worst.
We're willing to sacrifice the SoC in those cases. Your mileage may vary.
The point of secure boot is to make sure it's only our firmware running, and only our firmware connecting to our backend with the appropriate keys. Anything else is a security nuisance at best and an company killing problem at worst.
We're willing to sacrifice the SoC in those cases. Your mileage may vary.
First, you should never trust the client.
Second, you're creating e-waste when you go out of business. This is not something that should be legal.
Second, you're creating e-waste when you go out of business. This is not something that should be legal.
If you need to physically get into a device with CM4 or rPi to reset it....
...and you are malicious actor wanting to put a backdoored system in
...you could just get the new rPi in it, that's not blocked.
...and you are malicious actor wanting to put a backdoored system in
...you could just get the new rPi in it, that's not blocked.
Yes, in a properly designed system, programming of fuses should be under strict hardware control, i.e. the power supply for blowing the fuses has to be supplied to a specific pin on the chip, and that the voltage is not applied by default.
I'm really disappointed that Raspberry Pi didn't implement hardware protection of the efuses, using the method I described above, or one similar to it. So a jumper would have to be installed, in order to supply power for blowing the fuses.
Many Allwinner SoCs have a separate VPP pin, without power supplied to this pin, it's not possible to blow the fuses. I wish the rest of the industry did that.
Notably AMD Ryzen CPUs can have their efuses blown in the field, if the Platform Security Processor is compromised: https://www.servethehome.com/lenovo-vendor-locking-ryzen-cpu...
It's just another way malware could compromise your hardware, this time physically disabling it. I'm sure malware authors might end up putting this to use somehow. And that's why the hardware should have this feature disabled by default. It should not be possible to damage hardware through software, period. There must be hardware protection against this, in a well designed system. Anything else is negligence, in my opinion. In the event of malware causing CPUs to be bricked, AMD should be held liable for the costs of replacing the processors, as they should have had foreknowledge of this occurring, when they designed the processors?
Ampere Altra ARM processors have a separate pin for efuse power, you can find that in their datasheet below on page 55, and they explicitly state to pull it to ground if you do not want to use it: https://d1o0i0v5q5lp8h.cloudfront.net/ampere/live/assets/doc...
Sadly there are no desktop-class Ampere CPUs yet. But that might change in the future.
I'm really disappointed that Raspberry Pi didn't implement hardware protection of the efuses, using the method I described above, or one similar to it. So a jumper would have to be installed, in order to supply power for blowing the fuses.
Many Allwinner SoCs have a separate VPP pin, without power supplied to this pin, it's not possible to blow the fuses. I wish the rest of the industry did that.
Notably AMD Ryzen CPUs can have their efuses blown in the field, if the Platform Security Processor is compromised: https://www.servethehome.com/lenovo-vendor-locking-ryzen-cpu...
It's just another way malware could compromise your hardware, this time physically disabling it. I'm sure malware authors might end up putting this to use somehow. And that's why the hardware should have this feature disabled by default. It should not be possible to damage hardware through software, period. There must be hardware protection against this, in a well designed system. Anything else is negligence, in my opinion. In the event of malware causing CPUs to be bricked, AMD should be held liable for the costs of replacing the processors, as they should have had foreknowledge of this occurring, when they designed the processors?
Ampere Altra ARM processors have a separate pin for efuse power, you can find that in their datasheet below on page 55, and they explicitly state to pull it to ground if you do not want to use it: https://d1o0i0v5q5lp8h.cloudfront.net/ampere/live/assets/doc...
Sadly there are no desktop-class Ampere CPUs yet. But that might change in the future.
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.
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.
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!
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.
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.
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.
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.
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...
[1] https://www.raspberrypi.com/documentation/computers/raspberr...
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...
[1] https://github.com/raspberrypi/usbboot/blob/master/secure-bo...
[deleted]
When are Raspberry Pi's going to be easily found online again for purchase? I've eyed them every few months for the past year and have seen in stock 0 times.
It does seem to be getting slightly better. I just looked at rpilocator.com, and it claims 12 different models are available from some retailers (none in the US, though). The models available are... not exactly desirable. But the last time I looked, and all prior times, for the past year or two, I would see at most one or two models available, and often just nothing.
So it's still useless, but... less useless than before? And maybe that means it'll get to a point where useful models are available again soonish?
So it's still useless, but... less useless than before? And maybe that means it'll get to a point where useful models are available again soonish?
I just bought a win 10 mini pc for $91. It's insane.
It's back up to $99 now (I got it discounted). It works fine.
https://www.amazon.com/dp/B0BHP34TH1?ref=ppx_yo2ov_dt_b_prod...
It's back up to $99 now (I got it discounted). It works fine.
https://www.amazon.com/dp/B0BHP34TH1?ref=ppx_yo2ov_dt_b_prod...
Sadly I've let go. Switched to some other small and fanless things. Surprisingly with x86-64!
same here moved on to ODROID, and not looking back .
I'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?
Does it do that transparently, maybe when the keys are enrolled?
The idea is that then bootloader verifies the rest; then your kernel would need to verify everything it runs.
Sure, but also normally you aren't manually installing the relevant firmware. There's different semantics when the 'firmware' lives on the same block device as your root filesystem.
What is the end-goal here? Vendor locking?
Make sure that someone doesn't tamper with your device. No, it's not infallible. Yes, it's better than nothing.
Why would someone tamper a RPI? Usually most people don't really store anything important on a RPI, other than services like searx or whatever.
It's not a powerful device for hosting databases, it's not really used for storage, only for small things like a Kodi server and even that lags.
It's not a powerful device for hosting databases, it's not really used for storage, only for small things like a Kodi server and even that lags.
There are several industry grade devices based on raspberry pi platform, LOL. Not just media servers.
Some people also deploy them outdoors to stuff like weather, ADS-B etc. Some make it into cubesats.
Don't just underestimate its use cases.
It has many use cases, but they don't really need extreme security. Secure boot is not really needed for something that's always running (a server).
I think the final user or implementor must be a judge of that not us.
If I have access to the physical device and the SD card/USB drive in order to pull off an attack that secure boot prevents, then why wouldn't I just take the whole damn device and swap it with my own? Presumably the network/gpio/etc. are the important part here and not the Pi.
Well, if you have physical access, you can always do basically anything. I'm sure you can easily mess up a lot of industrial equipment with your bare hands.
However, let's say that the said industrial equipment is stored in a security box, with tamper-resistant screws, and you are on camera. It's a lot harder to tamper with then, compared to just plugging in a flash drive and rebooting the Pi into USB boot; at least in theory. Ditto for helping to prevent persistent remote attacks.
However, let's say that the said industrial equipment is stored in a security box, with tamper-resistant screws, and you are on camera. It's a lot harder to tamper with then, compared to just plugging in a flash drive and rebooting the Pi into USB boot; at least in theory. Ditto for helping to prevent persistent remote attacks.
You'd presumably be using the secure boot to authenticate the device, on the network and elsewhere.
[deleted]
Or the mitigation of someone running unsigned code on your product using an embedded pi.
Stop some ways supply chain attacks can happen.
Probably some other use cases I've not considered too.
Stop some ways supply chain attacks can happen.
Probably some other use cases I've not considered too.
DRM and Treacherous Computing.
Except you can use your own keys? Nothing stops you from signing the stuff yourself (other comments in this thread link to a step by step guide!)
What's the driver situation with Bookworm on the Raspberry Pi 4 with UEFI? Has v3d[1] been ACPI-ized[2]?
[1]: https://www.kernel.org/doc/html/latest/gpu/v3d.html
[2]: https://wiki.debian.org/RaspberryPi4#Using_EFI_Firmware_and_...
[1]: https://www.kernel.org/doc/html/latest/gpu/v3d.html
[2]: https://wiki.debian.org/RaspberryPi4#Using_EFI_Firmware_and_...
What does the Pi use as a secure enclave?
The Pi does not have a Secure Enclave for secrets; as far as I know. However, it does have OTP (One Time Programmable Memory) also known as e-fuses, which if you burn a key into, it will check whatever it boots matches that key. No Secure Enclave is necessary for that functionality.
Oh nice, I didn't know about the OTP memory. That's useful. Thanks!
Raspberry PIs are mythical beasts where Iam at. They are being resold at atrocious prices by scalpers very likely in connivance with the official channels.
Does this (TianoCore) work on the Raspberry Pi Compute Module 4 (CM4)?
[deleted]
* 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)