Share this story

Updated, August 12: Microsoft has now responded to the Secure Boot blooper.

The company said: "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."

Original Story

Microsoft has inadvertently demonstrated the intrinsic security problem of including a universal backdoor in its software after it accidentally leaked its so-called "golden key"—which allows users to unlock any device that's supposedly protected by Secure Boot, such as phones and tablets.

The key basically allows anyone to bypass the provisions Microsoft has put in place ostensibly to prevent malicious versions of Windows from being installed, on any device running Windows 8.1 and upwards with Secure Boot enabled.

And while this means that enterprising users will be able to install any operating system—Linux, for instance—on their Windows tablet, it also allows bad actors with physical access to a machine to install bootkits and rootkits at deep levels. Worse, according to the security researchers who found the keys, this is a decision Microsoft may be unable to reverse.

The golden keys were found by MY123 and Slipstream in March this year. They've just posted, on a rather funky website, a description both of Microsoft's security errors and of its seeming reluctance to patch the issue. The researchers note that this snafu is a real-world demonstration of the lack of wisdom in the FBI's recent demands for universal backdoors in Apple's devices. They wrote:

A backdoor, which MS put in to Secure Boot because they decided to not let the user turn it off in certain devices, allows for Secure Boot to be disabled everywhere! 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['s] own stupidity. Now, what happens if you tell everyone to make a "secure golden key" system? Hopefully you can add 2+2...

The researchers seem to have found the golden key—which isn't a PKI-type private key you would use to sign binaries, but rather a way to alter the tasks executed by UEFI at boot—bundled in dormant form on retail devices, left in as a debugging tool by accident. Now apparently available online, it should allow any user to turn off Secure Boot.

Further Reading

Secure Boot works at the firmware level, and is designed only to allow an operating system signed with a key certified by Microsoft to load. It can be disabled on many desktops, but on most other Windows devices, it's hard-coded in. The golden key policy seems to have been designed for internal debugging purposes, to allow OS signature checks to be disabled, apparently so programmers can test new builds. In practice, it could well open up Microsoft's tablets and phones to serious attacks.

At first, Microsoft apparently dismissed the find as a non-issue, before changing its mind, and then slowly applying a patch. The software giant eventually awarded a bug bounty in June, and has since released two patches—MS16-094 and MS16-100—with a third on the way. It's understood that none of them are able to directly shut the back door, and there's a distinct possibility that the hole opened by the golden keys may not be truly closable.

According to the researchers, "it'd be impossible in practise for MS to revoke every bootmgr earlier than a certain point, as they'd break install media, recovery partitions, backups, etc."

Further Reading

In February, in the wake of the San Bernardino shootings in the US, the FBI asked Apple to introduce backdoors into its products, after it had proved difficult to access information on an iPhone belonging to one of the shooters. In a statement, Apple CEO Tim Cook wrote:

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.

Specifically, the FBI wants us to make a new version of the iPhone operating system, circumventing several important security features, and install it on an iPhone recovered during the investigation. In the wrong hands, this software—which does not exist today—would have the potential to unlock any iPhone in someone's physical possession.

The FBI may use different words to describe this tool, but make no mistake: Building a version of iOS that bypasses security in this way would undeniably create a backdoor. And while the government may argue that its use would be limited to this case, there is no way to guarantee such control.

Ars has sought comment from Microsoft.

This story was updated on August 11 to clarify the nature of the "golden key," which isn't technically a key at all.

It doesn't seem to be. Secure Boot is a different system that Bitlocker. Now the big question is since Microsoft decided to put "golden key" backdoors in Secure Boot did they also do so with Bitlocker and if they did then how long before that "golden key" gets stolen?

It's good to remember that Microsoft:

a.) gets a copy of your Bitlocker key by default when you encrypt your drive (so they already have your key to give to their worldwide govt partners for abuse whenever its needed - would President Donald want to know what's on all the Muslim's computers?).

b.) they removed the elephant diffusor code from bitlocker with Windows 8 onward - the elephant diffusor made it much harder to brute force the drive encryption and Microsoft never gave a good explanation for it - one can surmise the FBI and NSA liked it though.

c.) has a copy of the drive encryption key with all new Windows 10 installations although its not called bitlocker (for whatever reason).

