(Reposted from my my old blog).
Some rather interesting AntiSec/Wikileaks stuff is posted at Cryptome.org regarding lawful access to various things. What caught my eye are the docs relating to BitLocker, as I’ve been curious to know whether it’s backdoored as many speculated. And it’s only ethical to expose whatever flaws are found in a publicly trusted cryptosystem.
Attacking a Typical Cryptographic System
Attackers rarely bother with codebreaking, because it’s usually more effective to go for whatever the cryptosystem is deployed on. As it happens, most of those attacks are successful because people are generally unaware of how keys are stored and managed, and because analysts know where to look.
In other cases, attacks are successful because a given cryptographic system was badly made. It might be designed to store keys in system memory, but not to prevent them being read by another program, to clear the memory location after, or to prevent the keys being swapped out. Incidentally, BitLocker does protect against ‘cold boot’ attacks, and it works near the hardware layer.
There is no Backdoor, it Seems
As we can see, the proper selection, implementation and use of cryptography isn’t an easy task, and this can provide several methods of attack. The good news is BitLocker appears overall to be quite strong, and the leaked documents make no mention of a backdoor. Microsoft essentially says the only way to decrypt a volume is to somehow find the key, and that’s the task of the law enforcement agency. This does make sense, as many of Microsoft’s corporate users expect BitLocker to provide decent protection against foreign governments. From the Building Confidence in the Cloud report (2010), it seems Microsoft also recognises trust has become a major issue for any company trying to achieve market dominance.
The first document leaked outlines the process for duplicating the key from a live system, which might enable data recovery on another workstation running Windows OS. A couple other methods were suggested in the second document – running Manage-BDE.exe, or an incident response script that automates the recovery process on a live system.
Obviously, physical access to the system is needed while it’s running, and I’m assuming where BitLocker won’t be configured to use the Trusted Platform Module. The key’s ID can be determined by forensic analysis of the encrypted drive, and I’m wondering whether the key itself could potentially be derived from that.
TPM, USB, PIN and Authentication
There are several modes of authentication that use a Trusted Platform Module, USB drive, PIN, or different combinations of these. It makes things a little harder for the attacker, who must determine which mode’s being used, but it really boils down to where the key is stored.
If the authentication is done entirely by the TPM, the volume can be encrypted and decrypted seamlessly on the machine. Although the key itself should be encrypted in the TPM, a skilled attacker with the resources could potentially recover it.
Authentication could also be based entirely on the USB drive. This protects the encrypted volume against those without the drive if they do get physical access to the machine. Of course, ensuring the recoverability of the data involves backup copies, which in turn means a greater chance of the key being mislaid or stolen.
The TPM and PIN mode provides two-factor authentication, where the key is stored in the TPM and protected with a PIN. This would also be vulnerable to hardware attacks.
Finally the PM and USB drive are used together. This means physical access to both the target machine and the USB drive is required.
So, BitLocker itself appears to be a pretty strong AES-based cryptosystem, and judging by the leaked documents there’s no backdoor law enforcement agencies are aware of, which also means the storage volume will be reasonably safe against most threats if implemented properly and the key is well protected. What should be noted is the level of security can depend on whether the TPM, manufactured by a third party, itself is backdoored or resistant to hardware-based attacks.