Protect Verification Key for BitLocker Encryption

BitLocker drive encryption is a data protection feature available on Windows devices. The data stored on a BitLocker-encrypted device becomes inaccessible even when the device is decommissioned or recycled. Therefore, enabling BitLocker on a device ensures that the data is safe from unauthorized access. When used in conjunction with TPM versions 1.2 and above, BitLocker encryption provides maximum protection.

When a drive is encrypted using BitLocker, a BitLocker recovery key (encryption key) that can be used to access encrypted data is also generated. The recovery key is stored as plaintext on the device if no key protector is assigned. A key protector is an authentication method that prevents storing the volume encryption key as plaintext on the device. It can be a PIN or a USB drive containing the key. BitLocker uses this key protector to retrieve the encryption key that reads data from the encrypted drive. This document helps the admin on how to protect the recovery key of a BitLocker-encrypted device.

BitLocker Encryption Status

Admins can monitor the encryption status of a remote Windows device through the Device Summary page of the target device on the portal. Note that the BitLocker encryption status can be verified even if the BitLocker is enabled manually. The BitLocker encryption status of a device takes either of the following forms:

1. N/A – BitLocker encryption is not supported on this device.
2. Encrypted – The encryption of the volume is completed.
3. Encryption in progress – BitLocker encryption has started and is ongoing.
4. Encryption paused – The encryption of the specified volume is paused.
5. Not encrypted – The device is not BitLocker encrypted at the moment.
6. Decryption in progress – The decryption of the specified volume is ongoing.
7. Decryption paused – The decryption of the specified volume is paused.
8. Status unknown – The volume protection status cannot be determined. This can be caused by the volume being in a locked state.
9. Encrypted but unprotected – Encryption is complete, but the volume encryption key used to unlock the drive is unprotected and openly available on the hard disk.

Encryption is completed but the verification key is unprotected

The BitLocker encryption status Encrypted but unprotected denotes that the volume encryption is complete, but the volume encryption key is stored as plain text on the device without any protection. As a result, the encryption key is vulnerable to unauthorized access and can be used to read encrypted data on the drive.

Follow these steps to protect and store the encryption key,

1. Setup key protectors using the BitLocker policy from the Hexnode console.

   Admins can configure key protectors through the BitLocker policy settings by navigating to Policies > New Policy > New Blank Policy > Windows > BitLocker. Within the BitLocker settings, enable the Configure BitLocker OS drive policy under OS Drive Settings. Additionally, ensure that the checkbox corresponding to Configure additional startup authentication settings is selected to activate the relevant authentication options. You can use the following authentication methods to protect the encryption key.

   • Allow BitLocker to be activated on devices without a compatible TPM
   • Authenticate with TPM Startup
   • Authenticate with Startup Key
   • Authenticate with Startup PIN



2. Backup the recovery key from the device.

   You can back up the recovery key on the Windows device by following these steps,

   1. Type Manage BitLocker in the search box in the Start menu.
   2. Next, scroll down to the encrypted drive section and click on Turn on BitLocker.

   

   3. In this step, the user will be prompted to set up a key protector. The user can choose from any of the key protectors that are enabled in the BitLocker policy. The selected key protector containing the recovery key will be used in the future to decrypt the drive.
   4. Back up the recovery key using any of the methods provided below,
      1. Save to your Microsoft account – This method requires the user to be signed into a Microsoft account to store the recovery key to the specified account.
      2. Save to a file – Choosing this option allows you to save the recovery to a drive that is not encrypted or a removable device.
      3. Print the recovery key – This option allows the user to print the recovery key on paper.
   5. Complete the setup assistant to back up the recovery key. The BitLocker encryption will be completed after this step, and the encryption status in the portal will be changed to Encrypted.

Frequently Asked Questions(FAQs)

1. Where can the admin view the recovery passwords escrowed to the portal?

The admin can access the BitLocker recovery password by navigating to the Manage tab, selecting the target device, and viewing the Hardware Info sub-tab under Device Summary.

2. Can the admin refresh or change a recovery key that has already been exposed?

Yes. The admin can utilize the Rotate BitLocker Recovery Password remote action from the Actions > Security menu. This action invalidates the current recovery password and generates a new one, which is then securely synchronized and updated within the Hexnode portal.

3. Can the admin manage BitLocker on Windows Home edition devices?

No. BitLocker is a native feature restricted to Pro, Enterprise, and Education editions of Windows. The admin will observe an encryption status of N/A for devices running the Home edition, as the operating system lacks the support for full-disk encryption.

Troubleshooting

1. Error: ‘Unable to turn on BitLocker as the system cannot find the file specified.’

Probable Cause:

The Windows Recovery Environment (WinRE) is misconfigured, or the REAgent.xml file is corrupted, preventing the BitLocker provisioning process from locating necessary system files.

Solution:

The admin should reset the REAgent.xml file on the device. This is achieved by navigating to C:\Windows\System32\Recovery, renaming the REAgent.xml file to REAgent.old, and then re-associating the BitLocker policy from the Hexnode portal.

Best Practices

• Suspend Prior to Maintenance: The admin should instruct users or automate a process to suspend BitLocker protection before performing BIOS, firmware, or significant hardware updates to prevent the device from entering a recovery loop.
• Pilot Group Deployment: It is recommended that the admin deploy BitLocker policies to a small pilot group of devices first. This allows the admin to identify hardware-specific issues or BIOS incompatibilities before a large-scale rollout.
• Avoid Overlapping Protectors: The admin should avoid configuring both a Startup Key and a Startup PIN for the same drive unless required by strict compliance mandates, as managing multiple physical and numerical protectors increases complexity for both the user and the support team.