On 02/10/2018, Nico Huber nico.huber@secunet.com wrote:
Am 02.10.18 um 11:53 schrieb Sam Kuper:
On 01/10/2018, Youness Alaoui kakaroto@kakaroto.homelinux.net wrote:
tldr; whether the effort to disable write protection is reasonable or not depends on what you want to write protect.
Agreed.
You two might have different kinds of updates in mind. You don't need a switch for every update. With a read-only root of trust, for instance, that is secured by the switch or jumper or whatever, you could still update everything else with software only. That root of trust could either verify a signature of the following firmware parts (like vboot does) or start a measuring chain or (ideally) do both.
Separating functional updates from those that change platform-ownership is a key feature of vboot. Without such separation, you'll either make owning too easy or updating too hard.
In principle, I agree. But in practice, Librems don't seem to possess this kind of separation (yet?).
As for your question earlier about someone forgetting it. I would assume that it would be easy to have the Heads menu show a big warning to the user if it's left unprotected
Your assumption fails against a BadHeads attack.
You need to tamper more than just HEADS, otherwise the attestation of the firmware (e.g. via TOTP or a Librem Key) would fail.
That was not my understanding.
See this outline of a putative "BadHeads" attack: https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-w...
Also see Kyle Rankin's apparent confirmation that such attacks succeed (on current Librems): https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-w...
If I was mistaken about this, then I apologise.
But... there are technical pitfalls that leave the same problem for a momentary switch: Unless you use real custom chips, you'll have to use the access protection current chips support and in the case of SPI NOR flashes there usually is no simple on/off signal that tells the chip to deny writes. Usually, you only signal it to protect its write-protection configuration which you could forget to set correctly after flashing too.
Does this mean that Peter Stuge's suggestion to (de-)solder a typical SPI flash chip's write-protect pin was erroneous?
https://media.ccc.de/v/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening_...
What I'm trying to show here is that there is no simple solution that can be implemented in a single spot like putting a switch next to the existing kill switches. One shouldn't rush to implement new schemes that might seem better (compared to the state of the art, which is vboot, imho). If one wants to enhance the security of their next batch of laptops, implementing something compatible to what is already there and has itself proven to work would be a good approach (and it seems to me that is what Youness has in mind).
I agree about not leaping to conclusions. Sorry if it seemed that this is what I was doing. A couple of posts back, I did try to make clear that I believe security improvements in the firmware will be valuable (albeit probably not sufficient; i.e. a hardware switch of some kind would also be helpful).
Also, Sam, you seem to be pushing for a hardware addition that suits [wanting] to install updates that you just compiled yourself. But that's not everybody's use case.
Whether the context is a solo user, a small organisation, or a large one, it seems to me that upgrading at least *some* parts of the firmware should require physical access.
As for how much effort it should be to gain that physical access, I agree with your implicit point that if changing the root of trust is separated from upgrading other parts of the firmware, then it may make sense for the former, which should probably be done only rarely, to be effortful (e.g. to require removal of the bottom case, and use of ESD precautions). This would reduce the risk of a passer-by being able to change the root of trust on a laptop that someone has accidentally left running and unlocked for a moment while going to the bathroom or whatever.