On Wed, Oct 17, 2018 at 9:42 AM R S rene.shuster@bcsemail.org wrote:
Yes, thanks Youness for all the hard work and research. You provided an exceptional service. I enjoyed your rants and explanations both on Purism's blog and here. Hopefully Purism can fill that void you are leaving behind.
Thanks! I had a lot of fun, and this community is really great! I hope we still get to work together again in the future and cross paths!
On Tue, Oct 16, 2018 at 7:45 PM Sam Kuper sam.kuper@uclmail.net wrote:
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.
Thanks! I understand that the criticism was never personal, and I think you all were justified in being critical as well, but then things started to change for the better in purism and it took time for people here (understandably) to see that the change was not just smoke and mirrors. I hope that with me gone, they'll find a good replacement and they'll continue working with the coreboot community and keep moving forward, instead of backward. No, you or anyone else's criticism here had zero part in my decision to leave. On the contrary, I really enjoyed working with the coreboot community, you're all very welcoming, so thanks for that! I'm leaving because I'm feeling close to a burnout, and I don't want to get stuck in one, so I dropped both Purism and a second client I had, in order to concentrate on my health and well being. The reason I might not be coming back to Purism in the future is because they have a new contract for employees/contractors which I disagree with and I'm not ready to sign. It's still a draft though so if the feedback is taken into consideration and lawyers don't reject the feedback and the final version of the contract is acceptable to me, then I might come back. We'll see what happens! :)
@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...
Yeah, it might make someone not update if they realize they need to do that, but I guess if they'd only need to do it in order to break the root of trust and overwrite the bootblock or whatever, then that might be good. Either way, it's better than having the WP# hard wired to VCC as it is right now.
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).
Yeah, I did that a few months ago, the PoC is rather simple but would be hard to have in a test suite, I'm not sure. Basically, I did 'cbmem -c | grep -i extend" to get the log which says "extending PCR <id> with <hash>", then I rebuilt coreboot and disabled MEASURED_BOOT, then in head's init script I just added the lines : tpmcli pcr extend <id> -h <hash> (more or less, can't remember the name of the command or what arguments it needed.. I think i had to build a modified version of the tool so i can give it directly the hash to extend with instead of a message for it to hash) That's all!
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.
I don't think there's a way to fix it without using some other method. Currently, having Heads block any writes to the SPI flash and only allow heads itself to update the bios after it verifies that the rom is signed correctly, that's a good solution, but of course, it will only prevent remote attacks or local software attacks. Anyone can always just open the cover and use a hardware flasher to replace everything. Hopefully with the next hardware, they'll have a way to tell users if the cover was ever opened, and make it easier for users (I'm hoping for a header) to have users verify their flash content with a hardware flasher when needed/periodically. Either way, 100% security doesn't exist in my opinion, all anyone can do is make it so difficult, it stops being worth the trouble (or force the attack to tailor his attack to a specific machine).
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.
I don't know, either way, in 2 days, it will be out of my hands :) I've sent Kyle a link so he can read this entire thread and figure out what needs to be done.
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.
You're welcome! You can see here : https://www.winbond.com/resource-files/w25q64fw_revk%2007012016%20sfdp.pdf Pages 14 to 20. Especially figure in 7.1.7
All best,
Sam
Thanks, Youness.
-
Youness Alaoui