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."
is over?
Don't people burn memory blocks any more? This is sensitive data handling 101.
Way too tedious (and requiring physical possession of the hardware after encryption passwords/etc have been entered!) for the modern NSA -- they'll just install keylogging hardware that communicates over radio frequencies and not the internet if they need your encryption key. Then, your hacked ethernet/bluetooth port will also send them image of your drive over RF or some other discreet channel. Who needs this!?!
While good to know these types of attacks exist, TrueCrypt's security model is still holding strong. http://www.truecrypt.org/docs/security-model
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.
I guess this means no hibernating any more.
Now I'll have so much extra time every winter!
This seems like the almost classical DMA attack, which I was first acquainted with on Apple G4 PowerBooks via FireWire. My ExpressCard-equipped laptop is probably vulnerable as all PCIe devices get full DMA access by their nature, unless I disable the whole slot from the BIOS.
Fun times. But nothing /really/ new, or is it?
Nothing that you mentioned would prevent someone from taking a memory dump of your machine.... With firewire, pci slots, or other DMA-capable hardware slots, memory can be captured with physical access and no user credentials required. With (root) user credentials, memory can be captured through projects such as LiME that are kernel modules that dump physical memory to disk or over the network.
A billion people not in your parents' basement?
Or you could just read the ecryptfs key from memory just like this does, the "vulnerability" here is that the software needs to actually have the key someplace in order to do the encrypting and decrypting, which is kind of hard to get around. OS makes no difference.
Well a few points...
Well, you can use swap partitions, if they're encrypted. There are other ways to get a memory dump as well, you know. There are various nefarious ways to do this, if you are clever ;)
But what makes you think that if an attacker were able to get a memory dump of your system somehow(perhaps via firewire as an example), that ecryptfs on Linux would fare any better than TrueCrypt with regards to extracting the key from said memory dump.
The choice of operating system isn't really relevant here...
The summary implies physical access is needed. But if they have remote (root) readout they could still get a ram dump and go at it, couldn't they?
Is there a tool that automatically removes sensitive information (like encryption keys) from core dumps?
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.
Wire up that case intrusion detection switch and tie it to a key destroyer. Plenty modern boards have'em, might as well use'em. Still not a panacea, but a start, and useful along with disconnecting external usb ports and so on.
The moral of the history: if you have sensitive encrypted information on your laptop, never travel on standby mode, always turn off or use hibernation over an encrypted file or partition
Are they saying that it's possible for someone to read the contents of an encrypted drive if it's mounted? Wasn't this always obvious, or did I miss something?
-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.
Plenty of ports can do DMA, dumping all physical memory without any say by the operating system, all without opening the case. Anything on the PCI bus can do it; do you have an external PCI port? No? Did you know that PCI is routed over DisplayPort? And of course Firewire can do it. And so can ESATA. And laptops have card slots and docking station ports that expose a lot more avenues for attack.
Good luck getting all those disabled, not just in the OS, but in the hardware layer.
Yes, that's way too difficult for us. You are totally safe. No need to do anything else. We've all quit and found regular jobs in the private sector.
they need to get a ram dump wile true crypt is running and mounted. and at the point if they can tell what is running and when aka full remote access they can use a key logger for the same effect.
Seperent hunh? Interesting...
Way too tedious (and requiring physical possession of the hardware after encryption passwords/etc have been entered!) for the modern NSA -- they'll just install keylogging hardware that communicates over radio frequencies and not the internet if they need your encryption key. Then, your hacked ethernet/bluetooth port will also send them image of your drive over RF or some other discreet channel. Who needs this!?!
Corporate spies, private contractors, miscellaneous extrajudicial entities, local brute-squads that don't want to communicate with their local fusion center (or other organizations with greater jurisdiction (i.e., up to no good (i.e., everyday "police business"), don't get along, etc.)).
no you can encrypt with public key but need to decrypt with a private key, there is no reason the private keys would be stored in the malware thats doing the encryption and as a result not in the memory either
TruCrypt can be written to automatically unmount the 'drive' as the computer goes to sleep
It could, but it isn't. I was shocked to discover that my TC volume was still mounted after resuming from sleep. After all, notebooks get stolen, and that is why I have my passwords and SSH keys in a TrueCrypt volume. And notebooks are not normally shut down but put in sleep mode instead. So I discovered that the way Truecrypt worked made it's encryption quite irrelevant...
I fixed the problem on my Ubuntu notebook with a "tc-unmount" script in /etc/pm/sleep.d/ but I guess not many people do that. In Windows, I think there is a configuration setting for unmounting on sleep, but it was not enabled by default last time I looked.
So, while it may sound impressive that it is possible to extract the keys from RAM, it is usually unnecessary. The volume may simply be mounted and directly accessible, even after sleep.
But who the hell uses Windows anymore?
Not-so-Serious Business, grandma, and gamer "dude."
That probably counts as accesible any truecrypt volume you have in AWS and other cloud servers. Regarding your PC and laptops, there is anything in the NSA catalog targetting specifically this? They could had put it in when you bought it. If well a backdoor installation could make things simpler, this hardware approach could survive OS reinstalls/replacements.
The choice of operating system isn't really relevant here...
Well TrueCrypt kind of implies Windows, as Linux people tend to rather use cryptsetup/LUKS/dm-crypt, BSD people use geli/cgd and Apple people use something shiny
CLI paste? paste.pr0.tips!
It seems like the attack vector people are worried about here is "people get physical access to your machine while the key resides in RAM and extract it".
Could you program Truecrypt to maintain a continuous watch via a laptop's built-in webcam for the physical presence of someone at the keyboard (face detection, say), and upon detecting that the person has moved, dismounts the volume, overwrites the section of memory storing keys with random bits (to protect against "put the RAM modules in the freezer" attacks), kills the bulk of the Truecrypt software, overwrites it, and then kills itself? You could add other failsafes if you wanted, I suppose (based on the machine's microphone input, perhaps), but the idea is to have a dead-man's switch that will automatically dismount the partition and remove the keys from memory when Something Goes Wrong, so the keys are only around when you are actually sitting there working, and as soon as you aren't there, they are wiped.
> 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."
By investigators, do you mean government workers conducting industrial espionage?
http://www.washingtonsblog.com/2013/10/nsa-busted-conducting-industrial-espionage-in-france-mexico-brazil-and-other-countries.html
http://www.abc.net.au/news/2013-12-04/asio-arrests-key-witness-in-east-timor-spying-scandal/5132954
http://www.globalresearch.ca/canada-spied-on-brazils-government-as-part-of-global-commercial-espionage-campaign/5353642
http://www.smh.com.au/national/australian-spy-agency-helped-bhp-negotiate-trade-deals-20131106-2x1sw.html
https://www.techdirt.com/articles/20131111/11532125198/australia-spied-japan-to-help-companies-negotiate-trade-deals.shtml
http://www.crikey.com.au/2013/12/02/revealed-the-government-agency-stealing-ideas-from-businesses/
http://the-japan-news.com/news/article/0000940560
http://www.theguardian.com/uk/2013/jun/16/gchq-intercepted-communications-g20-summits
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.
Why can't there be SATA controllers with drive encryption support? Your drive encryption program could then just be an expansion UEFI ROM card that prompts you for your password and sends it to the SATA controller, then erases it from main memory. There's no need to do anything else after that point, because encryption and decryption would be completely transparent to all software on the system.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Can somebody give us some pointers about the techniques for recovering arbitrary information such as how keys, card tracks, passwords, etc from memory?
Presumably, hostile code is injected into a running process, but once that happens, is it a brute force search? Or is something cleverer done, e.g. monkey-patching subroutines in memory, and reading fixed offsets on the stack, or indexing something off the stack into the heap?
Memory-scraping has been in the news (mostly for the wrong reasons lately), and I'm wondering how this is actually achieved in practice.
Yes, TrueCrypt implies windows.
The parent implied that his use of Linux and ecryptfs somehow protected him from this type of attack, which really it doesn't, just this particular implementation of this attack.
My point is, that other full disk encryption implementations are typically vulnerable to the same sort of attack, that is the encryption key is going to be stored in memory.
There are in fact tools to extract keys over firewire(or other methods) for a variety of operating systems, not just Windows and TrueCrypt, consider Inception
Oh man windows crashes, you must have been the life of the fucking party in 1996. Your wit knows no bounds, I am humbled by your comedic genius. Of course Ubuntu does the same thing you just described...
Only the State obtains its revenue by coercion. - Murray Rothbard
You mean like the Yubikey?
http://www.yubico.com/products/yubikey-hardware/yubikey/
Don't forget: you can still encrypt with a keyfile you keep on a microSD card in your wallet. [copy to a USB stick in a lockbox, in case you lose it or get robbed.] Then, they can have your key, they still need the file.
Pay no attention to the man behind the curtain with all your metadata.
The choice of operating system isn't really relevant here...
Well TrueCrypt kind of implies Windows, as Linux people tend to rather use cryptsetup/LUKS/dm-crypt, BSD people use geli/cgd and Apple people use something shiny
Why would TrueCrypt imply Windows? I use it all the time on OS X and Linux.
Word documents for client "A", open that specific volume, make an edit, unmount. Excel spreadsheets? Same thing.
You will spend your entire days entering keys.
Because you have so many of them, you will have to write them down, or use some trivial progression algorithm.
Your keys will be weak because getting all those random gibberish keys just right will drive you to drink.
This is one of those ideas that sounds good, but is totally impractical in application.
What other methods of key storage are there other than relying on wetware ?
Sig Battery depleted. Reverting to safe mode.
Pass, Keepass, Xkeepass and so on, all do the same obvious thing. Just like a physical key ring, they allow you to lose all your keys at the same time.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Shut your machine OFF before you get to the border; don't put it to sleep.
The first question to ask is "Why you are carrying high risk/high value files across an international border?"
No affiliation, but this sounds like a good reason to move to TRESOR-like implementation in which the AES key is kept in hardware registers that are cleared when you go to S3 and on each reset. It's still vulnerable to anyone that gets root access to your OS, but a cold-reboot attack or a DMA attack on the RAM are not going to work -- so that's some forward progress.
Anyone want to take a stab at porting it to TrueCrypt?
Talking out my ass with a basic layman understanding, and no education to back it up, but here goes... Encrypt/decrypt what goes in/out of RAM? I have always thought a light sensor that uses the lighting of the room/wavelength/brightness as a means of generating random encryption keys would be useful. Or pull random info from your face moving around on a webcam, something that just can't be duplicated.
If you're an uptime freak, you upgrade the Linux kernel without rebooting. I even had an employee swap out a CPU without a reboot once. I guess that CPU was completely idle at the time. (The machine had two CPUs.)
And like a physical key-ring, no one else has developed a better solution that actually works in the real world.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Western Digital World Edition drives and some other network capable external drives run Linux. Truecrypt runs on Linux, so there's no reason you can't run Truecrypt (or cryptsetup) in your external drive.
cryptsetup may well be included already in the default firmware.
If you're using TrueCrypt but without full disk encryption, encrypt your pagefile: http://www.sevenforums.com/tutorials/143662-page-file-encryption-enable-disable.html
"Politicians and diapers must be changed often, and for the same reason."
You could get a non-NSA backdoored cryptocard from the German Privacy Foundation and store your stuff behind a PIN in a tamper proof device.
I just don't understand why your bootloader cannot be modified to fill all the memory with zeros and then give you the opportunity to power-off.
Actually they have - sort of. The general idea is to replace the metal thing on your keyring with (a part of) yourself. You can get door locks that uses bionics to unlock/open the door instead of keys, which can be lost, stolen, duplicated or circumvented with picks. Most bionic solutions today are insecure, flawed, buggy or just not good enough, but I'm sure that will change as the technology matures.
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
If attackers have sufficient access and sufficient privilege to dump a snapshot of your RAM then all bets are off. Dumping RAM is the least of things they could do - they could directly steal the secrets off the volume itself if they were that interested in them, or log keystrokes, or install rootkits etc. Heck, why not just replace the TrueCrypt binaries with modified ones which write the passphrase off somewhere and lift that later?
Biometrics is your username, you still need a password.
Waiting for an amusing sig.
Truecrypt is used across many platforms. Unlike cryptsetup / loop fun, you can walk it to a windows box, mount and modify, and walk it back.
Will this help beat ransomware like Cryptlocker?
Sure. My point was, nobody actually uses it outside the Windows world.
CLI paste? paste.pr0.tips!
well you're doing it wrong then
CLI paste? paste.pr0.tips!
The NSA's makin' a list, checkin' it twice... It's like Christmas all over again!
CAPTCHA: approved
>With the creation of these plugins a wide range of investigators can now decrypt Truecrypt volumes regardless of the algorithm used
Yeah, just want we want, people _helping_ the NSA and GCHQ.
Haha you're using windows, binary closed blob driver Radeon, and IE... and yet you talk about serious security! How cute :)
For Windows: System Properties > Advanced > Startup and Recovery > set Write debugging information to (none).
This is the file (memory.dmp) needed to do the scan if the computer has been turned off and there are no volumes mounted.
This file gets written when there is a System failure unless the switch is turned to (none).
I understand that reading from RAM (or a dump of) is a valid issue, but we're talking about RAM here. It's not persistent storage. Why can't there be a kernel level tool which, upon a complex keystroke, RAM is zeroed-out. Obviously this would crash the running OS, but then, you probably don't care at the point you saw such a need.
What about tools that cleanly shutdown an OS, and wiped RAM just before cycling the power supply? Maybe linked with the computer's bluetooth sensor (to detect that the user has moved a certain distance away). Some systems have motion sensors now too - I can see ways to integrate, say, detection of a strong shock (such as slamming the laptop lid down, or someone snatching the system and trying to run)...
Frankly - if your data security needs are so sensitive, that you're worried about someone snatching the system from you while its running. You're going to need to give up some luxuries of convenience.
And you have more faith in KeepAss's security than TrueCrypt's?
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Indeed. If they have access to your RAM, they could copy that and probably filter an open document of there just as well as a password.
Actually they have - sort of. The general idea is to replace the metal thing on your keyring with (a part of) yourself. You can get door locks that uses bionics to unlock/open the door instead of keys, which can be lost, stolen, duplicated or circumvented with picks. Most bionic solutions today are insecure, flawed, buggy or just not good enough, but I'm sure that will change as the technology matures.
Biometrics? It's just a signal on a fucking wire. The biometric reader scans your finger, your retina, your anus, whatever, and creates some sort of flimsy hash of that scan and sends that hash over to the authenticating system. The hash is flimsy because you need to be able to log in tomorrow when your finger is slightly different due to how you pressed it on the reader, your retina has aged and deteriorated, and your anus is covered with a different patterns of shit particles.
Morons who like biometrics like to tout "Something you have, "something you know, and something you are" as some sort of trifecta of authentication.
With biometric scanners, "something you are" is simply something you have.
"Something you have" is pointless. When you're arrested, THEY have YOU and everything YOU have.
"Something you know" is the only thing that means a damned thing. When you authenticate with remote systems, it's all "something you know" anyway. Your bank doesn't send someone to your house to verify who you are or that you have their little temporal password authenticator.
Is there a file that or something in init that gets activated on sleep?
If so, should just be a matter of "truecrypt -d" or something like that whenever the machine is going into a suspended state.
These types of "attacks" are very common in police forensics and hence the forensics community have studies ways of how to do encryption with stored keys that don't store them in memory (to for example avoid cold-boot attacks.
One of the interesting approaches are taken by the TRESOR team. They store encryption keys in CPU registers instead of main memory, making a cold boot attack, or hibernation attack impossible.
They have implementations for Linux and Android phones. The Linux implementation on an Intel with AES-hw support is even slightly faster than doint key expansion in memory! It's an interesting approach, but perhaps a bit over the top for most cases.
Stefan Axelsson