Can you cite any sources for this?

Because at first glance, it reads like your tinfoil may be on a little tight.

Bitlocker saves a recovery key to onedrive by default. If you are paranoid enough that can be construed to imply they are storing your keys for recovery reasons but it's probably them getting sick of bitlocker drive recovery requests in customer support.

Device Encryption saves a key to OneDrive by Default, not BitLocker. BitLocker gives you like 3 choices to back-up your key to either print it, upload it to OneDrive or copy it to a file or something, I forget the third. The "automatic" Device Encryption that is used in like 8" Windows Tablets that don't run a Pro version of Windows are the ones that by default and automatically back-up the key to your OneDrive account.

Seems like you're right. Also seems like the third choice is a registry key, if my Google-fu isnt failing me.

Do all uefi pc's feature secure boot? Only pc's with TPM? Maybe I don't have any capable devices but, all my pc's simply have a toggle in the bios to turn secure boot on and off.

Secure Boot doesn't require a TPM. If however you have a TPM and you have Secure Boot enabled, Windows uses an enhanced version of Secure Boot called Measured Boot if you're in an enterprise environment with the proper server setup.

Hey maybe I'll be able to turn this spare Surface RT into something actually useful :\

That was my first thought. The hardware is moderately interesting, and often available at attractive prices(the Tegra3 is a bit long in the tooth; but not impossible); but the knowledge that they were substantially more locked down than pretty much any Android tablet, and that MS had essentially abandoned them to a weird quasi-fork of Windows8 forever, made them a no-go.

With a bootloader that doesn't hate you, the non-pro Surfaces could actually be pretty nice(and no, before someone accuses me of being a Linux-at-all-costs zealot, the non-pro surfaces could also have been pretty nice if they ran a version of Windows that didn't restrict you to MS App Store only; and actually had some hope of getting Windows 10; but since that appears to be off the table for the RT Surfaces, Linux is pretty much the remaining option).

Golden Key backdoor in your secure boot intended for testing but left in for production which is stolen and leaked by a third party.

That's a paddlin.

Actually three cheers for Microsoft for showing the folly of "golden keys".

Everyone has some kind of Golden Key.How do you think these bootloaders and OS systems files get digitally signed?

Even Apple already *has* a golden key: If Apple accidentally leaks its signing key or someone from the FBI (or Russian equivalent?) manages to get that key, then it's game over for iOS passcode security (because anybody would be able to patch the current OS files to allow an infinite number of password entry, and the device would happily boot because it would be signed with the leaked key).

The whole debate about backdoors is ridiculous from the beginning, since everybody seems to forget that Apple/MS/... do own a "master key" in the form of a code signing certificate.

Of course, it is still better to have a master key and risk leaking it, than not having any boot protection feature at all, as is the case with linux PCs.

There are other ways though to validate that the bootloader doesn't get tampered with. BitLocker was using a bootloader footprint stored in the TPM chip back in the days of Windows 7, when Secure Boot was not implemented yet. Win8/10 can still use this method to protect against rootkits.

Secure Boot works at the firmware level, and is designed only to allow an operating system signed with a key certified by Microsoft to load. It can be disabled on many desktops, but on most other Windows devices, it's hard-coded in. The golden key policy seems to have been designed for internal debugging purposes, to allow OS signature checks to be disabled, apparently so programmers can test new builds. In practice, it could well open up Microsoft's tablets and phones to serious attacks.

Do all uefi pc's feature secure boot? Only pc's with TPM? Maybe I don't have any capable devices but, all my pc's simply have a toggle in the bios to turn secure boot on and off.

Secure Boot doesn't require a TPM. If however you have a TPM and you have Secure Boot enabled, Windows uses an enhanced version of Secure Boot called Measured Boot if you're in an enterprise environment with the proper server setup.

Bitlocker saves a recovery key to onedrive by default. If you are paranoid enough that can be construed to imply they are storing your keys for recovery reasons but it's probably them getting sick of bitlocker drive recovery requests in customer support.

Device Encryption saves a key to OneDrive by Default, not BitLocker. BitLocker gives you like 3 choices to back-up your key to either print it, upload it to OneDrive or copy it to a file or something, I forget the third. The "automatic" Device Encryption that is used in like 8" Windows Tablets that don't run a Pro version of Windows are the ones that by default and automatically back-up the key to your OneDrive account.

