Slashdot Mirror
TrueCrypt Master Key Extraction and Volume Identification
An anonymous reader writes "The Volatility memory forensics project has developed plugins that can automatically find instances of Truecrypt within RAM dumps and extract the associated keys and parameters. Previous research in this area has focused specifically on AES keys and led to the development of tools such as aeskeyfind. The Volatility plugin takes a different approach by finding and analyzing the same data structures in memory that Truecrypt uses to manage encryption and decryption of data that is being read from and written to disk. With the creation of these plugins a wide range of investigators can now decrypt Truecrypt volumes regardless of the algorithm used (AES, Seperent, combinations of algos, etc.). Users of Truecrypt should be extra careful of physical security of their systems to prevent investigators from gaining access to the contents of physical memory."
Given that we're in an era of low-cost portable devices (Raspberry-Pi, BeagleBoard, etc.), it would be really nice if TrueCrypt could implement a driver that passed data off to an external, open-source device for processing that held the keys in its own memory, and provided no other service than to perform the cryptographic functions and hand back the data. It would be slower, but at least then you don't have the keys in memory on a general purpose computer running browsers, java, flash, adobe reader, etc. etc.
Take one of those devices and attach a small screen to them and you could enter your passphrase using a keyboard attached directly to them, and use a keyfile on a flash stick plugged into the USB port too. The distro powering all of this could be minimal and audited.
TrueCrypt has to keep the keys somewhere so long as a volume is mounted. Whatever happens, so long as it's not currently on the CPU (and potentially even if it is), something that can read its data structures is always going to be able to find the keys in RAM if the structure is known. Maybe if TrueCrypt has some crazy polymorphic engine and corresponding polymorphic data structure that changed on every run it could get very difficult, but probably not impossible, to extract them.
I wouldn't be claiming this until the audit is completed.
http://istruecryptauditedyet.com/
Did you ever wake up in the morning, with a Zombie Woof behind your eyes? -- FZ
A billion people not in your parents' basement?
Also, you have to ask how much worth would that would be.
If they have your RAM dump the securiy has been already lost.
Shut your machine OFF before you get to the border; don't put it to sleep.
I do not fail; I succeed at finding out what does not work.
"While not perfect, such activity can be mitigated. TruCrypt can be written to automatically unmount the 'drive' as the computer goes to sleep/hibernate/etc' for FDE, it does dismount and scrub the key during hibernation. Sleep is different though and RAM is not cleared during it. "and could even be written to plop the keys into a random section of RAM each time it re-connects." This doesn't really change anything. TC must still be able to find the key and the current drive version could be extracted from memory and reverse negineering to determine where the key currently is.
Not if it throws away the key and prompts you to re-enter it every time it wakes back up.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
-a KEYLOGGER is an infinitely greater risk to the use of ANY encryption system, and keyloggers are trivially inserted into a PC via almost unlimited numbers of hardware and software methods.
-gaining access to the current RAM of a system is just about the most convoluted and 'expensive' method of a targeted attack. The contents of RAM, of course, are lost once the system powers down. If you are targeted, there are a million easier ways of gaining your password. Many simply use the placement of hidden cameras. At the other extreme, remote equipment can be used to recreate your screen content via EM radiation emitted by the display and drivers.
If Truecrypt is coded properly, it can attempt to keep the 'key' within the caches of the CPU only, and avoid 'write-back' on most processors. If RAM must be used, there are numerous obfuscating RAM usage methods that can prevent the key from living in predictable sequences of RAM bytes. However, you can assume Trucrypt is doing such as much as is useful. Truecrypt FAILS the moment the user is a LIVE (as in current Truecrypt user) target of a 1st class US intelligence operation. Gaining the password from a person who is still entering the password on a regular basis, when money is no object, and the Law is bent as is required, can be taken for granted.
The owner's of Slashdot promote stories like this for one reason- to DISCOURAGE as many people as possible from bothering with Truecrypt in the first place. If naive sheeple THINK Truecrypt is as compromised as the NSA back-doored products from Microsoft et al, they'll 'think' they might as well use the Microsoft or similar product, because of ease of use.
EVERY anti-Truecrypt story is NSA FUD. EVERY commercial encryption package, for instance, allows warrantless searches at the border to reveal the use of encryption, and allows the agents to strong-arm the KNOWN existing passwords from you. However, despite what the vile shills tell you here, used properly there is ZERO trace of actual encryption use on your laptop with Truecrypt, so the probability of warrantless hassle is reduced to as close to zero as you are going to get.
Upon unmount, TC should write (and overwrite) lots of random junk to the ram it was using to store keys so you don't have to worry about stale ram recovery techniques.
Even better, start not just having one TC volume, but many. Separate your stuff out by what you are doing, and unmount it when you are done. Word documents for client "A", open that specific volume, make an edit, unmount. Excel spreadsheets? Same thing.
This way, if the computer gets taken and the master drive image key slurped off, it means control of the OS, but not much else.
Even better, to prevent data leakage (/tmp files), the next step up is having virtual machines or Evalaze-sandboxed applications that channel all writes to one volume, that is easily unmounted.
TrueCrypt is just one tool in a toolbox.
Of course, there is the fact that people may not have to worry about seizure. My biggest security threat are the meth-heads who will break into a place just to grab stuff to take to a pawn shop or fence in order to stop their DTs. They don't care what's on the machine, so basic encryption turns a hardware + data theft into just hardware lost... which is easily replaced by insurance.
Actually, TrueCrypt already has most of those features so they don't need to be written in
TrueCrypt 7.1a for Windows has the following options:
AutoDismount If:
- User Logs Off
- Screensaver Is Activated
- Entering Power Saver Mode*
- Dismount if no data has been read/written in (xx) minutes
I haven't tested ALL of them but I know the screensaver one works. Features may differ depending on platform.
* with a warning that the Windows OS may not properly alert applications that it is shutting down due to low battery power so this feature is not entirely dependable; this seems more a limitation of the OS than the application
And according to the Truecrypt website: "As Microsoft does not provide any appropriate API for handling hibernation and shutdown, master keys used for system encryption cannot be reliably (and are not) erased from RAM when the computer hibernates, is shut down or restarted."
I use Truecrypt for the entire harddrive on my laptop. And when it hibernates, I have to feed it my Truecrypt password to get it back awake.
Presumably, the difference is that I use whole disk encryption, rather than just a part of the disk....
"I do not agree with what you say, but I will defend to the death your right to say it"
The risk is limited to only when you are sitting at your computer. As soon as you lock your computer, the key is purged from ram.
I hate grammar Nazi's.