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.

  • 3
    "In forensics, we have known about this for years" Commented Mar 11, 2013 at 7:17
  • 1
    This isn't a new attack. It's obvious that TrueCrypt fails if the attacker gains access to a running computer with unlocked encrypted volumes. So you need to power-off your comp or at least unlock the encrypted volumes when police knock down your front door, or whatever your attack scenario is. | Hardware based encryption has its share of issues too, and I don't really trust it either. But if you're paranoid, you can use both at the same time ;) Commented Mar 11, 2013 at 7:56
  • To me, the question is squarely off-topic, and belongs to security.se. Also, the attack linked to in the question does not "retrieve decryption keys from a device's RAM (even after shutdown)"; as far as I understand, it retrieves the keys either from a running computer using a well-know attack using DMA-thru-Firewire (which is highly system-specific), or from an hibernation file when the computer was hibernated with the volume mounted; I'm not sure what are the fine prints for the later to work.
    – fgrieu
    Commented Mar 11, 2013 at 9:10
  • Don't forget about freezing the RAM. zdnet.com/blog/security/… Commented May 29, 2014 at 21:22
  • As of 5/2014 Truecrypt "is not secure as it may contain unfixed security issues" truecrypt.sourceforge.net Commented May 29, 2014 at 21:43

1 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .