A collection of information

Owning your Windows 8 UEFI Platform

Even if you only ever plan to run Windows or stock distributions of Linux that already have secure boot support, I’d encourage everybody who has a new UEFI secure boot platform to take ownership of it. The way you do this is by installing your own Platform Key. Once you have done this, you can use key database maintenance tools like keytool to edit all the keys on the Platform and move the platform programmatically from Setup Mode to User Mode and back again. This blog post describes how you go about doing this.

First Save the Variables

The first thing to do is to install and run KeyTool either directly (the platform must have secure boot turned off, because keytool is unsigned) or via the mini USB image and save all the current secure variable keys (select the ‘Save Keys’ option from the top level menu). This will save the contents of each variable as a single esl (EFI Signature List) file, so you should end up with three files: PK.esl, KEK.esl and db.esl. These files can later be used to restore the contents if something goes wrong in the updates (and because some platforms put you into setup mode by erasing the contents of all the secure variables), so save them in a safe place.

Use the UEFI Menus to remove the Platform Key

This is the step that it’s impossible to be precise about. Every UEFI platform seems to be different in how you do this. The Linux Foundation hosts a web page collecting the information but so far it only has the Intel Tunnel Mountain system on it, but if you work it out for your platform, leave me a comment describing what you did and I’ll add it to the LF page.

The most common way to get a UEFI system to display the UEFI menus is to press ESC as it boots up.

Create your own Platform Key

If you rpm installed efitools, it will automatically have created a Platform Key for you in /usr/share/efitools/keys, plus all of the PK.auth and noPK.auth files.

A platform key may be self signed, but doesn’t have to be (I’m using one signed with my root certificate). However, assuming you want to create a self-signed platform key manually, here are the steps: The standard command for doing this with openssl is

None of the parameters for the key (Like the Common Name) matters, so you can replace <my CN text> with anything you like (mine says ‘James Bottomley Platform Key 2013’) you can also add other X509 well known objects like your address. Once you have the two files PK.crt and PK.key, you need to save them in a safe location (PK.key is the one to guard since it’s your private key).

Next, create an EFI Signature List file with the public key in (this and the next steps require that you have either installed the efitools rpm or compiled the unix commands from efitools.git and installed them on your system)

cert-to-efi-sig-list -g <my random guid> PK.crt PK.esl

where <my random guid> is any random GUID you choose. You also need to create an empty noPK.esl file which can be used to remove the platform key again

> noPK.esl

(do an ls -l on it to make sure it has zero size).

Now you create the signed update files (called .auth files)

sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth

sign-efi-sig-list -k PK.key -c PK.crt PK noPK.esl noPK.auth

copy the two .auth files to your USB key and you should now be able to use KeyTool to insert them into where the platform key is. Go to ‘Edit Keys’, select the ‘The Platform Key (PK)’ and then ‘Replace Keys(s)’. Navigate the file Chooser to your PK.auth file and you now are the platform Owner. Press ESC to go to the top level menu and it should tell you the platform is in User Mode and Secure Boot is enabled. Now verify you can move back to Setup Mode by going to ‘Edit Keys’, ‘The Platform Key (PK)’ and this time selecting the first entry (showing the GUID you chose for your platform key) and then ‘Delete with .auth file’. This time navigate to noPK.auth and select it. The platform key should now be gone and when you ESC to the top menu it will tell you you are in Setup Mode. You now own your own platform and can move easily between setup and user modes.

Replace or Edit the rest of the Keys

Now you own your own platform, restoring or replacing the current platform keys is easy. Where you saved the original keys, you should have a KEK.esl and a db.esl file. If you find that KEK and db are blank, you can restore them with this file, simply place the platform into Setup Mode, go to ‘Edit Keys’, ‘The Key Exchange Key Database (KEK)’ and ‘Replace Key(s)’ and finally navigate to the KEK.esl file you saved. You can also do the same thing with db.esl

