0

How does Windows use the TPM for BitLocker encryption without an attacker being able to do the same?

From this FAQ, I understand that BitLocker uses the following keys to encrypt the hard-drive:

  • Full volume encryption key (used to encrypt raw data; encrypted by the volume master key and stored on-disk)
  • Volume master key (encrypted by a key protector and stored on-disk)
  • Key protector (TPM or numerical password)

The following output from manage-bde (with hidden data) shows that the system uses both TPM and numerical password (recovery password) as key protectors:

    C:\WINDOWS\system32>manage-bde -protectors -get C:
    BitLocker Drive Encryption: Configuration Tool version 10.0.16299
    Copyright (C) 2013 Microsoft Corporation. All rights reserved.

    Volume C: [Windows]
    All Key Protectors

    Numerical Password:
      ID: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
      Password:
        XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX

    TPM:
      ID: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
      PCR Validation Profile:
        0, 2, 4, 11

In this case, what key protector is used to encrypt the volume master key?

Also, what prevents an attacker from either using the TPM as Windows would do it, or to read the recovery password from disk (the latter protector must exist in cleartext)?

Shuzheng
  • 1,147
  • 4
  • 23
  • 38

1 Answers1

3

The volume master key is encrypted by one or more key protectors. You have a range of key protectors to choose from depending on the machine's configuration and hardware, each can be used to unlock the volume master key independently.

In your configuration above you have two encrypted copies of the volume master key - a TPM key protector, as well as a Numerical Password key protector - a 48-bit recovery password which itself decrypts the volume master key.

Raw data is encrypted with the full volume encryption key, which is then encrypted with the volume master key. The volume master key is in turn encrypted by one of several possible methods depending on your authentication (that is, key protectors or TPM) and recovery scenarios.

The full volume encryption key is encrypted by the volume master key and stored in the encrypted drive. The volume master key is encrypted by the appropriate key protector and stored in the encrypted drive. If BitLocker has been suspended, the clear key that is used to encrypt the volume master key is also stored in the encrypted drive, along with the encrypted volume master key.

This storage process ensures that the volume master key is never stored unencrypted and is protected unless you disable BitLocker. The keys are also saved to two additional locations on the drive for redundancy. The keys can be read and processed by the boot manager.

BitLocker Key Management FAQ

When you access a disk protected by BitLocker, such as when starting the computer for the OS volume, BitLocker requests access to the key protector.

For a recovery password key protector, you are required to type it in to the pre-boot environment.

The TPM Key Protector is a special key protector that (a) stores the encryption key inside tamper-resistant non-exportable memory in the chip, and (b) uses the capabilities of the security processor to perform validation of the machine's current configuration before releasing the key from its encrypted memory to the Operating System.

When BitLocker with a TPM key protector is initialised, a validation profile is created in the TPM chip of the machine which includes the readings of a number of Platform Configuration Registers (PCRs). Each PCR represents the state or value of a number of boot-critical components and services. This validation profile is the 'known good' state of the machine.

Each time the machine is booted, the TPM measures these PCRs again. Provided the PCRs match the known-good profile, the TPM releases the key to the Operating System enabling the automatic unlock of the disk and the remainder of the boot process. Additionally, a PIN may need to be inputted to provide additional authentication to the TPM of the user (highly recommended).

If the value of any of these have changed (e.g. the Master Boot Record (MBR) code has been modified by an attacker to display or release the encryption key in the clear), the PCR will have changed when assessed by the TPM during boot, the system is not deemed to be secure and the TPM will not release the key. In this case another key protector is tried - which is often prompting the user to input the recovery password.

Whilst Windows provides a secure by design default configuration, you can change the PCRs that are assessed and read more about the functions of each PCR in the relevant Group Policy settings for BitLocker PCRs:

Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Operating System Drives\Configure TPM platform validation profile (...)

This is fundamentally what stops a malicious user from accessing the volume master key via the TPM.

