The Trustworthiness Of BitLocker

A concerned individual sent me an e-mail relating to claims I made in a previous article about BitLocker, Microsoft Windows’ integrated full disk encryption software. In the article I suggested that full disk encryption on Windows systems might be a waste of time against a nation state level adversary. I stand by those comments.

An article on mashable about a month ago detailed claims that the alphabet soup agencies asked for (and it is implied likely attained) a backdoor that would allow BitLocker encrypted volumes to be read. Given the closed source nature of both BitLocker and the Windows operating system it is impossible to substantiate this argument in either the affirmative or the negative.

Given Microsoft has a history of cooperation with the NSA (remember the suspicious NSAKEY that was found in the crypto DLL about ten years ago?) I feel it is reasonable to assume that the alphabet agencies have some means to subvert the software.

Most disk encryption software does not actually encrypt the entire drive with the user supplied passphrase. Such a scheme would, amongst other things make changing the passphrase a less than trivial process as the entire disk would need to be decrypted with the old passphrase and encrypted again with the new one, block by block. The typical solution to this issue is to generate a strong and long random key which is used to encrypt and decrypt the data. This key is then encrypted using the user’s passphrase (which is usually stretched using a few thousand rounds of PDKBF2) and stored on the disk. When mounting an encrypted volume the software requests the passphrase (or token) from the user and uses this to obtain the actual on disk encryption key. This system allows almost instant password changes with the caveat that the static key used to actually encrypt the data on the disk never changes and thus if it is compromised directly (through, say a cold boot attack) the user may falsely believe that changing the password will re-secure the volume. Naturally such a scheme also creates a single point of failure such that if the blocks that store the keying data are corrupted the entire volume is rendered unreadable. Sometimes this is used advantageously as a way of effectively immediately rendering the disk unusable by overwriting just those blocks. Most schemes store the data in two or more separate locations at diverse positions on the disk, for example one in the volume header and one in the footer.

A subverted full disk encryption solution could store only slightly more data in this area and allow bypass by storing not only the on disk key encrypted to the user’s passphrase but a copy that is encrypted using the NSA’s public key. This is essentially a form of key escrow with the exception that the term generally implies the user has knowledge of it occurring.

A slightly more robust (and covert) scheme involves limiting the entropy of the pseudorandom number generator used by the encryption software. This has the advantage that a reference implementation which successfully opens an encrypted volume could be released (along with full source code) to essentially prove they have nothing up their sleeve. Of course should someone use the “clean” implementation to create a new volume this volume would not be generated with the deliberate entropic weakness but you can almost guarantee that few users would have the inclination or skill to compile from source and most would use the officially distributed binaries. With a closed source operating system you could even defer random number generation to a library which is shipped with the operating system thus ensuring that even the “clean” implementation would produce the required weakness. Third party that relied upon said libraries would also be able to be compromised. The dirty PRNG could indeed produce random numbers but with a confined seed thus reducing the amount of time a brute force attack would take when such seed values are known. It could also simply be running AES in counter mode and working from a known secret which then becomes the agency’s master key.

The implementation could also deliberately leak the key perhaps stashing it elsewhere on the drive in an obfuscated manner and then using the ATA command set to tell the drive controller to mark these blocks as bad. It could then zero the logical blocks with the knowledge that they have been remapped and the key persists on the physical media. This is obviously platform dependent. The implementation could also conceivably leak the key during the initial Windows activation or during a Windows Update. If the HDD serial number is queried using SMART and transmitted along with the leaked key then a database would be held that could be queried by an agency like the NSA when they seize a computer that uses said implementation just by supplying the serial number of the disk. This would be far more persistent than storing the CPU ID, MAC address or other identifying information as the disk may be portable or could conceivably move from an old computer to a new one throughout its life. Failing this (say, if the disk has been cloned to another with a different serial) all known keys could be tried via a brute force attack. This would likely not take a lot of time on a modern cluster and would certainly be preferable to brute forcing the passphrase – which would not be feasible if a strong one of a long length is used. We will assume that the user is smart enough to avoid using natural language or a simple password that could be determined using a dictionary attack.

My point here is that I cannot definitively say that BitLocker contains a backdoor nor can I claim that it is safe. Given the source code of Windows is not available for review this will remain a topic of contention. Even if the source code was available a subtle backdoor may indeed go undetected (see the attempted Linux backdoor where using = instead of == in the code would allow a privilege escalation for an idea as to just how subtle these things can be). Assuming that the code is clean and has been audited one could not guarantee that the public binary release of Windows is identical to the one released as source without Microsoft adhering to some kind of deterministic build system to actively allow such an audit to take place.

Given the number of proprietary drivers (and other code that is bound by third party licensing and/or NDA) included in Windows it is doubtful that Microsoft could ever fully open source Windows even if they wanted to (and they clearly don’t).

My advice therefore remains unchanged. Don’t rely on BitLocker (or Windows at all for that matter) to protect your secrets, particularly if your threat model includes the government as a potential adversary.