TrueCrypt Master Key Extraction and Volume Identification 222
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."
Burn after reading? (Score:4, Insightful)
Re:Burn after reading? (Score:5, Insightful)
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.
Re:Burn after reading? (Score:5, Informative)
Also, you have to ask how much worth would that would be.
If they have your RAM dump the securiy has been already lost.
Re: (Score:3, Interesting)
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, and could even be written to plop the keys into a random section of RAM each time it re-connects. Hell, you could even rig an option to unmount the drive when the screensaver comes on.
That would only leave the ability to access it when the computer is active - but then it's pretty much game-over in that situation anyway.
Re:Burn after reading? (Score:5, Interesting)
Re:Burn after reading? (Score:5, Informative)
Not if it throws away the key and prompts you to re-enter it every time it wakes back up.
Re: (Score:2)
THats called hibernate.
Re:Burn after reading? (Score:5, Informative)
Re:Burn after reading? (Score:4, Interesting)
So ultimately, if you want to keep your data secure, you need to shut down your laptop at least several minutes before it could be potentially seized. I remember last year reading a piece about how even volatile RAM, if kept very cool, could be read with some fidelity even after a computer had been shut down, but these seem like lab conditions. I think we're along way from declaring disk encryption "crackable", providing appropriate measures are taken.
Re:Burn after reading? (Score:4, Insightful)
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.
Re: (Score:3)
You can defend against such attacks with some work. First make sure that the BIOS is locked with a password and set to do a full memory test a boot. That way even if they grab the machine and hit the reset button to boot their malware CD/flash drive the BIOS will first erase the entire contents of RAM and they won't be able to stop it (make sure your BIOS doesn't allow the test to be cancelled). The password makes booting from CD/USB impossible without forcing you to reveal it either
Unfortunately they may b
Re:Burn after reading? (Score:5, Informative)
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."
Re: (Score:3)
At least for hibernation, using BitLocker on the system drive will make sure the hiberfil.sys (and I guess the paging file as well) is on an encrypted volume that can't just be copied and analyzed later.
Re: (Score:2)
The thing with hibernate is that it's capturing an image of memory, and storing on your disk. Handy when you want to wake up from really-powered-off, but also handy for anyone who wants to do a forensic analysis of everything in memory when it went to sleep. Ditto iPhone backups too IIRC, which is why (a) I don't use hibernate, and use sleep unless I'm expecting something invasive like going through US Customs where they apparently have free reign over your constitutional rights, and (b), iPhone backups are
Re: (Score:2)
Autodismount is not, of course, applicable to FDE.
TC is usually still mounted after sleep anyway (Score:3)
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
Re:TC is usually still mounted after sleep anyway (Score:5, Interesting)
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....
Re: (Score:3, Funny)
It's that Southern Cypherpunk series of books about a hacker/waitress, Mary Sue Stackdump.
Re: (Score:3)
Ideally, you'd just use an OS that's secure against arbitrary programs reading out all of your RAM contents. Unforutnately Windows is not such a beast, and GNU/Linux has RAM sims mounted as a gods damned file. Unfortunately none of the mainstream OSs were designed to be secure.
Unlike my "hobby" OS, yours do not have zero exploitable bugs, and do not employ rigorous unit tests, input fuzzing of all functions, and code coverage of every single instruction. Your OS's built in character or block device inter
Re: (Score:2)
Don't people burn memory blocks any more? This is sensitive data handling 101.
I knew I should have moved to the rim of that active volcano.
Re: (Score:3)
Well, you can set Windows 7 to wipe your RAM on shutdown, at least. It takes a good minute or two for 2 GB of RAM.
Although if you're really serious about running TrueCrypt on Windows, you should have virtual RAM disabled, too. And never hibernate. And have hidden volumes. And and and...
Stop please (Score:2)
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...
no need to reboot for kernel, cpu upgrades (Score:2)
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.)
Re: (Score:2)
Clearly crashing and dumping is a feature in Windows to appease the NSA.
at least this is old fashioned forensics work... (Score:4, Interesting)
Re: (Score:2)
Still working as intended (Score:2)
Re:Still working as intended (Score:5, Interesting)
http://istruecryptauditedyet.com/ [istruecryp...tedyet.com]
Re: (Score:3)
"I wouldn't be claiming this until the audit is completed."
Why not? Nobody else has cracked it, so unless and until the audit is completed, it is indeed "holding strong".
Re:Still working as intended (Score:4, Informative)
Nobody has claimed to have compromised Truecrypt, that is true, but as we know the NSA and other spook orgs would never admit it if they have and for all we know one of the anonymous developers works for a spook org.
Re: (Score:2)
Compare it to a new design for a physical safe. It's claimed to be too strong to crack. Now, it may be that eventually somebody will find a weakness, but until they do, the safe is still holding strong.
There's nothing at all wrong with that. It's just a matter of what assumptions you make about what the phrase means.
It's true that the NSA might have cracked it, but it's pointless to argue about that because it's likely that nobody else will ever know... unless of course the audit
Re: (Score:3, Interesting)
Suppose I find a vulnerability in some software. I've got two choices
1) Make it public and at best get a mention on slashdot when it is fixed.
2) Sell the details to either the NSA/GCHQ etc or to criminal types. In which case no mention on slashdot, but cash up front.
See the problem with security - any security - is that revealing vulnerabilities to the project so they can be fixed is likely to be much less lucrative than selling them other people who want to exploit them.
If I were cynical here's what I'd do
What would be sweet... (Score:5, Insightful)
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.
Re: (Score:2, Funny)
And dont forget to put the RPI inside a Faradey Cage....
Re:What would be sweet... (Score:4, Insightful)
There's already a market for Pi cases, I don't see why not..
Re:What would be sweet... (Score:5, Interesting)
An even better idea would be to eliminate software from the equation completly.
Have a hardware device that contains the keys in secure storage that's on the same die as a fast hardware AES implementation (so they cant be read out by someone with full physical hardware access). Or alternately have the keys on some sort of removable storage that plugs directly into the specialized hardware (so as not to expose the keys to the host machine). The hardware would sit between the disk controller and the secure drive and basically MITM all data flowing in either direction and encrypt it as it went to the drive/decrypt it as it came from the drive).
Done properly it would prevent a lot of attacks including the attack described in TFA.
Hardware Key to Encryption (Score:2)
You mean like the Yubikey?
http://www.yubico.com/products/yubikey-hardware/yubikey/ [yubico.com]
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.
Re: (Score:2)
The key is something used constantly, can't it be kept in on die L1 or L2 cache? If it ever had to pass through RAM on the way from the HDD, just overwrite the area in RAM a few times, and leave it on the die for the whole time the computer is running.
I''d venture to guess that keeping the key in the on CPU cache makes it an order of magnitude harder to get than keeping it in RAM.
Re: (Score:2)
The other issue to address is physical security. However, there have been cheap ICs for years that store a key and securely wipe it nearly instantaneously if signaled on a given pin--this allows you to hook it up to physical interlocks on a computer case, alarm system, remote control, or whatever (or OR-gate a few of those). Due to low power draw, these could easily run off a battery, preventing the security being defeated by the attacker shutting off power.
Re: (Score:2)
Re: (Score:2)
Sounds great. Where's the guarantee of no NSA backdoor ?
Not only that, but what if I don't want AES? What if I want one of the other algorithms, or a chain? What about different modes of operation, like XTS, that are added over time? How do I test this hardware implementation does what it says it does?
I can look at the code for the pi easily. Firmware for a hardware device, if anyone even gets access to it?
Re: (Score:2)
Why not just use the RPi etc. as an encrypted NAS?
Re: (Score:2)
Sure, assuming you want to share your mounted volumes, you don't mind your decrypted files traveling over the network via whatever protocol your desktop OS is compatible with and its associated security model, and it handled all the underlying file systems you wanted to mount volumes on, and all the code to support mounting all those base file systems was trusted and fully audited too, and the act of running a samba server or something and all of the auth code that might go along with supporting the stack e
Re: (Score:2)
To add to this, I explicitly *do not want* the device holding my keys attached to/addressable via the network. NAS is out.
Why can't encryption be in the SATA controller? (Score:2)
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.
Re: (Score:2)
Fuck that bro. You want to trust the private little OS that disks have running in them? If you can't audit the source code, it's crap.
I'm sure they would implement fucking 3DES or some shit and call that secure, or a terrible version of AES that is accidentally on purpose super weak, and that's assuming they don't just cache the fucking keys.
Hardware encryption solutions that you can buy? You have no reason to trust them.
Re: (Score:2)
SATA drives dont have OSes, they have firmware.
Done. WD World & other external drives embed L (Score:2)
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.
Why is physical access needed? (Score:2)
In other words (Score:5, Insightful)
Shut your machine OFF before you get to the border; don't put it to sleep.
Re: (Score:2)
And when the spooks turn it back on, the key gets copied into RAM again because that's part of the bootup process, and necessary if the system is to read the disk and finish booting.
In the end, it's difficult to secure something when you're handing them both the lock and the key, no matter how cunningly you've wrapped up the key.
Re: (Score:3)
Only if they have probable cause to compel you to supply the password. Have you ever used Truecrypt in disk mode? You have to enter the volume password first thing after the BIOS.
Re: (Score:2)
Re:In other words (Score:5, Informative)
"Only if they have probable cause to compel you to supply the password. Have you ever used Truecrypt in disk mode? You have to enter the volume password first thing after the BIOS."
Nope. Check out the recent court cases, and past Supreme Court cases. Probable cause is NOT sufficient to compel you to turn over your password. Only a court can do that, and in order to do that legally, the court has to have a great deal more evidence than mere probable cause. In fact they have to pretty much know in advance that the drive contains material that proves you broke the law.
Forcing someone to give up their password raises 5th Amendment questions. Pretty much the only time they can do that is if they ALREADY KNOW beyond reasonable doubt that something illegal is there, because in that case you would not be incriminating yourself; you are already "incriminated".
Re: (Score:2)
Is that true also at the border?
Specifically: if someone, US citizen or not, comes over the border with a laptop, can the border goons compel someone to boot the machine (supplying whatever passwords are necessary to do so) to enter?
Re:In other words (Score:4, Insightful)
can the border goons compel someone to boot the machine (supplying whatever passwords are necessary to do so) to enter?
No legal power to compel, but refusal is "suspicious behaviour" and is going to fuck up your trip until some real lawyers show up and say the court battle isn't worth the prize. Your name will go on a watch list and goons the world over will give you grief for years to come, but your porn collection will remain private.
Re: (Score:2)
Your name will go on a watch list and goons the world over will give you grief for years to come
And if that's true, then tens of thousands of businessmen with perfectly legitimate encrypted data, who don't want to (or have any reason to) show it to government, would get put on lists and have their travels complicated or curtailed for years to come.
That's not just intrusive, it's asinine. The government should not be interfering with business like that. It hurts everybody.
Re: (Score:2)
"GP said 'border' there are no laws or courts at international borders."
Yes, there are. Read some of the Supreme Court decisions about precisely what laws there are at those borders.
There are no "normal" U.S. laws outside U.S. borders... that is true. But there ARE U.S. laws AT the border. And by damn, they enforce them too.
Re:In other words (Score:5, Informative)
"And when the spooks turn it back on, the key gets copied into RAM again because that's part of the bootup process, and necessary if the system is to read the disk and finish booting."
No, it isn't. Have you ever actually used TrueCrypt?
When the program quits normally (or after a configurable time period), the key is GONE. It may linger in RAM for a very brief period but then it's gone. Truecrypt stores the key only in RAM, so when a machine is shut down, again the key is GONE. If your machine is on sleep or hibernate, the RAM might be preserved, but otherwise no. GP said "turn it off". Turn it off and the key is GONE.
Booting up has zero effect on this; the key is not stored anywhere on disk (unless YOU stored it somewhere on purpose, which would be dumb).
Re: (Score:2)
Is there anything to prevent someone from tampering with the (necessarily unencrypted) bootloader (or whatever the program that accepts your password and decrypts the volume is called)? Why not replace that piece with one that logs the password or otherwise weakens the encryption? Access to the computer for 60 seconds would be sufficient to install something like this.
This is of course relevant to any full disk encryption that doesn't have access to a TPM (and even then, can you trust the TPM?), like FileVa
Re: (Score:2)
Thats called an evil maid attack, and it is a real threat-- as is hardware keyloggers. There is mitigation, however: its not super easy to do ahead of time, because each truecrypt bootloader is unique. The drive encryption key is encrypted with the passphrase, and stored with the bootloader-- and it must be present for the "fake" bootloader to be able to decrypt the drive. So for such an attack, someone would need to have access to the drive, make a copy of the bootloader, modify the bootloader with the
Re: (Score:3)
If you have a pagefile, there's a chance it could still reside in the pagefile. Do not use a pagefile if you're using truecrypt.
There are also possible caching mechanisms behind the scenes that may also store parts of the key or the data contained in the truecrypt volume. There's nothing you can do about it, really. Best you can do is wipe your drive's free space periodically.
But it doesn't matter. If you're a target, you're done. Your mouse, keyboard, and monitor all leak signals through the cable and user
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Thats not 100% true; the key generally IS stored on-disk, and is itself encrypted with your passkey.
The reason they do this is so that you can change your passkey without re-encrpting your whole drive; instead they just have to re-encrypt your 256/512 bit key.
For FDE, the key is stored as part of the bootloader, which is why you have to burn your own recovery disk: if the bootloader goes heels up, you need to recover it as it is the only place the actual key is stored. It also means that you can trivially
Re: (Score:2)
Re:In other words (Score:4, Informative)
RAID 5 across the internal drive and and 2 external USB drives. Ship the USB drives via separate methods (UPS, FedEx, USPS, whatever) and reassemble on the other end of the trip. Any one missing portion of the volume can be recovered, but no recoverable portion travels as a single unit. And TrueCrypt the whole thing from a USB-stick installation of TC, with keys stored on the USB stick with TC, but not with any of the portions of the actual protected data. Throw in a fake TC volume on the USB stick for indirection.
(And yes, external drives can be put into RAID configurations. Heck, there are videos of floppy RAID setups out there.)
Yes, it's a pain in the ass. But it shouldn't be impossible. If your data is worth that much to keep out of the hands of some numbnuts at DHS/ICE that has "TURRISTS!" on the (lack of?) brain, then it shouldn't be too much to ask, really.
Just beware the $5 wrench.
Since parts of your data will still be recoverable from a single RAID-5 volume, you have little to gain by splitting up a RAID-5 volume set, unless you don't care that someone can recover up to one third of your data.
If you want your laptop to be unreadable without one of the external drives, you'd be better off storing random data on one or more external drives to use as a one-time-pad. Without one of the OTP drives, the data on your laptop is unreadable (for bonus points, encrypt the OTP to reduce the chance that someone can intercept it and copy it). You can fill each OTP drive with the same random data so you only need to receive one of them to recover your data, or fill them with different random data so you need all of the drives to recover data.
"Any Port In A Storm" (Score:3)
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?"
Re: (Score:2)
Re: (Score:2)
Powering down ensures that any cached passwords aren't in memory, regardless of the mounting status of individual volumes.
I wouldn't just take someone's word that the cache is cleared when the volume is dismounted if I were paranoid enough to be using TrueCrypt in the first place.
Moral of the history (Score:3)
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
So let me understand this ... (Score:2)
Re: (Score:2)
Re: (Score:2)
more FUD from Slashdot's owners (Score:5, Informative)
-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.
Re: (Score:2)
Re: (Score:2)
sheeple
You lost me here, gunpistolman.
Actual exploits (Score:2)
What about a face recognition trick? (Score:3)
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.
LOL "investigators" (Score:3, Informative)
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 [washingtonsblog.com]
http://www.abc.net.au/news/2013-12-04/asio-arrests-key-witness-in-east-timor-spying-scandal/5132954 [abc.net.au]
http://www.globalresearch.ca/canada-spied-on-brazils-government-as-part-of-global-commercial-espionage-campaign/5353642 [globalresearch.ca]
http://www.smh.com.au/national/australian-spy-agency-helped-bhp-negotiate-trade-deals-20131106-2x1sw.html [smh.com.au]
https://www.techdirt.com/articles/20131111/11532125198/australia-spied-japan-to-help-companies-negotiate-trade-deals.shtml [techdirt.com]
http://www.crikey.com.au/2013/12/02/revealed-the-government-agency-stealing-ideas-from-businesses/ [crikey.com.au]
http://the-japan-news.com/news/article/0000940560 [the-japan-news.com]
http://www.theguardian.com/uk/2013/jun/16/gchq-intercepted-communications-g20-summits [theguardian.com]
Re: (Score:2)
Re:Key recovery from memory (Score:4, Funny)
Reminds me of TRESOR (Score:2)
No affiliation, but this sounds like a good reason to move to TRESOR [wikipedia.org]-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?
Re: (Score:2)
That is only one option when it comes to hiding the key. I foresee that we will have an arms race, and one alternative would be to change the key storage and keep a decoy key in the standard location just to confuse.
Encrypt your pagefile (Score:3)
Re: (Score:3, Informative)
Re:Memory dump lol (Score:5, Funny)
A billion people not in your parents' basement?
Re: (Score:2)
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 h
Re: (Score:2)
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
Re: (Score:3)
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 T
Re: (Score:2)
Re: (Score:2)
Plenty of ports can do DMA (Score:2)
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.
Re: (Score:2)
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.
I don't think PCI is exposed over DisplayPort... Are you thinking of Thunderbolt (which combines Displayport and PCIe)?
Firewire does have a DMA attack vulnerability, but is eSATA susceptible too? I thought the SATA host controller had to set up DMA transfers, can a client SATA device set up DMA transfers without cooperation from the host controller?
Re: (Score:2)
You are correct. Tunderbolt is essentially an extension to Displayport that includes PCIe. My bad.
I know that SATA does DMA, unlike USB, but I'm not clear on how much control can be initiated from the outside. A quick search suggests that it's safe.
I found this, which discusses the issue further:
http://support.microsoft.com/kb/2516445 [microsoft.com]
It talks about dealing with 1394 and Thunderbolt DMA attacks.
I doubt there's much you can do to prevent a DMA attack through a laptop's docking port, t
Re:So does this mean the TrueCrypt hijacking busin (Score:5, Interesting)
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.
Re: (Score:2)
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 ?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The problem you have is that the decryption key is stored in RAM when it is accessed using a password.
But if the PC has been powered off then the key is not available in RAM.
However if there is a trojan in you PC then it may have the ability to read the decoded key and upload it somewhere, which means that the NSA or other authority may be able to dump the readable contents of your hard disk if they ever get their hands on it - or through the trojan.