Slashdot Mirror

http://blog.hansenpartnership.com/
(Scroll down, it's the third blog post down)

Has instructions on how to own your platform. It's not that hard. You first install KeyTool.efi to backup your original shipped keys, then you generate and install your own, and sign an authorization to delete it... then you can toggle between tpm setup mode and user mode at will, and add or remove whatever keys you want. Should take you maybe 20 minutes (and a few reboots) or so if you know your way around a command line.

Personally, when I got a new windows 8 laptop, this was the second thing I did. (The first one being to install the non-crapware oem version of windows 8 onto an external bootable usb3.0 drive so it's there if I ever really need it for something, but doesn't waste space on my primary drive for the ocassional dual boot)... ((PS: to do the latter you need to get your registration key from the last string of /sys/firmware/acpi/tables/MSDM))

http://blog.hansenpartnership.com/
(Scroll down, it's the third blog post down)

Has instructions on how to own your platform. It's not that hard. You first install KeyTool.efi to backup your original shipped keys, then you generate and install your own, and sign an authorization to delete it... then you can toggle between tpm setup mode and user mode at will, and add or remove whatever keys you want. Should take you maybe 20 minutes (and a few reboots) or so if you know your way around a command line.

Personally, when I got a new windows 8 laptop, this was the second thing I did. (The first one being to install the non-crapware oem version of windows 8 onto an external bootable usb3.0 drive so it's there if I ever really need it for something, but doesn't waste space on my primary drive for the ocassional dual boot)... ((PS: to do the latter you need to get your registration key from the last string of /sys/firmware/acpi/tables/MSDM))

Why can't I load the key myself from UEFI or another side channel?

You can.

http://blog.hansenpartnership.com/owning-your-windows-8-uefi-platform/

Typical Slashdot ignorance and blind hatred.

This covers a good part of the process:

http://blog.hansenpartnership.com/owning-your-windows-8-uefi-platform/

I think this is the biggest, and most complained about, assumption in all the debacle. If it was true, the Microsoft key issue wouldn't exist (we'd just have a "Linus key" and that would be the end of it).

Sure, MS give lip service to this but there's nothing that guarantees it will be available. Nothing at all. You can turn Secure Boot off, but then you've had BIOS engineers working on a feature that you then turn off because it doesn't work as you need it to.

Sorry but that's just wrong.
Here's how you add your own keys(and remove Microsoft's if you want):
http://blog.hansenpartnership.com/owning-your-windows-8-uefi-platform/

Owning your Windows 8 UEFI Platform
Posted on 15 February 2013 by jejb

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=/” -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 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 PK.crt PK.esl

where 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

Linux Foundation approach to Secure Boot
James Bottomley just published a description of the Linux Foundation's Secure Boot plan, which is pretty much as I outlined in the second point here - it's a bootloader that will boot untrusted images as long as a physically present end-user hits a key on every boot, and if a user switches their machine to setup mode it'll enrol the hash of the bootloader in order to avoid prompting again. In other words, it's less useful than shim. Just use shim instead.

Further UEFI bootloader work
A couple of people have asked whether we're planning on implementing the Linux Foundation approach of simply asking the user whether they want to boot an unsigned file. We've considered it, but at the moment are leaning towards "no" - it's simply too easy to use to trick naive users into running untrusted code. Users are trained to click through pretty much any security prompt that they see, and if an attacker replaces a legitimate bootloader with one that asks them to press "y" to make their computer work, they'll press "y". If that bootloader then launches a trojaned Windows bootloader that launches a trojaned Windows kernel, that's kind of a problem. This could be somewhat mitigated by limiting this feature to removable media, and we're seriously considering that, but there are still some risks associated. We might just end up writing the code but disabling it at build time, and then anyone who wants to distribute with that policy can do so at their own risk.