Windows 8 Secure Boot signing with custom keys

Is there a way to run Windows 8 in UEFI Secure Boot with a custom signing key (ie delete the Microsoft keys from the key db)? I've tried signing "bootmgfw.efi", "bootmgr.efi" and "winload.efi" but all it does is kick off the repair which replaces the original files. The end goal is to have a system which would only boot drives signed with custom keys.

How EXACTLY have you attempted signing those .efi files?

I don't think that you can sign MS executables anyway, most probably you want to use a SHIM, instead :

http://www.rodsbooks...secureboot.html

the whole stuff is anyway AFAIK/AFAICU (little) very tricky matter:

http://www.rodsbooks...rolling-sb.html

https://en.altlinux....Boot_mini-HOWTO

Wonko

I have an HSM produced key and I signed the binaries with the signtool as described here:

https://technet.micr...y/dn747881.aspx

I know that the signing process works because I can boot Linux with a boot loader signed the same way just fine.

I'm looking into using a shim but the question is if I were to remove the Microsoft signature from the allowed db would bootmgfw.efi (still signed by Microsoft) still work? Do any of these boot components do some kind of self-verification (I mean how does it know to kick repair off)?

Thanks

AFAIK the whole idea is that the MS originated bootloader is signed and ONLY verifies with the MS issued signature, which is needed and that cannot be removed.

The general idea of Secure Boot is not about "security" (in the sense of "limiting access" or "limiting execution to a given machine" which is what I understand you are attempting to achieve ) , but more to only execute "trusted and verified" software), see:

https://technet.micr...y/dn747883.aspx

 

 

The Secure Boot process works as follows and as shown in Figure 1:

1. Firmware Boot Components: The firmware verifies the OS loader is trusted (Windows 8.1 or another trusted operating system.)
    
2. Windows boot components: BootMgr, WinLoad, Windows Kernel Startup. Windows boot components verify the signature on each component. Any non-trusted components will not be loaded and instead will trigger Secure Boot remediation.
   • Antivirus and Antimalware Software initialization: This software is checked for a special signature issued by Microsoft verifying that it is a trusted boot critical driver, and will launch early in the boot process.
      
   • Boot Critical Driver initialization: The signatures on all Boot-critical drivers are checked as part of Secure Boot verification in WinLoad.
      
3. Additional OS Initialization 
    
4. Windows Logon Screen 

As I see it (but I might be very wrong about it ) you need to "insert" something "before" the BOOTMGR is loaded and that file is what you can sign, then this (at the moment only hypothetical file, let's say it is a custom, modified, and self-signed version of GRUB2) would need to chainload the EFI BOOTMGR, with something *like*:

 

 

menuentry "Windows 8 UEFI" {
insmod part_gpt
insmod fat
insmod search_fs_uuid
insmod chain
set root='(hd0,gpt2)'
search --fs-uuid --no-floppy --set=root 3f85-acfe
chainloader (${root})/efi/Microsoft/Boot/bootmgfw.efi
}

IF the Microsoft key is not found the BOOTMGR (AND the following files in the boot chain) will refuse to boot, but as well if *somehow* the MS EFI BOOTMGR is chainloaded without going through your "authentication" program it will boot fine (since the key for it exists), so all the security stands (not entirely unlike what used to be in good ol' BIOS) in locking the system in such a way that only the "pre-bootmgr" bootloader can be actually booted.

Wonko

The problem with the shim approach (or GRUB2), as I understand it, is that if one were to put a vanilla Windows 8 drive in, it would still boot fine because the Microsoft key is still in the allowed signatures database. If I were to remove it, would part 2 of the secure boot process (where Windows boot components verify each others signatures) still work? ie is this signature stored elsewhere on the system, outside of the UEFI allowed signatures database?

Thanks

Yes, that is the issue, AFAIK the boot chain verifies itself against keys stored in the firmware, not anywhere else.

As said it is like good ol' BIOS, you lock the booting to a given device and protect the BIOS access, an intruder would need to open the case and replace the hard disk in order to boot the machine (and - as an example - there used to be cases with an alarm connected to their opening, nothing that could not be worked around by a determined intruder anyway).

In theory-theory one could *somehow*:

1) remove the MS key from firmware

2) have the hypothetical pre-boot program re-add it before chainloading the EFI bootmgr

3) as soon as the OS boots remove again the key from the firmware through another hypothetical program running in the OS

But locking the UEFI firmware would be anywyay needed to avoid that any other device could be booted, and the replacing of the boot device would still be possible.

Of course the new, stupid BTW, EFI environment allows to write also very "complex" programs, BUT it it sane enough to separate the boot from the runtime processes, so AFAICU:

http://vzimmer.blogs...ing-system.html

you cannot have #3 above, it is likely that you could have (still theory-theory) the MS key automatically removed at each boot by the same #2, but this makes m00t of the approach as "at rest" the system will have the key and thus it will be exposed to "other boot device attack".

One could mandate that instead of switching off the computer it should be rebooted into the hypothetical #1 and then switched off at the time the key is removed, still a determined attacker with physical access could still be able to (say) remove the disk device and image/clone it, etc.

Wonko

I think you're trying to fundamentally avoid the whole purpose of secure boot.

The point of secure boot is that your boot loader and firmware is not being interfered by a rootkit or third party malware. It's a real great idea in theory, it's extremely anticompetitive in practice (which, I think, microsoft knows).

What you are asking for is a way to make your own keys that will allow you to boot whatever you like and have the firmware be OK with it. That's really never going to happen. There are firmwares out there that allow installing custom keys, but there is not a standard implementation, and impractical besides.

At the moment, secure boot requires microsoft signed keys, and even that is usually ignored by the manufacturer. For example, HP theoretically supports the secure boot standard, but a microsoft signed grub loader *still* does not load properly. This is an improper implementation of secure boot, and HP doesn't give a shit.

The answer is to disable secure boot. It's not the ideal answer, it's not even the best practice answer, but that's the only way you're gonna get anything but microsoft to reliably load on a computer.

For the moment, I have never seen a computer that doesn't allow secure boot to be disabled. When it does happen, then we must start worrying, but I doubt that would be the case anytime soon.