Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UEFI Secure Boot on the Raspberry Pi

linux.it

Post reply on HN
Print view View original

11–20 of 61 posts

Re: UEFI Secure Boot on the Raspberry Pi

#11

Post by electroly »

adql wrote: post #9
dividuum wrote: post #3

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…

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

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!

Re: UEFI Secure Boot on the Raspberry Pi

#12

Post by section_me »

adql wrote: post #9
dividuum wrote: post #3

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…

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

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.

Re: UEFI Secure Boot on the Raspberry Pi

#16

Post by josephcsible »

adql wrote: post #9
dividuum wrote: post #3

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…

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.

Re: UEFI Secure Boot on the Raspberry Pi

#18

Post by gjsman-1000 »

josephcsible wrote: post #16
adql wrote: post #9

Earlier quoted context omitted.

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.

Re: UEFI Secure Boot on the Raspberry Pi

#19

Post by simulator5g »

gjsman-1000 wrote: post #18
josephcsible wrote: post #16

Earlier quoted context omitted.

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 i…

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.

Re: UEFI Secure Boot on the Raspberry Pi

#20

Post by gjsman-1000 »

simulator5g wrote: post #19
gjsman-1000 wrote: post #18

Earlier quoted context omitted.

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 i…

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.

Post reply on HN