Skip to main content


Configuring BitLocker for Tablets

Published: December 18, 2012

Author: Chris Hallum, Senior Product Manager

Ideally security works completely in the background, rarely making its presence known to the user. However, in the case of disk encryption solutions such as BitLocker and those from third parties, it often gets in our way. For the most part disk encryption solutions manage to do their work behind the scenes, but when devices are configured with pre-boot authentication you’ll find that security quickly moves into the foreground.

Those of you who are familiar with disk encryption solutions know that pre-boot authentication is a critical mitigation that is put in place to protect the encrypted volumes from certain types of attacks, however, many customers seem to have forgotten exactly which types of attacks they were trying to prevent. Consequently, many customers end up over deploying pre-boot authentication within their organizations which results in a diminished user experience and increases support costs (for example, a forgotten PIN).

So let’s start with a quick refresher on which types of attacks pre-boot authentication is designed to prevent. The short answer is “cold boot attacks” which enable an attacker who has physical access to the device to retrieve the encryption keys which are loaded into system memory when the device is booted. These keys can be accessed using a number of techniques including using a port with unauthenticated Direct Memory Access (for example, Firewire) to dump the system memory to an external device. Another example is taking advantage of data remanence properties of DRAM and SRAM which can enable system memory to remain readable for a short period of time after power has been removed. In this case an attacker could power off the device, remove the memory physically from the device, and potentially get access to the data on the memory chip using another device. To prevent these types of attacks, pre-boot authentication is used to prevent the keys from going into memory until an authorized user has been authenticated.

With the release of Windows 8, devices are going through a tremendous amount of change. Devices are increasingly being equipped with touch, sensors, etc. and we have new processor support (i.e., ARM, etc.). With all of this change going on, we took the opportunity to drive some new hardware improvements into the ecosystem. One of these improvements eliminates the need for pre-boot authentication in certain types of devices.

Many Windows 8 tablets and convertibles will be designed to adhere to a new architectural standard called Connected Standby. These devices are effectively always on, run in a low power state when not in use, have great battery life, and are similar to smart phones from a power management perspective. As part of the Connected Standby certification requirements we’ve added language that prevents the inclusion of Direct Memory Access (DMA) ports and system memory can’t easily be removed. These changes eliminate the requirement for implementing pre-boot authentication on Connected Standby certified devices.

When I talk to customers about Connected Standby devices they love the power management capabilities, and of course eliminating the need for pre-boot authentication is an attractive attribute as well. However, more than a few customers mention that pre-boot authentication also gave them the ability to mitigate the risks of brute force attacks on the Windows sign-in since the device’s TPM chip would lock the device if a brute force attack was detected during pre-boot. We actually anticipated this feedback and made a significant improvement in Windows sign-in’s brute force protection feature which previously just locked the applicable user accounts out. In Windows 8 when an attack is detected the device will immediately reboot and enter into BitLocker recovery mode which makes the device inaccessible but has the added benefit of leaving it in a recoverable state if it is ever retrieved. To take advantage of this functionality Administrators can set the “Interactive logon: Machine account lockout threshold” Group Policy under \Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options, or use the MaxFailedPasswordAttempts policy of Exchange ActiveSync, to limit the number of failed password attempts before the device goes into Device Lockout.

In the end, we are really excited about the improvements that we’ve made that will benefits users and reduce costs, while at the same time maintaining, and in some cases, increasing overall security. We hope that you find this information helpful as you define your Windows 8 deployment plans and consider new device types in the future.

About the Author

Chris Hallum photoChris Hallum is a Senior Product Manager focusing on Windows Client Security for commercial business scenarios. He has been at Microsoft for fifteen years and has worked in a number of engineering roles as a Program Manager within the Server and Tools Division (for example, Windows Scripting, System Center Operations Manager, Microsoft BitLocker Administration and Monitoring).

Chris recently moved into Product Management where he now manages all security features (malware resistance, data protection, and identity and access control) within the Windows Client operating system.

Microsoft Security Newsletter

Sign up for a free monthly roundup of security news, bulletins, and guidance for IT pros and developers.