Re: Bitlocker Registry Settings Windows 10
Joad Smith
When BitLocker was new, roughly half a dozen DLLs for user-mode BitLocker support each read for themselves by their own methods their own selection of BitLocker policy settings. For Windows 8, Microsoft unified this into library code that is linked into each of these DLLs. Most of the policy settings are organised into tables which are reproduced in each DLL. Each table gives for each setting the applicable registry key, the registry value and (optionally) the default for the data. For some settings, this tablular definition is at best a basis for interpretation. For a few, it is not even relevant, notably because the setting continues to be interpreted by old code.
To the library code for loading the registry keys from which to read the settings, this pair of keys in the Software and System branches of HKEY_LOCAL_MACHINE are just the root policy keys. There is also a notion of volume policy. (These names are taken from the names of internal routines, as known from public symbol files.) The volume policy is, or would be, read from the SOFTWARE and SYSTEM hives in the Windows\System32\Config directory of a particular volume, specifically such that the two usual keys would instead be
The plain intention is that a BitLocker-protected volume that Windows might be booted from, with the usual keys then supplying the root policy, can have alternatiive policy settings that apply just to this volume when accessed for some special purpose. What this purpose might be, whether just for testing or for some type of recovery, is not known since no software that uses the library code is yet known to have code for calling it with the arguments that would load the volume policy. Further study is required.
It is, of course, just an implementation detail, but the library code organises its definitions of policy settings into separate tables for different types of registry value: dword, string and multi-string. Public symbol files for Windows 8 and higher show that each table has an enumeration for indexing a setting within the table: eFveGpDwSetting, eFveGpStrSetting and eFveGpMultiStrSetting. Public symbol files for Windows 8.1 and higher show that each table is an array of a templated structure named POLICY_REGISTRY_INFO, with a different template argument for each type of registry value. For a reverse-engineered list of the defined settings, it is only natural to follow the implementation, including to separate the types.
The vast majority of BitLocker policy settings are integers. Unless otherwise noted, FVEAPI requires that the registry value has REG_DWORD as the type of its data (in contrast, for instance, to accepting four bytes of REG_BINARY data). Most of these settings require the REG_DWORD type not because they range widely as integers but because they are boolean or take values from an enumeration. Classification of these cases is a work in progress.
As made plain by the user-interface description, this value has long been superseded. Its first replacement was EncryptionMethodNoDiffuser (see next) in version 6.2. This and later versions retain EncryptionMethod as a fallback for when newer values are not present, but the Diffuser is not supported for new encryption, and so 1 and 2 are treated as 3 and 4.
Starting with the 1511 release of Windows 10, FVEAPI looks first for EncryptionMethodWithXtsOs and similar values (see far below), which have the advantage of allowing different encryption methods for different types of drive. These new registry values also provide for new encryption methods, represented by 6 and 7, which happen also to be meaningful for this superseded value if it is fallen back to.
What gets chosen for the encryption method when not specified (or if 0 is specified) is more complicated than is suggested by the parentheses in the user-interface descriptions. Definitive enumeration awaits further study.
This value superseded EncryptionMethod (see preceding). It is in turn superseded by EncryptionMethodWithXtsOs and similar values (see far below). It is still read as a fallback when the applicable new value is not present. The new values have the advantage of allowing different encryption methods for different types of drive. They also provide for new encryption methods, represented by 6 and 7, which happen also to be meaningful for EncryptionMethodNoDiffuser.
Before version 6.2, the Enabled value is meaningful only in the PlatformValidation key. Later versions select the key according to the FIRMWARE_TYPE as learnt from a SYSTEM_BOOT_ENVIRONMENT_INFORMATION structure that gets filled by the NtQuerySystemInformation function when given the (undocumented) information class SystemBootEnvironmentInformation. Anything other than FirmwareTypeBios and FirmwareTypeUefi (for the second and third keys, respectively) is treated as invalid. There is no fallback to the first key, which these versions have in their table but can never use.
In each of the three possible keys, the Enabled value has user-interface support through the Local Group Policy Editor as the following items in the Operating System Drives category of the BitLocker Drive Encryption administrative template:
The values 0 to 23 have user-interface support through the Local Group Policy Editor as check-boxes in the user-interface support for the Enabled value (see preceding) in the same key. Each check box corresponds to one numbered Platform Configuration Register (PCR). In the PlatformValidation and OSPlatformValidation_BIOS keys, these are labelled:
in the Operating System Drives category of the BitLocker Drive Encryption administrative template. This user interface has a check-box and four drop-down boxes which configure the next five registry values: EnableBDEWithNoTPM, UseTPM, UseTPMPIN, UseTPMKey and UseTPMKeyPin.
The OSRecovery, FDVRecovery and RDVRecovery values have user-interface support through the Local Group Policy Editor as the following items in their respective categories of the BitLocker Drive Encryption administrative template:
This user interface has four check-boxes and three drop-down boxes for the next seven sets of values: OSManageDRA, OSRecoveryPassword, OSRecoveryKey, OSHideRecoveryPage, OSActiveDirectoryBackup, OSActiveDirectoryInfoToStore and OSRequireActiveDirectoryBackup and similarly for fixed drives and removable drives.
Each of the OSRequireActiveDirectoryBackup, FDVRequireActiveDirectoryBackup and RDVRequireActiveDirectoryBackup values has user-interface support through the Local Group Policy Editor as a check-box labelled
Each of the OSActiveDirectoryInfoToStore, FDVActiveDirectoryInfoToStore and RDVActiveDirectoryInfoToStore values has user-interface support through the Local Group Policy Editor as the first drop-down box beneath the label
The FDVPassphrase and RDVPassphrase values have user-interface support through the Local Group Policy Editor as the following in their respective categories of the BitLocker Drive Encryption administrative template:
The user interface has a check-box, a drop-down box and an up-down box for the FDVEnforcePassphrase, FDVPassphraseComplexity and FDVPassphraseLength values (see below), and similarly for removable drives.
There are two essential points of difference between requiring password complexity and merely allowing it. The first is with where the complexity is assessed: require means a domain controller; allow means the local computer. The second is with disposition to the answer: require means the password is rejected without a positive answer from a domain controller; allow means the password is accepted unless the local computer answers specifically that the password is too simple.
The user interface provides for setting a minimum password length between 8 and 255 inclusive. FVEAPI tolerates 1 to 256 inclusive. Anything outside this range is corrected to the default, as if the setting had been left unspecified. There is no registry value for a maximum password length: this is hard-coded as 256.
in the Fixed Data Drives and Removable Data Drives categories of the BitLocker Drive Encryption administrative template. This user interface for RDVDenyWriteAccess has a check-box for setting the RDVDenyCrossOrg value (see above).
in their respective categories of the BitLocker Drive Encryption administrative template. The user interface has two check-boxes and one text-box for the OSAllowSoftwareEncryptionFailover, OSRestrictHardwareEncryptionAlgorithms and OSAllowedHardwareEncryptionAlgorithms values, and similarly for fixed drives and removable drives.
The OSAllowSoftwareEncryptionFailover, FDVAllowSoftwareEncryptionFailover and RDVAllowSoftwareEncryptionFailover values each have user-interface support through the Local Group Policy Editor as a checkbox labelled
The OSRestrictHardwareEncryptionAlgorithms, FDVRestrictHardwareEncryptionAlgorithms and RDVRestrictHardwareEncryptionAlgorithms values each have user-interface support through the Local Group Policy Editor as a checkbox labelled
in the Operating System Drives category of the BitLocker Drive Encryption administrative template. The user interface has two multi-line text boxes for the OSBcdAdditionalSecurityCriticalSettings and OSBcdAdditionalExcludedSettings values (see below).
The RecoveryKeyMessageSource value is interpreted by BDESVC.DLL to affect the Boot Configuration Data (BCD) options fverecoverymessage and fverecoveryurl. If the data for RecoveryKeyMessageSource is 2 or 3, then fverecoverymessage or fverecoveryurl is set from the string data for the RecoveryKeyMessage or RecoveryKeyUrl value (see below), and the other BCD option is deleted. For any other non-zero data, both BCD options are deleted.
In the absence of the applicable value for the volume type, FVEAPI falls back to the superseded values EncryptionMethodNoDiffuser and EncryptionMethod (in decreasing priority). All values have the same interpretation for their data: 1 and 2 are treated as 3 and 4; 0 leaves the method unspecified; anything else is invalid.
d3342ee215