Because EFS has been enhanced considerably
with Windows Vista, and because you use EFS with smart cards, you may
not need to run BitLocker Full Drive Encryption on your mobile systems.
The basic difference between BitLocker and EFS is that EFS only
encrypts the user's data on the mobile system. BitLocker encrypts the
entire system drive including the operating system as well as all data
for all users of the system.
NOTE
Only
two Windows Vista editions support BitLocker: Enterprise and Ultimate.
Keep this in mind if you decide to use BitLocker. All business editions
of Vista support EFS.
The
difference between BitLocker and EFS also extends to the way you put
them in place. EFS is an extension of your data protection strategy and
can be added once your systems are deployed. BitLocker, on the other
hand, must be implemented during the installation of the operating
system and cannot be added afterwards unless you have made specific
preparations beforehand. This is because BitLocker requires two
partitions: one small partition is used to begin the system boot
process and the other is encrypted and will contain the entire OS (see Figure 1).
NOTE
BitLocker
protects the entire contents of a system drive and therefore provides
more protection than EFS does. This is because a malicious user that
gains access to a system running EFS could eventually gain access to
the files it contains through a brute force attack to obtain the user's
password. Because EFS only protects data and not the entire system
drive, the attacker gains access to system folders and can try to
obtain the user's password from there. Two mechanisms can protect
against this: using smart cards to remove the encryption certificate
from the PC and using long and complex passwords. Most brute force
tools today will have difficulty with passwords longer than 11
characters.
Most
often, you will deploy BitLocker on systems that include a Trusted
Protection Module (TMP) version 1.2. The TPM is a special microchip
that is used to securely store decryption keys and user passwords. If
you decide to deploy BitLocker on systems that do not include a TPM,
then you will need to rely on external storage for the encryption keys,
much like you would rely on a smart card for EFS encryption keys. This
method is less secure than when using a TPM because even though the TPM
is included in the PC, it cannot be tampered with. If, as with EFS,
users leave a USB Key that includes the decryption keys within their
computer bag, then their system will not be fully protected.
Because
of this, you usually decide to deploy BitLocker when you build your
systems. Both of the partitions you create must be primary partitions.
Usually, 2GB is sufficient for the unencrypted boot partition while you
assign the rest to the OS partition. The 2GB boot partition must be set
as active so that it can launch the boot process.
NOTE
The
Windows Recovery Environment (WinRE) also relies on two partitions: the
first partition stores the recovery environment and the second stores
the OS. Using two partitions for WinRE lets you recover broken system
disks without having to resort to installation media. If you choose to
combine BitLocker and WinRE, then you should store WinRE on the same
partition as the OS. If not, the WinRE partition will not be encrypted
and may become a security risk. Keep in mind however, that your
technicians will need a different method of accessing WinRE in order to
recover lost BitLocker partitions.
When you plan to deploy BitLocker, you'll have a couple of choices for installation:
You
can deploy BitLocker during the PC build process, using custom
preconfigured BitLocker images. These images can be deployed with
Windows Deployment Services or through unattended installations. Once
the image is deployed, you rely on a Windows Management Instrumentation
(WMI) script to enable BitLocker.
You
deploy a standard PC build using two partitions. Then once the
installation is complete, you either rely on a WMI script or the
built-in manage-bde.wsf script to enable BitLocker.
Each process requires preparation beforehand so that your build process will support the creation of two partitions.
1. Understanding BitLocker requirements
Deploying
BitLocker in your environment is not a menial task. In fact, you must
seriously consider the need for BitLocker before you put it in place.
When in use, BitLocker requires a special encryption key mechanism.
Then, this key protection mechanism is linked with the authentication
method you've decided to implement to support system startup. Table 1
outlines the various protection mechanisms you can use with BitLocker.
These mechanisms are used whenever the system boots from either a
complete shutdown or from hibernation. Table 2 lists the authentication methods BitLocker supports.
Table 1. BitLocker Protection Mechanisms
| Key Protection Mechanism | Comment |
|---|
| TPM 1.2 Microchip | The Trusted Protection Module is a special chip that securely stores the BitLocker encryption key. |
| Personal Identification Number (PIN) | This is a numeric value that is used in conjunction with the TPM to unlock the system. |
| Startup Key on Removable Media | The
encryption key can also be stored on removable media. This includes USB
keys, removable disk drives, and floppy disks. Obviously, the most
practical media for this is the USB key. Startup Keys can be used with
or without TPM chips. |
| Recovery Password | The
Recovery Password is used to recover a BitLocker installation. This is
a 48-digit number that is entered after the administrator presses the
F1 and F10 keys during system startup. |
| Recovery Key | The Recovery Key is an encrypted file that can also be used to recover a BitLocker installation. |
Table 2. BitLocker Authentication Mechanisms
| Authentication Mechanism | Comment |
|---|
| TPM Alone | The TPM itself validates the boot process. No user interaction is required. |
| TPM and PIN | The TPM validates the boot process, but the user must enter a PIN before the process can complete. |
| TPM and Startup Key | The TPM validates the boot process, but the user must insert the Startup Key for the process to complete. |
| Startup Key Alone | No TPM is used. The user must insert the Startup Key before the boot process can complete. |
As
you can see, using BitLocker implies some changes to the processes you
use to manage systems. Of all of the authentication mechanisms you can
use with BitLocker, only the first listed in Table 2
does not require user interaction to boot. Of course, this level of
authentication does not offer very much protection because the system
opens by default. All of the other mechanisms require user input.
Therefore, if you deploy updates to your systems and they require
reboots, all systems using comprehensive BitLocker protection will fail
during this boot process and will be in a locked state until the user
returns. This leaves much to be desired as a remote management
mechanism.