Seems like you're right. Also seems like the third choice is a registry key, if my Google-fu isnt failing me.

I recently configured both of my daily-use personal computers with BitLocker. The options are:* Print* Save to file (but it won't let you save on the drive you just encrypted)* Save to OneDrive

You must pick at least one. As a workaround, you can print to a file that you then save on the encrypted drive, in case your printer is on the fritz like mine was. I have since created a hard-copy that is securely stored.

As an aside, I do like that I can enable BitLocker without a TPM and am then required to provide the key myself at every boot.

Further - I'd love an option for OneDrive that automatically disables sync if you log in on an un-encrypted device (e.g. my wife's laptop that lacks a TPM and isn't the idea device for a double-password login process).

Further - I'd love an option for OneDrive that automatically disables sync if you log in on an un-encrypted device (e.g. my wife's laptop that lacks a TPM and isn't the idea device for a double-password login process).

Why does that matter? You don't think BitLocker encrypts your OneDrive folder that gets synced to MS' servers do you? Because it doesn't.

Edit: I don't normally complain about "downvotes" but obviously there are some people here that don't understand how BitLocker works. FDE software like BitLocker does not encrypt individual files and folders, but entire drives at a time. It gets "unlocked" when you log-in and the key is stored in memory until you shut your computer down again and the key is wiped from memory and the drive is now once again "locked." So while your computer is on, and OneDrive is busy syncing your folder to MS' servers, all of your files are completely unencrypted.

So for those of you following at home, that means it's syncing the files in an unencrypted state - it is stored unencrypted on MS' servers. Otherwise how would you expect to be able to open the files on another computer? If you want to encrypt files that get uploaded to OneDrive (or any Cloud Syncing tool) you need to use Windows' EFS feature, which encrypts files and folders on an individual level. Like adding a password to a .ZIP file to encrypt it.

If you think BitLocker keeps your stuff encrypted "in the cloud" then you are dangerously uninformed.

I have been using MS's rubbish for more than 20 years now and I am genuinely amazed at the fact that they manage to get in the news with a security breach almost every week without failing. You would think after such a lomg time they would have learned from their mistakes, but no...

Further - I'd love an option for OneDrive that automatically disables sync if you log in on an un-encrypted device (e.g. my wife's laptop that lacks a TPM and isn't the idea device for a double-password login process).

Why does that matter? You don't think BitLocker encrypts your OneDrive folder that gets synced to MS' servers do you? Because it doesn't.

Edit: I don't normally complain about "downvotes" but obviously there are some people here that don't understand how BitLocker works. FDE software like BitLocker does not encrypt individual files and folders, but entire drives at a time. It gets "unlocked" when you log-in and the key is stored in memory until you shut your computer down again and the key is wiped from memory and the drive is now once again "locked." So while your computer is on, and OneDrive is busy syncing your folder to MS' servers, all of your files are completely unencrypted.

So for those of you following at home, that means it's syncing the files in an unencrypted state - it is stored unencrypted on MS' servers. Otherwise how would you expect to be able to open the files on another computer? If you want to encrypt files that get uploaded to OneDrive (or any Cloud Syncing tool) you need to use Windows' EFS feature, which encrypts files and folders on an individual level. Like adding a password to a .ZIP file to encrypt it.

If you think BitLocker keeps your stuff encrypted "in the cloud" then you are dangerously uninformed.

I know it's not encrypted in the cloud. So yes, a warrant could easily get access (similar to how Apple happily turns over iCloud backups). But the data there is protected from access by users to whom I have not granted permission. And I generally trust Microsoft to have robust enough security that my files in the Cloud can't be accessed by unauthorized users.

Given the mobile nature of laptops, I don't want it to be a weak(er) link in the security chain should it be lost or stolen.

For things that need true security, I have a variety of file-level encryption tools available. For example, I keep my passwords encrypted in KeePass.

[edit] No idea why you got downvoted - your point is a good one and something many non-technical users might not know (given that is generally not the audience here).

This is one of those times that Linus Torvalds being stubborn comes off well, I think -- he refused to merge support for this not too long ago.

I have a Dell with secure boot that I simply toggled it off of in the BIOS to install Arch a while back; I didn't realize some machines ship without the toggle.

It's not like there are full blown PC's coming completely locked down, the 'can't be turned off' is talking about all-in-one stuff like Windows RT tablets.Its not all that different from Apple or Samsung locking the bootloaders on iPads or Galaxy tabs.

Its just that on a compatible PC you administer you can also choose to turn it on for additional security.

Would never have expected a backdoor in MS security software. No no. They did not turn a secure communication platform (skype) into a spy tool for NSA. No, they would never do that and we should just trust that all the data that Win10 sends is also secure and not in anyway whatsoever harmful for the users.

Gotta love it when main issue with tinfoil hat is that you didn't put enough tinfoil.

The funny part is you think Skype was ever secure. The NSA was already able to break Skype's security before MS even bought them.

That's pretty funny. Of course, they still want you to route all your o/s data to them and not worry about it and the FBI still wants a special backdoor through encryption..... even though this just happened and showed them exactly what can happen if we give in to their insane give us access for your own good drek.

For someone like myself who doesn't have a great low-level understanding of the firmware side of things...

Is my home computer running Windows 10 (or 7, 8, or 8.1) susceptible to this security hole? And how would I go about plugging said hole?

Are all Windows Phone and Surface tablet devices irreversibly affected?

Short answer, probably not.

On a home built system, It may support Secure boot with Windows 8-10, but unless you specifically turned it on, you almost certainly aren't using it anyway (Windows 7 doesn't support secure boot anyway - Outside certain Asus boards that used a non-standard method to make it work).

