4.3 Setting permitted encryption types
Windows Server allows users to encrypt full volumes or
used space only. Encrypting full volumes takes longer, but it is more
secure because 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. To allow only one type or the other, you can enable and configure the
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. Figure 13 shows the
policy for operating system drives. Here, after you select Enabled
to enable the policy, you set the encryption type to either Full
Encryption or Used Space Only Encryption.
Important
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.
4.4 Preparing BitLocker for startup authentication and secure
boot
Windows allows you to pre-provision BitLocker so that you can
turn on encryption prior to installation. Windows 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 preboot input capability. To allow
a USB keyboard to be used on such a platform in the preboot
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
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.
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 need to enable this by
selecting the related option). Figure14 shows an example platform
validation-profile configuration.
