What Microsoft's Secure Boot means for the future of Linux
We take a look at the most recent controversial feature to emerge from Redmond
18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems."
What this means is that (as long as your computer isn't an using an ARM processor) a Windows 8 certified machine must allow you to both add keys to boot a different system and disable Secure Boot. Of course, there is no way to know whether there will be similar requirements for certification in future versions of Windows.
And herein lies the crucial point: Secure Boot, in its current form doesn't lock Linux out of a computer, but it starts us down a path where access to particular hardware on a PC can be locked by the vendor. We can only speculate on where this will go, but it's not difficult to foresee a future where it becomes increasingly difficult to install the operating system of your choice on your hardware.
Understanding signatures
To fully understand this, we have to take a look at digital signatures. If you write a letter the old fashioned way, you'll probably finish it with your signature. This is a mark unique to you so that the person reading it knows that it was really you who wrote the letter. It works because everyone writes in a slightly different way, so it's quite easy to create a mark that's easy for you to make and remember, but which is very hard for other people to copy.
The secret key
In the digital world, signatures are superficially similar (in that they verify who sent the message), but they are implemented very differently. They start with a hash (also known as one-way encryption) which reduces a digital object (be it a text document, zip file, operating system kernel or anything else), and converts it into a number. There is no way of working back from the number to the original document (hence one-way encryption), and if you decide to change the original object, it will produce a different hash.
The second part involves a public/private key pair. These keys are a little like passwords and can be used to encrypt documents, but work in such a way that anything encrypted using the public key can be decrypted using the private key, and visa versa. The public key can be given to everyone, but the private key must be kept secret.
To sign something, then, you need to bring these two elements together. Firstly you hash the binary object, and then you encrypt it with your private key to create a signature unique to you. This signature can then be passed on alongside the binary object.
Get the best Black Friday deals direct to your inbox, plus news, reviews, and more.
Sign up to be the first to know about unmissable Black Friday deals on top tech, plus get all your favorite TechRadar content.
The receiver of the object and the signature then unencrypts the signature using your public key to unveil your hash, then re-hashes the object themselves. If the two hashes are equal then they know that the object is the same one you signed. If they aren't, then either the object had been changed, or the signature has been forged. Either way, they know to discard it.
In the case of Secure Boot, Microsoft's public key is included in the motherboard's firmware, so anything they sign with their private key (whether it happens to be an operating system or a new key) can be verified before being used.