Secure Boot, Microsoft's implementation of UEFI, has been a cause of concern for Linux users ever since it was announced in January 2012. We've looked at it a few times before, but as the dust is still settling, we've decided to revisit it.
But before we get ahead of ourselves, let's go back to the beginning and find out exactly what Secure Boot is.
Prior to 2012, all PCs booted using BIOS. This was a relic of the 80s that many manufacturers miss-implemented, which lead to a kludgey kind of system that was held together by the digital equivalent of gaffa tape. It worked, but only because of the hard work of developers who could have spent their time coming up with much cooler things t han boot interfaces if they weren't fiddling around trying to make the darned things work more smoothly.
So when Microsoft started to talk with manufacturers about the possibility of replacing the old system, everyone was quite glad of the impending demise of BIOS.
UEFI is, in many respects, a far superior system. It gives the boot programs more space to work in, and can better support more modern hardware. If it had all been left there, most people would have been happy.
However, it wasn't. They tinkered. They had to go a step further and added Secure Boot. This is an extension to UEFI that restricts booting to just systems that have been cryptographically signed using a trusted key. And the sting in the tail: Microsoft controls the master key. Crafty.
Of course as we know, this little addition doesn't make it completely impossible for Linux to boot on Secure Boot systems, it just makes it a bit tricky.
Security risk
Of course it would be easy to claim that it's all just a cynical attempt by Microsoft to further tighten its hold on the PC industry - and there are a good many people who hold that particular view.
However, it is based on a genuine security risk that can be found in Windows: boot sector viruses. This is a class of malware that infects the Master Boot Record (MBR) that sits at the start of a disk. When the user boots up, the BIOS runs the code in the MBR. If all is well, in a correctly running system, this then boots the operating system. However, a boot sector virus can hijack this process and run some malicious action before booting the OS.
Under the Secure Boot system, the system will only boot signed code, so in principal such viruses won't be able to boot. Sounds good, right? Well, there are a couple of not insignificant problems with it.
Firstly, it relies on a single key, and historically single keys have not been able to stay secret for long (remember when Pl ayStation and Blu-ray keys were secret?). Secondly, and perhaps more importantly, boot sector viruses were common back in the days of MS-DOS. The world has moved on a fair bit since then, and malware writers are no exception.
Secure Boot is a huge upheaval to solve a problem that was dying out on its own. Frankly, there are far more pressing security concerns for Windows that are completely unaffected by it.
Microsoft speaks
So, it's not likely to have an impact on the world of malicious software on Windows. It's also not particularly effective at locking other operating systems out of PCs. In the Windows 8 Hardware Certification Guidelines, Microsoft state:
"17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following: a. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.
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.
< h3> Understanding signaturesTo 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 dec ide 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.
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.
Platform boots
Let's now take a closer look at how Secure Boot works. It revolves around four things held in the motherboard's firmware: the Platform Key (PK), the Key Exchange Key (KEK), the signature database (db) and the revoked signatures database (dbx).
None of these are hard-coded on PCs, and they can be changed by a physically present user even if they do n't know any of the existing keys (for instance, you have to reboot the system and enter setup, so it can't be done over SSH, VNC or any other remote protocol).
The Platform Key is the highest level key, and can be used to sign new KEKs. The Key Exchange Key comes at the next level. This can be used to sign new entries in the db and dbx. There can be more than one KEK stored by the motherboard. Db and dbx are the main pieces that do the work. Db contains public keys that are trusted by the system to sign code so it can run. Dbx, on the other hand, contains public keys that are explicitly not trusted (for example, ones that are known to be compromised).
By default, when you buy a Windows 8 certified computer, the PK will be the manufacturer's key. There will be one KEK, that is Microsoft's KEK, and there will be one entry in db which will be Microsoft's UEFI key. If you run Windows 8, the motherboard will check the Windows 8 kernel signature against the keys in db and dbx. It will find it matches with the entry in db, and there will be nothing in dbx, so it will allow it to boot.
A choice of three
So, how does Linux work? Well, there are a few options. A distribution could produce it's own KEK that users could manually load into their systems, and then sign all their kernels with that. They could even try and get manufacturers to sign their KEK with their PK, and so distribute it along with their installation media. However, the first of these is quite technical to do, and the latter requires a degree of influence few, if any, distributions have.
There is a third way. For a one-time fee of $ 99, Microsoft will sign bootable software - but there's a catch: the software must itself be what they describe as secure. That is, it must continue the chain of signatures and not allow untrusted code to take over the machine.
If it weren't for this catch, the Linux community could just get a boot loader signed, and then use that as freely as we currently use Grub. Of course, if it weren't for this catch, and a normal boot loader was signed, virus writers could use this signed boot loader to start their malware and it would defeat the point of secure boot.
The solution most commercially sponsored distros are going with at the moment is to use a shim boot loader. Ubuntu, Fedora and OpenSuse are all doing this. The shim boots before anything else, and does very little other than include an extra key that is specific to the distribution. This extra key can be used to sign a normal Linux bootloader (usually Grub 2), which in turn loads a signed Linux kernel, and the chain of trust is complete.
There are, however, a few problems with this. Firstly, it means that the user can't compile their own Kernels (since they can't sign it using the distribution's key). Secondly, it means that Microsoft could terminate the signature for the shim bootloader (that is, add it to dbx) at a ny point if they wanted to. Which could potentially leave you right in the lurch.
There is, however, another way that's only just been released, and at the time of writing, isn't used by any distros. However, since it doesn't involve a distro getting anything signed, we expect that it will quickly become the preferred method of choice for smaller or non-commercial Linuxes. This method uses a pre-bootloader similar to the shim that's been developed by the Linux Foundation. It's also signed by Microsoft's key, but instead of using distribution-specific keys, it uses user-added hashes. This means that when a user updates their kernel, they'll have to add a new hash to the pre-bootloader's database.
In principal this could be done automatically, but that would break the chain of trust that the signatures create. This should, in theory, be as simple as the user pressing a key to confirm that they want to do this. However, this has to happen at bootup, so it can't be automated. The chain of trust is then preserved because it's the action of a physically-present user and can't be done by some malware. It is hoped that in future releases, the shim and the Linux-Foundation's pre-boot loader can be combined so that a single pre-boot loader can be used across multiple distros.
How does it work?
The final thing we'll look at is how well all this works in practice. To be honest, we didn't have terribly high hopes when we received a Windows 8 PC. We downloaded a selection of distros, burned them to DVDs, and started battle.
So we were presently surprised to find that, by and large, things just worked. Or at least they did if you selected the default options. On Ubuntu, OpenSuse and Fedora we were able to install on our Secure Boot enabled PC without having to fiddle with keys, boot loaders or anything else, for that matter. However, we had some problems when we tried to create custom partitions on the disc, or dual boot.
When it was announced, many people thought Secure Boot would lock Linux out of PCs. Fortunately, that just isn't the case, and a number of major distributions already support this system. Many more are likely to support it soon now that the Linux Foundation's pre-boot loader is ready to be used. We can only hope that these solutions continue to work with future versions of Secure Boot.
During this article, we've casually skipped over one of the biggest restrictions of Secure Boot. That is, the requirement that it can't be disabled on ARM systems. We can look at this a few different ways.
We could casually ignore it since there are so few Windows RT machines available - and regardless of Secure Boot, few people seem inclined to buy them. We could also point to the fact many of the currently best-selling (pre-Windows 8) ARM machines have locked bootloaders (iPad and iPhone among them).
We could even suggest that many of the best-selling ARM computer s that aren't phones or tablets have unlockable bootloaders (Chromebook, RaspberryPi). All these come together to make the case that we don't need to be worried about Secure Boot being locked on ARM machines.
But there is another angle to it all. Microsoft probably couldn't have insisted that manufacturers lock the boot loader on x86 machines. In the EU at least, this would almost certainly be construed as abusing a dominant market position, and that has got Microsoft in trouble before.
With ARM though, they don't have a dominant market position so are legally free to abuse their non-dominant position as much as they wish. With this in mind, some people have speculated that Secure Boot on ARM is what Microsoft want to do, and on x86 it's what they've been forced to do.
In the future, these people speculate, the x86 version will creep closer and closer to how it is on ARM until it finally locks users out of their own computers.
Cathy Malmrose, CEO of ZaReason, is one such person, and she spoke with us recently. Take a look at the interview for her views on the subject.
For now, though, Linux works perfectly well on both x86 Windows 8 machines - but we're still going to keep a very close eye on how Secure Boot changes in future versions.
     |
No comments:
Post a Comment