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