Further reading: How does the TPM perform integrity measurements on a system?

Andrew
  • 161
  • 5
  • Awesome answer, @Andrew. So, if I boot from a CD, then the CD's boot code will be compared to that stored in the PCR for the hard drive's boot code - and the comparison will fail? Are PCRs specific to Windows and created from storage within the TPM - or are TPMs manufactured with a fixed number of PCRs? – Shuzheng Jul 09 '19 at 14:46
  • I guess, a TPM can only be manipulated/reconfigured, if it's first reset - otherwise, malicious boot code would be able to tamper with it and possibly obtain the key by e.g. not resetting the original key first. – Shuzheng Jul 09 '19 at 14:49
  • Does the TPM actually encrypts the volume master key, or does it only store it? – Shuzheng Jul 09 '19 at 14:53
  • The BIOS boot block, as the Core Root of Trust for Measurements (CRTM), takes a number of measurements of the system starting with the BIOS itself and continuing the chain of boot up to the OS. It stores a hash of the measurements in the PCRs using the 'extend' function. If you are booting from a CD, or change the boot order itself, the resulting hash of one or more of the PCRs will change. PCRs are not specific to Windows but are a property of the TPM. The TPM PCRs are reset on each boot, and cannot be set/manipulated - only extended by a hash. The last link has some good reading. – Andrew Jul 10 '19 at 12:40
  • Windows stores multiple copies of the Volume Master Key (VMK) on the encrypted drive, one copy of which will represent the TPM key protector. The TPM does not store the VMK itself. Windows send the VMK to the TPM to _unseal_ (decrypt) it. The TPM feeds the PCR values into this operation, if they do not match exactly the unseal operation will fail. It's relatively cheap and easy to intercept the returned clear-text VMK and defeat BitLocker - see [Pulse Security](https://pulsesecurity.co.nz/articles/TPM-sniffing) - which makes pre-boot authentication **critical** to BitLocker's security. – Andrew Jul 10 '19 at 12:56
  • Last question: Why do BitLocker has two keys, *Volume Master Key* and *Full Volume Encryption Key* - I don't see why two keys in this case should provide much better security than one? – Shuzheng Jul 11 '19 at 04:23
  • But thanks for all your help! I would correct your sentence "It stores a hash of the measurements in the PCRs using the 'extend' function." to "It stores **hashes** of the measurements in the PCRs using the 'extend' function." – Shuzheng Jul 11 '19 at 04:34
  • Might be out of scope, but of course the TPM includes some random value that it only knows about in the symmetric key for encryption/decryption; otherwise, the key could be derived from PCRs alone? – Shuzheng Jul 11 '19 at 05:58
  • The Full Volume Encryption Key (FVEK) is used to encrypt the data on disk; the FVEK is then encrypted again by the Volume Master Key (VMK). The benefit is that the VMK can be changed as it is just encrypting the FVEK. If the FVEK was used directly, to change it you'd need to re-encrypt all the data on-disk. – Andrew Jul 16 '19 at 11:04
  • The TPM Encrypts the Volume Master Key (VMK) with its Storage Root Key (SRK) inside the TPM, which is never revealed. So TPM PCRs + SRK = decrypted VMK. [link](https://slideplayer.com/slide/1518007/5/images/21/BitLocker+keys+Separate+VMK%2FFVEK+adds+flexibility+%E2%80%94+how.jpg) – Andrew Jul 16 '19 at 11:06
  • I think we might mean the same thing, but the value of each PCR is a single hash. Each time you extend a PCR with a new piece of data, the result is: hash(old hash, new data). The bank of PCRs are therefore read as a list of hashes. – Andrew Jul 16 '19 at 11:08
  • I don't see what extra protection the VMK provides? In any case, if a key protector is leaked, then the FVEK is obtained. In any case, the FVEK cannot be changed without re-encrypting the whole disk? – Shuzheng Aug 05 '19 at 09:04