Microsoft’s BitLocker allows for full-disk encryption that seamlessly integrates with the operating system and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers. BitLocker is a hardware-based security feature that addresses the growing need for better data protection. The feature uses a hardware device, the Trusted Platform Module (TPM 1.2 or later) to protect user data and to ensure that PCs that are running Windows Operating System (OS) are not been tampered with while the system was offline. See this guide for information on how to backup existing and new BitLocker recovery keys to Active Directory.
BitLocker Architecture: To achieve a higher level of security without greatly affecting usability, BitLocker supports different types of cryptographic algorithms and encryption layers, including multifactor authentication. The main goal of BitLocker is to protect user data on the operating system volume. To achieve this, disk sectors are encrypted with a full-volume encryption key (FVEK), which is always encrypted with the volume master key (VMK), which, in turn, is bound to the TPM (in TPM scenarios).
See this guide for information on how to enable or disable BitLocker Drive Encryption on Windows 10 and Virtual Machines, how to fix your device cannot use a Trusted Platform Module: Allow BitLocker without a compatible TPM” and how to enable FileVault disk encryption on a Mac device. Also, for how to enable Bitlocker Pre-Boot Authentication PBA via the Local GP Editor and the GP Management Console.
This strategy of protecting the VMK indirectly protects the encrypted volume and has the advantages that:
- The system can regenerate keys upstream in the chain if one or more of these keys are lost or compromised.
- The recovery process can be done without decrypting and re-encrypting the entire volume, which is expensive in terms of the user’s time.
Turning on BitLocker for your operating system volume encrypts all system files on the volume, including the paging files and hibernation files. The only exception is for the System partition, which includes the Windows Boot Manager and minimal boot collateral required for decryption of the operating system volume after the key is unsealed. See this link for more information.
BitLocker can be transparent to the user and is easy to deploy and manage. When a system is compromised, BitLocker has a simple and efficient recovery process for authorized users. Below are the various ways we can implement Full Disk Encryption. They are as follows
- Pre-boot Authentication
- Authentication after the user is unlocked
- BitLocker activation without a PIN.
A – Pre-boot Authentication (PBA): Previously Microsoft recommended using pre-boot authentication to protect against DMA and memory remanence attacks. BitLocker stores the encryption keys in memory only after pre-boot authentication is completed. Windows can not access the encryption keys, and the device can not read or edit this file on the system drive.
- PBA is designed to prevent the encryption keys from being loaded to system memory without the trusted user supplying another authentication factor such as a PIN or a startup key.
- To defend against malicious reset attacks, BitLocker leverages the TCG Reset Attack Mitigation, also known as MOR bit (Memory Overwrite Request) before extracting keys into memory.
Note: This is no longer a problem because starting with Windows 10 version 1803, new Intel-based devices have kernel protection against DMA attacks via Thunderbolt™ 3 ports enabled by default. This Kernel DMA Protection is available only for new systems beginning with Windows 10 version 1803, as it requires changes in the system firmware and/or BIOS.
- You can use the System Information desktop app (MSINFO32) to check if a device has kernel DMA protection enabled.
B – Authentication after the user is unlocked: This is similar to PBA and will require the OS to prompt the user for authentication credentials after unlocking.
Please apply due diligence! Both the "Pre-boot Authentication" and "Authentication after the user is unlocked" are no longer of importance due to the additional authentication requirement they present to users. - In addition, users can forget their PIN or lose their startup key and will be denied access to their data until they are able to contact the support team to obtain a recovery key. To mitigate this issue, you should implement BitLocker without requiring a PIN.
C – BitLocker activation without a PIN: We can actually configure BitLocker not to require a Pin or newer hardware due to the inconvenience Pre-boot authentication prompts can cause to users. In addition, users can forget their PIN or lose their startup key and will be denied access to their data until they are able to contact the support team to obtain a recovery key. To enable BitLocker FDE without requiring a PIN, below are the following options to get this running.
- Network Unlock: When BitLocker detects the device is connected to the organization network, it unlocks the device.
– But when the user is not connected to the organization network, he/she will therefore be prompted for a password. What if the PC is not connected to the network, this will introduce the over discussed above which users may never employ or use.
- Configuring Group Policy setting to not require additional authentication at startup and the corresponding setting in the BitLocker CSP is SystemDrivesRequireStartupAuthentication.
- TPM only: Using TPM-only validation does not require any interaction with the user to unlock and provide access to the drive.
Key protectors in Bitlocker: In simple and short, key protectors are the entities that protect the VMK. On a device, with compatible TPM (1.2 or later). Bitlocker gives the following options for key protectors. On computers with a compatible TPM, operating system drives that are BitLocker-protected can be unlocked in four ways:
|Authentication scenario||VMK BLOB||Algorithm to encrypt VMK|
|Default: TPM only||SRK(VMK)||RSA|
|TPM plus PIN||(SRK+SHA256(PIN))(VMK)||RSA|
|TPM plus startup key||SHA256(SRK(DerivedKey), StartupKey)(VMK)||AES|
|Recovery password||(Chained-hashing(Password), Salt)(VMK)||AES|
- TPM-only: Using TPM-only validation does not require any interaction with the user to unlock and provide access to the drive. If the TPM validation succeeds, the user sign in experience is the same as a standard logon. If the TPM is missing or changed or if BitLocker detects changes to the BIOS or UEFI code or configuration, critical operating system startup files, or the boot configuration, BitLocker enters recovery mode, and the user must enter a recovery password to regain access to the data. This option is more convenient for sign-in but less secure than the other options, which require an additional authentication factor.
TPM-only authentication method offers the lowest level of data protection. This authentication method protects against attacks that modify early boot components, but the level of protection can be affected by potential weaknesses in hardware or in the early boot components.”
- TPM with startup key: In addition to the protection that the TPM-only provides, part of the encryption key is stored on a USB flash drive, referred to as a startup key. Data on the encrypted volume cannot be accessed without the startup key.
- TPM with PIN: In addition to the protection that the TPM provides, BitLocker requires that the user enter a PIN. Data on the encrypted volume cannot be accessed without entering the PIN. TPMs also have anti-hammering protection that is designed to prevent brute force attacks that attempt to determine the PIN.
- TPM with startup key and PIN: In addition to the core component protection that the TPM-only provides, part of the encryption key is stored on a USB flash drive, and a PIN is required to authenticate the user to the TPM. This configuration provides multifactor authentication so that if the USB key is lost or stolen, it cannot be used for access to the drive because the correct PIN is also required.
Since my interest in this guide is on TPM only, I will not be needing any additional BitLocker PIN. Therefore, the general notion that “encryption may not provide confidentiality without authentication. A typical example is a device with a Self-Encrypting Drive or software FDE that boots right into a user account without authentication leaves the data completely exposed" is WRONG
Note: This assertion is no longer true because of the underlying hardware and OS security. In this scenario, you will rely on a secure operating environment. Windows integrates closely with the OEM partners (hardware) to help ensure that all certified Windows systems deliver a secure operating environment (with available hardware capabilities).
- Before Windows starts, you must rely on security features implemented as part of the device hardware and firmware, including TPM and Secure Boot. The good thing is, newer devices have TPM and Secure Boot to mitigate these forms of attack.
- Even when physical attacks are perpetrated to install malware on the device in order to steal the BitLocker Keys, the TPM should see this installation via Platform Configuration Register (PCR) measurements, and the BitLocker key will not be released. This is the default configuration.
A Platform Configuration Register (PCR) is a memory location in the TPM that has some unique properties. The size of the value that can be stored in a PCR is determined by the size of a digest generated by an associated hashing algorithm.
Therefore, all forms of hardware attacks are mitigated, and the goal of BitLocker Drive Encryption is to protect your Drive against offline attacks through encryption, unauthorized access either by running a software attack tool against it or by transferring the computer’s hard disk to a different computer.
I hope you found this blog post helpful. If you have any questions, please let me know in the comment session.