BitLockerTM Drive Encryption Security Policy Page 1 of 15 BitLockerTM Drive Encryption Security Policy For FIPS 140-2 Validation v 0.8 7/7/08 1. Table of Contents 1. TABLE OF CONTENTS ......................................................................................................................... 1 2. INTRODUCTION.................................................................................................................................. 2 2.1 List of BitLockerTM and Vista Cryptographic Modules.........................................................................................2 2.2 Brief Module Description ...................................................................................................................................3 2.3 Validated Platforms ...........................................................................................................................................3 3. INTEGRITY CHAIN OF TRUST .......................................................................................................... 3 4. CRYPTOGRAPHIC BOUNDARY ......................................................................................................... 4 4.1 Overall Cryptographic Boundary........................................................................................................................4 4.2 BitLockerTM Components Included in the Boundary ..........................................................................................4 4.3 Other Vista Components ...................................................................................................................................4 4.4 Other BitLockerTM Components .........................................................................................................................4 5. ROLES, SERVICES AND AUTHENTICATION ................................................................................... 4 5.1 Roles .................................................................................................................................................................5 5.1.2 User Role ...............................................................................................................................................................5 5.1.3 Crypto-officer Role.................................................................................................................................................5 5.2 Startup and Recovery Mechanisms ...................................................................................................................5 6. SECURE OPERATION AND SECURITY RULES................................................................................ 6 6.1 Security Rules ...................................................................................................................................................6 6.1.1 BitLockerTM Security Rules .....................................................................................................................................6 6.1.2 FIPS 140-2 Security Rules .....................................................................................................................................6 6.2 Enabling FIPS Mode ..........................................................................................................................................6 7. CRYPTOGRAPHIC KEY MANAGEMENT ........................................................................................... 7 7.1 Flow Logic .........................................................................................................................................................9 7.2 Key Generation ...............................................................................................................................................11 7.3 Key Entry and Output .....................................................................................................................................11 7.4 Key Distribution...............................................................................................................................................11 7.5 Key Zeroization ...............................................................................................................................................12 7.6 Key Storage.....................................................................................................................................................12 7.7 Other Key-related Details ................................................................................................................................12 7.8 Administration Aspects....................................................................................................................................13 8. FIPS SELF-TESTS .............................................................................................................................. 14 8.1 Algorithm implementation conformance testing..............................................................................................14 8.2 Power-on self-test (KAT) design .....................................................................................................................14 8.3 Integrity check design.....................................................................................................................................14 8.5 Continuous RNG checks design.......................................................................................................................14 © 2008 Microsoft Corporation ­ This non-proprietary Security Policy may be reproduced only in its original entirety (without revision) BitLockerTM Drive Encryption Security Policy Page 2 of 15 2. Introduction BitLockerTM Drive Encryption is a data protection feature available in Windows® Vista Enterprise and Ultimate for client computers. BitLockerTM is Microsoft's response to one of our top customer requests: address the very real threats of data theft or exposure from lost, stolen or inappropriately decommissioned PC hardware with a tightly integrated solution in the Windows Operating System. BitLockerTM prevents a thief who boots another operating system or runs a software hacking tool from breaking Windows Vista file and system protections or performing offline viewing of the files stored on the protected drive. This protection is achieved by encrypting the entire Windows volume. With BitLockerTM all user and system files are encrypted including the swap and hibernation files. The feature can use either a Trusted Platform Module (TPM 1.2) or a USB key to protect user data and to ensure that a PC running Windows Vista has not been tampered with while the system was offline. BitLockerTM provides both mobile and office enterprise information workers with enhanced data protection should their systems be lost or stolen, and more secure data deletion when it comes time to decommission those assets. BitLockerTM enhances data protection by bringing together two major sub-functions: full drive encryption and cryptographic integrity checking of early boot components. Integrity checking the early boot components helps to ensure that data decryption is performed only if those components are unmolested and that the encrypted drive is located in the original computer. BitLockerTM offers the option to lock the normal boot process until the user supplies a PIN, much like an ATM card PIN, or inserts a USB flash drive that contains keying material. These additional security measures provide multi-factor authentication and assurance that the computer will not boot or resume from hibernation until the correct PIN or USB flash drive are presented. 2.1 List of BitLockerTM and Vista Cryptographic Modules BitLockerTM Drive Encryption includes several cryptographic modules that operate in conjunction with the cryptographic modules of the Vista operating system. The BitLockerTM modules use the following cryptographic algorithms: 1. Hashing: SHA-1 (for TPM communications), SHA-256 2. Keyed hash: HMAC, AES in CCM mode (128 and 256 bit) 3. Symmetric key encryption: AES in CBC mode (128 and 256 bit), with or without the use of the Elephant Diffuser algorithm The modules performing cryptographic operations are (those in bold are included in as part of this validation): Pre-boot environment 1) BOOTMGR 2) WINLOAD.EXE 3) WINRESUME.EXE Post boot environment 4) CI.DLL 5) KSECDD.SYS 6) FVEVOL.SYS 7) DUMPFVE.SYS 8) FVEAPI.DLL 9) BCRYPT.DLL 10) WIN32_TPM.DLL © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 3 of 15 2.2 Brief Module Description This section briefly describes each module and the technical differences between them: BOOTMGR This is the system boot manager, called by the bootstrapping code that resides in the boot sector. It locates the VMK (Volume Master Key) and the FVEK (Full Volume Encryption Key), it gets the authentication keys required (depending on the authentication scenario) and decrypts a portion of the disk so that the OS can be loaded. It then checks the integrity of the OS loader and launches it. WINLOAD.EXE This is the OS loader. It loads the boot-critical driver image files and the OS kernel image file itself. WINRESUME.EXE This is the filter that handles resuming from hibernation. At resume time, the data is decrypted as it is paged back into memory. CI.DLL This component provides Code Integrity for the OS by cryptographically verifying the integrity of OS components each time they are loaded into memory. KSECDD.SYS This is the main cryptographic provider for the OS itself. DUMPFVE.SYS This is the BitLockerTM filter that sits in the system dump stack. Whenever the dump stack is called (in the event of a crash, or for hibernation), this filter ensures that all data is encrypted before it gets written to the disk (as a dump file or hibernation file) FVEVOL.SYS This is the BitLockerTM driver. It performs disk conversion (encryption/decryption) and on-demand decryption of disk data. FVEAPI.DLL This is the internal (un-exposed) API that controls the different BitLockerTM functions, in particular key generation and key management. BCRYPT.DLL This Vista component provides cryptographic services to callers executing outside of the kernel space. WIN32_TPM.DLL This is the Windows Management Instrumentation (WMI) provider for the TPM API. It provides an interface for controlling TPM functionality. 2.3 Validated Platforms The BitLockerTM components identified in section 4 have been validated on the Microsoft Vista Ultimate Edition, both x86 and x64. The Microsoft Vista Ultimate Edition is a superset of the Vista Enterprise Edition, which also includes BitLockerTM Drive Encryption. Thus, BitLockerTM maintains FIPS 140-2 compliance on both Vista Enterprise and Ultimate Edition, for both x86 and x64 processor architectures. 3. Integrity Chain of Trust The cryptographic integrity checking of early boot components in the Vista and BitLockerTM cryptographic modules as follows: 1. BOOTMGR cryptographically checks its own integrity during its start up. 2. BOOTMGR then cryptographically checks the integrity of the OS loader (WINLOAD.EXE or WINRESUME.EXE if resuming from hibernation) before starting it. 3. WINLOAD.EXE cryptographically checks the integrity of CI.DLL before loading it. 4. CI.DLL cryptographically checks the integrity of the post-boot Vista and BitLockerTM cryptographic modules (KSECDD.SYS, DUMPFVE.SYS, FVEVOL.SYS, FVEAPI.DLL, BCRYPT.DLL, and © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 4 of 15 WIN32_TPM.DLL) when the Windows Vista Memory Manager attempts to load such cryptographic module. 4. Cryptographic Boundary 4.1 Overall Cryptographic Boundary For FIPS 140-2 purposes the cryptographic boundary is the physically contiguous enclosure of the computer system upon which Microsoft Windows Vista and BitLockerTM Drive Encryption executes (as we define the module to as a multi-chip standalone module). Within the Microsoft Windows Vista Operation System exists a second cryptographic boundary, drawn around those components responsible for providing BitLockerTM Drive Encryption functionality. 4.2 BitLockerTM Components Included in the Boundary The Windows Vista BitLockerTM Drive Encryption cryptographic boundary includes the WINRESUME.EXE, DUMPFVE.SYS, FVEVOL.SYS, and FVEAPI.DLL components. These components, in addition with the other Vista operating system components described below, provide the cryptography and functionality for full drive encryption and chain of trust integrity checking during the boot process. 4.3 Other Vista Components In addition to the aforementioned BitLockerTM components, other Windows Vista operating system components provide integral to the operating of BitLockerTM Drive Encryption. The Windows Vista BOOTMGR (Cert. #888), WINLOAD.EXE (Cert. #889), KSECDD.SYS (Cert. #891), CI.DLL (Cert. #890), and BCRYPT.DLL (Cert. #892) provide supporting cryptographic services to the BitLockerTM Components as well as cryptographically assure the integrity of the BitLockerTM components (in addition to cryptographically ensuring the integrity of each component in the Vista boot sequence). The BitLockerTM Driver Encryption cryptographic boundary does not include these components as these components have been subjected to separate FIPS 140-2 validations to ensure compliance. Because the BitLockerTM Drive Encryption components depend upon these other Vista operating system components, the BitLockerTM Drive Encryption validation is said to be bound to the Vista operating system, and requires it to remain compliant. 4.4 Other BitLockerTM Components Beyond the BitLockerTM Drive Encryption components included in the cryptographic boundary, there exist other BitLockerTM components that not included in the boundary. The non-cryptographic components of BitLockerTM, for example, the BitLockerTM Setup Wizard that provides a friendly graphical user interface, are not suitable for inclusion into the cryptographic boundary as they provide no cryptography. 5. Roles, Services and Authentication BitLockerTM provides two different, implicitly assumed roles and a set of services particular to each of the roles. As a FIPS 140-2 level 1 validated product, BitLockerTM itself does not provide any authentication; however, as with all other Windows components, access to BitLockerTM is granted only after the Windows Vista operating system successfully authenticates (through WinLogon) an operator. The Microsoft Vista operating system authenticates an operator's identity by verifying his credentials through WinLogon, at login © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 5 of 15 time, and then implicitly assigns him either the Crypto-Officer or User role depending on the group permissions associated with the operator's ID. 5.1 Roles BitLockerTM provides both a Crypto-officer (Administrator) and User Role. 5.1.2 User Role The User Role has no access to any BitLocker configuration or control services; rather the User Role benefits from the seamless encryption and decryption of the user's files written to and read from a BitLockerTM encrypted volume. 5.1.3 Crypto-officer Role The Crypto-officer Role has access to the PC's administrative commands, including BitLockerTM administration. The Crypto-officer must initialize BitLockerTM on a new PC upon receipt, by selecting the authentication and recovery methods to be used and launching the conversion (encryption) process. Once authenticated, the Crypto-officer can perform any of the following commands: · Configuring BitLockerTM into FIPS-mode (see section 6.2 below) · Start-up the BitLockerTM Setup Wizard · Select / Create authentication methods (key protectors) o TPM, TPM+PIN, TPM+USB, USB · Select / Create recovery key · Manage keys o Copy keys (startup key, recovery key) o Reset PIN · Disable/ Re-enable protection (go into and out of disabled mode) 1 · Turn-off BitLockerTM (volume decryption) 5.2 Startup and Recovery Mechanisms BitLockerTM incorporates four different startup methods and two recovery mechanisms (of which a subset is available when initializing BitLockerTM to operate in FIPS-mode): - TPM-only authentication; - TPM and PIN authentication; - TPM + Startup key authentication; - Startup key only authentication The fowling recovery mechanisms are available: - Recovery key authentication - Recovery password authentication 1 1 Not available in FIPS mode. © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 6 of 15 6. Secure Operation and Security Rules In order to operate BitLockerTM, the operator should be aware of the security rules enforced by the module and should adhere to the physical security rules and secure operation rules required. 6.1 Security Rules The security rules enforced by BitLockerTM include both the security rules that Microsoft has imposed and the security rules that result from the security requirements of FIPS 140-2. 6.1.1 BitLockerTM Security Rules The following are security rules imposed by BitLockerTM: 1. BitLockerTM can only be initialized by a Crypto Officer. 2. BitLockerTM will only allow a Crypto Officer to perform key management operations 3. BitLockerTM will allow any User that possesses the appropriate authentication credentials to operate a computer that has a volume protected with this technology. 6.1.2 FIPS 140-2 Security Rules The following are security rules that result from the security requirements of FIPS 140-2: 1. BitLockerTM will not allow creation or use of a recovery password in FIPS mode as FIPS 140-2 prohibits using password deriving keys for data encryption/decryption. a. A "recovery password" is a 48 digit value that can be used to recover an encrypted volume, in the event that the main authentication keys are lost, stolen or unusable. 2. BitLockerTM will only release keys to be stored on USB flash drives, if the Crypto Officer performs this operation 3. BitLockerTM Drive Encryption is currently supported on Windows Vista Enterprise and Ultimate Editions (both 32-bit and 64-bit versions). 4. Windows Vista is an operating system supporting a "single user" mode where there is only one interactive user during a logon session. 5. BitLockerTM Drive Encryption provides a variety of different key management options to allow customers to implement a key storage, authentication, and backup/recovery scheme that meets their needs. When placed into FIPS-mode, BitLockerTM will only offer FIPS approved methods included as part of this validation. 6. BitLockerTM will only operate in its FIPS-mode once volume conversion (encryption) has completed and the volume is fully encrypted. 6.2 Enabling FIPS Mode In order to allow the local administrator to enable or disable FIPS compliance, BitLockerTM complies with the "System Cryptography: Use FIPS compliant algorithms" policy. Additionally, the local administrator may need to enable the BitLocker to operate without a valid TPM device if the computer lacks a valid TPM device. The registry key used for the FIPS-mode policy is: HKEY_LOCAL_COMPUTER\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Ena bled The FIPS mode policy (that can be found here: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> System Cryptography: Use FIPS compliant algorithms) setting allows you to configure the computer to use only FIPS compliant algorithms. © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 7 of 15 The registry key used for the TPM policy is: HKEY_LOCAL_COMPUTER\System\CurrentControlSet\ Control\Lsa\RequireValidTPM\Disabled The policy controlling whether BitLocker will require the presence of a valid TPM device (that can be found here: Computer Configuration -> Local Computer Policy -> Administrative Templates -> Windows Components -> BitLocker Driver Encryption -> Control Panel Setup: Enable Advanced Startup Options) must be set if the computer lacks a TPM or if using the Startup Key only method. Finally, the administrator should select one of the three available options ­ "Use Bitlocker without Additional Keys", "Require PIN at every startup", or "Require Startup USB key at every startup" ­ under the "Set BitLocker Startup Preferences" setup wizard screen. By enabling these policy settings and specifying one of the available options, BitLockerTM will operate in its FIPS-mode and will only use FIPS compliant algorithms authentication and recovery mechanisms. This means that no recovery password can be created or consumed, and that only a recovery key can be used for recovery purposes. This is also valid for foreign or data volumes: you can recover/unlock such volume only with a recovery key, and not with a recovery password. Therefore, when operating in FIPS-compliant mode, the Setup wizard will disable the buttons allowing the creation, display or printing of a recovery password. The Save to Folder link will also be disabled on the save recovery key page. Additionally, the recovery wizard will only allow recovery of foreign volumes using a recovery key. In FIPS mode, it will grey-out the Disable mode link and the Recovery Password entry option. Only a recovery key can be used, and only to decrypt the volume. Once the administrator has configured the policies as described above, and set up BitLockerTM, BitLockerTM will begin encrypting the operating system volume. Once this conversion process is complete, BitLockerTM will be operating in FIPS-mode. Additionally, it is recommended that domain administrators enable the FIPS policy before turning on BitLockerTM. If FIPS mode is enabled after BitLockerTM was turned on, BitLockerTM must be turned off, and turned back on in order to remain compliant with the FIPS 140-2 requirements. This is because FIPS requires that all keys used in FIPS mode should have been created in FIPS mode. 7. Cryptographic Key Management In order to achieve a higher level of security, without greatly affecting usability, BitLockerTM supports different types of cryptographic algorithms and encryption layers, including multi-factor authentication. Note that only a subset of options is available when operating in FIPS-mode. The main goal of BitLockerTM is to protect user data on the Operating System volume of the hard drive. To achieve this, disk sectors are encrypted with a Full Volume Encryption Key (FVEK), which is always encrypted with the Volume Master Key (VMK), which, in turn, is bound to the TPM (in TPM scenarios). The VMK directly protects the FVEK and therefore, protecting the VMK becomes critical. Protecting the disk through the VMK allows the system to re-key easily when one of the other keys upstream in the chain is lost or compromised, especially since decrypting and re-encrypting the entire volume is a time-expensive operation. There are several different ways to encrypt the VMK: Scenario VMK blob VMK encrypted Available in © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 8 of 15 with FIPS-mode? Default (TPM-only) SRK(VMK) RSA2 Yes TPM with PIN (SRK+SHA256(PIN))(VMK) RSA2 Yes TPM and USB XOR(SRK(IK),SK)(VMK) AES2 Yes (TPM+SK) Startup key (SK) SK(VMK) AES Yes Recovery key (RK) RK(VMK) AES Yes Recovery password (Chained-hashing(Password),Salt)(VMK) AES No Clear key (CC) CC(VMK) AES No The SRK is the Storage Root Key held by the TPM. It is a 2048 bit RSA key pair generated when ownership of the TPM is taken. The SRK, referred to here as an RSA key, is actually the RSA public key; the private key member of the pair is never shown by the TPM. The SRK is stored within the non-volatile protected memory of the TPM and cannot be removed. This helps ensure that the private key material cannot be leaked, and prevents keys from being used on any platform other than the one they were created on. However, mechanisms are available to migrate keys from one TPM to another, for backup and disaster recovery purposes. All TPM key operations are based on the SRK. When ownership is taken of the TPM, the new owner is required to specify two pieces of authorization information, the ownership authorization and the SRK usage authorization. This SRK usage authorization will be required for each TPM operation. Since this is undesirable from a usability point of view, and since BitLockerTM requires that this information be known very early in the boot process, the TPM admin tools will set this usage authorization to a known value of all zeroes (20 bytes of 0). The SRK is re-keyed each time the owner changes. Note that recovery passwords are disabled when operating in FIPS mode. The diagram below shows the BitLockerTM Key Architecture. 2 In schemes using TPM, the VMK is considered to be in plaintext since no guarantee of cryptographic strength of the TPM implementation is provided by this module. © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 9 of 15 The keys are generated at set-up time, when BitLockerTM is enabled. They are stored after being generated. The FVEK and VMK are stored locally in three different places on the drive (beginning, middle, end) and cannot be changed. The only way to change these keys for an encrypted volume is to decrypt and re-encrypt the volume. Most of the keys (SK, RK, recovery password) ­ except the PIN ­ can be copied after the volume has been encrypted. Intermediate keys (IK) are keys that are stored encrypted on the drive and become [part of] the basis of another key. IK is an intermediate symmetric key, 256-bit long, randomly generated, stored on disk encrypted with the SRK. The clear key is a 256-bit AES key that encrypts the VMK; it is created when no other VMK-protecting key is present, in what is called "disabled mode". In this case, there is no security ­ it is as though the drive is not encrypted, the data is freely available. The clear key is stored as raw data on the disk, together with the VMK. If a computer does have a [detectable] TPM, BitLockerTM will offer to use the TPM. An external device to hold a key may still be used, but the key on the external device will be a "partial key" (for two-layer authentication) or a recovery key (RK). 7.1 Flow Logic BitLockerTM will look (at boot time and waking up from hibernation) for appropriate keys to decrypt the volume in the following sequence: 1. Clear Key 2. No-TPM required and no user input required a. SK (TPM-less scenario) 3. TPM system and no user input required © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 10 of 15 a. TPM b. TPM+SK 4. User Interface (UI) Required (TPM system or no-TPM system) a. TPM+PIN b. SK/RK c. Recovery password The following diagram illustrates the flow logic in the system. © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 11 of 15 7.2 Key Generation All keys are generated using FIPS-compliant Random Number Generators (RNGs). The only exception is the nonce used for sending commands to the TPM, which requires nonces to be generated ­ in this case by the TPM's RNG (random number generator). Key Generated by Algorithm used Used by FIPS Mode FVEK FVE API BCryptGenRandom FVE driver Yes VMK FVE API BCryptGenRandom Boot manager Yes FVE API SRK TPM vendor - TPM Yes Intermediate key FVE API BCryptGenRandom Boot manager No FVE API SK FVE API BCryptGenRandom Boot manager Yes FVE API RK (similar to SK) FVE API BCryptGenRandom Boot manager Yes FVE API Clear key FVE API BCryptGenRandom Boot manager No FVE API PIN User - Boot manager No FVE API TPM Nonce TPM RNG TPM vendor specific Boot manager Yes TPM WMI provider 7.3 Key Entry and Output The raw data encryption keys are all internal and never leave the computer. The only inputs by the user are the PIN or the recovery password (which was generated by the system, but manually entered in recovery mode). The keys that are exported are: Key Entry Output FIPS mode FVEK - - Yes VMK - - Yes SRK - - Yes Intermediate key - - Yes SK USB device USB device Yes RK (similar to SK) USB device USB device Yes Clear key - - No PIN manually - Yes Recovery manually Text file or No Password Active Directory Domain Services 7.4 Key Distribution As outlined in the previous section, keys reside on the local computer or on a USB device. Only recovery passwords are electronically stored (if so indicated by Group Policy) in an Active Directory Domain Services server. When needed, a user calls helpdesk and a domain administrator can read the AD entry once the user © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 12 of 15 has been properly identified. At this point the key can be transmitted back to the user either verbally, or any other form approved by the enterprise security policy in place. 7.5 Key Zeroization All keys are zeroized in memory (by overwriting once with 0s) once they are used and no longer needed. Additionally, on shutdown, the FVEK is also zeroized. Furthermore, when turning off BitLockerTM, the metadata sections are zeroized by overwriting the disk three times (once with 0s, once with 1s and once with encrypted 0s ­ which effectively outputs a random pattern). 7.6 Key Storage Below is a chart that details where the different types of keys are stored. Key Length Algorithm in Visible Storage Storage FIPS which is used to user Place Form Mode (default) FVEK 128, 256 AES No On disk Encrypted Yes VMK 256 AES No On disk Encrypted3 Yes SRK 2048 RSA No TPM Plaintext Yes Intermediate key 128, 256 AES No On disk Encrypted Yes SK 256 AES Yes External Plaintext Yes device RK (similar to SK) 256 AES Yes External Plaintext Yes device Clear key 256 AES No On disk Plaintext No PIN 4 to 20 digits SHA256 Yes - - No Password 48 digits AES Yes AD Plaintext No On disk, keys are stored in BitLockerTM metadata sections on the OS volume. The FVE metadata sections are present in three places on the OS volume and stored unencrypted. · At boot time, only the first copy of the metadata is used. The second and third copies are kept in sync by fvevol.sys ­ done on first access to encrypted disk. · Backup copies two and three are used for recovery purposes: using the restore tool · Tool will scan the disk for other metadata · BIOS parameter block (BPB) points to first copy · the space used for the pointer was previously used to point to backup Master file table (MFT), which doesn't really move · no space for more pointers · each copy then points to a subsequent copy 7.7 Other Key-related Details Volume Move: After being moved to a different computer, if the volume is moved back to the original TPM it may reuse its original keys, provided they were not over-written. Each BitLockerTM instance will have a single set of keys ­ if the keys are stored and have not been removed from the original computer the volume should work without recovery when moved back to the original computer. 3 For FIPS purposes, the VMK is considered to be stored in plaintext whenever the TPM only, TPM + Startup Key, or TPM + PIN modes are used for protecting this value. © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 13 of 15 External Keys External Keys are keys saved externally, on a USB flash drive. Startup Keys or Recovery Keys are examples of an External Key. External keys are saved as a .bek file, containing raw binary data of the key in clear. At set-up time, the SK or RK can only be saved on removable drives. The file is stored as a system file and hidden to prevent inadvertent deletion. RKs can also be copied after creation, ensuring additional back-ups are available. The RK will only be required at boot time, so it is recommended that users remove it after that for security's sake. PINs The user will be able to change PIN, but it will not be saved/escrowed programmatically. The RK or recovery password must be used if the PIN is lost. When the PIN scenario is enabled and the new encrypted VMK blob is stored, the system shall remove the encrypted VMK blob that was encrypted with only the TPM, if such blob is present ­ except for RK/RK or Recovery Password. In this manner, at next boot, the system will require the two-factor authentication, instead of working with only a TPM. Multiple PINs on a given computer are not supported in this version (the UI does not handle this, and WMI use is discouraged). Recovery Recovery is called during boot if BitLockerTM authentication fails (for data or non-OS volumes, when the BitLockerTM-protected volume fails to be mounted). A recovery key (RK) stored on a USB flash drive can be used in the recovery sequence to unlock the volume. The recovery password consists of a 48 character numeric string that is generated and displayed by the system and must be manually entered by the user to recover the volume. After being generated at set-up time, the recovery password can be viewed, saved locally or printed by the user and is sent to the AD server4, if required by Group Policy. If AD is not available, and AD password saving is required, then the BitLockerTM set-up is halted. Zero or more recovery passwords are supported. The maximum number of all key protectors is limited by the maximum size of the metadata structure that can contain them, which is 16K. So for practical purposes, the limit is about 10 recovery password blobs. If GP requires the recovery password to be sent to AD, then a recovery password is automatically generated, regardless of the Recovery Password UI Policy. If AD is not available, the set-up process is stopped. If AD is not required and the user sees the Recovery Password Creation screen, she will need to click on one of the links (see the password, save it, print it) to actually generate the password. Just clicking Next (without clicking on any of the links) will not generate a password. BitLockerTM supports the Windows FIPS Group Policy. This GP is off by default, but can be enabled by a local administrator or, through scripting, by a domain administrator. When set, recovery passwords cannot be created or consumed. The FVE API ensures that calls (from either the UI wizard or WMI scripts) to create or consume recovery password-based key protectors will fail. 7.8 Administration Aspects The Domain Administrator has full control over the enabling or disabling of BitLockerTM and most of its components. The administrator will be able to specify through Group Policy (GP): 4 A per-volume GUID is also generated and sent up with the recovery password. © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 14 of 15 a. Create recovery password: Must, Cannot, Optional (default) b. Store recovery password in Active Directory Domain Services: Yes, No (default) If AD is not available and it is required BitLockerTM Setup up will be stopped. c. Create recovery key: Must (default), Cannot, Optional d. Store recovery key to a folder/network location: Must, Cannot, Optional (default) Default media path e. Create external key: Must, Cannot, Optional (default) f. Create PIN: Must, Cannot, Optional (default) g. Display warning when no recovery mechanisms have been set h. System Cryptography: Use FIPS compliant algorithms: Enabled, Disabled (default) If the registry keys controlling these settings have not been set-up by GP, a default will be used. The default is to make choices optional, leaving them to the user. 8. FIPS Self-tests 8.1 Algorithm implementation conformance testing In order to ensure that each of cryptographic algorithms used by BitLockerTM is implemented correctly, each cryptographic algorithm was subjected to CAVP conformance testing. These conformance tests were conducted during the FIPS 140-2 validation process, and the following certificates were issued for the cryptographic algorithms employed by BitLockerTM: Algorithm Key Size Mode Cert # FIPS approved AES 128, 256 CBC 715 Yes AES 128, 256 CCM 715 Yes SHA-1 160 Byte oriented 737 Yes SHA-256 256 Byte oriented 737 Yes HMAC-SHA-1 KS < BS N/A 386 Yes HMAC-SHA-256 KS < BS N/A 386 Yes 8.2 Power-on self-test (KAT) design BitLockerTM implements Known Answer Test functions in each cryptographic component for each algorithm employed by that component. These tests run each time a module is powered up (after being powered-off, reset, rebooted, etc.). 8.3 Integrity check design Vista and BitLockerTM implement integrity checking starting with the boot manager and then continuing to check each subsequent component. The boot manager performs a cryptographic verification of its own integrity before checking the integrity of the next component in the boot process (winload.exe or winresume.exe, if coming from hibernation). Once control is passed to the OS loader, it will check CI.dll, and once the computer boots, Code Integrity (CI.dll) will perform integrity checks on all other modules. 8.5 Continuous RNG checks design In the FVE API, all RNG is performed using BCryptGenRandom (in bcrypt.dll). © 2008 Microsoft Corporation BitLockerTM Drive Encryption Security Policy Page 15 of 15 For the latest information on Windows Vista, check out the Microsoft web site at http://www.microsoft.com. © 2008 Microsoft Corporation