BitLocker

BitLocker Recovery Mode Guidance

Posted on Updated on

Created this BitLocker recovery guidance information for a client recently.  Not overly technical, but I thought it would be useful to share.

What to Do When BitLocker Recovery Mode Occurs

If a computer should be unexpectedly prompt the user for a recovery key, use following high-level steps to correct the system and help prevent future unnecessary BitLocker security trips.

  1. Obtain the recovery key from Active Directory and enter it into the prompt
  2. Login to Windows
  3. Suspend BitLocker protection. By suspending BitLocker, restarting Windows, and resuming BitLocker protection again, the TPM module will be resealed with the current PCR settings.  This will help prevent subsequent OS starts from prompting for BitLocker recovery mode.  Note that it is not necessary to decrypt and re-encrypt the drive
  4. Shutdown computer
  5. Boot into BIOS configuration and ensure that the hard disk is listed first in the boot order.  If not, make the appropriate change and the save the modifications
  6. Restart and login to Windows
  7. Resume BitLocker protection
  8. Restart Windows to ensure the recovery mode was not tripped

Possible Causes of BitLocker Recovery

This is additional information as provided by Microsoft to help isolate causes of BitLocker recovery.  It should be noted that integrity check failures are not a result the Windows 7 image.  Recovery mode being initiated is a sign of BitLocker successfully detecting and interpreting a possible threat. The following types of system changes can cause an integrity check failure and prevent the TPM from releasing the BitLocker key to decrypt the protected operating system drive.

  • Moving the BitLocker-protected drive into a new computer.
  • Installing a new motherboard with a new TPM.
  • Turning off, disabling, or clearing the TPM.
  • Changing any boot configuration settings.
  • Changing the BIOS, master boot record, boot sector, boot manager, option ROM, or other early boot components or boot configuration data.

This functionality is by design; BitLocker treats unauthorized modification of any of the early boot components as a potential attack and will place the system into recovery mode. Authorized administrators can update boot components without entering recovery mode by disabling BitLocker beforehand.

The following list provides examples of specific events that will cause BitLocker to enter recovery mode when attempting to start the operating system drive.  Microsoft’s full list has been reduced and categorized for ease of reading and potential scenarios that may occur.

Software changes

  • When you are installing additional language packs onto the system, and selecting the option to apply the language settings to all users and system accounts. This causes a locale change in the BCD (Boot Configuration Database), which BitLocker with TPM interprets as a boot attack.
  • Malicious software

BIOS changes

  • Changing the BIOS boot order to boot another drive in advance of the hard drive.  (e.g. the hard drive needs to be first in the boot order)
  • Having the CD or DVD drive before the hard drive in the BIOS boot order and then inserting or removing a CD or DVD.
  • Upgrading critical early startup components, such as a BIOS upgrade, causing the BIOS measurements to change without first suspending BitLocker protection.

Hard drive changes

  • Changes to the master boot record on the disk.
  • Changes to the boot manager on the disk.
  • Changes to the NTFS partition table on the disk including creating, deleting, or resizing a primary partition.
  • Changing any boot configuration data (BCD) boot entry data type settings

Other hardware changes

  • Docking or undocking a portable computer. In some instances (depending on the computer manufacturer and the BIOS), the docking condition of the portable computer is part of the system measurement and must be consistent to validate the system status and unlock BitLocker.
    • This means that if a portable computer is connected to its docking station when BitLocker is turned on, then it might also need to be connected to the docking station when it is unlocked.
    • Conversely, if a portable computer is not connected to its docking station when BitLocker is turned on, then it might need to be disconnected from the docking station when it is unlocked.
  • Adding or removing hardware. For example, inserting a new card in the computer, including some PCMCIA wireless cards.
  • Disabling the code integrity check or enabling test signing on Windows Boot Manager (Bootmgr).
  • Adding or removing add-in cards (such as video or network cards), or upgrading firmware on add-in cards.

