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.

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.

It's not quite clear due to the rambling about "golden keys": this isn't a leak of the signing key for Microsoft's bootloader. What it actually is is the discovery that the way one of the test policies is loaded during Windows boot allows you to merge a policy that allows booting unsigned OSes into an otherwise valid policy due to ID checks occurring at the wrong point during the process (i.e. loader checks the policy, then merges the new policy, but does not check the newly merged policy).

Also, here is the site text so you don't need to read it on that godawful animated doesn't-work-in-some-browsers webpage:

Specific Secure Boot policies, when provisioned, allow for testsigning to beenabled, on any BCD object, including {bootmgr}. This also removes the NT loaderoptions blacklist (AFAIK). (MS16-094 / CVE-2016-3287, and MS16-100 / CVE-2016-3320)

Found by my123 (@never_released) and slipstream (@TheWack0lian)Writeup by slipstream (@TheWack0lian)

First up, "Secure Boot policies". What are they exactly?

As you know, secureboot is a part of the uefi firmware, when enabled, it onlylets stuff run that's signed by a cert in db, and whose hash is not in dbx(revoked).

As you probably also know, there are devices where secure boot can NOT bedisabled by the user (Windows RT, HoloLens, Windows Phone, maybe Surface Hub,and maybe some IoTCore devices if such things actually exist -- not talkingabout the boards themselves which are not locked down at all by default, but enddevices sold that may have secureboot locked on).

But in some cases, the "shape" of secure boot needs to change a bit. For examplein development, engineering, refurbishment, running flightsigned stuff (as ofwin10) etc. How to do that, with devices where secure boot is locked on?

Enter the Secure Boot policy.

It's a file in a binary format that's embedded within an ASN.1 blob, that issigned. It's loaded by bootmgr REALLY early into the windows boot process. Itmust be signed by a certificate in db. It gets loaded from a UEFI variable inthe secureboot namespace (therefore, it can only be touched by boot services).There's a couple .efis signed by MS that can provision such a policy, that is,set the UEFI variable with its contents being the policy.

What can policies do, you ask?

They have two different types of rules. BCD rules, which override settingsin the on-disk BCD, and registry rules, which contain configuration for thepolicy itself, plus configuration for other parts of boot services, etc. Forexample, one registry element was introduced in Windows 10 version 1607'Redstone' which disables certificate expiry checking inside mobilestartup's.ffu flashing (ie, the "lightning bolt" windows phone flasher); and another oneenables mobilestartup's USB mass storage mode. Other interesting registryrules change the shape of Code Integrity, ie, for a certain type of binary,it changes the certificates considered valid for that specific binary.

(Alex Ionescu wrote a blog post that touches on Secure Boot policies. He teased afollowup post that would be all about them, but that never came.)

But, they must be signed by a cert in db. That is to say, Microsoft.

