How to defeat Cold Boot Attack? Current precautionary measures. Ans/Views/suggestions

If you encrypted them separately then the other volumes will have different keys, even if they share the same password as the system volume. During bootup TC temporarily caches the preboot auth password (if requested) and passes it on to the "system favorites" volumes that you want TC to mount during bootup.

 

Exactly. One other point....there are sometimes practical reasons (NTFS vs FAT 32 being one) why a person, like me, might want to use this method. It's not being done as a box within a box within a box for no reason, there is a method to the madness.

 

Thanks for the clarification, Dantz.

 

So are you saying that in the case where your system/memory is compromised (cold boot attack/memory dump), if you had cleared the cache and dismount the other partitions, the other partitions would still be securely encrypted? Even if they (system and other partitions) shared the same passphrase? And this applies towards encrypted containers (that shared the same passphrase) also not just partitions?

To elaborate: If I were to encrypted my system and other partitions separately (with AES + same passphrases for each) and if I were to set "cache preboot auth password" + "mount system faves automatically." If I would dismount all my other partitions and wipe the cache, and lets say my system partition had its key stolen from a cold boot/memory attack, so in this case my other partions would be secured and still safely encrypted in this situation? (As in whatever key or pass that is residing in the memory that was stolen because of system partition being mounted cannot be used to open other partitions)

 

You're mostly correct, although I'm surprised that you would even consider intentionally caching the password when you're trying to defend against memory attacks. However, if you really needed to do this then I suppose the best approach would be to use the /w (wipecache) switch immediately after mounting the volume(s). At this point no passwords would remain in memory. If needed, a quick dismount of all mounted volumes would wipe their keys, leaving only the system volume's key vulnerable, since it can't be quickly wiped. Nor (to the best of my knowledge) does TrueCrypt ever wipe this key, even during system shutdown. You'll just have to let it decay. This is why I suggested using secondary encryption along with system encryption.

However, keep in mind that other data might still remain in RAM, including data that might have originated from the encrypted partitions. When you dismount a volume TrueCrypt wipes its master key, but it doesn't wipe all of free memory.

 

I had such a great time reading this thread that I wanted to provide a link to the original paper, through Princeton University, Wind River, and Electronic Frontier Foundation:

http://citp.princeton.edu/pub/coldboot.pdf

And Caspian, the answer to your FBI question, here:

"There is one irony here. One Princeton Ph.D. student, Joseph Calandrino, is listed as having "performed this research while under appointment to the Department of Homeland Security." Because this research lets them bypass file-system encryption in some cases, police agencies are the most obvious and immediate beneficiaries of this research.

As early as 1984, the FBI Laboratory began developing computer forensics hardware. And we know from the Scarfo, Forrester-Alba, and Boucher cases how intent federal police agencies are in trying to find ways to circumvent the privacy that encryption provides. If the feds didn't know about these techniques already--remember, they were years ahead of everyone else in inventing public key cryptography--today will be a very good day for Homeland Security."

Read more: http://news.cnet.com/8301-13578_3-9876060-38.html#ixzz13Zv0Ioxo

 

Thx for the links nix!

-- Tom

 

An interesting observation from Microsoft...

Does this imply that a whole disk encryption product, running on a PC equipped with a TPM chip and using the Memory Overwrite Request feature, is substantially less likely to be at risk for a cold boot attack?

 

Substantially? Certainly not. The most likely scenario of a Cold Boot Attack is that the computer/laptop is still running or in standby. In this case the key is in RAM and you can't do anything about it (short of blowing stuff up with a kill switch).
If the system has been off (or in hibernate) for some time any FDE implementation will be safe.
So the only scenario left is an attack in the short time window between shutting down and the point were the remanent data is lost. Overwriting the RAM reduces this window to a split second.