Recent Features
| |||||||||||||
Other long term problemsOther long term problemsPosted Jun 11, 2012 23:12 UTC (Mon) by mjg59 (subscriber, #23239)In reply to: Other long term problems by nix Parent article: Fedora, secure boot, and an insecure future
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.
(Log in to post comments)
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.
|
|||||||||||||