Bitlocker Unlocked with Joy – Behind the Scenes Windows 10 – Part 1

In the last few articles, I talked about Microsoft’s security mechanisms in Windows 10 to help secure the Windows OS as a platform to maintain integrity and reliability for the corporate workforce. If you have not read them yet, below are the links.

Related Posts

• Part 1 – Bitlocker Unlocked with Joy – Behind the Scenes Windows 10
• Part 2 – Device Encryption – Bitlocker made Effortlessly
• Part 3 – Deciphering Intune’s Scope w.r.t Bitlocker Drive Encryption
• Part 4 – Intune and Silent Encryption – A Deeper Dive to Explore the Internal

• Understanding Windows 10 UEFI Secure Boot – How it helps to secure Pre-Boot Phase
• Understanding Windows Trusted Boot – Integrity Check and ELAM
• Windows Measured Boot – How it helps to ensure Windows OS Platform
• Understanding Device Health Attestation Intune Device Compliance Check

Introduction

Today let’s talk about one more such security mechanism and its significance in aiding the platform security.

Yes, I am talking about Bitlocker, which has been present for more than a decade, introduced with Windows Vista.

Since then, much has improved, so let’s start talking about Bitlocker relevant to Windows 10 on a UEFI platform.

• Part 1 – Bitlocker Unlocked with Joy – Behind the Scenes Windows 10
• Part 2 – Device Encryption – Bitlocker made Effortlessly

What is Bitlocker? Nothing new to introduce…

BitLocker is a logical Volume encryption mechanism implemented in Windows OS as a security measure to protect sensitive data while the OS is offline.

More detailed descriptions can be found here on Wikipedia and Microsoft documentation. As such, I won’t spend time re-describing.

NOTE: For SSDs with built-in hardware encryption, Bitlocker used to rely on the hardware encryption capabilities of the drive’s cryptoprocessor. This helped offload cryptographic operations to the drive’s controller from the CPU, thereby aiding performance and efficiency. Read this to know more about the functional architecture for such purposes.

However, in response to the vulnerabilities identified with self-encrypting drives, Microsoft released a Security Advisory ADV180028 urging customers to unencrypt any SSD that implements self-encryption, then re-encrypt it with software-based encryption. Bitlocker defaults to software encryption even if the system drive has self-encryption capability.

Relevance of Bitlocker in security…

Secure Boot ensures that the OS pre-boot phase is not compromised.

Measured Boot ensures that even if some malware has been successful in evading the ELAM and Code Integrity as subjected by Trusted Boot, its presence is still recorded, which can be used by an AM service for remediation. Combined, these all help to secure the OS platform.

But this is one side of the story. What about offline protection – when the OS is not running – the system is off or is yet to boot? Consider the device is stolen, or the attacker gets physical access to the device.

As the device boots up, you will be doing some productive work on it – you will have your corporate emails and many other corporate data stored in the device driver. 

Windows 10 offers many built-in security mechanisms to protect data in the device from attacks by individuals accessing the computer over the network.

But all these protection features are active when the OS is active and running.

What about the security of data stored in the device drivers?

Why is EFS encryption not enough?

Encrypting File System, a feature of NTFS (yes, the same encryption mechanism behind Windows Information Protection), starts after the OS boots and runs as a service (program) under LocalSystem context in a shared process of lsass.exe (Local Security Authority Subsystem).

It helps to protect data by encrypting individual files and directories but not an entire drive/volume.

However, design EFS can’t encrypt system files and directories, leaving the registry hives stored on the drive <C:\Windows\System3,2\config> unprotected. Thus an attacker with physical access to a compromised device can mount the drive to another system to gain access to the registry and hammer it with Brute-Force exploit tools to get data out from EFS encrypted files.

Not a full proof security…

Boot flow without Bitlocker

There is no additional security measure to restrict access to the OS Loader other than the Secure Boot compelled signature check.

Post control is passed over the OS Loader when Code Integrity and ELAM come into action to check the AV signature and integrity of the components being executed for booting.

But there is no mechanism implemented in this flow to restrict the access to the OS Loader or the drive contents. This flow only ensures the integrity of the OS platform but does not secure the drive contents.

What if I take out the drive and mount it to another system?

There is no mechanism in the above flow to check or restrict access to the drive contents.