If it's a pre-built computer, it might possibly be on, [url=you can confirm it in windows]http://www.eightforums.com/tutorials/20208-secure-boot-confirm-enabled-disabled-windows-8-a.html[/url]

I don't believe the FBI got into their two iPhones, like they said they did. I think they paid a hacker to back their story, so that they would lose less face in their losing battle.

I applaud that Apple found two or three constitutional grounds, in addition to privacy grounds, to oppose the FBI. In particular, Apple refused to be conscripted outside a declaration of war.

Just beware, if the FBI can't break down the door to your house, they'll burn it down. If they can't shoot you, they'll shoot your spouse and children. It's history.

If an Alphabet Agency wants into my PC, all they need to do is present me with a court order and I will turn over the password. There is nothing on there that I am willing to sacrifice my liberty for. I have taken steps to secure my equipment (as much as I can without sacrificing convenience) so that if I get burgled, and the burglar steals the PC and passes it to his fence, who passes it to his nephew who specialises in identity theft, I don't get my day ruined twice.

A little nitpick, the quote at the bottom from Tim Cook is a little out of place. There were two big issues that occurred at the same time last year. One, could Apple be compelled to crack the terrorist's phone, and two, the larger push for back doors into everything encrypted. This failing by Microsoft clearly illustrates the potential disaster of the latter. The cracking of iOS is related but only tangentially to the broader issue of mandated back doors in encryption.

Secure boot is code authentication, it has nothing to do with encryption. Why do some people have an inextricable inability to stop confusing the two?

Someone else asked whether this affects Bitlocker. Answer: Nope. The bitlocker efi boot module is already signed by Microsoft, so it wouldn't make a difference.

A little nitpick, the quote at the bottom from Tim Cook is a little out of place. There were two big issues that occurred at the same time last year. One, could Apple be compelled to crack the terrorist's phone, and two, the larger push for back doors into everything encrypted. This failing by Microsoft clearly illustrates the potential disaster of the latter. The cracking of iOS is related but only tangentially to the broader issue of mandated back doors in encryption.

Secure boot is code authentication, it has nothing to do with encryption. Why do some people have an inextricable inability to stop confusing the two?

Someone else asked whether this affects Bitlocker. Answer: Nope. The bitlocker efi boot module is already signed by Microsoft and will run whether Secure Boot is enabled or not.

But it does weaken the effective security of bitlocker by allowing an unauthorized OS to run. Secure Boot ensures an attacker couldn't boot the system from a new partition (additional drive, usb key, even cdrom). This is important because if they could in most implementations of bitlocker (TPM only) the encryption is transparent with no additional secret (i.e. PIN or fob). They could boot and the TPM would pass the decryption keys to the OS (the attacker installed OS) and then the hacker could read the drives and make a copy. The TPM is assuming that the OS booting and requesting the drive keys is "legit" and it does that by relying on SecureBoot.