Now your platform should be back to its original condition except that you own the Platform Key and can decide easily to flip it into Setup Mode. Once in setup mode, you can edit the actual keys. One thing you can do is create your own signature key (using the method above for PK) and place it into db. You could also (assuming you never plan to boot windows) delete all the microsoft keys from the system. Beware if you decide to do this that some of your UEFI drivers may be signed by microsoft keys, and removing them all may limit the functionality of your UEFI platform. Additionally, any UEFI update to your system is also likely to come signed with the microsoft keys, however, in this case you can put the Microsoft keys back before doing the update.

If pieces of your UEFI system do need to be signed, it might be possible to extract them and sign them with your key instead of Microsoft’s, but I haven’t yet found a system that needs this, so I don’t really have much of an idea how to do it.

Remember to move your platform back to User Mode to enable secure boot before you exit KeyTool.

30 thoughts on “Owning your Windows 8 UEFI Platform”

Nice set of instructions. Thanks. I’m working on a video tutorial for UEFI Secure Boot that has a similar set of steps, so it’s nice to see another method out there with similar intent (user ownership of the secure boot process).

It hadn’t occured to me, but you are right about signed parts of the platform. Going forward all Option ROMs will have to be signed and the one who owns the key is, invariably, Microsoft.

If you swap out the keys for something custom and put it back in User Mode, all signed platform drivers and Option ROMs will fail to load, potentially rendering a system booting off a SAS card unbootable.

It’s highly unlikely you’ll be able to extract and re-sign platform drivers, it’s even less likely you’ll be able to do so with an Option ROM. Yet another defect in the secure boot architecture – and yet another case where leveraging it in ways that don’t involve Microsoft can break the system.

Actually, you wouldn’t have to re-sign the roms necessarily. You can also authorise by hash which is independent of signature. In theory, it’s easy to take a rom image, extract the hash from the signature and add it to the approved database. In practice, I need a computer with a signed rom before I can come up with a tool that might do this.

Your right that every system is different. I have an HP G7 Pavilion and it is impossible to open the UEFI Settings. From, Troubleshooting>Advanced>UEFI Settings the system reboots and never brings me to the UEFI Settings screen. I gave up on this and reinstalled under Legacy Bios. People have to watch because every OEM can set up UEFI differently.

Do you have more info on your HP G7 Pavilion? When did you buy it? Does it have Windows 8 logo? As far as I know, only some of the most recent G7 models fully support the UEFI 2.3.1c features that Windows 8 needs. Especially, rebooting to the UEFI Settings screen from Windows 8 is only supported when you have that UEFI 2.3.1c support. If your machine does not have the Windows 8 logo, then it is certain that the feature you are looking for here is not supported. In fact, this is likely true for all PCs out there, regardless of the OEM.

OK, I’ve run into a little bit of trouble with KEYTOOL.EFI. I saved a copy of all the keys into .esl files as you suggested. However, I must have done something wrong because the Platform Key is cleared but when I try to reload it from the backup PK.esl file, KEYTOOL.EFI never seems to locate the file. It just keeps saying “Select File containing additional key for The Platform Key (PK)”. When I navigate to the directory where I saved the PK.esl file KEYTOOL.EFI doesn’t see it. What did I do wrong?

Nothing really: under UEFI rules the Platform Key has to be updated as a signed file. That means you can’t put it back as an esl file, it has to be an auth file and, if you’re trying to replace the original platform key, there’s no real way to get an auth file (because you don’t have the private part of the platform key). That said, a lot of platforms don’t obey the only signed PK updates rule, so perhaps I should allow .esl files here and let the platform report a security violation if it only accepts signed updates.

If you installed the efitools package, it should have generated a signed platform key update file called PK.auth for you

What did you mean by “These files can later be used to restore the contents if something goes wrong in the updates (and because some platforms put you into setup mode by erasing the contents of all the secure variables), so save them in a safe place.”

haha… it seems you have taken an alpha blog post for good fish… unlucky mate… and shame on the blogger who made it seem more trivial than it is probably 🙂

If at least we Europeans don’t f*cking clamp down on this… I can’t personally even see secureboot be enabled by default, ahead of disabled… in Europe.. if so, humans are game over .. nothing but meat as all US greed is about, no ethics, no morals, no values, no integrity… nothing. I was more extreme and saying ban all US products already in 99-2000 but I am always 10-15 years ahead in time to others. neo-nazism here we come ^^

I found my backup of the Platform Key useful, not for restoring the PK – that would be kind of defeating the whole point of this exercise, and the EFI settings already have an option for that anyway – but for making the former PK a KEK.

In my Lenovo, the only KEK was from Microsoft. Lenovo had the PK and one key in the db, nothing else. So removing their PK meant they no longer had any way to change the db or dbx. Not that I know if it actually matters, but I decided to add their former PK back as a KEK (below the PK which is now mine). 🙂

hi,i have coded a bootloader,kernel and some features of an operating system in assembly language but i don’t know how to go ahead and make them to communicate and operate together,so am looking for a step by step procedure on how to do it till i get a .iso file from the .asm files.am using nasm assembler,cdr tools,notepad and windows 8 platform.even if you don’t have the answer direct me where i can get the answer

Can the changes to the BIOS be read by Windows 8 – this would create a possibility for mischef on behalf of a certain OS vendor. If not now, could this facility be added – that is , key comparison with the original keys?
Will a efi / bios update trash the installed keys?
I am not technical, just a Linux user determined to stay that way.
Sorry if I missed any reference to these questions in earlier articles or in discussions.
Thanks for the work. I agree with the point of view that it is better to work around these issues than to ignore them. Andrew Tridgell and the Samba project should be the guide – persistence and anti-competition cases put to the EU.

The bit I am querying is the bit at the end where I sign the KEK with the PK. I presume this is the right way to do it – so that when I run keytool it will recognise that the signature list entry has been signed by the PK?

and the -a and -t flags have to match exactly what you passed in to create KEK.forsig

If you don’t need a detached signature, it’s easier just to do it all in one go:

sign-efi-sig-list -a -c PK.crt -k PK.key KEK KEK.esl KEK.auth

You also have to be careful about the -a flag. You have to make sure that you use KeyTool update (or UpdateVars -a) because the update flag is part of the signature (if you use KeyTool replace, or UpdateVars without the -a, you have to leave the -a off the sign-efi-sig-list input).

You have to make sure that you use KeyTool update (or UpdateVars -a) because the update flag is part of the signature (if you use KeyTool replace, or UpdateVars without the -a, you have to leave the -a off the sign-efi-sig-list input).

Hi, can you please explain me step by step how to install efitools in ubuntu, ive tried to install from source but it fails when i send the comand MAKE
This is very important for me because Ihave a tablet which doesnt let me install anything but windowsx86, i wanna be able to install linux on it.
Best regard

ASUS BIOS lets you save and load key databases from the setup and you can always restore back to factory state. The problem is they don’t tell you what format they need to be if you want to load your own.

As for option ROMs being signed and causing trouble I can testify to that — I have ASUS videocard (GTX 980) which has UEFI BIOS itself in order to enable option called “hardware fast boot” which is present in Z87PRO mainboard BIOS. If you clear MS keys this won’t work and you will have to boot in legacy mode.

James, thank you for a useful post.
Could you tell please: are there any news about running Windows on the platform WITHOUT Microsoft keys (with Secure Boot = ON)? Is it possible? I.e is there any way to start Windows successfully if I (a) remove MS PK/db keys, (b) load MY keys to PK/db and then (c) resign Windows loader with MY keys? Thank you!

Thank you very much for your efitools package! I now finally own the machine I’ve bought! Very satisfying. Instead of KeyTool, I used your efi-updatevar command from Linux, but that worked great too.

One minor thing though:

When, in secure mode, I tried to remove a key from the db, withefi-updatevar -d 3 -k PK.key db
I got an error message:No public key matching PK.key in KEK

While true, the key was in PK, and as far as I understand the UEFI specification (v2.6), the PK is meant to work everywhere a KEK can be used. (At least I haven’t found any description of KEK use where it doesn’t say the PK could also be used – though the UEFI specification isn’t the easiest read I have had, so perhaps I’m missing something.)

I have so far had no problems instead using auth files signed with my PK – for changing the db with efi-updatevar, also in secure mode. (I have as yet not bothered with any KEK of my own.) Which makes me suspect it might have been your tool rather than my EFI firmware that was stopping me in that first case.