Also, there is such a thing called DeviceID. It's the first 64 bits of a saltedSHA-256 hash, of some UEFI PRNG output. It's used when applying policies onWindows Phone, and on Windows RT (mobilestartup sets it on Phone, andSecureBootDebug.efi when that's launched for the first time on RT). On Phone,the policy must be located in a specific place on EFIESP partition with thefilename including the hex-form of the DeviceID. (With Redstone, this gotchanged to UnlockID, which is set by bootmgr, and is just the raw UEFI PRNGoutput.)

Basically, bootmgr checks the policy when it loads, if it includes a DeviceID,which doesn't match the DeviceID of the device that bootmgr is running on, thepolicy will fail to load.

Any policy that allows for enabling testsigning (MS calls these Retail DeviceUnlock / RDU policies, and to install them is unlocking a device), is supposedto be locked to a DeviceID (UnlockID on Redstone and above). Indeed, I haveseveral policies (signed by the Windows Phone production certificate) likethis, where the only differences are the included DeviceID, and the signature.

If there is no valid policy installed, bootmgr falls back to using a defaultpolicy located in its resources. This policy is the one which blocks enablingtestsigning, etc, using BCD rules.

Now, for Microsoft's screwups.

During the development of Windows 10 v1607 'Redstone', MS added a new type ofsecure boot policy. Namely, "supplemental" policies that are located in theEFIESP partition (rather than in a UEFI variable), and have their settingsmerged in, dependant on conditions (namely, that a certain "activation" policyis also in existance, and has been loaded in).

Redstone's bootmgr.efi loads "legacy" policies (namely, a policy from UEFIvariables) first. At a certain time in redstone dev, it did not do any furtherchecks beyond signature / deviceID checks. (This has now changed, but see howthe change is stupid)After loading the "legacy" policy, or a base policy from EFIESP partition, itthen 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 alegacy policy. And bootmgr of win10 v1511 and earlier certainly doesn't knowabout them. To those bootmgrs, it has just loaded in a perfectly valid, signedpolicy.

The "supplemental" policy does NOT contain a DeviceID. And, because they weremeant to be merged into a base policy, they don't contain any BCD rules either,which means that if they are loaded, you can enable testsigning. Not just forwindows (to load unsigned driver, ie rootkit), but for the {bootmgr} elementas well, which allows bootmgr to run what is effectively an unsigned .efi(ie bootkit)!!! (In practise, the .efi file must be signed, but it can beself-signed) You can see how this is very bad!! A backdoor, which MS put in to secure boot because they decided to not let the user turn it off incertain devices, allows for secure boot to be disabled everywhere!

You can see the irony. Also the irony in that MS themselves provided us severalnice "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 realworld example about why your idea of backdooring cryptosystems with a "securegolden key" is very bad! Smarter people than me have been telling this to youfor so long, it seems you have your fingers in your ears. You seriously don'tunderstand still? Microsoft implemented a "secure golden key" system. And thegolden keys got released from MS own stupidity. Now, what happens if you telleveryone to make a "secure golden key" system? Hopefully you can add 2+2...

Anyway, enough about that little rant, wanted to add that to a writeup eversince this stuff was found

Anyway, MS's first patch attempt. I say "attempt" because it surely doesn't doanything useful. It blacklists (in boot.stl), most (not all!) of the policies.Now, about boot.stl. It's a file that gets cloned to a UEFI variable only bootservices can touch, and only when the boot.stl signing time is later than thetime this UEFI variable was set.However, this is done AFTER a secure boot policy gets loaded. Redstone'sbootmgr has extra code to use the boot.stl in the UEFI variable to checkpolicy revocation, but the bootmgrs of TH2 and earlier does NOT have suchcode.So, an attacker can just replace a later bootmgr with an earlier one.

Another thing: I saw some additional code in the load-legacy-policy function inredstone 14381.rs1_release. Code that wasn't there in 14361. Code thatspecifically checked the policy being loaded for an element that meant this wasa supplemental policy, and erroring out if so. So, if a system is runningWindows 10 version 1607 or above, an attacker MUST replace bootmgr withan earlier one.

On August 9th, 2016, another patch came about, this one was given the designationMS16-100 and CVE-2016-3320. This one updates dbx. The advisory says it revokesbootmgrs. The dbx update seems to add these SHA256 hashes (unless I screwed upmy parsing):

I checked the hash in the signature of several bootmgrs of severalarchitectures against this list, and found no matches. So either thisrevokes many "obscure" bootmgrs and bootmgfws, or I'm checking the wrong hash.

Either way, it'd be impossible in practise for MS to revoke every bootmgrearlier than a certain point, as they'd break install media, recovery partitions,backups, etc.

::EDIT:: Looks like Ars' new design doesn't allow for collapsing either long Quote blocks or long Code blocks. I'll leave the text here for now unless a mod wants to delete it for being too large.::EDIT2:: But Spoiler tags do, thanks ChrisSD!

I'm concerned about this, but I don't know how concerned I actually need to be.

I don't have a Surface, or any other 'Locked bootloader' Windows device, what I do have is a home built PC that I have activated secure boot on myself, intending it to be another layer of protection against Malware.

If I want, I can disable Secure boot myself at any time by going into the (Password Protected) UEFI firmware and turning it off.

My questions are:

Does this leak mean that malware could potentially make changes to core windows files undetected by secure boot?

Supposedly the key has been revoked, but not all devices will necessarily know about the revocation, Is there a way I can check if my computer recognises the key as valid/invalid?

If it thinks it is, who would need to correct that? Me? The Motherboard vendor via BIOS update? Or Microsoft via Windows update?

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.

And let's hope this ends this stupid idea of a "vault" once and for all too.

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?

'Funky' seems to be a perfectly cromulent description of the site. For a moment there I honestly felt like I was visiting a site from the latter half of the 90's. Good times.

Hah, I love it. It's a good ol' fashioned cracktro, but in web form! Just needs 20 minutes of slowly scrolling greets to be perfect.

That's.... fucking awesome. I didn't understand what everyone was talking about, until I realized I needed to enable scripting on the page. Seriously, it's worth a trip on its own. Although now I'm paranoid and checking the code for abnormal behavior....

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?

The concern (to me at least) is, Assuming you use a TPM, moving a drive to another computer or even booting from USB etc, requires the 40 character unlock key, but when booting normally, the drive Is unlocked automatically by the TPMIf secure boot is compromised, could an attacker modify the boot files allowing them to bypass windows security once the TPM has unlocked the drive?

(I don't know that it is an issue, I just don't know enough to be certain it's not)

This goes back to Hacking Team, that had alot of their internal laundry outed mentioning that EUFI (secure boot) made things easy to get into. It's good to remember we switched over to this new BIOS replacement, pushed forward by Microsoft & Intel well after 9/11 and well after they were cooperating with our 3 letter agencies.

You can bet Microsoft had shared this key with the NSA (since they'd previously shared access to all their users communications with the NSA). It's good to see this out in public so we can refute the whole FBI push of this stupid idea.

We need open firmware on all our computers - its too juicy a target for our democratic government to not want to compromise it (for its own narrow wants), otherwise. JMHO....

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.

It's difficult for me to understand exactly what is going on, maybe I'm misunderstanding something, but it doesn't seem exactly a golden key or a backdoor.

A real golden key would be the private key for signing code for Secure Boot, which would be effectively unstoppable, but this is different. This seems to be a piece of code signed by Microsoft used to skip some checks for development or testing. The problem is that 1) they have made some mistakes in designing this tool and 2) they released accidentally the code.Something like that should have had a different signature for each device or at least per model so if something is released accidentally they can efficiently blacklist it. But something went wrong apparently...

In a certain sense it's seems backdoor but it wasn't designed as such but for testing, because in fact Microsoft don't need a backdoor if it has already the real golden key, the private key of the Secure Boot certificate and they can run whatever they want everywhere they like.

Putting for a moment the tin foil hat on, this tool could be made this way on purpose to give three letters agencies an access that don't require signing by Microsoft, but I personally think there would be easier way to do this...

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).

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?