A little nitpick, the quote at the bottom from Tim Cook is a little out of place. There were two big issues that occurred at the same time last year. One, could Apple be compelled to crack the terrorist's phone, and two, the larger push for back doors into everything encrypted. This failing by Microsoft clearly illustrates the potential disaster of the latter. The cracking of iOS is related but only tangentially to the broader issue of mandated back doors in encryption.

Secure boot is code authentication, it has nothing to do with encryption. Why do some people have an inextricable inability to stop confusing the two?

Someone else asked whether this affects Bitlocker. Answer: Nope. The bitlocker efi boot module is already signed by Microsoft and will run whether Secure Boot is enabled or not.

But it does weaken bitlocker. Secure Boot ensures an attacker couldn't boot the system from a new partition (additional drive, usb key, even cdrom) because if they could in most implementations of bitlocker (TPM only) the encryption is transparent. They could boot and the system would decrypt the drives and the hacker installed OS could read them and make a copy.

I don't know where you're getting your information from.

Windows, installed on a machine with Secure Boot will 100% boot fine on another machine which also has Secure Boot enabled.

You appear to be confusing Secure Boot with TPM-backed Bitlocker. That drive would not boot on another machine until the recovery key was entered, but after that you're home free. Stop confusing code authentication/verification (Secure Boot), with disk encryption and secure key storage (Bitlocker with TPM). they are two completely separate topics.

Edit: now that you've completely ninja edited your post it makes a bit more sense where you're coming from, but unfortunately you're still incorrect: the TPM will not just "pass along" the keys to whatever OS is installed, it doesn't "assume" that whatever code runs is allowed to access it. The TPM would need to be reinitialised by the new OS (in your example, some form of linux or live environment) in order to be read by the new OS, since that environment wouldn't have the correct signature verification to access the TPM otherwise. Reinitialising it would erase all the data on the TPM, rendering the original encrypted partition completely unreadable even with the recovery key.

For someone like myself who doesn't have a great low-level understanding of the firmware side of things...

Is my home computer running Windows 10 (or 7, 8, or 8.1) susceptible to this security hole? And how would I go about plugging said hole?

If your home PC is not running secure Boot, then it is a 'security hole' by default: no authentication is being performed on boot, so the system is wide open to anything.

If you home PC is running Secure Boot, and it is updated to the latest Windows patched release, then it is only vulnerable if the attacker already has enough access to downgrade the bootmgr to a vulnerable version.

A little nitpick, the quote at the bottom from Tim Cook is a little out of place. There were two big issues that occurred at the same time last year. One, could Apple be compelled to crack the terrorist's phone, and two, the larger push for back doors into everything encrypted. This failing by Microsoft clearly illustrates the potential disaster of the latter. The cracking of iOS is related but only tangentially to the broader issue of mandated back doors in encryption.

Secure boot is code authentication, it has nothing to do with encryption. Why do some people have an inextricable inability to stop confusing the two?

Someone else asked whether this affects Bitlocker. Answer: Nope. The bitlocker efi boot module is already signed by Microsoft and will run whether Secure Boot is enabled or not.

But it does weaken the effective security of bitlocker by allowing an unauthorized OS to run. Secure Boot ensures an attacker couldn't boot the system from a new partition (additional drive, usb key, even cdrom). This is important because if they could in most implementations of bitlocker (TPM only) the encryption is transparent with no additional secret (i.e. PIN or fob). They could boot and the TPM would pass the decryption keys to the OS (the attacker installed OS) and then the hacker could read the drives and make a copy. The TPM is assuming that the OS booting and requesting the drive keys is "legit" and it does that by relying on SecureBoot.

That's not even close to how a TPM works, if that's how insecure a TPM was, why do you think they'd be used at all? If you booted into a new operating system - even if it's just like a LiveCD or something - the TPM would not at all pass on the encryption key to the unverified and uninitialized operating system. If you tried to reinitialize the TPM within the new OS, then what you did is, is clear out the entire thing and thus making it impossible to access the BitLocker encrypted Windows drive without access to the recovery key.

