Geoff Chappell - Software Analyst
SKETCH OF HOW RESEARCH MIGHT CONTINUE AND RESULTS BE PRESENTED
The FVE_DATUM_KEY structure (formally _FVE_DATUM_KEY) is a fixed-size header for a BitLocker datum that is specifically an encryption key or similar input to a cryptography algorithm.
No documentation of the FVE_DATUM_KEY structure is known from Microsoft, but the name is Microsoft’s. It is known from public symbol files for FVEAPI.DLL.
The FVE_DATUM_KEY structure is 0x0C bytes:
| Offset | Size | Description |
|---|---|---|
| 0x00 | 0x08 | an FVE_DATUM as the fixed-size header common to all type-specific headers |
| 0x08 | word | key type |
| 0x0A | word | bit flags |
In the FVE_DATUM, the type at offset 0x04 is necessarily 1 for an FVE_DATUM_KEY, except if the FVE_DATUM_KEY is in turn the base of a larger header for a stretch key (type 3) or use key (type 4).
The header is followed by the bytes of the key as the whole of the datum’s data segment. The size of the key can be inferred from the size at offset 0x00 in the header, this being the total of the header and the key.
Much of the point of packaging a key into a BitLocker datum is to associate the typically random bytes of the key with some notion of how it is meant to be used. The single most important signifier is the key type at offset 0x08. These look to be defined in disjoint ranges. Though many values are known, much further study is yet required.
For some key types, the data segment is not exactly a key in the sense of being directly the secret input to an algorithm for converting between plain text and cipher text, but is instead input for preparing such a key or for varying the behaviour of such an algorithm.
For key types 0x2000 to 0x2FFF inclusive, the data segment is a key for authenticated encryption. The plain text, typically for being pseudo-random, has little intrinsic support for recognising whether it is recovered correctly from a supposed decryption of the cipher text. The encryption is therefore performed to produce both the cipher text and a MAC. If decryption recovers the MAC, then some assurance is obtained that the plain text also has been correctly recovered. Such assurance is specially important when the encrypted data is itself a key, notably the FVEK which encrypts the disk sectors.
Whether the range from 0x2000 to 0x2FFF also specifies an algorithm is unclear. In all known cases, the algorithm is 256-bit AES in CCM mode. The library routine that public symbol files name as FveDatumAesCcmEncCreate creates an FVE_DATUM_AESCCM_ENC as a package of the encrypted data (as the data segment) with a nonce and MAC. The key for the encryption must be provided as an FVE_DATUM_KEY in which the key type can be anything between 0x2000 and 0x2FFF.
Some keys, notably those for encrypting disk sectors, are for algorithms that convert between plain text and cipher text without authentication. Encryption takes a key and plain text as input to produce cipher text. Decryption takes the same key and the cipher text as input to recover the plain text. The plain text and the cipher text have the same size. For a key that has this intended use, the key is the data segment of the FVE_DATUM_KEY and the key type at offset 0x08 tells which algorithm the key is intended for.
For all known key types in this range at 0x8000, the data segment is specifically an FVEK. There is some suggestion that these values of the key type are thought of at Microsoft as an FVEK type. For instance, an internal routine (actually a member function of a class) that produces them for FVEAPI is named by public symbol files as MapFveMethodToFvekType.
| Key Type | Description | Key Size | Versions |
|---|---|---|---|
| 0x8000 | 128-bit AES with Elephant diffuser | 0x40 | 6.0 and higher |
| 0x8001 | 256-bit AES with Elephant diffuser | 0x40 | 6.0 and higher |
| 0x8002 | 128-bit AES in CBC mode | 0x10 | 6.0 and higher |
| 0x8003 | 256-bit AES in CBC mode | 0x20 | 6.0 and higher |
| 0x8004 | 128-bit AES in XTS mode | 0x20 | 1511 and higher |
| 0x8005 | 256-bit AES in XTS mode | 0x40 | 1511 and higher |
For both the 128-bit and 256-bit Elephant algorithms, the key is 0x40 bytes. In version 6.2 and higher, FVEAPI does not accept the corresponding key types when creating an FVEK, but since disks that were encrypted with algorithms from old Windows versions should remain usable, new Windows versions retain code for these algorithms. An FVE_DATUM_KEY that has 0x8000 or 0x8001 for its key type continues to be recognised.