The concern (to me at least) is, Assuming you use a TPM, moving a drive to another computer or even booting from USB etc, requires the 40 character unlock key, but when booting normally, the drive Is unlocked automatically by the TPMIf secure boot is compromised, could an attacker modify the boot files allowing them to bypass windows security once the TPM has unlocked the drive?

(I don't know that it is an issue, I just don't know enough to be certain it's not)

If you change the BIOS or MBR you will need to do a manual unlock with the recovery key. Now one could certainly do a social engineering attack. Use this flaw to modify the MBR and allow booting an unauthorized OS. User is then prompted for recovery key on next reboot. If user provides it then an unathorized OS will have access to the disk.

Of course one could use EFS (Encrypted Filesystem) on top of Bitlock is you were really paranoid.

It's difficult for me to understand exactly what is going on, maybe I'm misunderstanding something, but it doesn't seem exactly a golden key or a backdoor.

A real golden key would be the private key for signing code for Secure Boot, which would be effectively unstoppable, but this is different. This seems to be a piece of code signed by Microsoft used to skip some checks for development or testing. The problem is that 1) they have made some mistakes in designing this tool and 2) they released accidentally the code.Something like that should have had a different signature for each device or at least per model so if something is released accidentally they can efficiently blacklist it. But something went wrong apparently...

It's entirely number 1: the "boot unsigned OS" loader was designed so that you needed to do this with a device-specific key. The implementation placed the device-specific key check in the wrong place in the check sequence (before the "boot unsigned OS" flag had been set) so it could be used without the device ID.

It's less "OMG, M$ built a backdoor into UEFI" and more "Microsoft's test loader implementation has a bug that allows for unsigned execution in an environment that should enforce signed execution".

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?

The "golden key" for Bitlocker is your individual recovery key. If you keep that in an insecure location, than you're as good as boned if someone gets physical access to your computer and its on a post-it note next to your monitor. Bitlocker is of course proprietary, but there's never been any evidence of a universal back door.

Quote:

