In what could be absolutely considered a glittering example of exactly why golden keys offering a backdoor into secure services shouldn’t exist, Microsoft accidentally leaked the master key to their Secure Boot system.
The leak potentially unlocks all devices with Microsoft Secure Boot technology installed, stripping their locked operating system status, enabling users to install their own operating systems and applications in place of those designated by the Redmond technology behemoth.
The leak shouldn’t compromise your device security — in theory. But it will open the lines for alternative operating systems and other applications that would previously have failed to work on a Secure Boot system.
How will Microsoft respond to this? A simple update to alter each Secure Boot base key? Or is it simply too late, damage done?
Let’s take a good look at what the Secure Boot leak means for you and your devices.
What Is Secure Boot?
“Secure Boot helps to make sure that your PC boots only using firmware that is trusted by the manufacturer”
Microsoft Secure Boot arrived with Windows 8, and is designed to prevent malicious operators installing applications or any unauthorized operating systems from loading, or making changes, during the system start-up process. When it arrived, there were concerns that its introduction would severely limit the ability to dual or multi-boot Microsoft systems. In the end, this was largely unfounded — or workarounds found.
As Secure Boot relies on the UEFI (Unified Extensible Firmware Interface) specification to provide basic encryption facilities, network authentication, and driver signing, providing modern systems with another layer of protection from rootkits and low-level malware.
Windows 10 UEFI
Microsoft wanted to ramp up the “protection” offered by UEFI in Windows 10.
To push this through, Microsoft informed manufacturers prior to Windows 10’s release that the choice to remove the option to disable Secure Boot was in their hands, effectively locking the operating system to the one a computer arrives with. It is worth noting that Microsoft wasn’t directly pushing this initiative (at least not entirely publicly), but as Ars Technica’s Peter Bright explains, changes to existing UEFI rules prior to the Windows 10 release date made this possible:
“Should this stand, we can envisage OEMs building machines that will offer no easy way to boot self-built operating systems, or indeed, any operating system that doesn’t have appropriate digital signatures.”
While there are undoubtedly numerous desktops and laptops for sale with unlocked UEFI settings, this could prove to be another stumbling block for those wishing to try an alternative to their Windows operating system.
Yet another road block for Linux advocates to work around… sigh.
And Now Secure Boot Is Permanently Unlocked?
Permanently, I’m not so sure. But for the meantime, Secure Boot can be unlocked. Here is what happened.
Secure Boot is on its deathbed.
Writeup coming tomorrow or Wednesday.
— slipstream/RoL (@TheWack0lian) August 8, 2016
I know I’ve been referring to a super-duper skeleton-type key that unlocks every single lock in the entire Microsoft UEFI Secure Boot universe… but it actually comes down to which policies you have signed on your system.
Secure boot disabling binary leaked. What's more annoying for Microsoft? https://t.co/n0fGr7pwdo
— Mythic Beasts (@Mythic_Beasts) August 10, 2016
Secure Boot works in tandem with certain policies, read and fully obeyed by the Windows boot manager. The policies advise the boot manager to keep Secure Boot enabled. However, Microsoft created one policy designed to allow developers to test operating system builds without having to digitally sign each version. This effectively overrules Secure Boot, disabling early system checks during the start-up process. The security researchers, MY123 and Slipstream, documented their findings (on a really delightful website):
“During the development of Windows 10 v1607 ‘Redstone’, MS added a new type of secure boot policy. Namely, “supplemental” policies that are located in the EFIESP partition (rather than in a UEFI variable), and have their settings merged in, dependant on conditions (namely, that a certain “activation” policy is also in existance, and has been loaded in).
Redstone’s bootmgr.efi loads “legacy” policies (namely, a policy from UEFI variables) first. At a certain time in redstone dev, it did not do any further checks beyond signature / deviceID checks. (This has now changed, but see how the change is stupid) After loading the “legacy” policy, or a base policy from EFIESP partition, it then loads, checks and merges in the supplemental policies.
See the issue here? If not, let me spell it out to you plain and clear. The “supplemental” policy contains new elements, for the merging conditions. These conditions are (well, at one time) unchecked by bootmgr when loading a legacy policy. And bootmgr of win10 v1511 and earlier certainly doesn’t know about them. To those bootmgrs, it has just loaded in a perfectly valid, signed policy.”
It doesn’t make good reading for Microsoft. It effectively means the debug-mode policy designed to allow developers – and only developers – chance to negate the signing processes is open to anyone with a retail version of Windows 10. And that that policy has leaked onto the Internet.
Remember The San Bernardino iPhone?
“You can see the irony. Also the irony in that MS themselves provided us several nice “golden keys” (as the FBI would say ;) for us to use for that purpose :)
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…”
For those encryption advocates this has been an all-to-bittersweet moment that will hopefully provide some well needed clarity for law enforcement agencies and government officials alike. Golden backdoors will never stay hidden. They will always be discovered, be that by an unforeseen internal vulnerability (Snowden revelations) or by those interested in poking and pulling technology and its underlying code apart.
Consider the San Bernardino iPhone…
“We have great respect for the professionals at the FBI, and we believe their intentions are good. Up to this point, we have done everything that is both within our power and within the law to help them. But now the U.S. government has asked us for something we simply do not have, and something we consider too dangerous to create. They have asked us to build a backdoor to the iPhone.”
The Ball Rests With Microsoft
As I mentioned, this shouldn’t really pose a massive security risk to your personal devices, and Microsoft released a statement downplaying the relevance of the Secure Boot leak:
“The jailbreak technique described in the researchers’ report on August 10 does not apply to desktop or enterprise PC systems. It requires physical access and administrator rights to ARM and RT devices and does not compromise encryption protections.”
As well as this, they have hastily released a Microsoft Security Bulletin designated “Important.” This will resolve the vulnerability once installed. However, it won’t take much to install a version of Windows 10 without the patch implemented.
Unfortunately, this is unlikely to lead to a new glut of Microsoft devices running Linux distros. I mean, there will be some enterprising individuals who take the time test this, but for the majority of individuals, this will simply be another security blip that passed them by.
Not giving a damn about Linux distros on Microsoft tablets is one thing, sure. But the wider implications of a golden key leaking into the public domain to unlock potentially millions of devices is another.
A couple of years ago The Washington Post made a rallying call for “compromise” on encryption, proposing that while our data should obviously be off-limits for hackers, perhaps Google and Apple et al should have a secure golden key. In an excellent critique of exactly why this is a “misguided, dangerous proposal,” Keybase co-creator Christ Coyne explains, quite plainly, that “Honest, good people are endangered by any backdoor that bypasses their own passwords.”
We should all strive for the maximum level of personal security possible, not deign to weaken it at the first available opportunity. Because as we have seen on multiple occasions, those super-duper skeleton-type key’s will end up in the wrong hands.
And when they do, we’re all playing a dangerous game of reactive defence, whether we wanted to or not.
Should major technology companies create backdoors in their services? Or should government agencies and other services mind their own business and focus on maintaining security?
Image Credit: DutchScenery/Shutterstock, Constantine Pankin/Shutterstock