Additional Guidance for BitLocker Recovery Troubleshooting

PCR configurations

  • A platform validation profile consists of a set of Platform Configuration Register (PCR) indices. Each PCR index is associated with components that run when Windows starts.
  • Current enabled PCRs via GPO (all defaults): 0, 2, 4, 5, 8, 9, 10, 11
  • Per a support forum thread: Dell Support recommended to shut off PCR 0 and 2 and test further. Please understand that this will further reduce security from the default configuration.
  • PCR 0 (recommend to disable and test): Core Root of Trust of Measurement (CRTM), BIOS, and Platform Extensions
  • PCR 2 (recommend to disable and test): Option ROM Code

Software changes

  • Document the software installations that are being completed manually.
  • Install software during encryption of the disk then restart Windows to determine if that caused a change.
  • When you are installing additional language packs onto the system, and selecting the option to apply the language settings to all users and system accounts. This causes a locale change in the BCD (Boot Configuration Database), which BitLocker with TPM interprets as a boot attack.
  • Note: if a PCR is tripped, it will be logged into system events, but not the specific PCR that changed.  Other events surrounding that registered change can be evaluated as a possible source.
  • Note: Windows Updates have built-in logic to not trip BitLocker into Recovery Mode.

BIOS / TPM

  • Ensure that the hard drive is first in the BIOS boot order. The reason for this is the boot device makes up part of the system measurement used by BitLocker and this must remain consistent to validate the system status and unlock BitLocker
  • Update or modify BIOS to a newer version only after suspending BitLocker protection.  Remember to resume protection after the changes.

Malicious software

  • Ensure AV is fully functional and up-to-date
  • Perform a full AV scan of the hard drive
  • Use additional 3rd party tools to perform a cross-scan for malware

BitLocker & BIOS Boot Order

Posted on Updated on

One of the “gotchas” of BitLocker security is that by not having the hard drive first in the boot order within BIOS, can cause BitLocker security to become enacted and thus needing manual entry of the 48-character key upon the next system restart.  This can be a frustration for users who have this happen to them, especially while travelling and unable to reach the help desk.  So, during an OS deployment, make efforts to change the boot order in BIOS.

To do this with HP

  • Obtain the BIOSConfigUtility in the Systems Software Manager
  • Create a text file named “BootOrder.REPSET”.  The text file contains the below content.  Note that I found it is necessary to define two devices to modify the boot order.
English
Boot Order
     Hard Drive(C:)
     Notebook Upgrade Bay
  • Run command
BiosConfigUtility.EXE /SetConfig:BootOrder.REPSET

To do this with Dell

cctk.exe bootorder --sequence=hdd

If you find yourself in a position that you did not do this during the initial deployment of the OS, never fear, SCCM is here!  Using task sequences, you can automate the process as to set the hard drive to be first in the boot order and re-seal the TPM by performing the following steps:

  1. Suspends BitLocker protection
  2. Reconfigure the boot order (for HP or Dell)
     
  3. Restarts Windows
  4. Resumes BitLocker protection

HP BIOSConfigUtility Command Line in a Task Sequence

Posted on

First, let me start by saying there is already a good blog post which outlines how to use HP’s BIOSConfigUtility in an MDT task sequence (which can be easily translated into an SCCM task sequence).

I recently implemented this tool for a client to enable the TPM feature in BIOS in preparation for BitLocker.  The utility was being run from a task sequence with command line such as:

cmd.exe /c c:\temp\BIOSConfigUtility.exe /SetConfig:TPMEnable.REPSET /NewAdminPassword:"P@55word!"

In my testing, the BIOS password was being set properly, but the TPM enable would not get enabled.  BIOSConfigUtility.exe would terminate with error code 10, which essentially meant it was trying to enable TPM but the provided password is incorrect.  What I found to fix the problem was to instead specify the full path to TPMEnable.REPSET file.  So instead, the switch would instead be:

/SetConfig:c:\temp\TPMEnable.REPSET