다음을 통해 공유

Multi-boot Security

  • 아티클

As people start analyzing BitLocker, a question that keeps getting raised is "Can I break into BitLocker by installing another copy of Vista?" This blog entry intends to show how BitLocker allows and supports multi-boot without compromising security.

There is a saying that "if it walks like a duck and talks like a duck it is a duck." If I put two operating systems on a computer, at what point are they the same operating system? And at what point are they different? If it walks like a duck (boots) and talks like a duck (accesses unique encrypted data) then for all intents and purposes from an attacker’s perspective, it is a duck.

It’s important therefore for BitLocker to be able to differentiate a real duck from a fake duck using some form of DNA.  To ensure no genetic experiments on the duck, the DNA is kept secret. In the case of BitLocker, the DNA is a key called the "Volume Master Key" or VMK. Without the VMK, the "Full Volume Encryption Key" (FVEK) is not known. Without the FVEK, the content of the encrypted volume is not known. Not only is it not known, but it cannot be meaningfully modified as (with the aid of the Elephant algorithm) Decrypt(FVEK, OriginalSectorData + DeltaModification) results in an unpredictable change to the entire sector. Niels wrote a paper on the benefit of the Elephant algorithm, described in the preceding blog entry.

For this reason, the fully encrypted volume can be considered a black box and the VMK is it’s key. The next question that arises is can the VMK be passed to a red box. For this we need to understand what happens during boot.
I will describe the boot process as 3 stages:

  • Early Boot
  • Mid Boot
  • OS Boot

In "Early Boot", all boot components write values (measurements) to the TPM as the boot process proceeds. An example of this is that the BIOS will measure the boot code in the MBR, and write this to PCR[4] of the TPM. If the MBR is correct, the correct value will be in PCR[4]. If the MBR has been modified, the wrong value will be in PCR[4]. In either case, the MBR (legitimate or malicious) will be measured and will be executed. The TPM accumulates these measurements in a manner that cannot be undone unless the hardware is reset. It is important to ensure that all measurements are correct (therefore no modification to code) to successfully have the necessary PCR pre-conditions to allow the TPM to unseal the VMK.

In "Mid Boot", the time comes where the VMK is required to transition from "Mid Boot" to "OS Boot". BOOTMGR communicates with the TPM sending it a block of data previously encrypted by the TPM, and requests that the TPM decrypts the block of data. The TPM checks the values of PCR’s along with the values and policy conditions encoded into the block of data. The TPM also verifies the MAC (Message Authenticity Check) to ensure that the block of data was not tampered with. A legitimate BOOTMGR can obtain VMK, or know that it cannot obtain a VMK. A modified BOOTMGR will only know that it cannot obtain a VMK. If the VMK cannot be obtained, then there is nothing the modified BOOTMGR can do to open the black box. It is obvious therefore that the legitimate BOOTMGR must be used to retrieve the VMK at this point.

In "OS Boot", the legitimate BOOTMGR transitions to an active role to protect the VMK. The legitimacy of the BOOTMGR has been proven (above) implicitly by the fact that it has the VMK for a given volume. BOOTMGR must transition to the OS Loader, and it must do so without giving the VMK to the wrong OS Loader. This is where things get interesting. The metadata associated with the OS Volume contains a set of requirements indicating what boot executables are considered valid - more than one is required to support memory testing and to support resume from hibernate. BCD policy is also stored to ensure most BCD settings cannot be modified. To ensure the metadata is not tampered with, a MAC exists. Calculating the MAC requires knowledge of the VMK.

Before BOOTMGR transitions to the OS Loader, it verifies that the OS Loader and BCD settings are trusted. At this point the OS Loader can be trusted with multiple keys, but only if the metadata for the associated volumes indicate explicit trust. Modifying an OS Loader will immediately invalidate this trust. BOOTMGR also ensures that no more BitLocker keys can be accessed by writing a value to PCR[11] that is akin to locking a safe until the next boot.

Prior to transitioning to the OS, the OS Loader ensures that it will hand off at most one key (VMK) to the OS. Prior to handing the key off to the OS, the following conditions must apply:

  • All components up to and including BOOTMGR must be correct. If they were not correct, the VMK would not be available.
  • VMK must be correct to validate the MAC of the metadata. BOOTMGR verified this MAC.
  • OS Loader must be the loader approved by metadata associated with VMK. Verified by BOOTMGR.
  • BCD settings must be the settings approved by metadata associated with VMK. Verified by BOOTMGR.
  • VMK must correctly decrypt FVEK stored in the validated metadata. Verified by BOOTMGR.
  • FVEK must successfully decrypt data stored on the volume. Incorrect FVEK will result in invalid executable code or invalid data. In some cases this is caught by code integrity.
    • MFT must be encrypted by correct FVEK to access all files.
    • Phase 0 drivers including fvevol.sys must be encrypted by correct FVEK.
    • Registry must be encrypted by correct FVEK.
    • Kernel and Hal must be encrypted by correct FVEK.
    • Phase 1 components must be encrypted by FVEK, as fvevol.sys (encrypted by FVEK) will only decrypt using the same FVEK.
    • Phase 2 components must also be encrypted by FVEK etc.

The last point is particularly important, and is only true if the data on the volume is entirely encrypted - i.e. a volume where encryption was paused half way through is not secure. The black box OS described earlier will therefore meet these requirements; whereas the red box OS will not.

Conclusion

As only the OS that was encrypted by a given VMK/FVEK combination can access the VMK, multi-boot is not only secure, but very much a central part of the BitLocker design and threat analysis.

Jamie Hunter