4 ms·

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

by adql 3y ago

electroly 3y ago
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!
- ilyt 3y ago
  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.
section_me 3y ago
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.
josephcsible 3y ago
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.
- gjsman-1000 3y ago
  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.
  - simulator5g 3y ago
    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.
    - gjsman-1000 3y ago
      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.

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

by adql 3y ago

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!

ilyt 3y ago
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.

section_me 3y ago

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.

josephcsible 3y ago

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.

gjsman-1000 3y ago
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.
- simulator5g 3y ago
  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.
  - gjsman-1000 3y ago
    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.