A little nitpick, the quote at the bottom from Tim Cook is a little out of place. There were two big issues that occurred at the same time last year. One, could Apple be compelled to crack the terrorist's phone, and two, the larger push for back doors into everything encrypted. This failing by Microsoft clearly illustrates the potential disaster of the latter. The cracking of iOS is related but only tangentially to the broader issue of mandated back doors in encryption.

Those two things you list are not different - one is a subset of the other. Creating a cracked version of iOS that allows decrypting of a phone and turning that firmware over to the FBI is the equivalent of creating a "golden key", where one didn't exist before.

Apple's case was a specific example of the overall battle between backdoor access and not backdoor access. It isn't tangentially related - it IS what the FBI was pushing for in general.

Apple could have simply baked in a device ID such that you couldn't change the device ID without invalidating the digital signature.

Does someone with more insight than myself know if this compromises Bitlocker?

It doesn't seem to be. Secure Boot is a different system that Bitlocker. Now the big question is since Microsoft decided to put "golden key" backdoors in Secure Boot did they also do so with Bitlocker and if they did then how long before that "golden key" gets stolen?

It's good to remember that Microsoft:

a.) gets a copy of your Bitlocker key by default when you encrypt your drive (so they already have your key to give to their worldwide govt partners for abuse whenever its needed - would President Donald want to know what's on all the Muslim's computers?).

b.) they removed the elephant diffusor code from bitlocker with Windows 8 onward - the elephant diffusor made it much harder to brute force the drive encryption and Microsoft never gave a good explanation for it - one can surmise the FBI and NSA liked it though.

c.) has a copy of the drive encryption key with all new Windows 10 installations although its not called bitlocker (for whatever reason).

I don't know why the down votes. I just installed / activated / set up / whatever they call all the hoop jumping of Windows 10 on my new PC and when I refused to use a Microsoft account and forced it to use a local account only, it then warned me that Microsoft can't encrypt my hard drive without a Microsoft account. Now, why would Windows need a Microsoft account to encrypt my local hard drive if it wasn't giving a copy of the key to Microsoft?

Does someone with more insight than myself know if this compromises Bitlocker?

It doesn't seem to be. Secure Boot is a different system that Bitlocker. Now the big question is since Microsoft decided to put "golden key" backdoors in Secure Boot did they also do so with Bitlocker and if they did then how long before that "golden key" gets stolen?

It's good to remember that Microsoft:

a.) gets a copy of your Bitlocker key by default when you encrypt your drive (so they already have your key to give to their worldwide govt partners for abuse whenever its needed - would President Donald want to know what's on all the Muslim's computers?).

b.) they removed the elephant diffusor code from bitlocker with Windows 8 onward - the elephant diffusor made it much harder to brute force the drive encryption and Microsoft never gave a good explanation for it - one can surmise the FBI and NSA liked it though.

c.) has a copy of the drive encryption key with all new Windows 10 installations although its not called bitlocker (for whatever reason).

Can you cite any sources for this?

Because at first glance, it reads like your tinfoil may be on a little tight.

Does someone with more insight than myself know if this compromises Bitlocker?

It doesn't seem to be. Secure Boot is a different system that Bitlocker. Now the big question is since Microsoft decided to put "golden key" backdoors in Secure Boot did they also do so with Bitlocker and if they did then how long before that "golden key" gets stolen?

It's good to remember that Microsoft:

a.) gets a copy of your Bitlocker key by default when you encrypt your drive (so they already have your key to give to their worldwide govt partners for abuse whenever its needed - would President Donald want to know what's on all the Muslim's computers?).

b.) they removed the elephant diffusor code from bitlocker with Windows 8 onward - the elephant diffusor made it much harder to brute force the drive encryption and Microsoft never gave a good explanation for it - one can surmise the FBI and NSA liked it though.

c.) has a copy of the drive encryption key with all new Windows 10 installations although its not called bitlocker (for whatever reason).

I don't know why the down votes. I just installed / activated / set up / whatever they call all the hoop jumping of Windows 10 on my new PC and when I refused to use a Microsoft account and forced it to use a local account only, it then warned me that Microsoft can't encrypt my hard drive without a Microsoft account. Now, why would Windows need a Microsoft account to encrypt my local hard drive if it wasn't giving a copy of the key to Microsoft?

