Hardware Encryption, Secure Boot, and Network Unlock
Windows 8 and Windows Server 2012 add a number of BitLocker-related
enhancements. Most of these enhancements are controlled with the
Administrative Templates policies for Computer Configuration under
Windows Components\BitLocker Drive Encryption and will be discussed in this section.
Windows 8 adds support for disk drives with hardware encryption (referred to as encrypted hard drives).
Encryption in hardware is faster and moves the processing burden from
the computer’s processor to the hardware processor on the hard disk. By
default, if a computer has hardware encryption, Windows 8 will use it
with BitLocker.
In Group Policy, you can precisely control whether to permit
software-based encryption when hardware encryption is not available and
whether to restrict encryption to those algorithms and cipher strengths
supported by hardware. Do this by enabling the Configure Use Of
Hardware-Based Encryption
For Fixed Data Drives policy and configuring the related options. When
the policy is enabled, you must specifically allow software-based encryption when hardware-based encryption isn’t available.
Note
MORE INFO The Choose Drive
Encryption Method And Cipher Strength policy doesn’t apply to
hardware-based encryption. Under Fixed Data Drives, the Configure Use
Of Hardware-Based Encryption For Fixed Data Drives policy sets the
desired encryption methods for hardware-based policy. With
hardware-based encryption, the encryption algorithm is set when the
drive is partitioned.
Next, you might want to configure policy to control the permitted
encryption types. Windows 8 allows users to encrypt full volumes or
used space only. Encrypting full volumes takes longer, but it is more
secure as the entire volume is protected. Encrypting used space
protects only the portion of the drive used to store data. By default,
either option can be used. If you want to allow only one type or the
other, enable and configure related Enforce Drive Encryption Type
policy for BitLocker.
There are separate Enforce Drive Encryption Type policies for the
operating system, fixed data, and removable data drives.
Note
In high-security
environments, you will want to encrypt entire volumes. At the time of
this writing, and unless fixed with a future update or service pack,
deleted files appear as free space when you encrypt used space only. As
a result, until the files are wiped or overwritten, information in the
files could be recovered with certain tools.
Operating system drives are handled as special cases. Windows 8 allows you to pre-provision BitLocker so that you can turn on encryption prior to installation. Windows 8 also can be configured to do the following:
-
Require
additional authentication at startup. If you enable and configure the
related policy, Require Additional Authentication At Startup, user
input is required, even if the platform lacks a pre-boot input
capability. To allow a USB keyboard to be used on such a platform in the pre-boot environment, you should set the Enable Use Of BitLocker Authentication Requiring Preboot Keyboard Input On Slates policy to Enabled.
-
Allow secure boot for integrity validation. Secure
boot is used by default to verify boot configuration data (BCD)
settings according to the TPM validation profile settings (also
referred to as Secure Boot policy). When you use secure
boot, the settings of the Use Enhanced Boot Configuration Data
Validation Profile policy are ignored (unless you specifically disable secure boot support by setting Allow Secure Boot For Integrity Validation to Disabled).
You set TPM validation profile settings by platform. For BIOS-based
firmware, you use the Configure TPM Platform Validation Profile For
BIOS-Based Firmware Configurations policy. For Unified Extensible
Firmware Interface (UEFI)–based firmware, you use the Configure TPM
Platform Validation Profile For Native UEFI Firmware Configurations
policy. When you enable these policies, you specify exactly which
platform configuration registers to validate during boot (see Figure 1).
For BIOS-based firmware, Microsoft recommends validating Platform
Configuration Registers (PCRs) 0, 2, 4, 8, 9, 10, and 11. For UEFI
firmware, Microsoft recommends validating PCRs 0, 2, 4, 7, and 11. In
both instances, PCR 11 validation is required for BitLocker protection to be enforced. PCR 7 validation is required to support secure boot with UEFI (and you’ll need to enable this by selecting the related option).
When you protect a computer with BitLocker,
you can require additional authentication at startup. Normally, this
means a user is required to have a startup key on a USB flash drive, a startup PIN, or both. The Network
Unlock feature provides this additional layer of protection without
requiring the startup key, startup PIN, or both by automatically
unlocking the operating system drive when a computer is started,
provided that:
-
The BitLocker-protected computer must have an enabled TPM.
-
The computer must be on a trusted, wired network.
-
The computer must be joined to and connected to a domain.
-
A Network Unlock server with an appropriate Network Unlock certificate is available.
Because the computer must be joined to and connected to the domain
for network unlock to work, user authentication is still required when
a computer is not connected to the domain. When connected to the
domain, the client computer connects to a Network
Unlock server to unlock the system drive. Typically, the Network Unlock
server is a domain controller configured to use and distribute Network
Unlock certificates to clients. The Network Unlock certificates in turn
are used to create the network unlock keys.
You can configure a domain controller to distribute this certificate
to clients. To do this, create an X.509 certificate for the server, for
example using Certmsg.mc, then use the BitLocker
Driver Encryption Network Unlock Certificate setting to add this
certificate to a GPO applied to the domain controller. You’ll find this
Computer Configuration setting under Windows Settings\Security
Settings\Public Key Policies.
Finally, Windows 8 also allows you to provision BitLocker
during operating system deployment. You can do this from the Windows
Pre-Installation Environment (WinPE). It’s important to point out that
Windows PowerShell includes a DISM module that you can import. As this
module doesn’t support wildcards when searching for feature names, you
can use the Get-WindowsOptionalFeatures cmdlet to list feature names,
as shown in this example:
get-windowsoptionalfeatures -online | ft
To completely install BitLocker and related management tools, use the following command:
enable-windowsoptionalfeature -online -featurename bitlocker,
bitlocker-utilities, bitlocker-networkunlock -all
