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
openssl req -new -x509 -newkey rsa:2048 -subj “/CN=<my CN text>/” -keyout PK.key -out PK.crt -days 3650 -nodes -sha256
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.
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).
Pingback: LinuxLife Blog » Bottomley: Owning Your Windows 8 UEFI Platform
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.
Pingback: UEFI Restricted Boot: Torvalds Asks Developers Not to “Please Microsoft by Doing Idiotic Crap Approach”, Petition Set Up to Nail Microsoft for This Antitrust Abuse | Techrights
Pingback: Microsoft Windows 8 UEFI Secure Boot complaint: The case for and against | News Weblastic
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?
Thanks,
Barry
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
Hmm. What good is a backup of the Platform Key then?
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.”
Thanks,
Barry
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.
Hi James, if I run:
sign-efi-sig-list -a -t ‘May 13 00:00:00 UTC 2013’ -o KEK KEK.esl KEK.forsig
would I be right in thinking that the correct way to sign the list is to do it like this:
openssl smime -sign -binary -in KEK.forsig -out KEK.signed -signer PK.crt -inkey PK.key -outform DER -md sha256
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?
Thanks
yes, that’s right (it’s what man sign-efi-sig-list says). You need a final step where you create the authorised update from the smime signed bundle:
sign-efi-sig-list -a -i KEK.signed -t ‘May 13 00:00:00 UTC 2013’ KEK KEK.auth
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).
Hi James,
With my AMI UEFI-based board, I’m doing great until I go to import the PK and get:
Failed to update variable: (26) Security Violation
Keytool says the variable is empty and Secure Boot is not enabled. What does this mean? I followed your tutorial verbatim.
thanks,
Ben
Sorry for the spam. It turns out that the board I was using had a bad BIOS image. A newer one seems to work fine! Thanks for these fantastic tools!
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).
Pingback: Secure Boot with Debian Testing | burtness
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
Or it would be even better if you could email me the key with all the required files to insert them in my UEFI
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.
Hello 🙂
I am trying to create the noPk.auth file and it appears that sign-efi-sig-list will not accept a file of 0 size. Can someone please point me in the right direction here. Thanks!
It works for me:
> noPK.esl
sign-efi-sig-list -c /usr/share/efitools/keys/PK.crt -k /usr/share/efitools/keys/PK.key PK noPK.esl noPK.auth
Timestamp is 2016-1-14 09:10:59
Authentication Payload size 40
Signature of size 1142
Signature at: 40
James
Hi James,
What Linux are you on? I’m on Ubuntu 15.04.
Thanks
Never mind that last question… I got it. Silly mistake on my part ;p
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, with
efi-updatevar -d 3 -k PK.key dbI got an error message:
No public key matching PK.key in KEKWhile 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.
The firmware is from Insyde, in a now 2 year old Lenovo computer.
I had one question on platform key. You mentioned that it doesn’t have to be self signed. But if it acts as root of trust, then how does UEFI verify it. It can be verified only when it is self signed. Am i missing something in my understanding?
UEFI only cares about the embedded public key. The X.509 root of trust is never checked by UEFI (because it doesn’t have access to a PKI), so UEFI for secure variables fundamentally doesn’t care about the X.509 chain of trust and X.509 is merely a convenient carrier for a public key.
There are a few situations where partial chain checking occurs, like an authenticode signature by a key that chains to the db key. But for the verification to pass, all intermediate certs must be in the pkcs7 bundle of the authenticode so the chain can be checked without reference to a PKI.