All your keys are belong to us: Windows 8.1, BitLocker and key-escrow

The first crypto-wars

It is said that history is written by victors. The conventional account of 1990s Crypto Wars is an epic struggle pitting the software industry against the Clinton administration over use of strong cryptography in commercial software. At the time such products were curiously regulated as “munitions” and subject to ITAR (International Traffic in Arms Regulations) in much the same way as selling a Stinger missile. Concerned about the implications of strong cryptography and intent on keeping it from falling into the wrong hands, the administration favored an escrowed encryption standard. This envisioned a world where users could have their strong cryptography with one caveat: a copy of the secret keys protecting the communication would be made available to law enforcement. This notion of key-escrow became the flash-point in a contentious debate. Industry argued that such handicaps would greatly disadvantage US products in global markets, since competing offerings from European and Asian firms faced no such restrictions.

The unusual alliance of civil libertarians, first-amendment proponents, cypherpunks and commercial interests won that argument. The Clipper chip proposal for implementing the EES standard went nowhere, the administration backed down and most vestiges of export controls were gone in a matter of years.

Fast forward to today, key escrow is back in more subtle and insidious ways.

Bitlocker

The next chapter of the story stats out innocuously with Microsoft introducing BitLocker full-disk encryption with the ill-fated Vista release of Windows. Designed to leverage special tamper-resistant hardware called Trusted Platform Module (TPM), BitLocker provides encryption for data at rest– a valuable defense as data breaches resulting from theft of laptops are on the rise. Windows 7 extends the underlying technology to also protect removable drive using a variant called BitLocker-To-Go.

Forgot your password?

There is a down side to encryption: it creates an availability problem, a new way to lose data. If cryptographic keys are lost, data encrypted in those keys becomes unrecoverable just as if the disk had been wiped clean. In the case of BitLocker that could mean TPM malfunction, user forgetting a passphrase, entering an incorrect PIN too many times or losing the smart card. The solution? Backing up keys. When setting up Bitlocker encryption, Windows will helpfully remind the user to stash a recovery key in a “safe location,” lest they lose the primary decryption mechanism.  There are a couple of options:

• Print a hard-copy on paper
• Save it to a file or removable drive– ideally not on the same disk, otherwise a circularity results
• For domain-joined machines, there is also the “option” to upload recovery keys to Active Directory— in other words key-escrow to the IT department, (In quotes because the decision is not made by end users but configured centrally by IT policy.)

Key-escrow reconsidered

When evaluating the impact of key-escrow on a particular encryption design, the critical detail is the relationship between the data owner and third-party acting as escrow agent. For example in enterprise deployments, Bitlocker is commonly employed with automatic escrow to the corporate IT system as noted. Arguably this model makes sense in a managed environment for two reasons:

1. Ownership: This is controversial but many enterprises state in their acceptable use policy (AUP) that data residing on company issued hardware belongs to the company.  (Note that the bring-your-own-device or BYOD model muddies the waters on this.) In that sense the data-owner is not the individual employee but the enterprise and it is their decision to escrow keys with the IT department.
2. Threat model: IT staff operating the Active Directory system already have administrator privileges on user machines and can execute arbitrary code. Users can not have privacy against their own IT department under any realistic threat model of a managed environment. In that sense key-escrow to AD does not introduce any additional privacy risk: the escrow agent was already in a position to read all data.

To the cloud

Windows 8 introduced a new option for BitLocker recovery keys, displayed prominently as the first choice: save to your Microsoft Account.

BitLocker recovery key options. (Screenshot from Windows 8 BitLocker-To-Go setup wizard.)

That means storing back-up keys on Microsoft servers, with access gated by the MSFT online identity system, also known by past names .NET Passport and Windows Live. By authenticating with the same identity in the future, users can retrieve the keys from the cloud if they need to recover from a key loss scenario. In other words, key-escrow to Microsoft.

This is arguably the most reliable way to back up keys. It also happens to be the most opaque one and fraught with privacy questions. When keys are printed out on hard-copy or saved on USB drive, they are still in physical possession of the user. That does not mean they are immune to risk– pieces of paper can be stolen, files stored on a machine can be pilfered by malware. Yet these risks are visible and largely under the control of the user. For example if the user happened to save recovery keys on a thumb drive, they could choose to put that object into a safety deposit box if they were sufficiently paranoid. By contrast when keys are uploaded to the cloud, the chain of custody goes cold. The cloud service is a blackbox and users have no way to ascertain what is going, how keys are stored and if anyone else has been given access.

Unlike the enterprise scenario, the escrow-agent is not the data owner in this case. Microsoft is the provider of the operating system. There is no expectation that any user data stored on that machine must be accessible to the vendor providing the software. There are additional privacy risks introduced by electing this option but it remains just that– an option. Each user can weight the options and decide independently whether the added reliability merits such risks.

Defaults and nudges

Windows 8.1 will not be released until October but developer previews are already available. Judging by preliminary information on MSDN, Bitlocker “enhancements” for Windows 8.1 and Windows Server 2012 R2, this release ups the ante. Key escrow is enabled by default on consumer PCs.

Unlike a standard BitLocker implementation, device encryption is enabled automatically so that the device is always protected. If the device is not domain-joined a Microsoft Account that has been granted administrative privileges on the device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a recovery key is uploaded to online Microsoft account and TPM protector is created.

Remembering that “not domain-joined” will apply to most consumer PCs for use at home,  this translates to: for any Windows 8.1 machine that happens to have requisite TPM hardware, BitLocker disk encryption will be enabled with recovery keys escrowed to MSFT automatically.

Why is this significant? One could counter that it is merely an opt-out setting users are free to override if they happen to disagree with MSFT policies. But it is well-known that choice of default settings made by the application developer are critical. Majority of users will accept them verbatim. Behavioral economics literature is full of examples of crafting  default options to “nudge” the system overall towards a particular social outcome, without overt coercion applied at individual level.

There is nothing wrong with offering an option for cloud escrow. But making that an automatic decision without giving users upfront notice and meaningful chance to opt-out is disingenuous. It is particularly tone-deaf given the current post-Snowden climate of heightened awareness around privacy and surveillance. Allegations around US government surveillance have raised questions about the safety of personal information entrusted to cloud providers. Such accusations are expected to cost the industry billions of dollars in lost revenue as customers curtail their investment of resources in the cloud.

One could also counter that any encryption is better than leaving the data unprotected. But enabling BitLocker automatically also has the downside of crowding out other options by creating a false sense of security. It sends the users a misleading signal that the data protection problem is solved, no further action is required. Users are far less likely to comparison-shop for different full-disk encryption schemes— including alternatives that don’t have same weakness around key management. They are less likely to make an informed decision based on their personal preferences. For some the automated key-escrow may be a welcome convenience, a complete non-issue. Others disturbed by Snowden revelations may consider it a deal-breaker. That is a decision MSFT can not make on behalf of users. It is telling that managed environments with Active Directory– the type one would find in a medium/large company– are already exempted from this feature, in recognition of different negotiation dynamics. It is not individual employees but centralized IT department making decisions about how to protect company data. The idea of someone in Redmond having copies of their encryption key may not sit very well with this audience. (It also turns out to be much more difficult to force unwanted functionality on this group– witness how well Vista fared in the enterprise.)

Windows 8.1 is deliberately giving up ground the industry bitterly argued over– and won– during the Clinton administration. It is bizarre that Microsoft, both a central figure in and prime beneficiary of that struggle, is now voluntarily creating the same outcome It once tried to avert. Only this time key-escrow is hailed as a “feature.”

CP