Device Encryption – Bitlocker made Effortless – Part 2

In my previous article, I tried to explain the working mechanism of Bitlocker encryption, the internal OS components involved, and most importantly – why it is necessary and how it helps secure the OS platform from cold boot attacks. I would urge you to give it a read here if you have not seen it yet.

Related Posts

• Part 1 – Bitlocker Unlocked with Joy – Behind the Scenes Windows 10
• Part 2 – Device Encryption – Bitlocker made Effortlessly
• Part 3 – Deciphering Intune’s Scope w.r.t Bitlocker Drive Encryption
• Part 4 – Intune and Silent Encryption – A Deeper Dive to Explore the Internal

Introduction

When we talk about the security aspect of Windows 10 devices, Bitlocker presents itself in three different forms, namely.

• Bitlocker Device Encryption
• Bitlocker Drive Encryption
• Bitlocker To Go

A continuation of my previous post, today in this post, I will be focusing on Bitlocker Device Encryption and how it is integrated as a seamless experience with Windows 10.

Getting to know Device Encryption… (Bitlocker Automatic Encryption?)

Device Encryption is a lightweight version of Bitlocker, stripped-down of the administrative capabilities and available across all Windows 10 SKU.

As per the Microsoft article, from Windows 10 version 1703 onwards, devices that are

• HSTI compliant

• and support Modern Standby (S0 Low Power Idle ACPI Sleep State)

Device Encryption feature triggers Bitlocker Encryption for the OS volume and fixed Data drive (if found any) out of the box, as end-users complete the device initialization through the 1st boot setup experience (OOBE).

Device Encryption – ensuring protection with zero administrative cost involved

The encryption gets triggered when you are presented with the First Sign-In Animation (FSIA) screen.

An anomaly to the Device Encryption requirement I discovered…

I checked using a Dell E7270 laptop which is HSTI compliant (the above HSTI test result is a snap from that laptop) but does not have support for S0 low power idle sleep state modern standby.

Surprisingly, System Information (msinfo32) showed that the device meets the prerequisites for Device Encryption.

So cannot confirm if Modern Standby is a legitimate requirement anymore or not. I could not find any Microsoft document stating the change in conditions.

In reality, I have seen Device Encryption working on the device running Windows 10 version 1803 onwards, without support for Modern Standby. (HSTI compliance is still required, though!)

Device Encryption settings – Cipher strength and Key Protector

Device Encryption uses the default Bitlocker settings –

• 128 bit AES-XTS algorithm to create the FVEK
• Used space only encryption scheme for speed
• TPM only as of the authentication method for protecting the VMK
• Recovery Key is escrowed to the online account (Microsoft account or Work Account) without any prompts to the end-user.

Device Encryption in its default form is unmanageable – you cannot change the cipher strength or cipher algorithm.

The device Encryption feature of Windows 10 does not require any administrative overhead, like deploying a Bitlocker policy from AD (via GPO) or Intune (any MDM solution as such).

Since Windows 10 Home SKU does not come with the standard Bitlocker Drive Encryption features, you do not have the Bitlocker GUI tool (Control Panel) or the manage-bde command-line tool available.

However, for other SKU of Windows 10 (Pro, Enterprise, and Education), you can add additional Key Protectors to the default TPM-only authentication used at startup to unlock OS volume for added security (at the expense of some user experience!) using the tools as mentioned above.

The tool behind Device Encryption

BitlockerDeviceEncryption.exe found at C:\Windows\System32 is essentially what gets triggered during the FSIA if the device meets all the required criteria of Device Encryption.

How does it work? Automatic Device Encryption…

If you have used a Microsoft Account or a Work Account to join the device to Azure AD, during the OOBE setup, Windows 10 will automatically trigger Bitlocker Device Encryption if the device meets the criteria (HSTI compliant with Modern Standby (?) support).

It is the same story in the background.

• Disk sectors are encrypted using the FVEK (128-bit AES-XTS)
• The FVEK gets protected using the VMK (256 bit AES-CCM)
• The VMK is protected using TPM (TPM EK Cert + SHA measurement of PCR 7,11)
• The recovery Key generated is backed up against the online account (Microsoft Account or Azure AD for Work Account)

A simple check to know if your device supports Device Encryption?

Open System Information (msinfo32) with admin rights and check for the highlighted item

If your system meets the prerequisites of Device Encryption, check encryption status using the command-line tool. manage-bde (for Pro, Enterprise, or Education SKU only)

