1. BitLocker: deep details, improvements and benifits
Sudhir Rao
Technology Specialist
Microsoft Corporation

2. Agenda BitLocker Drive Encryption Overview Deployment Planning
Recovery, Threats, and Mitigation
Deployment Planning
Deployment Scenarios
WMI Management Interfaces and Tools
Group Policy and Recovery
Maintaining BitLocker Systems
Things to Consider
Additional Resources

3. BitLocker Drive Encryption Overview

4. BitLocker™ Drive Encryption
BitLocker Drive Encryption fully encrypts the entire Windows Vista volume.
Enhanced in Windows Vista SP1 and Windows Server 2008 to provide multi-volume/drive protection!
Designed specifically to prevent the unauthorized disclosure of data when it is at rest.
Provides data protection on your Windows client systems, even when the system is in unauthorized hands.
Designed to utilize a v1.2 Trusted Platform Module (TPM) for secure key storage and boot environment authentication
BitLocker

5. What Is A Trusted Platform Module (TPM)?
Smartcard-like module on the motherboard
Protects secrets
TPM is made up of a set of entry points called PCR’s. Holds Platform Measurements (hashes).
Performs cryptographic functions
RSA, SHA-1, RNG
Creates, stores and manages keys
Provides a unique Endorsement Key (EK)
Provides a unique Storage Root Key (SRK)
Anchors chain of trust for keys and credentials
Protects itself against attacks
TPM is made up of a set of entry points called PCR’s. These PCR’s are used to store information that builds what is called the Core Root of Trust Measurement.
EK is a key applied by the manufacturer, VAR, or OEM. Infineon TPM’s are manufactured with an EK in place. Broadcom TPM’s do not ship with an EK in place. This service can be provided by your OEM or VAR but this is dependant on the PC manufacturer. If your machine do not have EK’s you can create one using the TPM WMI provider however this is not the recommended method. The EK that is placed on the TPM should be managed by and organization that can guarantee it uniqueness and that is was applied in a secure environment.
TPM has built in protection for dictionary attacks using anti-hammering technology.
TPM 1.2 spec:

6. BitLocker™ Partition Layout
Disk partition requirements for BitLocker are unique make sure you consider this from the beginning of your deployment design.
Two partitions are required.
System Partition (Primary, NTFS, Active, 1.5Gb, Type 7)
Why so large? – The minimum partition size recommendation was made for the following reasons:
BitLocker requires 50mb of space
WinRE requires 550mb of space
Servicing requires 900mb of space
OS Partition (Primary, NTFS, Type 7, Any size)

7. Encryption Key Storage
OS Volume Contains:
Encrypted OS
Encrypted Page File
Encrypted Temp Files
Encrypted Data
Encrypted Hibernation File
Where’s the Encryption Key?
SRK (Storage Root Key) contained in TPM
SRK encrypts FVEK (Full Volume Encryption Key) protected by TPM/PIN/USB Storage Device
FVEK stored (encrypted by SRK) on hard drive in the OS Volume
System Volume Contains:
(All Unencrypted)
MBR
Boot manager
Boot Utilities
SRK
You would have your Master Boot Record or MBR, you would have a small system partition that would be approximately 1500MB and would hold your boot utilities. This partition is unencrypted.
This unencrypted code works with the TPM to determine if the system is in order and to obtain the initial decryption key. If any part of the code is compromised (for example by introduction of malicious code) the TPM ensures that the volume decryption key is never revealed.
And lastly you have an encrypted OS volume that holds an encrypted OS, and encrypted page, temp and hibernation files, and any other data in the volume.  This entire volume is encrypted with full volume encryption.  2
FVEK 1 3

8. BitLocker Protectors
BitLocker™ offers a spectrum of protection allowing an organization to customize according to its requirements.
*******
This slide shows the 4 levels of protection that BitLocker provides. The concepts of “What it is”, “What you know”, and “What you have”
TPM only
TPM plus PIN
USB only
TPM plus USB

