$ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt \ -nodes -days 3650 -subj "/CN=Your Name/" $ openssl x509 -in MOK.crt -out MOK.cer -outform DER
Originally written: 11/4/2012; last update: 2/3/2013
I'm a technical writer and consultant specializing in Linux technologies. This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!
| Donate $1.00 | Donate $2.50 | Donate $5.00 | Donate $10.00 | Donate another value |
This page is part of my Managing EFI Boot Loaders for Linux document. If a Web search has brought you to this page, you may want to start at the beginning.
In addition to implementing a new boot protocol, UEFI adds a new feature that has the potential to cause a great deal of confusion and trouble, but that can also improve system security: Secure Boot. As the name implies, Secure Boot is intended as a security feature. Its potential to improve system security is greatest on Windows systems. By its very nature, though, Secure Boot can also make it harder to boot Linux. This page provides an overview of what Secure Boot is and how the Linux community is responding to it. Be aware that these matters are changing rapidly, so if you read this more than a few months into 2013, be aware that things may have changed!
For decades, PCs have been plagued by viruses, worms, and other malware. Some of the earliest viruses for PCs spread as boot sector viruses: They resided as code in the boot sectors of floppy disks and spread from one computer to another when users booted their computers using infected DOS floppies. Although other modes of virus transmission gained prominence as floppies faded in importance and Internet connections became common, pre-boot malware has always had its advantages to malware authors. By executing before an OS kernel gains control of the computer, malware can "hide out" in ways that aren't possible once an OS has taken over. Pre-boot malware can become invisible to the OS, making it virtually impossible for virus scanners to detect the malware—at least, not without rebooting into an emergency system that's not infected.
BIOS provides few protections against infection by pre-boot malware; in the BIOS boot path, the OS implicitly trusts whatever executes as the boot loader. Until late 2012, this has been true of most production EFI implementations, too. Secure Boot, though, is designed to add a layer of protection to the pre-boot process. With Secure Boot active, the firmware checks for the presence of a cryptographic signature on any EFI program that it executes. If the cryptographic signature is absent, doesn't correspond to a key held in the computer's NVRAM, or is blacklisted in the NVRAM, the firmware refuses to execute the program. Of course, this is simply the start of the process; a trusted EFI boot loader must continue the boot process in a secure fashion, leading ultimately to an OS that is itself secure. A malware author would need to get the malware signed, which would be difficult if users control their own system keys. Thus, pre-boot malware can be blocked. There are a lot of ways for things to go wrong higher up the chain, but Secure Boot at least provides a foundation from which to secure the computer as a whole—at least, in theory!
The description of Secure Boot in the UEFI specification doesn't provide any mechanism to create a web of trust for its keys. Based on the UEFI specification alone, one might think that Secure Boot would be implemented in a site-by-site fashion; administrators at a site could sign the boot loaders that they use, thus locking out malware authors. Microsoft, however, included a requirement in its Windows 8 certification program that vendors ship computers with Secure Boot enabled. As a practical matter, this means that vendors must include Microsoft's keys on their computers, and unless vendors include other keys, only boot loaders signed by Microsoft will work.
Fortunately, things aren't quite as bad as this might seem. Microsoft has partnered with Verisign to manage boot loader signing. Anybody can pay $99 to Verisign to obtain the means to sign an unlimited number of binaries such that they'll run using Microsoft's key—or more precisely, a key that Microsoft uses to sign third-party binaries. Furthermore, Microsoft requires that x86 and x86-64 computers provide the means to completely disable Secure Boot, giving users control over the process. (ARM users aren't so lucky; Microsoft requires that Secure Boot can not be disabled on ARM systems bearing a Windows 8 logo.)
The initial public discussion of these matters was sparked by a blog post by Matthew J. Garrett, a Red Hat developer, in September of 2011. Much of the initial discussion on Web forums and other public meeting places was downright panicky, and even a year later I see occasional overwrought posts. I urge calm; as described on this page, there are at least three ways to deal with Secure Boot: disable it, use a pre-signed boot loader, or use your own keys.
If you aren't convinced that Secure Boot will improve your system's security, you might want to disable the feature entirely. Given the fact that most malware targets Windows, this approach is most reasonable on computers that don't run Windows. You'll have to be comfortable navigating your firmware's setup screens to do this. Unfortunately, there's no standardization in where Secure Boot options might be located or what they might be called; therefore, I can't provide a procedure that will work for every computer. I can, however, describe the options on one computer I own that supports Secure Boot: The ASUS P8H77-I motherboard. This board ships with Secure Boot options disabled, but based on my experimentation, I can see how it would probably ship if it were used on a computer with Windows 8 pre-installed. Based on those assumptions, to disable Secure Boot, you should:
Of course, your computer's firmware is likely to be different from mine. Your best bet if you want to disable Secure Boot is to study your own system's firmware options. Your user manual might or might not be of any help. In the case of my ASUS P8H77-I, the manual makes no mention of Secure Boot options; I had to figure this out by trial and error. I've heard of implementations that are both better and worse than the one in my ASUS. On the "better" side, some label the option with a fairly obvious name of Secure Boot and options of Enabled and Disabled. On the "worse" side, I've heard of others that produce scary-sounding messages in red when you try to disable Secure Boot, or that require booting into Windows and running a Windows program before you can access the firmware.
Using a boot loader signed with Microsoft's key is the simplest and most direct approach to dealing with Secure Boot; however, it's also the most limiting approach. Depending on what signed boot loader you use, you'll have to deal with boot-time confirmation whenever you try to boot an unsigned boot loader or be limited in what OSes and kernels you can boot. As of early 2013, I know of two signed boot loaders intended for use with Linux: Fedora's shim program (which is also being used by Ubuntu, SUSE, and Sabayon) and the Linux Foundation's "PreBootloader." As I write, a signed version of shim is available, but the PreBootloader has yet to be released as a signed binary. I also describe how to verify a signed boot loader's signature to be sure it is what you think it is.
To adhere to the goals of Secure Boot, a Linux boot loader should provide authentication of the Linux kernel, and a Linux distribution should provide further security measures in the kernels it provides. Unfortunately, these goals are at odds with the open source philosophy of freedom and user control of their computers. Thus, a Secure Boot solution for Linux must balance these two goals. Fedora designed its shim program to do just that. It does so by supporting three different types of keys:
The whole point of Secure Boot is to prevent malware from gaining control of the computer. Therefore, when booting with Secure Boot active, Fedora 18 restricts actions that some Linux users take for granted. For instance, Linux kernel modules must be signed, which will complicate use of third-party kernel drivers, such as those needed by Nvidia's and AMD/ATI's proprietary video drivers. To launch a locally-compiled kernel, you must sign it with a MOK and register that MOK with the system. The extent of such restrictions is entirely up to those who develop and sign the boot loader launched by shim and the kernel launched by that boot loader, though. Some distributions are likely to ship kernels that are relatively unencumbered by added security restrictions.
In addition to Fedora (and presumably eventually Red Hat Enterprise Linux), SuSE and Ubuntu have announced that they'll be using the shim boot loader—in fact, Ubuntu 12.10 already uses an early version that doesn't support MOKs. (See this blog post for an analysis of it in action.) Signed versions of shim should be available in versions of these distributions released in late 2012 and thereafter.
As a practical matter, if you want to use shim now, you have three choices: You can run Ubuntu 12.10; you can run Fedora 18; or you can run the signed version released by Matthew Garrett, add your own MOK, and sign whatever binaries you like. Unfortunately, this process is still a bit tedious right now. In brief, it is:
$ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt \ -nodes -days 3650 -subj "/CN=Your Name/" $ openssl x509 -in MOK.crt -out MOK.cer -outform DER
At this point the computer may boot into its default OS, reboot, or perhaps even hang. When you reboot it, though, the boot loader you installed under the name grubx64.efi should start up in Secure Boot mode. Depending on its capabilities, it might boot any kernel it can boot as if Secure Boot were disabled, launch only boot loaders signed with the platform's Secure Boot keys, or launch EFI programs or kernels signed with regular Secure Boot keys or your own MOK.
In the future, using shim will be easier, since distributions will ship with pre-signed boot loaders, obviating the need for most of these steps. If you want to sign your own binaries, though, you'll still need to install the signing software, add your own key via MokManager, and sign the binaries you create yourself or obtain from another source.
The easiest way to verify that your boot loaders are properly signed is to try booting with them. You might want to check them before rebooting, though, just to be sure they'll boot. To do so, you'll need a copy of the public key that you created earlier with openssl. If the binary was signed by your distribution maintainer, you'll need a copy of their public key. If you've got the key in X509 certificate form (typically with a .crt filename extension), you can verify the binary with the sbverify command:
$ sbverify --cert keys/refind.crt refind_x64.efi Signature verification OK
This example shows a successful verification of the refind_x64.efi binary against the keys/refind.crt public key. Failures are typically preceded by messages that describe what went wrong, often using technical language. Typically, binaries are either not signed or they're signed with a key other than the one whose public counterpart you tried to use.
If you're trying to verify a binary that was signed by your distribution provider, you'll need a copy of their public key. These are often provided in the source package for their copies of shim, so check there. I also provide several with my rEFInd boot manager, in the refind/keys subdirectory. The problem is that the most readily-accessible key files are in DER form (with a .cer or .der filename extension), but you need a text-mode PEM file (with a .crt filename extension). You can convert from one form to the other with openssl:
$ openssl x509 -in fedora-ca.cer -inform der -out fedora-ca.crt
This example converts the fedora-ca.cer file to fedora-ca.crt, which you can use to verify the authenticity of signed Fedora binaries.
The Linux Foundation's solution to the Secure Boot problem, known as PreBootloader, shares some significant similarities with shim, but it's also different in two key respects:
As a practical matter, PreBootloader has an advantage if you want to launch an unsigned boot loader (as on an older Linux distribution) or if you want to distribute a bootable image but lack the funds to pay for your own signing key. It's particularly good in these cases if you're not technically inclined, since you don't need to deal with the signing keys described in reference to shim. If your distribution signs its boot loaders and/or kernels, you're better off using shim. If your boot loaders (perhaps including your kernels) seldom change, then either program will work equally well, provided you're willing to deal with signing keys.
To use PreBootloader, follow these steps:
At this point, your computer should reboot into your regular boot loader, and it should be able to launch kernels and follow-on boot loaders as if they were signed with your platform's Secure Boot key—provided you registered those binaries with HashTool! This last point is an important one. If you're using rEFInd or gummiboot to launch Linux kernels, you'll need to register each new kernel as you (or your distribution's package system) installs it. This fact also means that you must provide a way to launch HashTool. ELILO can't do this, but you can configure rEFIt, rEFInd, gummiboot, GRUB Legacy, and GRUB 2 to launch HashTool. In fact, rEFInd 0.6.7 and later recognize the HashTool.efi binary and provide a tag for it on the main screen.
Behind the scenes, the PreBootloader is actually using the same MOK list that shim uses; PreBootloader is simply using it to store program hashes rather than keys. It's possible that in the future, shim and PreBootloader will acquire each others' features. At the moment, though, if you want to use keys, you should use shim, and if you want to use hashes of unsigned binaries, you should use PreBootloader. In theory, you should be able to use one of these tools to launch the other, which would then launch your boot loader, thus enabling you to use either keys or hashes for authentication. I've not tried this, though.
It's possible to replace Microsoft's keys with your own. This can be a useful approach if you want the benefits of Secure Boot but don't want to trust Microsoft or any of the others who will be signing binaries with the Microsoft keys. There are three main steps to this process: generating your own keys, signing your binaries, and installing your keys in your firmware. I describe each of these steps in turn. Be aware that, at least as of late 2012, the procedures required to add your own keys are fairly advanced. For instance, I describe how to obtain the necessary Linux software via git and to compile it locally. If you're not comfortable with such procedures, you may have to abandon this approach.
The first step to using your own Secure Boot keys is to generate these keys. To do so, you must first install two programs, neither of which is yet widely available in binary form. The first of these programs is efitools and the second is sbsigntool (the same program used to sign MOKs). Both programs rely on the GNU-EFI library. The procedure for installing all of these packages is as follows:
At this point, you have Secure Boot keys in files within the efitools directory, and the LockDown.efi program will install them once you run it from an EFI shell program under the right circumstances. Of course, there's no point to locking down the firmware unless you have a signed boot loader, so that's the next step....
You'll presumably want to sign binaries such as grub.efi or a Linux kernel with an EFI stub loader. Furthermore, if you're planning to dual-boot with Windows or some other OS, you'll probably have to sign its boot loader, too. This is true even if it's already been signed with another key—the procedure described on this page replaces your firmware's existing keys, so existing signatures will no longer work, and you must therefore replace the signatures on existing binaries.
In any event, the procedure to sign an EFI binary is fairly straightforward, once you've installed the sbtools package and created keys by preparing the efitools package:
$ sbsign --key ~/efitools/DB.key --cert ~/efitools/DB.crt \
--output vmlinuz-signed.efi vmlinuz.efi
warning: file-aligned section .text extends beyond end of file
warning: checksum areas are greater than image size. Invalid section table?
This example signs the vmlinuz.efi binary, located in the current directory, writing the signed binary to vmlinuz-signed.efi. Of course, you must change the names of the binaries to suit your needs, as well as adjust the path to the keys (DB.key and DB.crt).
This example shows two warnings. I don't claim to fully understand them, but they don't seem to do any harm—at least, the Linux kernel binaries I've signed that have produced these warnings have worked fine. Another warning I've seen on binaries produced with GNU-EFI also seems harmless:
warning: data remaining[1231832 vs 1357089]: gaps between PE/COFF sections?
On the other hand, the ChangeLog file for GNU-EFI indicates that binaries created with GNU-EFI versions earlier than 3.0q may not boot in a Secure Boot environment when signed, and signing such binaries produces another warning:
warning: gap in section table:
.text : 0x00000400 - 0x00019c00,
.reloc : 0x00019c91 - 0x0001a091,
warning: gap in section table:
.reloc : 0x00019c91 - 0x0001a091,
.data : 0x0001a000 - 0x00035000,
gaps in the section table may result in different checksums
If you see a warning like this, you may need to rebuild your binary using a more recent version of GNU-EFI.
If you're using rEFIt, rEFInd, or gummiboot, you must sign not just those boot manager binaries, but also the boot loaders that they launch, such as Linux kernels or ELILO binaries. If you fail to do this, you'll be unable to launch the boot loaders that the boot managers are intended to launch. Stock versions of ELILO and GRUB don't check Secure Boot status or use EFI system calls to load kernels, so even signed versions of these programs will launch any kernel you feed them. This defeats the purpose of Secure Boot, though, at least when launching Linux. At least some future versions of GRUB will communicate with shim for authenticating Linux kernels and so may refuse to launch a Linux kernel that's not been signed.
Once you've signed your binaries, you should install them to your ESP as you would an unsigned EFI binary. Signed binaries should work fine even on systems on which you've disabled Secure Boot.
As a side note, the pesign utility, available from git://github.com/vathpela/pesign.git, is an alternative to sbtools; however, because efitools is coded to use sbtools, I've barely looked at pesign. You might want to check it out if you have problems with sbtools, though.
With your keys ready and your binaries signed, you can now configure your computer to use them. Unfortunately, this process is likely to vary greatly from one EFI implementation to another. The following is based on my experiences with an ASUS P8H77-I motherboard, so if you're using a different EFI implementation, you may need to look for options that are similar but not identical to those described here, or even deviate very substantially from the following instructions. With that caveat out of the way, here's how to install Secure Boot keys on at least some computers:
At this point, your computer should be set up for Secure Boot. (If you haven't already installed your signed EFI binaries, though, you must do so now.) You should be able to reboot and use the signed binaries; but unsigned binaries, or those signed by anybody but you, should not run.
In late 2012, Secure Boot is a modest-to-major hassle for Linux users. Although it has the potential to improve security, Linux has historically not been plagued by viruses, so it's unclear that Secure Boot will be a benefit for Linux-only computers. If you dual-boot with Windows, though, you may want to keep Secure Boot enabled. In the medium and long term, using the Fedora shim program looks like the best way to do this; but as of early January 2013, the rarity of pre-signed follow-on binaries makes shim awkward to install and use. In the meantime, disabling Secure Boot is the easiest way to deal with it. Signing your own boot loaders to use the native Secure Boot mechanism and your own key set is another alternative, and one that provides you with the greatest security and flexibility; but this approach is the hardest one to implement.
In other words: It's a mess right now, but Linux developers are working to clean it up.
Go on to "Repairing Boot-Repair"
Return to "Managing EFI Boot Loaders for Linux" main page
If you have problems with or comments about this web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.
Return to my main Web page.