What does the Pi use as a secure enclave?
UEFI Secure Boot on the Raspberry Pi
21–30 of 61 posts
Re: UEFI Secure Boot on the Raspberry Pi
#22What 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.
Re: UEFI Secure Boot on the Raspberry Pi
#23[deleted]
Re: UEFI Secure Boot on the Raspberry Pi
#24What 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.
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.
Re: UEFI Secure Boot on the Raspberry Pi
#25Earlier 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.
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.
Re: UEFI Secure Boot on the Raspberry Pi
#26What 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!
Re: UEFI Secure Boot on the Raspberry Pi
#27Earlier 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.
That kind of defeats how secure boot works.
Re: UEFI Secure Boot on the Raspberry Pi
#28Earlier 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 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.
Re: UEFI Secure Boot on the Raspberry Pi
#29When 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.
Re: UEFI Secure Boot on the Raspberry Pi
#30Earlier 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…
> 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.