The Open Source community has a corner turn coming, in the upcoming roll out of UEFI enabled 'Secure Boot' hardware. And the 'Build Your Own' hobby computer builders are in for a rude shock as well, as they are going to have to start paying per each re-install of a commercial operating system, because UEFI provides a mechanism to reliably control (read: prevent free unlimited) reinstalls of Microsoft operating systems, as well as end user Application software
An integrated computer hardware or motherboard Manufacturer (Dell, HP, SuperMicro, etc) will have no choice but to conform to the new 'latest is greatest' approach that Windows 8 will bring to the market if it wants to keep selling new hardware. ... which means being able to run whatever Microsoft's latest is. And I don't want to be coy about this: it is in their economic interest as well to gain a way to limit the life of hardware, as it builds a ready market for re-selling to customers with older hardware
I simplify here, but once in full release, Windows 8, (and going forward, I think I can safely predict that high ticket proprietary Applications), will ONLY install on a system that has a secure chain of signed binaries and RELATED counter-signed Variables. That secure chain will be done by verifying a chain of checksums ('hashes') duly counter-signed by a Key-Exchange Key (KEK) public/private key pair, on back to a database itself counter-signed and verifiable by a Platform Key (PK). The PK may, but is not required to be able to, be wiped by an end consumer. For the reasons below, I think there WILL be an ability to reset the NVRAM on the general case
But perhaps not -- in the past applying some firmware updates required cracking open a case and moving a jumper. So I feel pretty comfortable that a mechanical 'jumper' option will appear as motherboards are designed, to prevent purely electronic (via executable code actions) key-wipes; it just makes sense in a corporate IT environment to prevent end employees from tampering with machines. And in some use cases, the jumper disappears altogether
Fresh from the fabrication plant, no PK exists in a UEFI 'bios' and it is said to be in a 'Setup' state. In the usual case, a PK will initially be generated and 'injected' into the NVRAM keystore at the time of manufacture (those cases where the end customer expects to receive a 'ready to run' computer). That is, while there may be provision for generating and injecting a PK keypair (either at initial receipt, or on a unit needing a 'wipe and reinstall'), in the general case the PK keypair injection will have already been done by the Manufacturer. And the Manufacturer is NOT going to readily supply the private side of that key with each chassis it ships ... the support load is too great, and an end user will be told: they are out of luck as it is not available
Those Variables I mentioned will almost certainly contain one or more 'unique per unit' UUID type hash, and as I say, these variables will be countersigned and held in the motherboard's non-volatile configuration ram. We have seen such approaches before -- old SGI hardware used NVRAM to hold a MAC address, that may have been signed as well, and SGI install disks looked for values in a range assigned to SGI
Part of an OS install process will be generating and authorizing a unique UUID, signed by a controlled KEK keypair chain, that chain running unbroken through a specific PK. The Manufacturers will generate a keypair, good for a given number of units and report sales to their Licensor. No more pesky COA stickers. If a KEK pair is compromised, they report it as such to their Licensor (here, Microsoft), and the public side is added to a blacklist database update. Computers relying on that trust chain simply stop booting, or stop running some node-locked Application, and instruct their owners to call technical support
Eventually Tech support says that this unit is out of warranty and end of life, and the Manufacturer or its competitor gets a new sale. Life is good for the Licensor and the Manufacturers as a group
As I read the UEFI specification, however, nothing requires being able to 'read back' those hashes, so that one could back them up, or have them at hand to be able to re-inject them. Indeed, the usual model is to NOT be able to read back enough information from a secure key store to be ABLE to back up and restore it. To do so would destroy the metering and regulation value of the KEK signed hashes and Variables
I assume the Open Source community will solve how to transition most hardware back into Setup state; I see that some of the kernel hackers have already solved wiping and then injecting new keys into the PK. I know that UEFI supports, but does not mandate use of x.509 certificates, so it is just a matter of time until StartSSL or some other Open Source friendly Certificate Authority documents and issues signing keys for both formal distributions, and end users compiling local kernel modules needing signing
Two futures are around the corner, here: Either way, BYO hobby users of commercial operating systems and applications lose a lot of usability to experiment. When it is too hard to 'play' around, they will need a new space to experiment and customize in. It is Open Source for the win as such a venue
And for the Open Source folks: 1. If the hardware permits an ability to re-set a UEFI 'bios' to Setup state and to re-inject an initial PK, Open Source wins, as it picks up new users when a person is presented with an estimate for re-purchasing all that they thought they had bought, but that need new activation keys, and asks: what else can I do? 2. If the hardware does not, this is readily apparent, and the manufacturer is shunned and their hardware avoided by folks in the know
I know it is the present fashion the Open Source community to damn UEFI and all, but the outlook is not all darkness. Just a turn around the corner to a new future
Updated: The interface at blogger.com (wasn't this formerly blogspot.com) has changed, and I missed that the final copy would 'lay our' so poorly; it is also eating random markup that formerly worked ... fixed
