UEFI Secure Boot on the Raspberry Pi • Hacker News Board

Re: UEFI Secure Boot on the Raspberry Pi

#31

Post by captn3m0 » Thu, May 04, 2023, 6:51 PM UTC

deckard1 wrote: post #24

justeleblanc wrote: post #15

Earlier quoted context omitted.

Make sure that someone doesn't tamper with your device. No, it's not infallible. Yes, it's better than nothing.

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.

You'd presumably be using the secure boot to authenticate the device, on the network and elsewhere.

Re: UEFI Secure Boot on the Raspberry Pi

#32

Post by CircleSpokes » Thu, May 04, 2023, 6:54 PM UTC

josephcsible wrote: post #17

amelius wrote: post #13

What is the end-goal here? Vendor locking?

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!)

Re: UEFI Secure Boot on the Raspberry Pi

#33

Post by ilyt » Thu, May 04, 2023, 6:54 PM UTC

joezydeco wrote: post #27

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.

That kind of defeats how secure boot works.

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.

Re: UEFI Secure Boot on the Raspberry Pi

#34

Post by ilyt » Thu, May 04, 2023, 6:56 PM UTC

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…

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

Re: UEFI Secure Boot on the Raspberry Pi

#35

Post by ilyt » Thu, May 04, 2023, 7:05 PM UTC

electroly wrote: post #11

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 ?

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…

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.

Re: UEFI Secure Boot on the Raspberry Pi

#36

Post by ilyt » Thu, May 04, 2023, 7:05 PM UTC

monocasa wrote: post #2

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?

The idea is that then bootloader verifies the rest; then your kernel would need to verify everything it runs.

Re: UEFI Secure Boot on the Raspberry Pi

#37

Post by [deleted] » Thu, May 04, 2023, 7:16 PM UTC

deckard1 wrote: post #24

justeleblanc wrote: post #15

Earlier quoted context omitted.

Make sure that someone doesn't tamper with your device. No, it's not infallible. Yes, it's better than nothing.

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.

[deleted]

Re: UEFI Secure Boot on the Raspberry Pi

#38

Post by r12343a_19 » Thu, May 04, 2023, 7:17 PM UTC

kylehotchkiss wrote: post #29

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.

Sadly I've let go. Switched to some other small and fanless things. Surprisingly with x86-64!

Re: UEFI Secure Boot on the Raspberry Pi

#39

Post by cma » Thu, May 04, 2023, 8:07 PM UTC

gjsman-1000 wrote: post #20

simulator5g wrote: post #19

Earlier quoted context omitted.

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, yo…

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.

Re: UEFI Secure Boot on the Raspberry Pi

#40

Post by kelnos » Thu, May 04, 2023, 9:03 PM UTC

kylehotchkiss wrote: post #29

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?