Thus, in case of a lost/stolen device or attacker gaining physical access to the system, it’s easy to access the device storage and thus the data stored within.

There needs to be a mechanism that will encrypt the entire drive and not just individual files/directories like EFS. The encryption protects the data within the industry even when the OS is non-functional. 

This is where Bitlocker encryption finds its relevance.

Bitlocker and EFS can work as two-layered security mechanisms where the former protects the drive contents. At the same time, the OS is non-functional, and the latter protects individual files while the OS is functional.

But if Bitlocker encrypts the complete drive, how will a system start the boot process?

Understanding the Disk partitioning requirements for Bitlocker

The drive partition requirement can be found here in the Microsoft document. If you have noticed, for the fresh OS installation on a UEFI system, Windows Setup by default partitions the OS drive to support Bitlocker.

• EFI SYSTEM PARTITION (FAT32 FS) of 260 MB at the initial drive sectors to contain the OS BOOT MANAGER
• Microsoft Reserved partition (MSR) [not visible in diskpart utility]
• OS volume partition formatted to NTFS (Volume with mount point C:)
• Recovery partition to contain the files (winre. wim image) necessary for running Windows Recovery Environment (WinRE) (also NTFS)

You can have additional partitions created to organize your data, which Bitlocker can also encrypt.

Since Bitlocker is a Full Volume Encryption mechanism, it requires a separate partition where the bootstrap codes (boot manager) are contained – EFI System Partition,, which is not encrypted. This allows the system to start the boot process.

Bitlocker Drive Encryption only encrypts the OS volume by default.

However, Bitlocker cannot encrypt a volume if it meets any conditions mentioned below.  

• Insufficient space on Volume partition (required for FVE Metadata Block and is explained later)
• Incompatible File Format system
• Dynamic Volume
• Volume designated as System Partition

How does Bitlocker help to aid in security?

Modern-day implementation of Bitlocker is dependent on two other security features –

• TPM (not a requirement for Bitlocker, but offers the hardware security which is much needed)
• Windows Measured Boot (a security feature of Windows implemented using the TPM capabilities)

TPM can create cryptographic keys and encrypt them so that the TPM can only decrypt the process is called wrapping or “binding a key to TPM.” 

The key, as generated, is wrapped/bound using a master wrapping key (unique to each TPM), called the Storage Root Key (SRK).

SRK is an RSA 2048 bit public-private key pair where the SRK_Pub is used for encryption operation as it is exposed outside TPM. However, only the TPM can decrypt the encrypted content as only it has the SRK_Priv (this is stored within TPM and is never disclosed outside)

A TPM can also create a key that has not only been wrapped but is also tied to certain Platform measurements (PCR values). This process is referred to as “sealing the key to the TPM.”

Binding a key to TPM with platform measurement ensures that it can be unsealed only when the current platform measurement matches the measurement values with which the key was sealed. 

Thus utilizing the TPM chip’s crypto-security capabilities coupled with Measured Boot, Bitlocker seals the encryption key to TPM using the original boot measurements.

This ensures that if the boot parameters change, TPM won’t unseal the key to decrypt the drive and will result in throwing the Bitlocker Recovery screen.

Even if the attacker takes out the system drive and tries to mount it on another system, it will still ask for the Bitlocker recovery key to unlock the device.

This safeguards the data on the system drive even when the OS is not active.

Bitlocker Encryption Process – explained in plain text

Bitlocker encrypts the disk sectors (used space only by default) using Full Volume Encryption Key (FVEK), which is generated using FIPS-compliant pseudo-Random Number Generators (RNG) as implemented in the OS, using the AES algorithm either in CBC or XTS mode (key length 128 bit or 256 bit).

By default, Bitlocker uses an AES encryption algorithm in XTS mode with 128-bit key length. ut this is configurable either via

• traditional management using Group Policy (Computer Configuration > Administrative Templates > Windows Components > Bitlocker Drive  Encryption)

• modern management via Intune (Windows 10 Device Configuration profile > type Endpoint Protection > Windows Encryption)

The FVEK is the key that encrypts the raw data on the disk  Bitlocker protects it by encrypting it (AES algorithm used) using another key – Volume Master Key (VMK), which is a 256-bit key. His is a pre-defined process and not configurable.

Thus VMK is the protector of FVEK. Ow, anyone having access to the VMK can use it to decrypt the encrypted FVEK with which he can get access to the data stored in the drive. S such, it is important to protect the VMK as well.

This is where the Bitlocker authentication part comes in – the key protectors.

Knowing the key protectors in Bitlocker…

In simple and short, key protectors are the entities that protect the VMK. n a device with compatible TPM (1.2 or 2.0), Bitlocker gives the following options for key protectors

• TPM only (used by default in Windows 10 unless specified by policy otherwise)
• TPM + PIN (4-20 digits)
• TPM + Startup Key (USB drive)
• TPM + Startup Key (USB drive) + PIN (4-20 digits)

This is a mapping to the Group Policy setting “Require additional authentication at startup” “under Windows Components > Bitlocker Drive Encryption > Operating System Drives

You can use manage-bde to get the protector details

On devices with non-compatible TPM, Bitlocker offers only two options for protectors.

• Password, or
• Startup Key (USB drive)

This is controlled via the setting “locker with non-compatible TPM chip” “in the above reference snap from Intune.

I am leaving it as Not configured results in the default config in devices with non-compatible TPM, which will prompt the user to create a Password or Startup Key to protect the Bitlocker VMK. Hen set to BlBlockrevents Bitlocker from proceeding with drive encryption.

If you wish to use Bitlocker without TPM (not very much secured and recommended), currently not configurable from Intune UI, but you can use the Bitlocker CSP reference to create a custom OMA-URI profile.

Bitlocker Encryption Process explanation cont…

In its default implementation, Bitlocker uses the device TPM to protect the VMK.

The TPM encrypts the VMK using the SRK_Pub key (RSA 2048 bit),, and the encryption is “ealed” “to the platform measurement values (PCR 7, 11) at the time of the operation.

Bitlocker can use PCR banks 0, 2, 4, 7, and 11 to validate a UEFI system with compatible TPM. However, in reality, by default, it only uses the PCR 7 and 11.

This is to prevent Bitlocker from entering the Recovery mode post a Firmware update, or in case you need to dual boot your system. with Secure Boot enabled (PCR 7), Secure Boot can verify and guarantee the integrity of the components being measured for PCR 0, 2, and 4, as such it is not required to define them to be used for Bitlocker validation explicitly.

In cases where the device is not having a TPM or an incompatible TPM where PCR 7 binding is not possible, Bitlocker cannot use the Secure Boot for integrity validation. In such a scenario, you can explicitly define the PCR banks for confirmation via GPO settings.

This feature is not available natively in Intune and via Bitlocker CSP.

However, both the VMK (encrypted with TPM SRK + PCR measurement values) and FVEK (encrypted with VMK) are stored on the Bitlocker protected volume itself (yes, the keys to unlock the book remain in the covered book itself).

Doesn’t it sound like you have locked your apartment door and then remembered that the keys to unlock it are inside?

When Bitlocker encrypts a volume, the disk sectors that make up that volume get encrypted. some are left unencrypted to contain

• the Volume Header containing the necessary info related to the volume partition for the OS to access it (volume label, filesystem signature, etc.)
• the filesystem generated metadata files ($ Boot, $MFT, $Logfiles, etc.)

For a Bitlocker protected volume, the FVE Metadata Block Header replaces the standard NTFS partition header and contains all the Bitlocker related necessary information like

• signature “FVE-FS-” t the beginning (0 offsets) to identify the volume as Bitlocker encrypted
• FVE metadata block one offset
• FVE metadata block two offset
• FVE metadata block three offset

The FVE metadata block holds the encrypted keys – the FVEK protected by VMK and multiple copies of the protected VMK.

Why multiple copies of VMK?

The number of copies of VMK depends on the number of protectors. Regarding the protectors, more copies of VMK as each document is protected using the individual protector.

There are 3 FVE metadata blocks found across a Bitlocker encrypted volume protected by two types of integrity mechanisms for redundancy.

• A CRC-32 checksum at the end of the metadata block guards against media corruption
• A cryptographic signature based on this checksum to prevent malicious modifications

Below is the difference in the structural layout of a Bitlocker protected volume from a normal NTFS volume.

Recovery Password – Why is it needed?

When Bitlocker is implemented, does the authentication method defines the only key protector(s)?.

At the time of initialization, Bitlocker also creates a Recovery Password (48 digits numeric key) to protect the VMK. is used in case the primary authentication fails and Bitlocker enters the recovery mode.

In recovery mode, there is no TPM dependency or operations involved. If an attacker gains access to the Recovery Password (48 digit key), the drive is compromised.

A copy of the VMK is encrypted with a 256-bit AES-CCM key that can be computed with the Recovery Password and an “alt” “stored in the metadata block.

For home PC (workgroup, unmanaged), Bitlocker initialization will automatically prompt the user to save Recovery Password as a text file or displayed on the screen.

For a device joined to local AD or Azure AD, you can define through policy to back up the Recovery Password to AD or AAD against the device object. If the device fails to back up the recovery password to AD or AAD due to any issues (network or others), the process is halted.

 Bitlocker Key Structure

Below schematic representation shows the structure of Bitlocker keys and the key protectors (as they are stored in the FVE metadata)

Bitlocker uses AES in CBC-MAC (AES-CCM) mode for the encryption operation of a key with its protector. As such, it results in the generation of

• Message Authentication Code (MAC) – helps to verify the authenticity and integrity
• Nonce – used to identify the key generation sequence and timestamp of operation

which are also associated with the key protector structure in the metadata.

A twist in the encryption logic of Bitlocker

We have seen that Bitlocker protects a key by encrypting it with a key protector. t it also encrypts the key protector with the key. The encrypted key and encrypted key protector are stored in the FVE metadata entry.

To understand this logic, llet’sconsider [k₁] is the key, and [k₂] is the key protector. Bitlocker performs the below encryption operation.

• AES e[ [k₁] , [k₂] ]
• AES e[ [k₂] , [k₁] ]

What is the meaning of encrypting the key protector with the key?

Well, to answer this, AES is symmetric. As such, the key to the lock is the key to unlock. When the key is encrypted, it is indistinguishable as it appears as random text. By encrypting in such a manner, during the decryption operation, after the key protector is used to decrypt the encrypted key, Bitlocker also checks if the key can decrypt the encrypted key protector, ensuring this is the intended key.

Bitlocker encryption process – Symmetric or Asymmetric?

The generation of FVEK and VMK uses the AES algorithm, an asymmetric key encryption cipher.

Symmetric encryption means the key used to encrypt is the key used for decryption.

This is true for Bitlocker as the FVEK, which encrypts the disk sectors, is also used to decrypt them to get clear text data. Similarly, for the VMK, it is used to both encrypt the FVEK and solve it.

But when it comes to sealing the VMK to TPM, this is an asymmetric process. Cause the TPM uses the RSA algorithm for crypto operations. e SRK is public-private key pair where TPM uses the  SRK_Pub (shared outside TPM) to encrypt the VMK.

For decryption, it will use the SRK_Priv, which remains securely stored within the TPM, ensuring security and authenticity. At the authentication phase, the key used to encrypt the VMK is not the key used to decrypt it, changing the nature to asymmetric.

Hence with the involvement of TPM, we can say the Bitlocker encryption process is a mixture of both symmetric and asymmetric operations.

Bitlocker enabled boot process – how all the pieces fit in…

Since the EFI System Partition is not Bitlocker encrypted, the system can start the normal startup sequence.

As the system starts the boot process and UEFI firmware triggers the Windows Boot Manager (bootmgfw. efi), it reads the BCD entry to locate the OS loader (winload. fi) in case the system is starting from a shutdown.

If the system is starting from a hibernate(or sleep), it would instead look for the location of the winresume—I in the BCD entry.

Now both the winload.exe and winresume. I am present in the OS Volume partition, which is Bitlocker encrypted, identified by the signature “VE-FS,” which implies

Windows Boot Manager ccan’taccess the OS Boot loader or OS Resume loader directly.

This aims to protect while the OS is offline – the OS Kernel is yet to be triggered!

Then the system is in its early boot phase, and there is no specialized driver to facilitate the disk read/write. E kernel is yet to get initialized, during which the filesystem driver will come online. Such it is the UEFI drivers which facilitate the block IBlockerations on the disk.

The low-level Bitlocker code implemented in Windows Boot Manager checks the OS volume’s FVE Metadata Header block to offset the 1st FVE metadata block. Om there, it learns the authentication type implemented.

Similarly, the TPM operations required are facilitated via the low-level TPM operations code implemented in the Windows Boot Manager.

For TPM only mode, it will fetch the encrypted VMK blob as obtained from the FVE Metadata and send it to TPM.

This is where it hits the 1st roadblock.

TPM will check the blob to see if the current platform measurement matches the one with which the key was sealed.

Any modification in the boot chain will result in a different hash for the PCR measurement, which will trigger Bitlocker to enter the Recovery mode, as TPM wwon’tunseal the VMK.

Bitlocker protects the drive if the unencrypted files (OS Boot Manager) on the system partage get compromised.

If the current PCR measurement matches that with which the VMK was sealed, TPM will unseal the VMK using the SRK_Priv (Private part of SRK stored within TPM) and send the unencrypted VMK back to the OS Boot Manager.

With the VMK in access, Boot Manager will decrypt the FVEK to unlock the disk sectors containing the OS Boot Loader (winload. efi) or OS resume loader (winresume. efi).

Since the decryption involves evaluation of the associated MAC, it ensures the OS Boot Loader has not been modified. Here also Secure Boot checking for the same. So due to Measure Boot, the OS Boot Loader is measured before execution.

NOTE: Bitlocker never decrypts the entire volume at a go but decrypts only sectors as required by the read/write request from the I/O Manager

This is where it hits the 2nd roadblock.

Any changes in measurement will cause Bitlocker to abort the transfer of decrypted VMK from OS Boot Manager to OS Boot Loader.

If it is found that it is not the intended OS Boot Loader (in case you try to dual Boot a Bitlocker protected system creating an identical Windows installation and try BBootto the other instance), it will enter Bitlocker Recovery mode.

Considering that the OS loader is the intended one and has not been tampered with, Boot Manager will hand over the VMK to the OS loader, which will then be loaded in RAM and used for decryption/encryption of disk sectors on the fly as per load.

Conditions that trigger Bitlocker Recovery for a UEFI system

Recovery mode is activated if any of the following conditions are met

1. Perform a clear TPM operation post Bitlocker is enabled.
2. Modifying the Secure Boot state (PCR 7)
3. Any tampering with the OS Boot Loader or on the drive itself  (PCR 11)

High-level overview of the main components that make up Bitlocker

Low level code (implementation of TPM API) in Windows Boot Manager to facilitate TPM operations

Low level code (Implementation of functions provided by FVE API) in the Windows Boot Manager (%System%\EFI\Microsoft\Boot\bootmgfw.efi) that

BitLocker filter driver (%SystemRoot%\System32\Drivers\fvevol.sys), a kernel-mode driver that performs on-the-fly encryption and decryption of the volume.

While the OS is active, programmatic access to TPM is facilitated via the TPM Base Service API, which includes

• a user-mode dll, acting as a service interface for user-mode applications to access the TPM (%SystemRoot%\System32\tbs.dll)

• a kernel-mode driver, which is essentially the implementation of same library functions in the kernel space (%SystemRoot%\System32\drivers\tbs.sys)

The functions are also made available via WMI provider class Win32_Tpm.

There is also an MMC snap-in for TPM configuration (%SystemRoot%\System32\tpm.msc) however, the use of which has been deprecated as the functionality is now implemented via Windows Security Center -> Device security -> Security processor Refer here to know more

The Bitlocker operations are supported by functions as implemented in fveapi.dll and fveapibase.dll at location %SystemRoot%\System32\

The encryption operations are facilitated by functions implemented in ncrypt.dll and bcrypt.dll (%SystemRoot%\System32\…)

Last but not the least, BitLocker WMI provider class Win32_EncryptableVolume provides a configuration interface to command-line tool manage-bde

Ending

With this, I will draw the curtains on this article.

In the next article regarding Bitlocker, I will talking about deploying Bitlocker policy from Intune, the different types of Bitlocker encryption available in Windows 10 and the most common errors that you may face as an Admin when you deploy an Endpoint Protection policy from Intune.

Till then, keep reading, keep learning…

Resources

• More details about the header and block formats
• Some more details about BDE format specification