| |||||||||||||
Other long term problemsOther long term problemsPosted Jun 11, 2012 11:51 UTC (Mon) by nix (subscriber, #2304)In reply to: Other long term problems by neiljerram Parent article: Fedora, secure boot, and an insecure future
A few days ago, pjones wasn't even an LWN subscriber.pjones subscriber ID: 31722 (and he's a guest, so he's not using RH's block subscription -- I assume they have one). Another subscriber ID in the same thread: 84918. By extension, unless holes in the ID are being filled in, pjones has been reading LWN for a while. I'm concerned about this problem too. As I see it there are two possibilities. Either updating keys and adding revocations is prohibited except in a special mode, in which case malware authors will copy whatever that mode is (if necessary by having kernel-mode code loiter and spy on an update in progress to observe variable parameters, before elevating themselves from kernel-mode to BIOS compromise), or updating keys is prohibited but adding revocations is not, in which case malware authors have an instant free DoS attack vector. It is possible that, given a completely compromise-free kernel, malware could never run in kernel mode to spy on a key update -- but firstly a compromise-free kernel is a pipe-dream and secondly malware that couldn't even get to kernel mode could never compromise the BIOS in the first place. So as far as I can see, as long as key updates or revocations are possible under software control at all this whole thing adds no security, adds a lot of inconvenience, and allows MS to prohibit other OSes from running on their ARM devices. (Which is the real point of all this.) Now perhaps key updates and revocations cannot be scripted, and can only be triggered from the BIOS (which means Windows updates cannot provide revocations for insecure keys but can only ask the user to do it). Desktop PCs might be safe, but server-class PCs are not, because they generally allow remote access to their BIOSes using technologies like IPMI. So on such a network malware on *another* machine can watch for a server to start rebooting, add its own key pre-emptively, then later infect it and replace its firmware. In general non-scriptable updates hugely annoy IT staff in large organizations anyway because they mean some poor sap has to walk around physically from desk to desk. So I bet the thing ends up scriptable across all machines, which eliminates its security advantages. Non-scriptable updates would mean that no keys ever got revoked on most desktop devices. So either this thing adds security only until the first key revocation (non-scriptable case) or it adds security only until the bad guys learn how to use a debugger, i.e. not at all (scriptable case). So I guess I still can't see the point of all this.
(Log in to post comments)
Other long term problems Posted Jun 11, 2012 12:21 UTC (Mon) by neiljerram (subscriber, #12005) [Link] A few days ago, pjones wasn't even an LWN subscriber.pjones subscriber ID: 31722 (and he's a guest, so he's not using RH's block subscription -- I assume they have one). Another subscriber ID in the same thread: 84918. True, but I thought I saw, a few (or several, now) days ago, "pjones (guest)". But I could be wrong about that, and in any case it's a somewhat distasteful point to make, so please consider that withdrawn. Regarding everything else you wrote: I agree, and thanks for expounding it so clearly.
Other long term problems Posted Jun 11, 2012 19:13 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> It is possible that ...
> Now perhaps key updates and revocation ...
> So I guess I still can't see the point of all this.
This is an actual written standard with actual implementations, your assumptions are questions and those questions have answers. Instead of spilling a lot of ink with possibles and maybes it would be worthwhile to see how this stuff actually works.
Other long term problems Posted Jun 11, 2012 22:03 UTC (Mon) by nix (subscriber, #2304) [Link]
That's true. I didn't think of it until after posting, and I don't really want to wade into the EFI swamp right now anyway.
Other long term problems Posted Jun 11, 2012 23:12 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
There's three levels of key in this. The first is the platform key, or Pk. Below that are the Key Exchange Keys (KEK). Finally there's the actual signature keys, db (for whitelisted keys and hashes) and dbx (for blacklisted ones). KEK updates have to be signed with Pk, and Pk will generally be under the control of the hardware vendor. db and dbx updates can be signed with either Pk or any key present in KEK. So in order to add keys to the white or blacklists, you need to have the private half of a key already.
Most users aren't going to have any of these private keys, so Microsoft mandate that it be possible to enter a "custom mode". The semantics of this aren't well defined, so it's valid for an implementation to manage it either by offering a firmware UI interface to enrol keys directly or to simply let the user delete all the existing keys which results in the system transitioning back to setup mode.
If you have unauthenticated management interfaces on your network then you obviously deserve to lose.
Other long term problems Posted Jun 12, 2012 7:10 UTC (Tue) by nix (subscriber, #2304) [Link] So in order to add keys to the white or blacklists, you need to have the private half of a key already.Aha, that makes sense. (And, again, had I done fifteen minutes of research rather than fifteen minutes' bloviating, I could probably have figured this out myself. So thanks for the information! :) ) I have horrible visions of vendors' getting the setup mode wrong such that the Pk is changed instead, breaking future updates -- but incompetent though most BIOS vendors are, I suppose the Pk is probably burned into the hardware and unchangeable even by an idiot BIOS. I must say the thought of BIOS vendors writing anything at all to do with crypto fills me with trepidation. I'm somewhat surprised that PCs can even boot reliably, with the boot process under the control of people as bad at writing code as BIOS vendors... adding extra complexity to this, particularly extra complexity designed to fail in the direction of not booting, seems seriously unwise to me.
Other long term problems Posted Jun 12, 2012 7:13 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
The crypto code itself is just openssl, and the interface on top is part of Tiano. So, thankfully, there's a single reference codebase for all of this.
|
|||||||||||||