SUSE and Secure Boot: The Details
In the previous posts, UEFI Secure Boot and Our Planned Approach to Secure Boot, Olaf Kirch has introduced you into the topic of UEFI Secure Boot and the basics of our approach to implementing it in SUSE. In this post, I’ll lead you through the technical details of our Secure Boot plan. So be prepared for this post to be rather detailed. And technical.
The goal of Secure Boot is to prevent malware from hiding embedded in the boot chain by performing a verification of every executed component starting with a fresh reboot of the whole platform. To achieve its goal, Secure Boot must prevent any modification of the verification process, the keys, or any other variables by untrusted code or untrusted entities. An example of an untrusted entity is a hacker who has penetrated the system through an unpatched security hole in the operating system.
There are two types of trusted users:
First, those who hold the keys. The Platform Key (PK) allows almost everything. The Key Exchange Key (KEK) allows all a PK can except changing the PK.
Second, anyone with physical access to the machine. A user with physical access can reboot the machine, and configure UEFI.
UEFI offers two types of variables to cater to the needs of those users:
The first is the so called “Authenticated Variables,” which can be updated from both within the boot process (the so called Boot Services Environment) and the running OS, but only when the new value of the variable is signed with the same key that the old value of the variable was signed. And they can either only be appended to or changed to a value with a higher serial number.
The second is the so called “Boot Services Only Variables.” These variables are accessible to any code that runs during the boot process. After the boot process ends and before the OS starts, the bootloader must call the ExitBootServices() call. After that, these variables are no longer accessible, the OS can’t touch them.
The various UEFI key lists are of the first type, as this allows on-line updating, adding and blacklisting of keys, drivers and firmware fingerprints. It’s the second type of variable, the “Boot Services Only Variable” that will help us in our quest for an implementation of Secure Boot that is both secure and open source friendly. And compatible with GPLv3.
As Olaf explained in the last post, we start with a shim, based on the Fedora shim, signed by either a certificate signed by the SUSE KEK or a Microsoft-issued certificate, based on what KEKs are available in the UEFI key database on the system.
This allows the shim to load and execute.
The shim then goes on to verify that the GRUB2 bootloader it wants to load is trusted. It will not use the SUSE KEK nor the Microsoft cert for this. In a default situation the shim will use an independent SUSE certificate embedded in its body. In addition, the shim will allow to “Enroll” additional keys, overriding the default SUSE key. Let’s call them “Machine Owner Keys” or MOKs for short.
The enrollment process begins by rebooting the machine and interrupting the boot process (e.g., pressing a key) when the shim loads. The shim will then go into enrollment mode, allowing the user to replace the default SUSE key with keys from a file on the boot partition. If the user chooses to do so, the shim will then calculate a hash of that file and put the result in a “Boot Services Only” variable. This allows the shim to detect any change of the file made outside of Boot Services and thus avoid the tampering with the list of user approved MOKs.
An important aspect to remember is that all of this happens during boot time, only verified code is executing now. Therefore, only a user present at the console can say, “I want to use my own set of keys.” It can’t be malware or a hacker with remote access to the OS because hackers or malware can only change the file, but not the hash stored in the “Boot Services Only” variable.
GRUB2, once loaded and verified by the shim, will call back to the shim when it wants to verify the kernel – to avoid duplication of the verification code. The shim will use the same list of MOKs for this and tell GRUB2 whether it can load the kernel.
And that’s it.
This is all you need to be able to work on improving the kernel or the bootloader. Install a new set of keys and authorize them by being physically present during the first reboot.
Also, thanks to MOKs being a list and not just a single MOK, you can make the shim trust keys from several different vendors, allowing dual- and multi-boot from the GRUB2 bootloader.
In the end the real implementation may be a little bit more complicated – for example password-protecting the MOK authorization feature to allow secure authenticated updating of the MOK list from within the OS – but this is the gist of it. And since you can freely modify GRUB2 and your kernel as an owner of a machine, you are happy and so is GPLv3 that the machine didn’t get tivoized.
You may be wondering whether this goes against the UEFI specification or Microsoft Win8 Logo requirements or any of the associated contracts.
I don’t think so – even the UEFI specification allows, but doesn’t mandate, that a UEFI implementation allow a user authorize EFI code with an invalid signature by adding a hash to a special variable.
And the Linux Foundation has asked vendors to make sure to include a way of clearing the PK to allow the user to enroll their own set of keys.
Our approach is just making sure that a feature like this is available everywhere.
To keep the “PC” a free platform.
Bravo… simple, elegent and secure.
So when opensuse rolls out a kernelupdate, that will be signed with a suse key, and does not need the user to import a file to importMOK, right?
Yes, you understand that right.
When using openSUSE kernels only, including updates, you’ll never have to enroll keys, as the SUSE certificate is present by default.
If you use your own kernels, even then you need to enroll your certificate into the MOK list just once and then keep signing your kernels with your signing key.
Thanks for clarifying. That private/public key, trusted certificate stuff is way over my head.
[…] Pavlík explains SUSE’s plans for supporting UEFI secure boot on the company’s blog. It is similar to […]
Its a down right pity that a Shim to give Machine Owner Keys.
I personally believe there still should be pressure to add Machine Owner Key support to the KEK.
Something not answered here is if Grub 2 will be able to say this kernel should be this MOK if it not stop. If boot loaders can declare MOK to use from particular points on everything here is perfect.
Basically the means to tell the shim you should have a MOK owning to X and this should be signed by that. Of course still keep the option to say to the shim if its any of what you have allow it as well.
Reason a person with many kernels on there system they think they are booting like SUSE but its been swapped with one swaped with one of the MOK keys.
Yes for debuging a means to have a list of MOK’s that have been used so far would be useful. The taint check. shim listing used MOK’s description should not cause a security issue.
Could you also consider doing the shim key less. That the SUSE public key is a MOK.
The reason why is if for some reason the SUSE private key does leak if its a MOK is removable and replaceable Also doing this make the shim 100 percent generic between distributions so possibly the Linux foundation pays for a once off signing that everyone uses.
Generic solution would allow SUSE, Redhat and others to have there own KEK and every machine to get that able to run what ever using SUSE, Redhat and others boot loader secure.
Also if the SUSE key was a MOK it clearly says if the system support MOK we don’t need to add our own shims to it. This way Linux support becomes does the machine have MOK or can be made support MOK.
SUSE fully supports the efforts of the Linux Foundation and the Free Software foundation to make sure that it is possible and easy for users to install their own PKs and KEKs on a machine, through the so-called “Setup Mode” or “Custom Mode” of Secure Boot.
The MOK list, handled entirely inside the shim is intended for scenarios where using KEKs isn’t possible or is inconvenient for any reason. It’ll hopefully also help unify key handling between distros, as it’ll no longer need to be platform-dependent.
Thanks a bunch for all your efforts to help ensure the Linux community is able to use the latest commodity hardware.
[…] (1, 2). Die Pläne für Suse unterscheiden sich an zwei Stellen aber von denen Fedoras, wie aus einem Eintrag im Suse-Blog hervorgeht, in dem Vojtěch Pavlík Details der vorgesehenen Implementation […]
A very elegant solution. Could someone write up a time line graph with points in the timeline where activites would take place? The concept is easier to conceptualize when there is a timeline chart with descriptions under the significant events (steps)
I would do it if I had a more hand-on situation, but my pc does not have UEFI code. Presumeably the shim will recognize that and just do its thing as if it received UEFI confirmation.
What will the system loader (anaconda) or other do when we have a new distribution version?
I’m working on a yet more detailed whitepaper, which should answer that. The shim is UEFI-only, it will not work on a BIOS-equipped machine, simply because there will be no way to load it. If you want to play with UEFI Secure Boot, you can always do so inside qemu or qemu-kvm, using the freely available Tianocore UEFI firmware from Intel.
[…] Via | SUSE […]
How would this work with virtualisation? Can GRUB2 on a virtual machine communicate with the shim and MOK list on the host, or are the shim and MOK list virtualised too? Or can the admin choose which model they want?
All of Secure Boot is contained within the virtualized environment. So the MOK list will be virtualized. The hypervisor, however, can pre-set the MOK variable to whatever value the adninistrator needs before booting the image.
OK – but it seems to me that for this to be secure, changing the Boot Services Only variables in the guest’s boot process needs to be disabled, or otherwise locked to something physical on the host (like a dongle of some kind?). Virtualisation solutions can allow access to the virtual machine’s entire boot process in a console that is available over a network, and even allow the virtual machine to access some physical resources on the client where the console is being run (as well as on the host machine). This means that “physical” access to a virtual machine provides no trust at all.
Also with a hosted hypervisor like VirtualBox or VMware Workstation, it seems to me that this represents a possible break in the trust chain. The image could be tampered with before being booted, or malware could inject something into the hypervisor software installation that subverts the images’ boot process. (Maybe it is possible in principle to write a complete malicious hypervisor, although that might be too big to deploy as malware payload:-)) Maybe the virtualisation software and/or the virtual machine images need to be signed, as well as GRUB2 and the kernel?
Please correct me if I have misunderstood something :-). I understand that this is not your problem (or indeed a problem of operating systems as such), but do you think that the issues that I have raised would need to be considered by the developers of virtualisation products in order to implement Secure Boot properly?
In a virtualized scenario, physical access is equivalent with access to the virtual machine image or to the remote console. As those are usually well protected and have a limited attack surface, I don’t expect the difference between physical and virtual to be much of an issue for Secure Boot.
Everyone missed the simple answer here. This shim could be avoid for open source virtual environment solutions at least. Why because you are in control of the virtual environment you are the hardware maker that sets up the KEK DB and can insert what ever keys you want.
So grub can be directly signed with a KEK Key for virtual.
This adds a interesting question can MOK keys be the same format as KEK DB keys. Just MOK will not do the I am signed by hardware maker.
Yes, the intent is to use a standard key format.
[…] or UEFI drivers from running at boot time especially for ARM based devices. Now, in a recent post on their blog, Article author, Vojtěch Pavlík explains some of the details about how Windows 8 […]
I have made a spanish translation of this article in my blog:
Thank’s to Vojtěch Pavlík for let me do it.
Will this work with the the draft NIST Special Publication 800-147, here?: http://csrc.nist.gov/publications/PubsSPs.html
Look in particular at the draft 800-147B, “BIOS Protection Guidelines for Servers”. Once this goes through, most US government computers (and many others) will be required to comply. I *think* it’ll be okay, but I’m not sure.
Having studied the NIST Special Publication 800-147(b), I can say that what I describe in the article doesn’t interfere with the firmware’s ability to comply with the guidelines.
In fact, while the 800-147(b) describes only the protection of the firmware (the guidelines calls it the BIOS, which the UEFI standard wouldn’t agree to), Secure Boot extends the same level of protection to the bootloader and, in the approach described in the article, to the OS, too, with the same root of trust in the firmware itself and the Platform Key. Even if you would extend 800-147(b) to include the bootloader and the OS kernel in the to be protected area, the described approach will still comply, as changing the MOKs requires local access, falling under Section 3.2, “Secure Local Update” and no remote update is possible if the UEFI firmware itself complies.
How is this going to affect the majority of the non-technically inclined end-users. Could they still be able to dual-boot OpenSUSE with Windows 8 on UEFI imbeded machines by going through the usual installation process simply answering a few more questions? Thank you.
>An important aspect to remember is that all of this happens during boot time, only verified code is executing now. Therefore, only a user present at the console can say, “I want to use my own set of keys.” It can’t be malware or a hacker with remote access to the OS because hackers or malware can only change the file, but not the hash stored in the “Boot Services Only” variable.
Why not? Hashes are not signed.
Its like you read my thoughts! You appear to grasp
so much approximately this, like you wrote the e book in it or something.
I believe that you just can do with a few % to force the message home a bit, but other than that, that is excellent blog. A great read. I will definitely be back.
I’m really enjoying the theme/design of your site. Do you ever run into any internet browser compatibility problems? A small number of my blog audience have complained about my website not working correctly in Explorer but looks great in Opera. Do you have any solutions to help fix this issue?
Thank you! We test in multiple browsers, and it’s true that there are often differences which we have to correct to get them all looking good (if not precisely the same). Your best bet is to test your site with all the standard browsers (certainly IE) going back a version or two, and do your best.
I absolutely love your website.. Pleasant colors & theme.
Did you build this website yourself? Please reply back as
I’m wanting to create my own personal website and would like to know where you got this from or exactly what the theme is named. Cheers!
Thank you for the nice compliment! This is a custom theme developed by our team, and so I’m sorry to say it’s not available for re-use. But if you Google for “wordpress themes” you’ll find there are some beautiful options for free or very inexpensively priced. Good luck with your site!
We are almost reaching the end of 2016 and in opensuse Leap 42.1 is still not possible to use uefi secure boot, so far the only distro i found that supports secure boot is Fedora.
Does Suse really plans to make a distro that supports secure boot or they simply left the secure boot approach?
Please tell me if im not in the prope place to ask this, if thats the case im sorry for my intervation.