You must have misread that or something, because while my normal user account is a microsoft account, the local admin isn't, and when I set up my current system last month, I had no problem setting up full disk encryption from that local admin account before I even added the user account.

That's not to say MS didn't word it ambiguously to imply you needed one, when what they meant is you loose the ability to back up the key. I didn't see the message myself though because the system didn't have Internet access during initial setup so it didn't even offer an online account.

This whole thing is somewhat mindboggling. This entire situation is about a failure in a solution to a problem nobody ever needed solved. So, you want to be able to ensure that the OS installed on your system is the one you thought was installed? Signatures are one way to go about this, but not a particulatly great way. Locking the hardware to use only those signatures such that the administrator of the system can't get another OS installed without trashing the entire protection mechanism? That's a failure in and of itself, whether or not the keys were ever leaked. Every OS vendor/distributor should publicly provide hashes of boot binaries (i.e. the things that are already signed) which can be validated via hardware (e.g. TPM). Open source OS? No problem: there are mechanisms to create the hashes for the binaries you compile. A signature would be created by a trusted source each time to verify that the hashes generated on boot match the hashes provided. AV software could easily validate these signatures to protect individual and small organization users. Large enterprises could do this on a larger scale, and leverage the date to ensure that any updates to boot loaders have been pushed to all systems correctly. There are still keys used, but they are easier to manage. A vendor's key (used to verify that the provided hashes are from them) could be leaked, but a cert could be quickly revoked and new keys and certs generated to cover the mishap. Each TPM would sign with its own key, and those are protected in hardware. It's a slightly more complicated system, but is much more flexible and doesn't have the flaws that "secure" boot has already suffered from.

This is one of those times that Linus Torvalds being stubborn comes off well, I think -- he refused to merge support for this not too long ago.

I have a Dell with secure boot that I simply toggled it off of in the BIOS to install Arch a while back; I didn't realize some machines ship without the toggle.

It's not like there are full blown PC's coming completely locked down, the 'can't be turned off' is talking about all-in-one stuff like Windows RT tablets.Its not all that different from Apple or Samsung locking the bootloaders on iPads or Galaxy tabs.

Its just that on a compatible PC you administer you can also choose to turn it on for additional security.

Just because Apple and Samsung also lock down their hardware doesn't make it OK for everyone else to lock down their hardware.

For someone like myself who doesn't have a great low-level understanding of the firmware side of things...

Is my home computer running Windows 10 (or 7, 8, or 8.1) susceptible to this security hole? And how would I go about plugging said hole?

Are all Windows Phone and Surface tablet devices irreversibly affected?

Short answer, probably not.

On a home built system, It may support Secure boot with Windows 8-10, but unless you specifically turned it on, you almost certainly aren't using it anyway (Windows 7 doesn't support secure boot anyway - Outside certain Asus boards that used a non-standard method to make it work).

If it's a pre-built computer, it might possibly be on, [url=you can confirm it in windows]http://www.eightforums.com/tutorials/20208-secure-boot-confirm-enabled-disabled-windows-8-a.html[/url]

I don't believe the FBI got into their two iPhones, like they said they did. I think they paid a hacker to back their story, so that they would lose less face in their losing battle.

I applaud that Apple found two or three constitutional grounds, in addition to privacy grounds, to oppose the FBI. In particular, Apple refused to be conscripted outside a declaration of war.

Just beware, if the FBI can't break down the door to your house, they'll burn it down. If they can't shoot you, they'll shoot your spouse and children. It's history.

If an Alphabet Agency wants into my PC, all they need to do is present me with a court order and I will turn over the password. There is nothing on there that I am willing to sacrifice my liberty for. I have taken steps to secure my equipment (as much as I can without sacrificing convenience) so that if I get burgled, and the burglar steals the PC and passes it to his fence, who passes it to his nephew who specialises in identity theft, I don't get my day ruined twice.

If you turn over all your stuff any time they ask, you have already lost your liberty. Every time you willingly give up your Constitutional rights, it makes it that much easier for them to take everyone else's Constitutional rights.

For someone like myself who doesn't have a great low-level understanding of the firmware side of things...

