And this is why I don't understand people who think that without secure boot devices like Pinephone are insecure.
Secure boot is nice optional protection, but real security comes from ability of the platform to reliably boot from known good media without any ability of the software outside that media to intervene.
That is the only way you can know what you're booting/running.
Relying on some crypto implementation and allowing other people to try to attempt to break it is a nice defense in depth, but not the ultimate protection, and may even induce false sense of security.
But that defeats the point of tamper-proof hardware: it should not be modifiable via software.
Unless you make adding your own keys a one-time event and then blow fuses, I’m not sure you can have a secure boot chain slung with control over the hardware keys.
It's about ownership. I want to own my phone. That means whatever I do with it is by definition not tampering.
The procedure should involve repeated ability to add and remove keys, but require direct physical access to the chip, perhaps by means of a separate device that's coded to only work with your phone, and that you would never carry together with your phone. Lacking that, I guess "one-time event and then blow fuses" is fine too, though end-users need to be warned up front they're doing something irreversible and must be absolutely sure to protect their key.
Aren’t the trusted boot signing keys from MSFT burned in and therefore not revocable? Maybe they have multiple keys with some offline backup keys or something.
Actually the solution is to store the secure-boot key and the full-disk-encryption key in the same place, and design the hardware so that erasing the former also erases the latter. You don't need any one-time anything.
Or, if you need more flexibility, some kind of out-of bound mechanism that doesn't rely on the OS that is booting and you are trying to verify. This could be loaded via some kind of internal memory card or via an interface that requires access to the board. This opens you up to physical attacks but you get a bit of a middle ground between security and flexibility.
> Secure boot is nice optional protection, but real security comes from ability of the platform to reliably boot from known good media
Which is exactly what (UEFI) Secure Boot usually aims to assist.
I mean... One can complain how it tries to achieve that, but either you realize it or not, you are seemingly in full agreement with the overall design-goal of Secure Boot.
As long as in-device firmware is modifiable and the protection relies on lack of bugs in its implementation, then I'm not in agreement.
What I have in mind is just a fixed boot order enforced by firmware stored in ROM, where external storage takes priority, and where you can easily control external storage. (as easy as inserting a uSD card)
All the TF-A, bootloader, kernel is loaded from the external storage, so no software at all is loaded from any modifiable storage that's part of the device itself, if you don't want to.
Any attacker made changes to the software on the storage inside the device would be irrelevant. Such setup seems much better than having to assume no bugs in existing firmware or HW related to secure boot, etc.
Secure boot is nice optional protection, but real security comes from ability of the platform to reliably boot from known good media without any ability of the software outside that media to intervene.
That is the only way you can know what you're booting/running.
Relying on some crypto implementation and allowing other people to try to attempt to break it is a nice defense in depth, but not the ultimate protection, and may even induce false sense of security.