Hacker News Reader

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!

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.

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.

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.

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.

> 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.

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.

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

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.

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.

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.

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.

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.

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.

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...

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...