BitLocker Drive Encryption: Value-Add Extensibility Options



BitLocker Drive Encryption: Value-Add Extensibility Options

May 16, 2006

Abstract

This white paper discusses how original equipment manufacturers (OEMs) and independent hardware vendors (IHVs) can develop preboot authentication extensions for the Microsoft® Windows Vista BitLocker™ Drive Encryption feature.

This information applies for the Microsoft Windows Vista™ operating system.

The current version of this paper is maintained on the Web at:

Contents

Introduction 3

Disk Encryption 3

Key Storage 4

Building a Platform Addition for BitLocker 6

Building a BitLocker Key Storage Provider 6

BitLocker Setup for a Startup Key Provider 7

Creating a Startup Key Protector 7

Registering the Startup Key File with a Custom BitLocker Authentication Provider 8

Custom Preboot Authentication 8

Releasing the Key Protector File to Windows Vista 9

Hiding the Key Following Successful Operating System Boot 9

Power States 10

Resources 10

Disclaimer

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.

© 2006 Microsoft Corporation. All rights reserved.

Microsoft, BitLocker, Windows, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Introduction

Today, unencrypted data that is stored on a hard disk can be accessed if the disk is mounted by another operating system. This can occur when a PC falls into unauthorized hands—if, for example, a laptop, desktop, or server machine is lost, stolen, or retired. To prevent this, the new Microsoft® BitLocker™ Drive Encryption feature of Microsoft Windows Vista™ allows the entire Microsoft Windows® volume and all system and stored user data to be encrypted.

BitLocker enhances data protection by bringing together two major subfunctions: full drive encryption and integrity checking of early boot components.

• Drive encryption protects data by preventing unauthorized users from breaking Windows file and system protection on lost or stolen computers. This protection is achieved by encrypting the entire Windows volume. With BitLocker all user and system files are encrypted, including the swap and hibernation files.

• Integrity checking the early boot components helps to ensure that data decryption is performed only if those components appear unmolested and that the encrypted drive is located in the original computer.

This document describes how an original equipment manufacturer (OEM) or independent hardware vendor (IHV) can offer alternative authentication and key storage solutions that replace or supplement the BitLocker component.

Disk Encryption

As the name implies, disk encryption encrypts essentially all user and system data on a disk volume, excluding the boot block and a region that contains metadata. The protected data includes the operating system itself, system files like the page file and hibernation file, and all stored user data on the volume. The first version of BitLocker offers a choice of cryptographic algorithms, but does not provide for third-party algorithms.

Current PC firmware cannot decrypt and boot a fully decrypted disk, so BitLocker systems are configured to commence boot from an unencrypted area called the system volume and then transfer control to the encrypted operating system volume called the operating system volume (see Figure 1).

[pic]

Figure 1. Schematic of the unencrypted system volume and an encrypted operating system volume that is protected with a Trusted Platform Module (TPM)

The system volume must contain the following code and data:

• Early boot files

• Other clear text data like the boot configuration database file

However, the system volume can also contain other code such as a recovery operating system and utilities.

Under the control of the boot manager, the system volume can start one or more encrypted operating system volumes.

Key Storage

BitLocker offers several choices for key storage. Each volume must be configured to use one or more key storage methods. The Windows Vista loader searches for usable keys for each enrolled option in turn until it finds a key that can decrypt the volume.

Windows Vista supports the following key storage options:

• TPM

• TPM plus personal identification number (PIN)

• TPM plus startup key (such as a USB or other storage device)

• Startup key (such as a USB or other storage device)

• Recovery password (for recovery only)

Protected volumes must be enrolled to use one or more key storage methods.

Key storage methods are configured by the user interface (UI) or by using the Windows Management Instrumentation (WMI) administrative interface. Each enrolled key storage method has an entry in an internal database and an associated key container file. Enrolled key storage methods and files are referenced by a globally unique identifier (GUID).

Each enrolled key storage method has a key container file that is associated with it, and, to use the key storage method, the Windows Vista loader must be able to find the key container file. The Windows Vista loader looks for key container files in the root directory of each BIOS enumerated block storage device that contains a recognized file system.

Key container files have names of the following form, where x is a hexadecimal digit 0-9, A-F:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.bek

Third-party key storage providers interoperate with Windows Vista by managing key container files, but note that third-party key storage providers are never required to create or edit such files: the BitLocker system creates properly formatted and named key storage files when a storage provider is enrolled. Key storage providers simply protect the key storage file without changing its name or contents.

Some key container files can be used alone (such as a startup key or recovery key container), but most must satisfy additional rules or steps. For example, a TPM-plus-PIN key container typically requires that the platform has booted an authorized loader (as reflected in internal TPM state) and use of a PIN (see Figure 2).