According to Microsoft sources, BitLocker does not contain an intentionally built-in backdoor; without a backdoor there is no way for law enforcement to have a guaranteed passage to the data on the user's drives that is provided by Microsoft. The lack of any backdoor has been a concern to the UK Home Office, which tried entering into talks with Microsoft to get one introduced, although Microsoft developer Niels Ferguson and other Microsoft spokesmen state that they will not grant the wish to have one added. Microsoft engineers have said that FBI agents also put pressure on them in numerous meetings in order to add a backdoor, although no formal, written request was ever made; Microsoft engineers eventually suggested to the FBI that agents should look for the hard-copy of the key that the BitLocker program suggests its users to make.

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.

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.

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?

The "golden key" for Bitlocker is your individual recovery key. If you keep that in an insecure location, than you're as good as boned if someone gets physical access to your computer and its on a post-it note next to your monitor. Bitlocker is of course proprietary, but there's never been any evidence of a universal back door.

Quote:

According to Microsoft sources, BitLocker does not contain an intentionally built-in backdoor; without a backdoor there is no way for law enforcement to have a guaranteed passage to the data on the user's drives that is provided by Microsoft. The lack of any backdoor has been a concern to the UK Home Office, which tried entering into talks with Microsoft to get one introduced, although Microsoft developer Niels Ferguson and other Microsoft spokesmen state that they will not grant the wish to have one added. Microsoft engineers have said that FBI agents also put pressure on them in numerous meetings in order to add a backdoor, although no formal, written request was ever made; Microsoft engineers eventually suggested to the FBI that agents should look for the hard-copy of the key that the BitLocker program suggests its users to make.

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.

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.

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?

The "golden key" for Bitlocker is your individual recovery key. If you keep that in an insecure location, than you're as good as boned if someone gets physical access to your computer and its on a post-it note next to your monitor. Bitlocker is of course proprietary, but there's never been any evidence of a universal back door.

Quote:

According to Microsoft sources, BitLocker does not contain an intentionally built-in backdoor; without a backdoor there is no way for law enforcement to have a guaranteed passage to the data on the user's drives that is provided by Microsoft. The lack of any backdoor has been a concern to the UK Home Office, which tried entering into talks with Microsoft to get one introduced, although Microsoft developer Niels Ferguson and other Microsoft spokesmen state that they will not grant the wish to have one added. Microsoft engineers have said that FBI agents also put pressure on them in numerous meetings in order to add a backdoor, although no formal, written request was ever made; Microsoft engineers eventually suggested to the FBI that agents should look for the hard-copy of the key that the BitLocker program suggests its users to make.

Well that is my point. There was no evidence of a backdoor in Secure Bootloader either until someone found one.

But why would MS need a "golden key" for BitLocker? This was used for internal testing and allowing the MS devs to load unsigned code. What could MS possibly need a universal key for BitLocker? The two aren't similar at all.

In a certain sense it's seems backdoor but it wasn't designed as such but for testing, because in fact Microsoft don't need a backdoor if it has already the real golden key, the private key of the Secure Boot certificate and they can run whatever they want everywhere they like.

Putting for a moment the tin foil hat on, this tool could be made this way on purpose to give three letters agencies an access that don't require signing by Microsoft, but I personally think there would be easier way to do this...

That's the thing about backdoors, was it a mistake or was it intentional? We will never really know. The very nature of having a 3 lettered agency tell you to put one in is that you have to design it to be 1) hidden 2) if found, give your company plausible deniability to prevent you from being sued to bankruptcy.

It's difficult for me to understand exactly what is going on, maybe I'm misunderstanding something, but it doesn't seem exactly a golden key or a backdoor.

A real golden key would be the private key for signing code for Secure Boot, which would be effectively unstoppable, but this is different. This seems to be a piece of code signed by Microsoft used to skip some checks for development or testing. The problem is that 1) they have made some mistakes in designing this tool and 2) they released accidentally the code.Something like that should have had a different signature for each device or at least per model so if something is released accidentally they can efficiently blacklist it. But something went wrong apparently...

In a certain sense it's seems backdoor but it wasn't designed as such but for testing, because in fact Microsoft don't need a backdoor if it has already the real golden key, the private key of the Secure Boot certificate and they can run whatever they want everywhere they like.

Putting for a moment the tin foil hat on, this tool could be made this way on purpose to give three letters agencies an access that don't require signing by Microsoft, but I personally think there would be easier way to do this...

Even if you are right, the problem here is that this key wasn't supposed to get leaked and thus, a true "golden key" certainly could as well.

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.

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.