Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

TrueCrypt Master Key Extraction and Volume Identification

Soulskill posted about 9 months ago | from the be-sure-to-use-it-the-right-way dept.

Encryption 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."

cancel ×

222 comments

Sorry! There are no comments related to the filter you selected.

So does this mean the TrueCrypt hijacking business (0)

Anonymous Coward | about 9 months ago | (#45970713)

is over?

Re:So does this mean the TrueCrypt hijacking busin (0)

Anonymous Coward | about 9 months ago | (#45971381)

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

Re:So does this mean the TrueCrypt hijacking busin (5, Interesting)

Anonymous Coward | about 9 months ago | (#45971551)

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:So does this mean the TrueCrypt hijacking busin (-1, Flamebait)

fast turtle (1118037) | about 9 months ago | (#45971953)

even better to prevent /tmp file leakage is to use a fucking ram disk as I do (Radeon Ramdisk) with 4GB and yes I've moved all of the fucking /temp /tmp and such from the HD to the god damn thing along with the fucking browser cache with IE & FF both using it. Used the software to create a ramdisk image file and mount it but never renew the damn thing. Works great.

It also helps that I've turned off the fucking Memory Dump in Windows along with the fucking swap file (I've got 16GB so don't need it). Now if I could get a fucking live DVD image for Windows with all of my software, I'd be a happy camper. Probably easier to use Linux and build the damn thing and use flash drives for persistence.

Burn after reading? (3, Insightful)

bazmail (764941) | about 9 months ago | (#45970729)

Don't people burn memory blocks any more? This is sensitive data handling 101.

Re:Burn after reading? (0)

Anonymous Coward | about 9 months ago | (#45970771)

What is the easiest way to 'burn memory blocks' on a Windows machine? Is it something you could do at a moment's notice?

Re:Burn after reading? (0, Interesting)

Anonymous Coward | about 9 months ago | (#45970837)

What is the easiest way to 'burn memory blocks' on a Windows machine? Is it something you could do at a moment's notice?

The only thing Windows knows how to do in a moment's notice is crash, which of course brings up the question of memory dump files for those who happened to be running TrueCrypt at the moment of BSOD impact...

Stop please (1)

ArchieBunker (132337) | about 9 months ago | (#45971705)

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

Re:Burn after reading? (1)

master5o1 (1068594) | about 9 months ago | (#45971845)

Clearly crashing and dumping is a feature in Windows to appease the NSA.

Re:Burn after reading? (5, Insightful)

DigitAl56K (805623) | about 9 months ago | (#45970795)

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? (1)

avltree (3501127) | about 9 months ago | (#45970851)

This would make it much more difficult, but even the current polymorphic version could be reverse engineered and then the key then extracted.

Re:Burn after reading? (5, Informative)

Anonymous Coward | about 9 months ago | (#45970859)

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:Burn after reading? (2, Interesting)

Penguinisto (415985) | about 9 months ago | (#45970905)

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? (5, Interesting)

avltree (3501127) | about 9 months ago | (#45970951)

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

Re:Burn after reading? (5, Informative)

mrchaotica (681592) | about 9 months ago | (#45970999)

Not if it throws away the key and prompts you to re-enter it every time it wakes back up.

Re:Burn after reading? (1)

avltree (3501127) | about 9 months ago | (#45971981)

How would this change anything?

Re:Burn after reading? (3, Interesting)

MightyMartian (840721) | about 9 months ago | (#45971027)

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? (4, Insightful)

Anonymous Coward | about 9 months ago | (#45971089)

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:Burn after reading? (4, Informative)

Somebody Is Using My (985418) | about 9 months ago | (#45971793)

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:Burn after reading? (1)

BitZtream (692029) | about 9 months ago | (#45971951)

Somebody needs to learn what WM_POWERBROADCAST does.

Re:Burn after reading? (-1)

Anonymous Coward | about 9 months ago | (#45971109)

What's "TruCrypt?"
 

TC is usually still mounted after sleep anyway (2)

rduke15 (721841) | about 9 months ago | (#45971419)

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.

Re:TC is usually still mounted after sleep anyway (4, Interesting)

CrimsonAvenger (580665) | about 9 months ago | (#45971823)

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:Burn after reading? (2)

MidSpeck (1516577) | about 9 months ago | (#45970819)

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.

at least this is old fashioned forensics work... (3, Interesting)

Midnight_Falcon (2432802) | about 9 months ago | (#45970743)

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!?!

Re: at least this is old fashioned forensics work. (0)

Anonymous Coward | about 9 months ago | (#45971251)

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.

Re:at least this is old fashioned forensics work.. (1)

luther349 (645380) | about 9 months ago | (#45971277)

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.

Re:at least this is old fashioned forensics work.. (0)

Anonymous Coward | about 9 months ago | (#45971355)

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

Still working as intended (2)

MidSpeck (1516577) | about 9 months ago | (#45970751)

While good to know these types of attacks exist, TrueCrypt's security model is still holding strong. http://www.truecrypt.org/docs/security-model [truecrypt.org]

Re:Still working as intended (5, Interesting)

al0ha (1262684) | about 9 months ago | (#45970803)

I wouldn't be claiming this until the audit is completed.

http://istruecryptauditedyet.com/ [istruecryp...tedyet.com]

Re:Still working as intended (2)

Jane Q. Public (1010737) | about 9 months ago | (#45971115)

"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 (3, Informative)

al0ha (1262684) | about 9 months ago | (#45972001)

Sorry bad logic. Nobody has any idea of Truecrypt's integrity as the entire project has never been peer reviewed and nobody knows all of the persons who contribute to it, so until proven it can't be and hasn't already been compromised, nobody can be confident of its security.

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.

What would be sweet... (5, Insightful)

DigitAl56K (805623) | about 9 months ago | (#45970767)

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:What would be sweet... (2, Funny)

Anonymous Coward | about 9 months ago | (#45970805)

And dont forget to put the RPI inside a Faradey Cage....

Re:What would be sweet... (3, Insightful)

DigitAl56K (805623) | about 9 months ago | (#45970841)

There's already a market for Pi cases, I don't see why not..

Re:What would be sweet... (0)

Anonymous Coward | about 9 months ago | (#45970815)

A Raspberry Pi is not a general purpose computer?

Re:What would be sweet... (1)

Anonymous Coward | about 9 months ago | (#45970891)

Perhaps not the ideal terminology, but obviously what was implied is that you have a desktop machine that's likely running all kinds of non-audited, high-risk applications that could be exploited, and you have a Pi that is running an audited, single-purpose OS with minimal attack vectors that should provide heightened security to your keys.

Re:What would be sweet... (4, Interesting)

jonwil (467024) | about 9 months ago | (#45971029)

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.

Re:What would be sweet... (1)

Anonymous Coward | about 9 months ago | (#45971053)

Sounds great. Where's the guarantee of no NSA backdoor ?

Re:What would be sweet... (1)

Anonymous Coward | about 9 months ago | (#45971751)

You don't even need an NSA backdoor -- if it's all in hardware, all someone has to do is have the hardware. If they're close enough to dump the memory (assuming it's not hidden malware aimed at this purpose) then they're close enough to get you to hand over the "secure" hardware. The problem with hardware is that it is physical, can't be destroyed as easily, and can't easily be sent through a second channel.

However, having a hardware dongle that acts like an authentication token would be useful -- like TrueCrypt + Yubikey for example. Modifying TrueCrypt to hand over part of the calculations to the yubikey would be a requirement however, and a keylogger would still gather useful information (as yubikey pretends to be a USB keyboard).

Re:What would be sweet... (1)

DigitAl56K (805623) | about 9 months ago | (#45971755)

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:What would be sweet... (1)

pcwhalen (230935) | about 9 months ago | (#45971861)

It seems they have the key to all the locks as soon as the lock gets built.

http://www.spiegel.de/international/world/catalog-reveals-nsa-has-back-doors-for-numerous-devices-a-940994.html [spiegel.de]

I think nothing is safe. Unless you're in a Faraday cage with a computer plugged into a UPS running a virtualized OS and ...

Fuck it. The NSA can have my data. Jack booted pricks.

Re:What would be sweet... (1)

jinchoung (629691) | about 9 months ago | (#45971965)

manufactured in the soviet union?

Hardware Key to Encryption (2)

pcwhalen (230935) | about 9 months ago | (#45971837)

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:What would be sweet... (1)

AC-x (735297) | about 9 months ago | (#45971279)

Why not just use the RPi etc. as an encrypted NAS?

Re:What would be sweet... (1)

DigitAl56K (805623) | about 9 months ago | (#45971503)

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 etc. didn't concern you, and you didn't care if the volumes it was mounting from might contain exploits against the Pi, etc.

The more you support, the harder it is to audit, the harder it is to secure, the easier it gets to exploit.

Re:What would be sweet... (1)

DigitAl56K (805623) | about 9 months ago | (#45971899)

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? (1)

Myria (562655) | about 9 months ago | (#45971575)

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:What would be sweet... (0)

Anonymous Coward | about 9 months ago | (#45971921)

You mean something similar to the support that TrueCrypt has for security tokens? Or do you mean exactly like the support that TrueCrypt has for security tokens?

Memory dump lol (-1)

Anonymous Coward | about 9 months ago | (#45970773)

This is why I use ecryptfs and never have a swap partition. And if I'm forced to use Windows for some reason, every install I take the same steps:

- No pagefile on any drives
- No system restore
- No memory dump on BSOD

But who the hell uses Windows anymore?

Re:Memory dump lol (3, Informative)

avltree (3501127) | about 9 months ago | (#45970797)

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.

Re:Memory dump lol (5, Funny)

Desler (1608317) | about 9 months ago | (#45970823)

A billion people not in your parents' basement?

Re:Memory dump lol (1)

Anonymous Coward | about 9 months ago | (#45970853)

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.

Re:Memory dump lol (1)

AndroSyn (89960) | about 9 months ago | (#45970867)

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

Re:Memory dump lol (1)

fisted (2295862) | about 9 months ago | (#45971533)

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:Memory dump lol (2)

AndroSyn (89960) | about 9 months ago | (#45971699)

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 [breaknenter.org]

Re:Memory dump lol (0)

Anonymous Coward | about 9 months ago | (#45971873)

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.

Re:Memory dump lol (0)

Anonymous Coward | about 9 months ago | (#45971441)

But who the hell uses Windows anymore?

Not-so-Serious Business, grandma, and gamer "dude."

Well shit (0)

Anonymous Coward | about 9 months ago | (#45970779)

I guess this means no hibernating any more.

Now I'll have so much extra time every winter!

Re:Well shit (2)

avltree (3501127) | about 9 months ago | (#45970825)

hibernating is okay if you use full disk encryption as the hiberfil.sys will be within the encrypted filesystem.

DMA attack (0)

Anonymous Coward | about 9 months ago | (#45970781)

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?

Re:DMA attack (2)

avltree (3501127) | about 9 months ago | (#45970883)

The DMA part is not new, but several other aspects are: 1) Other tools only find AES keys, the new plugins find any algo that truecrypt uses as it inspects the truecrypt data structures in memory to find the values instead of scanning memory hoping to find a key 2) Volatility shows you files that were being accessed (along with their full path) inside the TC mount 3) All of it is automated for Windows XP through 8 and the server versions

Why is physical access needed? (1)

timeOday (582209) | about 9 months ago | (#45970877)

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?

Re:Why is physical access needed? (1)

avltree (3501127) | about 9 months ago | (#45970923)

yes, but the idea is to grab the key in order to get around disk encryption. I guess you could remotely compromise the machine, grab the key, and then later get the disk image.

Re:Why is physical access needed? (0)

Anonymous Coward | about 9 months ago | (#45970993)

If the sstem is running, volume is mounted, and they have root access, they can just read the files right off the disk. They don't need to struggle to find keys decrypt the file data, since TrueCrypt will do it for them.

Core dump scrubber? (0)

Anonymous Coward | about 9 months ago | (#45970897)

Is there a tool that automatically removes sensitive information (like encryption keys) from core dumps?

Re:Core dump scrubber? (0)

Anonymous Coward | about 9 months ago | (#45971631)

Is there a tool that automatically removes sensitive information (like encryption keys) from core dumps?

No, prolly 'cuz the tool'd have to retain identifiers for what's "sensitive," so you'd need another thingamajigger to wipe the tool (or its data). Just use one o' them file-scrubber McDealies.

I use Eraser 5.something (before the guy from .ie fucked the UI and reliability up a bit) with 1-pass CSPRN w/ cluster-times & filenames on files, and the the same (minus cluster-tips) scheduled nightly for free space (doing cluster-tips on whole disk takes a long time and drives up drive temp). In regards to Eraser and the like, remember that rhyme Public Enemy spit: "Get up, get, get, get down. 35-pass is a joke in yo' town." Pete .nz Guttman himself agrees it's a joke in yo' town; it was a list that was never meant to me used in full, serial-style.

In other words (4, Insightful)

msobkow (48369) | about 9 months ago | (#45970927)

Shut your machine OFF before you get to the border; don't put it to sleep.

Re:In other words (1)

Chris Mattern (191822) | about 9 months ago | (#45971041)

Shut your machine OFF before you get to the border; don't put it to sleep.

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:In other words (2)

Nimey (114278) | about 9 months ago | (#45971079)

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:In other words (1)

luther349 (645380) | about 9 months ago | (#45971103)

yea this has no effect in disk mode but for folder encryption etc its now broken.

Re:In other words (4, Informative)

Jane Q. Public (1010737) | about 9 months ago | (#45971239)

"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:In other words (1)

Entropius (188861) | about 9 months ago | (#45971459)

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 (3, Insightful)

TapeCutter (624760) | about 9 months ago | (#45971717)

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:In other words (1)

Jane Q. Public (1010737) | about 9 months ago | (#45971797)

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:In other words (0)

Anonymous Coward | about 9 months ago | (#45971605)

GP said 'border' there are no laws or courts at international borders.

Re:In other words (1)

Anonymous Coward | about 9 months ago | (#45971139)

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.

Re:In other words (3, Informative)

hawguy (1600213) | about 9 months ago | (#45971599)

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.

Re:In other words (4, Informative)

Jane Q. Public (1010737) | about 9 months ago | (#45971179)

"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:In other words (1)

chihowa (366380) | about 9 months ago | (#45971779)

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 FileVault or BitLocker.

Re:In other words (1)

luther349 (645380) | about 9 months ago | (#45971291)

no it will not the key will not go back into ram until its reentered by the user.

Re:In other words (0)

Anonymous Coward | about 9 months ago | (#45971059)

You'll need to turn that machine off well before approaching the border. Cold temperatures can also affect how long RAM can be physically scraped.

Re:In other words (1)

luther349 (645380) | about 9 months ago | (#45971297)

shutting it down still works the key in ram in now lost unless they grabbed a dump before you shut it down.

Re:In other words (1)

Threni (635302) | about 9 months ago | (#45971243)

Or boot from a usb key which contains a micro sd card and don't touch the laptop's harddrives whenever you're using it.

Quick mitigation: (0)

Anonymous Coward | about 9 months ago | (#45970937)

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.

Plenty of ports can do DMA (1)

crow (16139) | about 9 months ago | (#45971193)

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:Plenty of ports can do DMA (1)

hawguy (1600213) | about 9 months ago | (#45971309)

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?

Moral of the history (2)

robmv (855035) | about 9 months ago | (#45971017)

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

Re:Moral of the history (0)

Anonymous Coward | about 9 months ago | (#45971289)

Is there a secondary moral to the story? If you have a server hosted by someone else (cloud server for example), then Full Disk Encryption is pointless, since the person hosting your server can relatively easily get your encryption key and decrypt your data.

So let me understand this ... (1)

chuckugly (2030942) | about 9 months ago | (#45971019)

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?

Re:So let me understand this ... (1)

avltree (3501127) | about 9 months ago | (#45971033)

It is getting the key out of memory to then decrypt the drive. Not reading the unencrypted drive live. Example scenarios are: 1) You get a memroy sample from a machine and the disk image. FDE was in use. This would allow you to extract the key and decrypt the whole drive. 2) Someone was using file containers and hibernated the machine. The key (could) still be in memory and you could decrypt the containers.

Re:So let me understand this ... (1)

luther349 (645380) | about 9 months ago | (#45971125)

would 3 also be memory sample to descriptor the containers at will as well.

more FUD from Slashdot's owners (5, Informative)

Anonymous Coward | about 9 months ago | (#45971063)

-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:more FUD from Slashdot's owners (1)

luther349 (645380) | about 9 months ago | (#45971191)

i rember hearing a wile back its weakness was in the ram storage. just seems it was confirmed . as long as your encrypted stuff is not being auto mounted this attack will not work unless the machine was suspended via sleep or hibernate with the volumes still mounted or they stole a ram snapshot wile true crypt was running. as you said a keylogger will save the spooks alot of time and trouble and what they will use.

Ahh editors... (0)

Anonymous Coward | about 9 months ago | (#45971303)

Seperent hunh? Interesting...

Actual exploits (1)

gmuslera (3436) | about 9 months ago | (#45971457)

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 [spiegel.de] targetting specifically this? They could had put it in when you bought it [theverge.com] . If well a backdoor installation could make things simpler, this hardware approach could survive OS reinstalls/replacements.

What about a face recognition trick? (2)

Entropius (188861) | about 9 months ago | (#45971537)

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" (2, Informative)

CuteSteveJobs (1343851) | about 9 months ago | (#45971547)

Key recovery from memory (1)

benjfowler (239527) | about 9 months ago | (#45971639)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?