5

My eyebrows rose with Matthew Garrett announcing his Secure GRUB Bootloader less than three hours after no longer being a Red Hat employee. This work and its impact on the trust chain design of the UEFI secure boot now being implemented on Windows 8 configured hardware has had me puzzled for the last six months. Can one shim the trust chain without significantly damaging the overall concept of secure boot?

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
zedman9991
  • 3,377
  • 15
  • 22
  • 2
    The enforced UEFI secure boot as microsoft is trying to enforce it's not how it's designed anyway. It's originally designed for the administrators of a system to configure and control. Not OEMs. – ewanm89 Dec 01 '12 at 17:42

2 Answers2

8

This depends what you mean by “the overall concept of secure boot”.

Pretty much all secure boot systems have several components, starting with one in ROM and ending with an operating system or even programs within that operating system. A typical boot chain is ROM → OEM bootloader → OS bootloader → OS kernel → OS startup programs. A typical secure boot chain has each element of the chain verify the signature of the next element. Each link may involve a different authority to decide which signatures are allowed (the chipset maker, the OEM, the OS vendor, …).

In the case of Matthew Garrett's shim, the path is: … → UEFI → shim → OS bootloader. The shim is signed with a signature that the UEFI BIOS accepts. The code of the shim decides what is allowed at the next stage. The shim is designed so that it allows anyone in physical possession of the device to provide their own signing key for the next stage.

If you think that secure boot is about the owner of the device controlling what the device can run, this is perfectly normal: the end user is in ultimate control of the software that is executed on the device. If you think that secure boot is about the device manufacturer locking the software against modifications by the end user, then allowing someone like Matthew Garrett to participate in the secure boot chain breaks secure boot.

The background is that Microsoft, in part via the UEFI specification, has been pushing for OEMs to activate secure boot on all platforms running Windows 8, allowing only OEM-approved operating systems (with Microsoft having a signing key). On PC-style platforms, Microsoft has signed a shim which allows other operating systems to be loaded, allowing other operating system vendors to provide a secure boot. On ARM platforms shipping with Windows 8, Microsoft has retained the only signing key, locking the user into Microsoft's operating system.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • 1
    Thanks, I will let 24 hours pass but it appears you get the check as the answer is outstanding. – zedman9991 Dec 03 '12 at 12:39
  • 1
    @Gilles - One should point out that Microsoft just wants `Secure Boot` enabled. At least on x86-64 platform its not about control over the OEM. If Microsoft didn't require `Secure Boot` to be enabled nobody would use the feature despite it being able to solve problems that do exist. – Ramhound Dec 03 '12 at 16:43
1

This is using Trusted Platform Module to defeat the Evil Maid Attack. In short this is to insure that your bootloader hasn't been tampered with, which could undermine an encrypted file system.

rook
  • 46,916
  • 10
  • 92
  • 181
  • 1
    For info: http://testlab.sit.fraunhofer.de/downloads/Publications/Attacking_the_BitLocker_Boot_Process_Trust2009.pdf – Rory Alsop Jul 02 '13 at 16:36
  • How will this defeat the evil maid attack, isn't it exactly the opposite? I quote: ["any bootloader signed with that key will then be trusted by shim"](https://mjg59.dreamwidth.org/20303.html). This is step 1 of the [evil maid attack scenario](https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html) you cite. – Stéphane Tréboux Feb 05 '18 at 13:36