3 ms·

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 t

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.

userbinator 3y ago
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.
- 1827163 3y ago
  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_Security_Memories_Protections.pdf 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.
AlotOfReading 3y ago
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.
- dingledork69 3y ago
  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.
  - joezydeco 3y ago
    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.
    - dingledork69 3y ago
      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.

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.

userbinator 3y ago

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.

1827163 3y ago
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_Security_Memories_Protections.pdf 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.

AlotOfReading 3y ago

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.

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