9. BitLocker™ Drive Encryption Architecture Static Root of Trust Measurement of boot components
When a PC is reset, PCR 0 through 15 on the TPM are reset and execution is transferred to a trusted portion of firmware. This trusted portion of firmware in combination with the hardware is known as the Core Root of Trust Measurement (CRTM). This portion of firmware can only be reflashed through a very secure mechanism.
The CRTM measures the next stage of firmware into PCR[0] before executing it. This is typically the portion of firmware used for testing and configuring critical hardware such as memory. As the boot proceeds, more code is measured and written into PCR[0] and the data is measured and written into PCR[1]. Code is always measured before it is executed. After a measurement is written to a PCR, its value is permanently changed. The new PCR value is the concatenation hash of the previous contents and the new measurement. This can be described as SHA-1or PCR[x] || data. As long as each portion of code ensures that any new code is measured before execution, then the chain of trust is maintained.
The firmware measures option ROMs into PCR[2]. Option ROMs may measure more code into PCR[2] and data into PCR[3]. Finally the firmware measures the code portion of the MBR into PCR[4] and the partition table into PCR[5].
The MBR takes over this process by determining the active boot partition, loading the first sector of the boot partition into memory, and measuring the first 512 bytes of that sector into PCR[8]. The MBR then transfers the execution to this boot sector.
The boot sector of the active partition loads and measures the remaining boot code into PCR[9] before transferring the execution to it.
After the boot code has found and loaded BOOTMGR, it measures BOOTMGR into PCR[10] before transferring the execution to it. In the EFI boot case, the BOOTMGR is instead measured directly into PCR[4] and PCR[8]. PCR[9] and PCR[10] are not used.
The BOOTMGR checks the integrity of any boot applications loaded with respect to any Secure Startup partitions and ensures that the necessary integrity is kept to access a Secure Startup partition after BOOTMGR has gained access to the partition. If the Root of Trust Measurement before this point is invalid, then no Secure Startup partitions are accessible.
BOOTMGR transfers control to the operating system loader for the specified partition that checks the integrity of all windows components before transferring control to the operating system. The operating system then checks integrity of all executables loaded up to, including, and after an authenticated logon.

10. BitLocker™ Recovery Scenarios
Lost/Forgotten Key Protectors
Lost USB key, user forgets PIN
Upgrade to Core Files
Planned change to pre-OS files (BIOS upgrade, etc…)
Broken Hardware
Hard drive moved to a new system
Deliberate Attack
Modified or missing pre-OS files (Hacked BIOS, MBR, etc…)
The important this to remember is that recovery can occur “in the field” allowing users to continue operating Windows normal.
Lost keys and PIN’s can be either recreated through the BitLocker GUI, using manage-bde, or the WMI provider.
Broken hardware you can move the disk drive to another machine and recover the data.
Deliberate attacks can happen for many reasons review the BitLocker error codes to determine problem. May be necessary to rebuild machine to ensure integrity. Some customers plan to replace the machine in the event a deliberate attack occurs.

11. BitLocker™ Recovery Options
BitLocker integrates with Active Directory Domain Services (AD DS) to provide centralized key management.
· Recovery password
A 48-digit recovery password used to recover a BitLocker-protected volume. Users enter this password to unlock a volume when BitLocker enters recovery mode.
· Key package data
With this key package and the recovery password, you will be able decrypt portions of a BitLocker-protected volume if the disk is severely damaged. Each key package will only work with the volume it was created on, which can be identified by the corresponding volume ID.
· TPM owner password hash
When ownership of the TPM is taken a hash of the ownership password can be taken and stored in AD DS. This information can then be used to reset ownership of the TPM.
The important this to remember is that recovery can occur “in the field” allowing users to continue operating Windows normal.
Lost keys and PIN’s can be either recreated through the BitLocker GUI, using manage-bde, or the WMI provider.
Broken hardware you can move the disk drive to another machine and recover the data.
Deliberate attacks can happen for many reasons review the BitLocker error codes to determine problem. May be necessary to rebuild machine to ensure integrity. Some customers plan to replace the machine in the event a deliberate attack occurs.

