What causes BitLocker Recovery Mode?

Sysadmins often ask us about BitLocker Recovery Mode. They have implemented BitLocker as their endpoint encryption solution which means that the IT service desk now has to issue recovery keys. Here’s where it gets complicated – the recovery keys are 25-digit hexadecimal numbers which are awkward to read, but also hear over a phone line.

This blog will look at the root causes of BitLocker Recovery Mode, and how your organization can mitigate the issue with self-service key recovery.

What is BitLocker Drive Encryption? 

Let’s start with an overview of BitLocker.  BitLocker Drive Encryption, which is commonly referred to simply as BitLocker, allows Windows users to encrypt hard drives in an effort to keep data secure. BitLocker has been a part of the Windows operating system since 2007 but Microsoft greatly enhanced BitLocker in Windows 10 version 1511, by introducing new encryption algorithms and making it possible to configure group policy settings separately for fixed data drives, removable data drives, and operating system drives.  

BitLocker authentication methods can trigger user lockouts. The most common authentication method is using the Trusted Protection Module (TPM), a microchip that is built into some laptops and desktops. It automatically decrypts hard drives on startup, without requiring the use of a PIN code, USB, or other form of authentication. This method does not require the user to do anything, and it is the least secure. 

Microsoft recommends using the TPM with a BitLocker PIN or startup key loaded on a USB to uplift security.  Both options require user interaction and can lead to lockouts in the event of a forgotten PIN, or lost USB. 

Authenticating to BitLocker

Let’s start with an overview of BitLocker authentication methods since they can trigger lockouts. The most common authentication method is using the Trusted Protection Module (TPM), a microchip that is built into some laptops and desktops. It automatically decrypts hard drives on startup, without requiring the use of a PIN code, USB, or other form of authentication. This method does not require the user to do anything, and it is the least secure.

Microsoft recommends using the TPM with a BitLocker PIN or startup key loaded on a USB to uplift security.  Both options require user interaction and can lead to lockouts in the event of a forgotten PIN, or lost USB.

Causes of BitLocker Recovery Mode

BitLocker Recovery Mode can occur for many reasons, including:

Authentication errors:

• Forgetting the PIN
• Entering incorrect PIN too many times (activating the anti-hammering logic of the TPM)
• Using a keyboard with a different layout that doesn’t enter the PIN correctly, or one that doesn’t map as assumed by the pre-boot environment
• Losing the USB flash drive containing the startup key

Boot/BIOS changes:

• Turning off BIOS support for reading USB devices in the pre-boot environment when using USB-based keys
• Changing the BIOS boot order to boot another drive ahead of the hard drive (such as giving a CD or DVD drive boot sequence priority)
• Upgrading critical early startup components such as BIOS upgrades
• Changes to the master boot record (MBR) on the disk
• Changes to the boot manager (bootmgr) on the disk
• Failing to boot from a network drive before booting from the hard drive
• Using a BIOS hot key during the boot process to change the boot order to something other than the hard drive

Hardware, software and firmware changes:

• Inserting or removing a CD/DVD
• Docking or undocking a portal computer if the computer was (respectively) undocked or docked when BitLocker was turned on
• Changes to NTFS partition table on the disk including: Creating, Deleting, Resizing primary partition
• Turning off, disabling, deactivating, or clearing the TPM
• Updating option ROM firmware
• Upgrading TPM firmware
• Adding or removing hardware
• Adding or removing add-in cards (such as video or network cards), or upgrading firmware on add-in cards

Other triggers:

• Modifying the Platform Configuration Registers (PCRs) used by the TPM validation profile
• Hiding the TPM from the operating system
• Moving the BitLocker-protected drive to a different system
• Upgrading the motherboard to a new one with a new TPM
• Failing the TPM self-test
• Having a BIOS or an option ROM component that is not compliant with the relevant Trusted Computing Group standards for a client computer
• Changing the usage authorization for the storage root key of the TPM to a non-zero value
• Disabling the code integrity check or enabling test signing on Windows Bootmgr
• Removing, inserting, or completely depleting the charge on a smart battery (portal computer)
• Pressing the F8 or F10 key during the boot process

What are PCR’s?

A lot of the above reasons are self-explanatory, but Modifying the Platform Configuration Registers (PCRs) is not always fully understood, or configured correctly. Basically, these settings tell the TPM chip what to check, during the power-on cycle, that the disk is still booting inside a valid machine that hasn’t been tampered. If the check completes, the TPM chip will release the keys to allow BitLocker to boot the encrypted disk.