Is my home computer running Windows 10 (or 7, 8, or 8.1) susceptible to this security hole? And how would I go about plugging said hole?

Are all Windows Phone and Surface tablet devices irreversibly affected?

Short answer, probably not.

On a home built system, It may support Secure boot with Windows 8-10, but unless you specifically turned it on, you almost certainly aren't using it anyway (Windows 7 doesn't support secure boot anyway - Outside certain Asus boards that used a non-standard method to make it work).

If it's a pre-built computer, it might possibly be on, [url=you can confirm it in windows]http://www.eightforums.com/tutorials/20208-secure-boot-confirm-enabled-disabled-windows-8-a.html[/url]

I don't believe the FBI got into their two iPhones, like they said they did. I think they paid a hacker to back their story, so that they would lose less face in their losing battle.

I applaud that Apple found two or three constitutional grounds, in addition to privacy grounds, to oppose the FBI. In particular, Apple refused to be conscripted outside a declaration of war.

Just beware, if the FBI can't break down the door to your house, they'll burn it down. If they can't shoot you, they'll shoot your spouse and children. It's history.

If an Alphabet Agency wants into my PC, all they need to do is present me with a court order and I will turn over the password. There is nothing on there that I am willing to sacrifice my liberty for. I have taken steps to secure my equipment (as much as I can without sacrificing convenience) so that if I get burgled, and the burglar steals the PC and passes it to his fence, who passes it to his nephew who specialises in identity theft, I don't get my day ruined twice.

If you turn over all your stuff any time they ask, you have already lost your liberty. Every time you willingly give up your Constitutional rights, it makes it that much easier for them to take everyone else's Constitutional rights.

Oh shut up, I'm not turning anything over 'whenever they ask' I specifically said when presented with a court order.

It's called the rule of law. In some respects the men living in lawless sh*tholes like Somalia are more free than me, they can do whatever they want, but I rather like living in civilisation and agree to abide by it's rules and as such be afforded it's protections.

A little nitpick, the quote at the bottom from Tim Cook is a little out of place. There were two big issues that occurred at the same time last year. One, could Apple be compelled to crack the terrorist's phone, and two, the larger push for back doors into everything encrypted. This failing by Microsoft clearly illustrates the potential disaster of the latter. The cracking of iOS is related but only tangentially to the broader issue of mandated back doors in encryption.

Secure boot is code authentication, it has nothing to do with encryption. Why do some people have an inextricable inability to stop confusing the two?

Someone else asked whether this affects Bitlocker. Answer: Nope. The bitlocker efi boot module is already signed by Microsoft and will run whether Secure Boot is enabled or not.

But it does weaken the effective security of bitlocker by allowing an unauthorized OS to run. Secure Boot ensures an attacker couldn't boot the system from a new partition (additional drive, usb key, even cdrom). This is important because if they could in most implementations of bitlocker (TPM only) the encryption is transparent with no additional secret (i.e. PIN or fob). They could boot and the TPM would pass the decryption keys to the OS (the attacker installed OS) and then the hacker could read the drives and make a copy. The TPM is assuming that the OS booting and requesting the drive keys is "legit" and it does that by relying on SecureBoot.

That's not even close to how a TPM works, if that's how insecure a TPM was, why do you think they'd be used at all? If you booted into a new operating system - even if it's just like a LiveCD or something - the TPM would not at all pass on the encryption key to the unverified and uninitialized operating system. If you tried to reinitialize the TPM within the new OS, then what you did is, is clear out the entire thing and thus making it impossible to access the BitLocker encrypted Windows drive without access to the recovery key.

Writing and reading the TPM's data spaces (encryption key storage) typically requires owner authorization (a hash of an owner password) as a parameter to the read/write command. The TPM is a passive component and doesn't have any knowledge or care what OS is running on top of it. Assuming an adversary had knowledge of the owner password, it would be possible for them to retrieve the keys from the TPM using any OS with a TPM driver, or no OS (using EFI firmware).

IIRC Bitlocker will generate an owner password (based on hashing a user-entered password plus some other data) and take ownership of the TPM with it, so if a compromised OS is loaded using the SecureBoot issue described in the article, and Bitlocker encryption is setup in this compromised OS, it would be possible to snoop the owner password and gain access to the TPM.