As you can see in the above snap, it shows that my device is standalone
workstation (not joined to local domain or Azure AD) and there is no local 
Group Policy applied as well. Still encryption status shows protection is ON.

Since Windows 10 Home edition does not come with any Bitlocker Administration interface, the way to check is by using the Windows Settings menu (Settings > Update & Security > Device Encryption)

If your device does not meet the hardware prescriptions, the System Information page will show you why the device failed automatic encryption.

Complete list of reasons for which a device can fail Device Encryption

• TPM is not available,
• TPM is not usable.
• PCR7 binding is not supported,
• Hardware Security Test Interface failed,
• The device is not Modern Standby,
• Un-allowed DMA capable bus/device(s) detected

If you see any of this in msinfo32 against the Device Encryption Support, your device will not get automatically encrypted.

Device Encryption Events to check…

For a device meeting, the prerequisites post completing the initial device setup as part of the guided experience (OOBE), open Event Viewer and navigate to Applications and Services Logs > Microsoft > Windows > Bitlocker-API > Management

You will see the below events for successful automatic encryption.

Event 768 Bitlocker encryption was started for volume C: using 
XTS-AES 128 algorithm  

Event 775 A Bitlocker key protector was created 

Event 828 Bitlocker Drive Encryption recovery information for volume C: 
was backed up successfully to your Microsoft Account

Event 817 Bitlocker successfully sealed a key to the TPM

Ways of getting the Recovery Key

Users can easily get access to the Recovery Key via

• for Microsoft Account, sign-in to https://aka.ms/myrecoverykey from another device to get the recovery key

• for a Work Account, sign in to https://account.activedirectory.windowsazure.com/ from another device and navigate to Profile > Devices > Select the device > Get Bitlocker keys

What if you create a Local Account during the initial setup? (Bitlocker Automatic Encryption…)

Suppose you have made a Local Account instead of using a Microsoft Account or a Work Account to sign in during the OOBE setup, even though Device Encryption will trigger the encryption process. In that case, it won’t create the key protectors (seal VMK to TPM and start the Recovery Key).

The protection status will show as Off, but notice that the volume is encrypted (used space only as default).

If you go and check Device Encryption from the Windows Settings menu, you will see that it requires you to sign in with a Microsoft account to finish the encryption.

The VMK at this stage is protected with a Clear Key. (It is not sealed to TPM yet)

Clear Key is an unprotected 256-bit AES key which gets created when there 
is no other VMK protector present. It is stored on the volume as RAW data 
along with the VMK in the FVE Metadata block to decrypt the VMK. 
In such a scenario, even though the drive (volume) is encrypted, but it 
will be freely accessible. The Clear Key gets removed as the VMK gets 
protected with the new protectors.

NOTE: The generated FVEK is constant for a particular initialization and cannot be removed or modified (cipher strength or cipher algorithm) unless a full decrypt and re-encrypt operation. This is true for the VMK as well.

As you change the Account type from Local Account and sign in with a Microsoft Account

Device Encryption will remove the Clear Key and seal the VMK to TPM. Recovery Key is also generated as part of the process and escrowed to the online Microsoft Account.

Requires you to sign out of your current user profile and sign in using the Microsoft Account !!!

What will happen if you connect your Work Account to register (not Azure AD join) the device to Azure AD instead of changing your Local Account to a Microsoft Account?

As you set up a Work Account to register the device to your organization’s Azure AD tenant

You would require to sign out and sign-in back (Important!) for Device Encryption to complete the process of creating the key protectors and resuming protection.

Device Encryption has no dependency on Intune (or any EMM/UEM products). Even if you do not have auto-enrollment enabled, it will still work.

NOTE: For AAD join/AAD register with auto-enrollment enabled, if your organization has a Bitlocker policy deployed from a device management service with a different cipher strength and encryption algorithm, that policy will always remain a failure state. (Explained more in the last part of this post). However, if it matches the Bitlocker default settings, it will show success.

What if you switch back to a Local Account?

This can be true for only two scenarios that I can think of.

For Windows 10 Home SKU

You initially signed in with a Microsoft Account. Still, you later decided to use a local account instead (something that Microsoft won’t certainly want you to as Windows 10 benefits from a connected experience).

You will get the below prompt to save the Recovery Key for later use in such a case. This is important because post switching to a local account, Device Encryption will not be paused but will continue to be effective 🙂

