Truecrypt compromised? (Coldboot attack)

Question

In light of recent developments in computer forensics and "password recovery" utilities, can encryption technologies such as TrueCrypt still be relied on for a high degree of protection?

It would seem to me as though the ability to retrieve decryption keys from a device's RAM (even after shutdown) means that hardware-based encryption solutions will be the way to go in the future.

Answer 1

can encryption technologies such as TrueCrypt still be relied on for a high degree of protection?

Yes, provided you understand exactly what protection you're getting from Truecrypt.

Encryption is not access control and it does not protect your system whilst it is powered on. Once you put the key material anywhere near the computer (e.g. typing it in, loading it into memory) you should treat the computer as containing the key material because it does.

Therefore, anything that can extract your computer's RAM can read this key material. This should not be remotely surprising in any way. I have looked through the truecrypt driver code in a fairly extensive way (I don't approve of the statically allocated stack buffers they use, they should prefer ExAllocatePoolWithTag, but what do I know?) and it would not be all that difficult to write a driver to pull the volume keys out of memory on a system which has truecrypt running.

If you want encryption of your disks to be effective, you must do two things:

1. Ensure that you do not attach the key material to the system when you can be observed by somebody you wish to prevent from accessing your data.
2. Have the system powered down when the data is stolen.

Against a casual, opportunistic thief, point 1 happens by default since the thief in question is almost never there when you are using your device. This makes disk encryption a good defence against stolen laptops, for example, since opportunistic thieves who steal powered down laptops get some hardware, but not some data.

The determined attacker, or what cyber-literature refers to as an advanced persistent threat, however, may have the resources to observe 1. This could be through several means:

1. Bugging the locations you input the key material including hardware keyloggers, cameras and whatnot.
2. Exploiting the good old remove the RAM, freeze it and whatever techniques preserve system memory after power down.
3. Compromising your system whilst it is powered on - firewire, malware, whatever.

This has been the case for as long as disk encryption has been in use and will be the case for as long as disk encryption is in use in its current form. Encryption does not protect you against these threats - for these, you need good access control, good auditing procedures, good security practises to prevent malware access, good physical security etc.

Slight update, for extra fun:

Hibernation is a known attack vector in modern operating systems which depending on your implementation stuffs up secure boot entirely. The work done on this was derived from the fact it was possible to bypass Patchguard by altering the page file to load code.

The motto of the story in these two cases is that the operating system cannot trust the state it loads from disk unless it has control of the CPU.

How does hibernating affect your in-memory key? That depends on whether the hibernation file exists on the encrypted drive or not. If it does, good - you'll need to re-enter the key to decrypt it (and you'll have prevented the hibernation file attack vector, too). If it doesn't, then if the key is written out into the hibernation file you are in trouble. If it isn't, you're still not massively safe, as a sufficiently determined attacker with serious resources can probably take advantage of that.