search slide
search slide
pages bottom

Microsoft leaks Secure Boot credentials, demonstrates why backdoor ‘golden keys’ can’t work

Over the past year, there’s been a raging debate over what kinds of encryption companies should use and whether they should retain the ability to crack end-user devices when ordered to do so by the federal government. Many in the government have called on companies to provide this functionality, claiming that it’s possible to create a backdoor with a so-called “golden key” that allows only legitimate government actors to access information while simultaneously locking out black hats and hackers.

A number of prominent security researchers and analysts have pushed back against this argument, noting that it’s practically impossible to ensure that knowledge of such a backdoor is confined to participating companies and appropriate agents of the government. Now, a new security breach in Microsoft’s Secure Boot protocol has highlighted precisely why golden keys can’t work in practice, no matter how robust they may be in theory.

Here’s the problem in a nutshell. Secure Boot is an option Microsoft has used since Windows 8. It verifies that the bootloader (as well as other components of the system) are cryptographically signed and permitted to run on the current platform. If Secure Boot is enabled, the system will only boot an operating system that’s been cryptographically signed (by Microsoft in this case — Linux doesn’t have a large OEM market, but there’s nothing stopping manufacturers from using Secure Boot on Linux, provided the OS supports it).

When the system is working properly, Secure Boot can stop various forms of malware from modifying system firmware or installing rootkits that load before or during the operating system’s initialization and are extremely hard to remove as a result. The basic Secure Boot system can also be modified through the use of Secure Boot policies — special sets of rules that load during the boot process and modify it in some fashion.

But here’s the problem: At some point, Microsoft created an internal debugging tool, probably so that its own developers didn’t have to sign every single OS build before installing and testing it. That policy accidentally shipped out on customer hardware, which means it can be recovered and retrieved by hackers and black hats across the ‘Net.

A system using this policy will not properly authenticate the operating system and will simply check to see if the file it’s been told to run is cryptographically signed. Self-signed binaries are fine, the OS no longer cares. This function means that it’s now hypothetically possible to load Linux or other operating systems on hardware that was previously locked to Windows but it also means that Secure Boot has been fundamentally compromised. It’ll run on any architecture, any device, and any hardware.

Now, Microsoft has already taken action to patch out the problem, via MS16-094. If you’ve updated your system with this patch, you won’t be able to install the patch that otherwise grants Secure Boot access — it’s been revoked. You can, however, still nuke Secure Boot on a system that doesn’t have the July security update installed, and some users have been interested in doing this since Microsoft has essentially abandoned the Surface RT and Surface 2 platforms. The team that discovered the flaw has also published their own write-up and in-depth explanation of the phenomena and its significance.

This particular flaw is only going to be of interest to people that want to run different operating systems on an ARM-based tablet or who want to put Linux on an x86 device that shipped with Secure Boot enabled. Microsoft has already patched the problem and as security flaws go, it’s not huge in and of itself. What it does show, however, is the folly of relying on the idea that backdoors can be locked down and perfectly controlled.

The existence of this policy isn’t something Microsoft promoted or discussed. The author of the initial report, Slipstream, writes:

About the FBI: are you reading this? If you are, then this is a perfect real world example about why your idea of backdooring cryptosystems with a “secure golden key” is very bad! Smarter people than me have been telling this to you for so long, it seems you have your fingers in your ears. You seriously don’t understand still? Microsoft implemented a “secure golden key” system. And the golden keys got released from MS own stupidity. Now, what happens if you tell everyone to make a “secure golden key” system? Hopefully you can add 2+2…

Golden key systems don’t work because the golden keys are inevitably found or stolen. Even the rumor of such a system can send hackers scurrying to dissect code and reverse engineer strategies. Policies and keys like the one Microsoft created for its own internal use either leak or are discovered and can be reverse-engineered thereafter. As Slipstream writes, Microsoft’s current patch can be bypassed by replacing the current Windows 10 boot manager with the earlier version from last year. Do that, and the system will continue to accept the Secure Boot policy that allows for any OS to be loaded.

One small leak is all it takes to let the cat out of the bag — and thanks to the Internet, there’s no way to prevent such information from spreading. Security regimes that depend on human perfection to lock down content will always fail, because humans aren’t perfect.

Episodes like this will never stop happening — which means we need to stop looking towards hypothetical golden keys as solutions to real-world problems.

Leave a Reply

Captcha image