Why backing up the Recovery Key is important in this scenario? 

If you are using Windows 10 Home SKU, then post account switch, you will
not have the usual Bitlocker management tools in the OS to take the backup 
of the Recovery Key. 

Under such scenario, if your device enters recovery mode during restart 
or cold boot due to any changes made, you have no way to get the data back
from the drive volume by yourself.

For Windows 10 Pro, Enterprise, and Education SKU

You have created a local account initially and then work registered your device. But post leaving the organization, you disconnect the Work Account and continue using the local account.

Sadly, you will not get a prompt to back up the Recovery Key in this scenario. But since Device Encryption will continue to protect the drive, it is important that you either turn it off (not recommended even for personal devices) or backup using the Bitlocker management tool from Control Panel or the manage-bde command-line tool.

Yes, since Work Account is only possible in Pro, Enterprise, or Education SKU, it will also have the full Bitlocker capabilities, unlike the Home SKU.

Device Encryption Error Scenario (Bitlocker Automatic Encryption failed?)

The only thing that can cause an error in Device Encryption is the security chip on your device – TPM

TPM needs to be ready with support for PCR 7 binding (Secure Boot needs to be enabled in UEFI) and key attestation.

But this is a Dell E7270 model, which I know is HSTI compliant as I have tested it many times. And it is certainly not possible that TPM is disabled in UEFI settings as this system has Secure Boot enabled. But still, it shows TPMPresent as False.

As I checked, I found the TPM option itself went missing in UEFI settings. I checked the Dell Support site and got a match for my issue. The fix was a firmware update, and TPM came back to life.

Always keep the device firmware and chipset drivers updated as made available by the OEM. The updates are made available for a purpose 😉

If you get errors related to TPM and you know your device has TPM 2.0, confirm in UEFI if the same is enabled or not.

Bitlocker Device Encryption does not support TPM 2.0 in Legacy and CSM Modes of the BIOS. Devices with TPM 2.0 must have their BIOS mode configured as Native UEFI only. Also, Secure Boot needs to be enabled as it will use PCR 7 measurement value for the binding operation.

How to stop Automatic Encryption?

There may be scenarios requiring Bitlocker to use stronger cipher strength (256-bit key instead of 128-bit) or a different encryption algorithm (AES-CBC instead of AES-XTS).

In such cases, Bitlocker Device Encryption can be a pain. Once automatic encryption is triggered, the volume needs to be manually decrypted before a custom Bitlocker policy can be applied to the device.

This is shown as a warning note when you configure the Bitlocker policy in the Intune portal.

If you do not decrypt the volume before custom Bitlocker policy deployment, the policy will always result in a failure state.

If you wish, you can disable Device Encryption by using Command Prompt (Shift + F10) during the initial phases of OOBE to make the necessary changes to the registry

• Key Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLocker
• Subkey: PreventDeviceEncryption
• Value: 1 (True)
• Type: REG_DWORD

Just a few days back, the same was achieved via Intune by deploying a custom OMA-URI profile (if you are doing AADJ from OOBE and have a different Bitlocker policy configured) since this is not available via native UI.

Name: PreventAutomaticDeviceEncryptionForAzureADJoinedDevices
OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Security/PreventAutomaticDeviceEncryptionForAzureADJoinedDevices
Data Type: Integer
Value: 1 

But as of today, Intune has introduced native UI settings to control the automatic encryption behavior on the devices.

Conclusion

Device Encryption is a good feature, especially for Windows 10 Home edition devices, since this version does not get the standard Bitlocker toolset for a user to encrypt the device manually.

For Enterprise, if all devices are HSTI compliant in your environment, it helps to reduce administrative burden by ensuring that the Windows 10 devices are automatically encrypted and protected as they are provisioned without any administrative cost involved.

Well, that was all for today. In my next post on this series of #bitlockerunlockedwithjoy I will be taking you through Bitlocker Drive Encryption – the fully-featured Bitlocker with which we as admins work.

Till then, keep reading, keep learning!

Resources

1. https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-bitlocker#bitlocker-automatic-device-encryption-hardware-requirements 
2. https://docs.microsoft.com/en-us/windows/security/information-protection/tpm/tpm-recommendations#tpm-and-windows-features
3. https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/hardware-security-testability-specification
4. https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-security#security-allowautomaticdeviceencryptionforazureadjoineddevices