Hi Youness,
On 15/10/2018, Youness Alaoui kakaroto@kakaroto.homelinux.net wrote:
One thing to note is that this week will be my last week at Purism as I'm going on sabbatical for a few months, and I may or may not (most likely won't) come back to Purism in a few months.
Thank you for your efforts to make Coreboot work on the Librems, and for the enthusiasm you displayed here in the mailing list and on the Purism blog.
Although I might have sounded critical on occasion, this was never personal; it was always out of a concern to avoid missing opportunities to achieve the most secure and privacy-protecting machines available within the constraints of the hardware and the business model. I.e. my "criticisms" were always intended to be constructive. I hope that they did not form any part of your decision to take a break from Purism, and if they did, I apologise.
I wish you a good sabbatical, in any case.
@Sam for 90% of the users, they would either :
- never [flash the ROM]
- only do it when a new update is released and interests them, i.e:
once or twice a year. So [...] it would be far from annoying to users since most won't care or notice that all that is needed, and if they do, they won't care to have to do it so rarely.
I fear that even performed rarely, it might be beyond some users' abilities. But...
It will however, especially with cover-opening protections (either using glitter/whatever methods on screws to notice if they'd been opened, or with an EC handling a cover switch notification), that could be very helpful to increase their security.
... I agree that making it tamper-evident is indeed potentially valuable.
Your assumption fails against a BadHeads attack.
Yes indeed, I wrote a proof of concept which was a Heads that would extend PCRs with the same values that coreboot did (and have a coreboot with measured boot disabled) and it passed the TOTP authentication.
Many thanks for confirming this to the mailing list. I was hoping to write and somehow disseminate (e.g. to the Heads developers) a POC myself, but I'm glad to be spared that need.
If you could send your POC to the Heads team for integration into the test suite, that would be great. This flaw in Heads needs to be fixed (if it hasn't already been). Having the POC in the test suite would also help to detect future regressions, once the issue is fixed (if it *can* be fixed).
If it hasn't yet been fixed... Thinking aloud: as a community, we need to find a way (or else, determine that it really is impossible) to achieve robust mutual authentication between PC and user, with just an SPI ROM and a boot disk and a TPM and a TOTP/challenge-response token. Some kind of formal verification might be in order.
That's something that other possible solutions would try to mitigate (such as vboot I think).
In the open world, vboot does seem to be the state of the art.
Apple's T2 chip might also mitigate against this sort of thing, although it does not authenticate to the user via TOTP: the check is implicit rather than explicit. I may be wrong, though. Public documentation seems to be scarce.
it would be great if Purism could be sure not only to spec, but also to list on the Librem specification pages on the website, a SPI flash ROM chip that *does* obey its write-protect pin regardless of firmware. Thanks :)
I didn't realize that "some chips don't obey the write-protect pin", but rather my understanding is that the write protect pin is there to say "the protected blocks are protected/not-protected according to hardware. The SPI flash (according to the datasheets I've read) can protect regions either with "don't protect" or "protected by WP#" or "protected until power-cycle". The status register bits can be written to either as volatile or non-volatile (for non volatile, you need another command iirc, and you can't do it with hardware sequencing, same for the 'protect until power cycle', which also needs to write to status-register-2 which can't be done with hardware sequencing either). So, really, a flash rom chip does obey its WP pin, it just depends on how it's set.
Thanks for this. I clearly need to spend more time reading data sheets and running tests on SPI flash ROM chips.
All best,
Sam
-
Sam Kuper