[pic]

Figure 2. Schematic of key recovery when a volume is configured to use the TPM-plus-PIN option

Alternatively, an encrypted volume that is configured to use a startup key searches for the external volume on BIOS enumerated storage devices (see Figure 3).

[pic]

Figure 3. Schematic of key recovery when a volume is configured to use a startup key

Building a Platform Addition for BitLocker

This section describes how BitLocker can be enhanced with a custom authentication provider. At a high level, a custom authentication provider must protect an enrolled startup key storage file and release it only if an authorized user is present (or other authentication condition is met). A startup key provider can secure the startup key storage file for either of the following:

• TPM-plus-startup-key authentication scenarios

• Startup-key-only authentication scenarios

Providers are encouraged to leverage the TPM by using the first option on platforms that support it.

Building a BitLocker Key Storage Provider

The Windows boot manager looks for key files in all BIOS enumerated storage devices. A BitLocker key storage provider:

1. Provides setup, configuration software to create the key storage file that uses the provided BitLocker APIs and to store that file in its custom location.

2. Protects the key file against unauthorized access. The threat model and assurance level are the responsibility of the provider.

3. Provides custom authentication of the user or environment.

4. If authentication succeeds, manifests the correct key storage file in the root directory of a (real or virtual) BIOS enumerated storage device so that the loader can read it in the following step.

5. Allows the operating system boot to commence.

6. Makes the key inaccessible before the next boot.

This section provides more details of the boot-time behavior of BitLocker, as well as other interfaces that are necessary to enhance BitLocker functionality. The following tasks are described:

• Setting up BitLocker to use a startup key provider and obtaining the necessary key file.

• Communicating the key file to the custom platform authentication provider.

• Preboot authentication.

• Releasing the key storage file, formatting the key file, and dealing with authentication errors.

• Hiding the key.

• Managing power state transitions.

BitLocker Setup for a Startup Key Provider

Microsoft provides a set of WMI interfaces for setting up BitLocker or for administering a working BitLocker-secured system (BitLocker Administration Interface). The vendor must choose whether to provide custom tools to provide the complete setup experience or to enroll an already-set-up system to use the custom authentication provider. For simplicity of explanation, this section assumes that the BitLocker system is already enabled.

As described earlier, BitLocker supports several basic types of key storage. For the purposes of this document, the most important are:

• Startup key

• Startup key and TPM

In the first type, the correct key file alone is sufficient to derive the volume encryption key. In the second type, both the key file and keying material that are obtained from the TPM are required to unlock the protected volume. In this second type, the TPM also validates the integrity of the boot files. Either version can be used with an external authentication provider. Because security is rarely absolute, additional authentication factors normally result in greater security. Therefore, two-layer (TPM-plus-startup-key) solutions are recommended wherever possible. This is practical because the code-authentication procedure that is employed in TPM authentication is invisible to the user.

Creating a Startup Key Protector

A BitLocker-protected volume is encrypted with a key that is derived from a key called the volume master key (VMK). The VMK itself is secured by using technologies known as key protectors. At boot time, Windows enumerates all key protectors for a protected volume in the order in which they were registered, looks for necessary files or configurations, and uses the first protector that provides successful recovery of the VMK.

To interact with an external authentication provider, the following steps are necessary:

1. A new key protector that is associated with an external file must be created. This can be either a TPM-plus-startup-key protector or a simple startup key protector. If a TPM is present, it should be used as part of the key protection.

2. The associated startup key must be exported to a file. This file must then be stored in the manner provided by the OEM/IHV extension. (For example, this file might be stored in a protected part of the BIOS.)

Key protectors can be created with the following BitLocker WMI methods:

Create a protector that must be present in conjunction with the correct configuration as enforced by the TPM:

uint32 ProtectKeyWithTPMAndExternalKey(

[in optional] string FriendlyName,

[in optional] uint8 PlatformValidationProfile[],

[in] uint8 ExternalKey[],

[out] string VolumeKeyProtectorID)

Create a protector that does not use the TPM (or even require that a TPM be present):

uint32 ProtectKeyWithExternalKey(

[in] string FriendlyName,

[in] uint8 ExternalKey[],

[out] string VolumeKeyProtectorID)

For more details, see the BitLocker Administration Interface Specification. Only processes or scripts that are running with administrative privileges can call these methods.

These methods register new key protectors with BitLocker, but do not create the startup key protector files themselves. To create the startup key protector file, the following method, which uses the VolumeKeyProtectorID that was returned on the previous method call, must be used:

uint32 SaveExternalKeyToFile([in] string VolumeKeyProtectorID,

[in] string Path)

SaveExternalKey to file creates a file whose name, contents, and file attributes should not be changed. However, the file can be moved to another physical or virtual storage location. Examples of this procedure are described in the following section.

Registering the Startup Key File with a Custom BitLocker Authentication Provider

The preceding section described how to create a key protector file for a BitLocker protected volume. At boot time, Windows searches all BIOS enumerated block storage devices that contain FAT or NTFS formatted file systems for files with the exact name returned from SaveExternalKeyToFile. This section describes how the file might be communicated to a BitLocker custom authentication provider.

The provider communicates this file securely into its security system. For example, if the custom authentication provider is hosted in the BIOS, then a custom ACPI method might be used.

It is not strictly necessary to delete the intermediate file that the WMI created if the file is stored on the BitLocker volume that is being protected, but it is good practice.

Custom Preboot Authentication

Custom authentication must occur before invocation of the Windows boot loader. Windows does not constrain the steps that a custom authentication provider takes to authenticate the user, code, physical device, or other principal. However, several security considerations should be remembered when designing this functionality.

Custom authentication providers must take careful note of the threat model that is addressed, the most common of which is an attacker trying to read data from the hard disk of a lost or stolen machine (desktop, laptop, or server). Solution providers must realize that, if an attacker can extract the volume protector key from the custom authentication provider, then the disk can be read (if the startup-key-only method is used) or is one step toward reading the disk (if the TPM-plus-startup-key method is used).

Therefore obfuscation or nontechnically enforced hiding techniques are generally not acceptable because attackers develop tools to circumvent such protections and these tools quickly become readily available. Instead, significant technical barriers to unauthorized access to the contents of the key protector file are necessary.

If the user (or other principal) does authenticate successfully, the key protector file must be manifested as described in the following section, which also describes how to handle authentication errors.

Releasing the Key Protector File to Windows Vista

If the custom authentication succeeds, a custom authentication provider must manifest the startup key protector file to the Windows Vista boot code. Windows searches for properly named key protector files in the root directory of all BIOS enumerated block storage devices that contain recognized file systems. If the boot files find the proper file on any of the enumerated media, then boot proceeds. If the loader does not find the proper file, then Windows Vista enters BitLocker recovery mode—typically prompting for a recovery key. The proper file must have the exact same contents and the exact name (or defined short file name contraction) that was returned from SaveExternalKeyToFile.

Following successful authentication, the following conditions must be met before Windows can use the external file key protector:

• The BitLocker custom authentication provider must manifest a block storage device through the BIOS. The device itself could be a “real” storage device, such as a USB flash drive, or could be a virtual device that is manifested by software. The device must be accessible through the standard BIOS interface.

• The storage device must be FAT or NTFS formatted.

• An external protector key file must be manifested in the root directory with the same name (or defined short file name contraction) as the file that was returned by the SaveExternalKeyToFile method called earlier.

• The contents of the file, and the file attributes, must be as returned from the SaveExternalKeyToFile method.

If authentication fails, the custom authenticator can offer options to retry or enter a custom recovery path, but must not reveal the key file. More specifically, the provider can choose to fail to meet the first condition (that is, do not manifest the storage device at all) or fail to meet the third condition (that is, do not manifest the external protector file).

If the custom authentication provider fails, then Windows tries other enrolled key storage methods. Typically, this results in the user being prompted to insert a USB flash drive that contains a recovery key or the user being prompted to enter the recovery password.

Hiding the Key Following Successful Operating System Boot

The main threat model that BitLocker addresses is protection against unauthorized users such as thieves. However, Windows denies access to volume encryption keys to nonadministrative accounts wherever possible. The protections that Windows can offer to protect keys from nonadministrative users are not complete. For example, key protector files that are exported to FAT-formatted USB drives are unprotected. Custom authentication providers may choose to provide similar protections.

Note that a custom authentication provider must protect access to startup key protector files if the platform enters a low power state (such as S3, S4, or S5).

Power States

Windows requires access to volume keys when booting and resuming from hibernation (S4). Custom authentication providers must provide key access for both of these power state transitions. Windows does not require access to startup key providers when resuming from suspended to RAM (S3). In this state, the contents of memory are not protected and, although the platform should return to the running operating system without opportunity for attacking code to execute, the protection is weaker.

A custom authentication provider might also require authentication when resuming from sleep. If authentication fails in this case, the custom authentication provider could deny boot, or even better, wipe memory.

Resources

For further information, send an e-mail to the BitLocker team at BDEINFO@.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download