I recently did some research into Device Encryption, an enabled-by-default BitLocker-encryption of the primary OS volume. Device Encryption was originally Windows RT only but Windows 8.1 brings the feature to every Windows edition. Furthermore, OEMs are required via logo certification (PDF) to leave Device Encryption enabled on all machines that support Connected Standby. The feature never came up when it was RT only, but launching with the other Windows Skus meant I needed to understand it.

This was my first foray into anything BitLocker, so I began by reading a bunch of source material on it. If you’ve played with BitLocker before, Device Encryption will be easy. If not, I found these resources to be supremely informative:

What is Device Encryption?

Device Encryption is a fancy name for a specific BitLocker implementation that’s designed to be consumer-friendly. BitLocker has traditionally been a Professional/Enterprise feature; Device Encryption is the first time the technology has been available to nonprofessional users. Machines that support Device Encryption will see the automatic BitLocker-encyrption of the OS volume and any additional fixed disks.

Device Encryption is established during the initial OS installation. Windows automatically BitLocker-encrypts the OS partition and any additional fixed disks. The BitLocker protection is intentionally left in the Suspended state with no established protectors – effectively, the contents of the OS partition and additional fixed disks are encrypted, but a clear key is at the front of each volume to allow them to be automatically unlocked/mounted. This is the first detail of the consumer-friendly implementation. Windows waits to take BitLocker out of the Suspended state until a user to signs in with a Microsoft Account. Then, it can silently upload a BitLocker recovery key to protect against unexpected failures.

So let’s jump forward a bit. The machine has left the factory with everything encrypted but BitLocker suspended. The user powers on the machine and is greeted by the Out of Box Experience. The OOBE asks for a Microsoft Account, the user signs in or creates one, and the key is uploaded to Microsoft. Windows removes the BitLocker clear key from the volumes, seals an unlock key in the TPM, and from then on relies on the TPM to reveal the key to unlock the volumes on boot. Device Encryption can then be considered truly enabled.

Quick Q&A:

How is the Drive Unlocked?

Device Encryption is TPM only BitLocker solution. BitLocker itself supports a number of different styles of protection, such as a pin code, smart card, additional USB drive, etc. Device Encryption’s choice of utilizing the TPM only is designed to provide protection with minimal user impact.

The TPM holds the unlock key sealed earlier as well as hashes of boot-critical components. When the computer turns on, boot components are compared against the hashes in the TPM to ensure none have been compromised. You can view the hashes as a combination to a safe that stores the unlock key. Get the combo right, and you get the key to unlock the volume. But if any hashes don’t match, the key is not released and the volume cannot be unlocked. In such a case, Windows prompts for the BitLocker recovery key.

On UEFI systems, four sets of components hashed:

[0] The Core Root-of-Trust for Measurement (CRTM), EFI boot and run-time services, EFI drivers embedded in system ROM, ACPI static tables, embedded SMM code, and BIOS code
[2] Option ROM code, such as any additional drivers loaded from an adapter card
[4] EFI Boot file (usually bootx64.efi) and any other EFI applications loaded by it 
[11] BitLocker access control. Includes some BCD settings verification and other internal checks such as a hash of some configuration settings

These are defined by the Trusted Computing Group here (PDF). The four chosen for Device Encryption have each been engineered to remain static every boot, hopefully preventing any false failures to validate. (In implementations for older versions of Windows, actions as simple as pressing F8 on boot would cause a prompt for a BitLocker key.) Of course, that’s not to say you’ll never see a prompt. Let’s look at how trying to repair Windows issues can trigger them.

How Does This Affect Repairing Windows?

I first looked at what actions would prevent the automatic unsealing of the unlock key on boot. For example, common repair steps are to boot to an offline environment, such as the built-in Windows Recovery Environment. In my testing, any attempt to interrupt or detour the boot process change the hashes of boot components and prevents the key from being released by the TPM. I tested the following scenarios:

Of course, there are options for suspending the protection. Windows will periodically need to service the boot files and things like firmware updates will change hashed components, so functionality exists to return BitLocker to the Suspended state. While in the OS, this can be done via WMI, BitLocker management APIs, or via the manage-bde.exe command:

manage-bde.exe –protectors –disable C:

Windows 8 and 8.1 allow you to specify how many reboots you would like to leave BitLocker suspended – they default to suspending for just one reboot and automatically unsuspending after that. An augmented command might be:

manage-bde.exe –protectors –disable C: -RebootCount 3

You can also simply print the key to unlock the volume.

manage-bde.exe -protectors -get C:

Wrapping Up

For repair scenarios, this should only prove a minor annoyance with machines that can still boot and log in. There, we can suspend BitLocker as needed and even print the key. But, other scenarios will require sourcing the recovery key via the online process. I can think of at least these: