In the last few articles, I was talking about the security mechanisms that Microsoft has implemented in Windows 10, to help secure the Windows OS as a platform, to maintain integrity and reliability for corporate workforce. If you have not read them yet, below are the links
- 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 secure Windows OS Platform
- Understanding Device Health Attestation Intune Device Compliance Check
Today let’s talk about one more of such security mechanism and its significance in aiding the platform security. Yes, I am talking about Bitlocker that has been present since long, more than a decade being introduced with Windows Vista.
Much has improved since then, so let’s start talking about Bitlocker with relevance to Windows 10 on a UEFI platform.
What is Bitlocker? Nothing new to introduce…
Bitlcoker is a logical Volume encryption mechanism implemented in Windows OS as a security measure to protect sensitive data while the OS is offline.
NOTE: For SSDs with built-in hardware encryption, Bitlocker used to rely on the hardware encryption capabilities of the drive’s crypto processor. This helped to offload cryptographic operations to the drive’s controller from the CPU thereby aiding in performance and efficiency. Read this to know more about the working architecture of such drives.
However, in response to the vulnerabilities as 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. At present, 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 together, these all helps to secure the OS platform.
But this is one side of the story. What about offline protection – when the OS is not running – system is off or is yet to boot? Consider the device is stolen or attacker gets physical access to 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 drive. Windows 10 offers many built in security mechanism 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 drive?
Why EFS encryption is 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, by design EFS can’t encrypt system files and directories, thereby leaving the registry hives stored on the drive
<C:\Windows\System32\config> unprotected. Thus an attacker having 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
As you see, there is no additional security measure implemented to restrict access to the OS Loader, other than the Secure Boot compelled signature check. Post control is passed over the OS Loader, is when Code Integrity and ELAM comes in action, to check 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 secures 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 lost/stolen device or attacker gaining physical access to the system, it’s easy to get access to the device storage and thus to the data stored within.
There needs to be a mechanism which will encrypt the entire drive and not just individual files/directories like EFS, such that the encryption protects the data within the drive even when the OS is non-functional.
This is where Bitlocker encryption find its relevance.
Bitlocker and EFS can work as two layered security mechanism where the former protects the drive contents as a whole while the OS is non-functional and the later protecting 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 fresh OS install on an 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 as well to organize your data, which can also be encrypted by Bitlocker.
Since Bitlocker is a Full Volume Encryption mechanism, it requires to have 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 of the 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 Bitlocker helps 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 they can only be decrypted by the TPM. This 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 a 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 exposed 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 current platform measurement matches with the measurement values with which the key was sealed.
Thus utilizing the TPM chips 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 changes, TPM wont 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 try mount it on another system, it will still ask for Bitlocker recovery key to unlock the device.
This safeguards the data residing 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 AES encryption algorithm in XTS mode with 128 bit key length. But 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 which actually 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. This is a pre-defined process and not configurable.
Thus VMK is the protector of FVEK. Now, 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. As 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 which protects the VMK. On 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 “Bitlocker with non-compatible TPM chip” in the above reference snap from Intune. Leaving it as Not configured results to the default config in devices with non-compatible TPM, which will prompt user to create a Password or Startup Key to protect the Bitlocker VMK. When set to Block, prevents Bitlocker to proceed 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 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 “sealed” to the platform measurement values (PCR 7, 11) at the time of the operation.
Actually Bitlocker can use PCR banks 0, 2, 4, 7 and 11 for validation on an 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 explicitly define them to be used for Bitlocker validation.
In cases, where 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 and in such scenario you can explicitly define the PCR banks to be used for validation via GPO settings
This feature is not available natively in Intune as well as 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 volume remains in the protected volume itself).
Doesn’t it sounds like you have locked the door of your apartment and then remember that the keys to unlock are inside?
Long story short, when a volume is encrypted by Bitlocker, not all the disk sectors that makes up that volume gets encrypted. Some are left unencrypted to contain
- the Volume Header which contains the necessary info related to the volume partiton 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-“ at beginning (0 offset) to identify the volume as Bitlocker encrypted
- FVE metadata block 1 offset
- FVE metadata block 2 offset
- FVE metadata block 3 offset
It is the FVE metadata block which actually 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. More the protectors, more the copies of VMK as each copy is protected using the individual protector.
For redundancy, there are 3 FVE metadata blocks found across a Bitlocker encrypted volume protected by two types of integrity mechanisms
- 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 shows the difference in the structural layout of a Bitlocker protected volume than a normal NTFS volume.
Recovery Password – Why is it needed?
When Bitlocker is implemented, does the authentication method defines the only key protector(s)? No.
At the time of initialization, Bitlocker also creates a Recovery Password (48 digit numeric key) to protect the VMK. This 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. As such if attacker gains access to the Recovery Password (48 digit key) then 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 a “salt” stored in the metadata block. For more information on this, please refer here.
For home PC (workgroup, unmanaged), Bitlocker initialization will automatically prompt 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. In such cases, if the device fails to back up the recovery password to AD or AAD due 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 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
Till now, we have seen that Bitlocker protects a key by encrypting it with a key protector. But it also encrypts the key protector with the key and both the encrypted key and encrypted key protector are stored in the FVE metadata entry.
To understand this logic, let’s consider [k1] is the key and [k2] is the key protector. So Bitlocker performs the below encryption operation
- AES e[ [k1] , [k2] ]
- AES e[ [k2] , [k1] ]
What is the meaning of encrypting the key protector with the key?
Well to answer this, AES is symmetric as such the key to lock is the key to unlock. But when the key is encrypted, it is indistinguishable as it appears as random text. So by encrypting in such 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 really the intended key.
Bitlocker encryption process – Symmetric or Asymmetric?
The generation of FVEK and VMK uses AES algorithm which is a symmetric key encryption cipher.
Symmetric encryption means the key used to encrypt is the key which will be used for decryption as well. 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 as well as to decrypt it.
But when it comes to sealing the VMK to TPM, this is a asymmetric process. Because the TPM uses RSA algorithm for crypto operations. The 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. Thus 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 Bitlocker encryption process is a mixture of both symmetric and asymmetric operations.
Bitlocker enabled boot process – how all the pieces fits in…
Since the EFI System Partition is not Bitlocker encrypted, system can start the normal start up 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.efi) in case the system is starting from a shutdown. In case the system is starting from a hibernate(or sleep), it would instead look for the location of winresume.efi in the BCD entry.
Now both the winload.exe and winresume.efi are present in the OS Volume partition which is Bitlocker encrypted, identified by the signature “FVE-FS“, which implies
Windows Boot Manager can’t access the OS Boot loader or OS Resume loader directly.
This achieves the goal of protecting the volume data while the OS is offline – the OS Kernel is yet to be triggered!
Till this point, system is in its early boot phase and there is no specialized driver to facilitate the disk read/write. The kernel is yet to get initialized, during which the filesystem driver will come online. As such it is the UEFI drivers which facilitates the block I/O operations on the disk.
With the low level Bitlocker code implemented in Windows Boot Manager, it checks the FVE Metadata Header block of the OS volume for the offset of the 1st FVE metadata block. From 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 done in the boot chain till this point will result a different hash for the PCR measurement, which will trigger Bitlocker to enter the Recovery mode, as TPM won’t unseal the VMK. This is how Bitlocker protects the drive if the unencrypted files (OS Boot Manager) on system partition gets compromised.
If 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 with. There’s also Secure Boot checking for the same. Also due to Measure Boot, the OS Boot Loader is measured prior to execution.
NOTE: Bitlocker never decrypts the entire volume at a go, but decrypt 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. As such, 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 boot to the other instance), it will enter Bitlocker Recovery mode.
Considering that the OS loader is the intended one and not been tampered with, Boot Manager will hand over the VMK to the OS loader which will then be loaded in RAM and will be used for decryption/encryption of disk sectors on the fly as per load.
Conditions which triggers Bitlocker Recovery for a UEFI system
Recovery mode is triggered if any of the following conditions is met
- Perform a clear TPM operation post Bitlocker is enabled.
- Modifying the Secure Boot state (PCR 7)
- 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
- gets the Authentication keys required (depending on the authentication scenario)
- locates the VMK and the FVEK, and decrypts a portion of the disk so that the OS can be loaded.
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 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
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 which provides configuration interface to command line tool manage-bde
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…