12. Platform Threats & Mitigations
BIOS Modification
THREAT --- Lost Core Root of Trust for Measurement
MITIGATION --- Secure CRTM Update
MITIGATION --- Provide extra protection with PIN or USB
Physical Memory
THREAT --- Key exposure in physical memory
MITIGATION --- Memory Overwrite on Reset
Dictionary Attack Against PIN
THREAT --- Key exposure
MITIGATION --- Anti-hammering countermeasures
End Users
THREAT --- Unsafe practices (PIN nearby, USB in laptop case)
MITIGATION --- User education, corporate security policy
This slide portrays some of the more common threats to the BitLocker platform, and how these are mitigated.

13. BitLocker Deployment

14. Prepare to Deploy – Part 1
Define support structure and processes. Who will do What, When, and How?
Extend active directory to support escrow of BitLocker recovery information (TPM owner pass, recovery pass).
Delegate rights to allow support personnel to recover machines. DA + Confidential Attribute by default.
If users are local admin apply other GP to prohibit users from changing BitLocker settings.
Use GP to configure power management settings.
It’s very important as with all technology projects to plan and prepare what you are going to do.
Always extend the AD schema so you are able to same recovery information from clients.

15. Prepare to Deploy – Part 2
Use GP to configure power management settings.
Work with the OEM to determine default ship state of TPM.
If possible ship with TPM enabled.
Choose a deployment tools and methodologies.
Enable BitLocker after joining domain
Decide what BitLocker protectors will be used.
TPM only least user impact
TPM+USB or PIN high user impact high support cost
Decide whether or not to use WinRE in conjunction with BitLocker.

16. Group Policy and BitLocker
BitLocker group policy exists for drive encryption and TPM management.
Can be configured and the domain level or via local policy.
Used to control backup of recovery information to Active Directory.
Control user experience in UI and prohibit use of certain protectors.
Can be used to set a mandatory encryption method.
BitLocker setting are controlled at the computer level not user.
GP Deployment Considerations
Always require backup of recovery passwords and TPM owner auth to AD.
On BitLocker machines limit the use of sleep and hybrid sleep. Setup power plan in GP to configure prohibit.
Limit user access to power management functions to prevent change.
Remove sleep options from start menu.
Limit user access to BitLocker control panel unless needed to reset PIN’s or create additional protectors.
Consider hiding the system partition using GP to keep user from seeing the drive.

17. Deployment Scenarios
Deploying Bit Locker ready machines with the following deployment tools
Windows Deployment Services
SMS 2003 OSD
Unattended Installation
Imaging with ImageX
System Center Configuration Manager
BDD 2007/MDT

18. Maintaining a BitLocker Enabled System
Disabling BitLocker does not decrypt the disk and encryption still occurs.
When disabled a key is written to the disk that is in the clear and is used to access the VMK.
Disabling can be automated through WMI and removes two-factor authentication allowing unobstructed reboots.
Re-enabling BitLocker re-keys and re-encrypts the VMK. Any two-factor options are restored.
MS provided SP’s, patches, and upgrades that update BitLocker or sealed boot components automatically call FVEUpdate so no disabling is needed.
BitLocker must be disabled before updating system BIOS.

19. Things to Consider
Only recovery passwords not recovery keys are escrowed to AD.
Recovery password escrow is only done when password is created cannot be re-escrowed.
Managing recovery passwords and keys post deployment requires scripting, manage-bde, or GUI.
No single application for post deployment management of machines.
PIN’s are only stored on the TPM and not escrowed anywhere for recovery.
No status information in WMI that can be queried by inventory tools.

20. Additional Resources Trusted Computing Group (TCG)
Windows Hardware & Driver Central (WHDC)
BitLocker MSDN Content

21. Questions