In my previous article, I explained 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 read it 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
When discussing the security aspect of Windows 10 devices, Bitlocker takes three different forms.
- Bitlocker Device Encryption
- Bitlocker Drive Encryption
- Bitlocker To Go
Continuing my previous post, I will focus on Bitlocker Device Encryption and how it is integrated seamlessly with Windows 10.
Getting to know Device Encryption (Bitlocker Automatic Encryption?)
Device Encryption is a lightweight version of Bitlocker, stripped of administrative capabilities and available across all Windows 10 SKUs.
As per the Microsoft article, from Windows 10 version 1703 onwards, devices that are
- and support Modern Standby (
S0 Low Power Idle ACPI Sleep State)
The 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 support 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 devices 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 algorithmto create theFVEKUsed space onlyencryption scheme for speed- TPM only as the authentication method for protecting the VMK
- The Recovery Key is escrowed to the online account (Microsoft account or Work Account) without prompting the end user.
Device Encryption in its default form is unmanageable – you cannot change the cypher strength or cypher 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 Windows 10 SKUs (Pro, Enterprise, and Education), you can use the tools mentioned above to add additional Key Protectors to the default TPM-only authentication used at startup to unlock the OS volume for added security (at the expense of some user experience!).
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 the 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 tell you why it 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 a 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 (cypher strength or cypher algorithm) unless a full decrypt and re-encrypt operation is performed. 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. A 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 be required 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 is not dependent on Intune (or any EMM/UEM products). It will still work even if auto-enrollment is not enabled.
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, this scenario will not prompt you to back up the Recovery Key. 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 the 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 must be ready with support for PCR 7 binding (Secure Boot must 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. 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 whether it is enabled.
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?
Some scenarios require Bitlocker to use stronger cypher 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 must be manually decrypted before a custom Bitlocker policy can be applied to the device.
This is shown as a warning note when configuring the Bitlocker policy in the Intune portal.
If you do not decrypt the volume before the 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-Bitlocker made Effortless – Part 2)
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 reduce administrative burden by ensuring that the Windows 10 devices are automatically encrypted and protected as they are provisioned without any administrative cost.
Well, that was all for today. In my next post on this series of #bitlockerunlockedwithjoy I will take you through Bitlocker Drive Encryption – the fully-featured Bitlocker with which we work as admins.
Till then, keep reading and keep learning!
Resources
- https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-bitlocker#bitlocker-automatic-device-encryption-hardware-requirements
- https://docs.microsoft.com/en-us/windows/security/information-protection/tpm/tpm-recommendations#tpm-and-windows-features
- https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/hardware-security-testability-specification
- https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-security#security-allowautomaticdeviceencryptionforazureadjoineddevices
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Joymalya Basu Roy is an experienced IT service professional with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He is awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site MDM Tech Space at https://joymalya.com
My laptop is Inspiron 15 3521. can I enable bitlocker or deviceencryption by any chance. OS- windows 10 home.
In security processor troubleshooting page I got error msg:
Device health attestation isn’t available
TPM storage is not available.
Under System information:”Device Encryption Support Reasons for failed automatic device encryption: TPM is not usable, PCR7 binding is not supported, Hardware Security Test Interface failed and device is not Modern Standby, Un-allowed DMA capable bus/device(s) detected, Disabled by policy, TPM is not usable”
I have update my Bios and other drivers from OEM website to the latest issued.
could you please help me to get the Bitlocker or device encryption facility?