When a machine is encrypted it stores the state of the BIOS/UEFI settings. Any changes to this state can cause the BitLocker recovery mode to kick in. This could be something as simple as choosing a different boot device at startup if not configured correctly based on the network requirements of your organization. E.g. if you normally boot from Hard Disk but need to boot from a CD/NIC/USB for some reason. 

In an enterprise environment the PCR settings are configured using Group Policy. For BIOS-based computers, you can find the settings here:

Computer Configuration>Polices>Administrative Templates>Windows Components > BitLocker Drive Encryption > Operating System Drives > Configure TPM platform validation profile for Bios-based firmware configurations

But don’t forget your UEFI based computers must be configured in a separate location as shown here:

Computer Configuration>Polices>Administrative Templates>Windows Components > BitLocker Drive Encryption > Operating System Drives > Configure TPM platform validation profile for native UEFI firmware configurations

If you are using MDOP MBAM to deploy and configure BitLocker, these settings can be found in the ADMX templates that are added as depicted below:

For BIOS-based settings there is a great blog post about them here:

For UEFI-based Computers, which tend to be more prevalent today. I’ll cover the PCR’s in more detail below. Microsoft recommends using PCRs 0, 2, 4 and 11. Note: PCR 11 must be enabled as this is specific to enabling BitLocker on the device.

• PCR 0: Core System Firmware Executable Code – Checks for changes to the code on the UEFI firmware – this includes Firmware Updates!
• PCR 1: Core System Firmware Data – Changes to usually static data (serial, model numbers), but also things like the amount of RAM and CPU type.
• PCR 2: Extended or pluggable executable code – Option ROM checking for external devices i.e. what’s plugged in during boot and is it valid/has it changed.
• PCR 3: Extended or pluggable firmware data – Option ROM static data i.e. optional hardware components such as network cards or firmware that might be used during the booting process.
• PCR 4: Boot Manager – Is your device likely to boot from the same device all the time. Do you push OS deployments from the network using PXE boot? Or has dual boot enabled? Then you might not want to enable this check.
• PCR 5: GPT/Partition Table – This will check for any changes to the Partition lists e.g. adding and removing partitions, resizing disks, etc.
• PCR 6: Resume from S4 and S5 power state events – Checks to see if the system has resumed from Hibernation(S4) or a Soft Off (S5).
• PCR 7: Secure Boot State – Has this changed or is this likely to change?
• PCR 8/9/10 and 16/17/18/19/20/21/22: Reserved for future use, not defined yet.
• PCR 11: BitLocker Access Control – this must be enabled.
• PCR 12/13/14/15: Looks for changes to the OS Kernel, File system, libraries, network connections etc.

What is BitLocker recovery key  

A BitLocker recovery key is a 48- digit numerical password used to unlock your BitLocker encrypted drive when BitLocker has triggered a lockout The key is generated during a BitLocker installation. 

Finding your BitLocker recovery key in Windows 10 

There are several places that your recovery key may be, depending on the choice that was made when activating BitLocker. These places can include: 

• Your Microsoft account: Sign into your Microsoft account from an unlocked device. If your primary device supports automated device encryption, the recovery key will likely be stored in your Microsoft account.
• A USB flash drive: If your recovery key was stored on a USB drive, simply plug the USB device into the locked computer and follow the instructions.
• A .txt file: If the recovery key was stored in a .txt file on a USB drive, plug the USB drive into an unlocked device to access the code.
• In Active Directory: If the locked device was ever signed into your organization account, the recovery key may be stored in your Active Directory account. While you may be able to access it on your own, contacting a system administrator may be necessary.

Self-service Key Recovery

Because there are so many lock out triggers that can cause a system to enter BitLocker recovery mode, it is important for organizations to have a  self-service encryption key recovery solution that users can use to unlock their devices without having to contact the helpdesk (especially since MBAM is no longer available). Given the highly sensitive nature of BitLocker keys, it is critical for such a solution to include a multi-factor authentication mechanism that requires the user to do more than just answer a question. Challenge / response-based authentication systems can be easy to fool and may become a point of vulnerability for the organization. 

Well that’s where our enterprise solution, Specops Key Recovery, comes in! When a user is prompted for a BitLocker recovery key, they can use the solution to prove their identity with multi-factor authentication (Google Authenticator, Duo Security, SMS, etc.) without having to call the service desk.

Using the information above you should be able to find a good balance between security and usability when deploying BitLocker to your organisation.