ElcomSoft Tool Cracks BitLocker, PGP, TrueCrypt In Real-Time

An anonymous reader writes "Russian firm ElcomSoft on Thursday announced the release of Elcomsoft Forensic Disk Decryptor (EFDD), a new forensic tool that can reportedly access information stored in disks and volumes encrypted with desktop and portable versions of BitLocker, PGP, and TrueCrypt. EFDD runs on all 32-bit and 64-bit editions of Windows XP, Windows Vista, and Windows 7, as well as Windows 2003 and Windows Server 2008." All that for $300.

Comments

Key theft != cracking encryption

[Anonymous Coward]

Yeah, this is really just exploiting retarded key control. The encryption standards themselves are still secure

Re:Key theft != cracking encryption

[iluvcapra]

Yeah, this is really just exploiting retarded key control.

I dunno, I've let my laptop go into hibernate with a TrueCrypt volume mounted. It's "retarded" but that doesn't mean it doesn't work.

Re:Key theft != cracking encryption

[Anonymous Coward]

It's still a key control problem.

If Windows notifies programs about suspends/shutdowns (not sure it really does), TrueCrypt needs to dismount immediately and do whatever it needs to do to protect its key.

None of these processes attack the encryption directly, just control of its keys. Of course, that still means data disclosure, but rather than meaning P=NP or some other news, it simply means that keys are being poorly protected by the software, which in the case of hibernation can hopefully be fixed.

Firewire doesn't matter...it's equivalent to a malicious PCI device, without (as far as I know) the possible protection of VT-d. Epoxy or X-acto. If you can read the system's memory space, you can do a *WHOLE* lot more than just recovering the key...the data itself is likely in there while being read or even the entire unencrypted volume if it's memory mapped. Let alone kernel memory etc. So that is not news really.

Re:Key theft != cracking encryption

[timeOday]

The problem is the key control isn't all that retarded. Re-entering your password every time a disk block is read from disk isn't too appealing.

Re:Key theft != cracking encryption

[icebike]

Exactly: They aren't breaking encryption, they are simply surfing for keys.

Quote TFA:

So, how does it work? Elcomsoft Forensic Disk Decryptor acquires the necessary decryption keys by analyzing memory dumps and/or hibernation files obtained from the target PC. You’ll thus need to get a memory dump from a running PC (locked or unlocked) with encrypted volumes mounted, via a standard forensic product or via a FireWire attack. Alternatively, decryption keys can also be derived from hibernation files if a target PC is turned off.

Note the basic misunderstanding embedded in that last sentence: Turned off != Hibernated.

While this tool might help you break into a computer you found hibernated, or running while locked, it won't do any good if the power cord is yanked, or the encryption software was intelligently written to only store its key an some volatile memory.

Re:Key theft != cracking encryption

[_Shad0w_]

You can register an interest in knowing about power events by calling RegisterPowerSettingNotification(); your application then gets sent the WM_POWERBROADCAST message when the the power setting changes, that includes suspending the system (PBT_APMSUSPEND). You get about two seconds to actually do something with this information.

Re:Key theft != cracking encryption

[icebike]

But holding it in volatile memory, and entering it once upon boot up is not all that bad. There are a lot of ways this can be done such that the private key never need be stored on the disk in unencrypted form.

Re:Key theft != cracking encryption

[Tawnos]

Freeze the ram, remove, reinsert into a device to dump the RAM's contents. It's been done before: http://zedomax.com/blog/2008/09/29/memory-hack-how-to-hack-encryption-keys-by-freezing-memory/

Re:Key theft != cracking encryption

[chis101]

Note the basic misunderstanding embedded in that last sentence: Turned off != Hibernated.

While this tool might help you break into a computer you found hibernated, or running while locked, it won't do any good if the power cord is yanked, or the encryption software was intelligently written to only store its key an some volatile memory.

I'm pretty sure that modern hibernate simply stores necessary information from RAM into a file on disk, and shuts off the computer. Then, on boot, it checks if this file exists, and if so attempts to resume from it. So, there is no difference between "off" and "hibernating." The boot sequence will just check if there is a file to resume from.

So, you still need to find a computer that has the volume mounted (either running, in 'sleep' mode with power still being supplied, or from a hibernate file on the disk)

Re:Key theft != cracking encryption

[Anonymous Coward]

In Windows the hibernation file is never deleted (I assume to keep enough HDD space reserved). In fact, many systems automatically hibernate after they've been suspended for a certain period of time. I don't know how Linux hibernation works. You might have the key sitting in the hibernation file from weeks ago.

Re:Key theft != cracking encryption

[Synerg1y]

Almost... but not quite, memory retains data for a while after the PC is powered off creating some interesting situations if the feds are banging on your door :)

Also, this is by far not the first tool of it's kind to steal keys out of various mem locations, $300 isn't a bank breaker though like some of the other tools in the biz are, or law enforcement only type stuff. I'm sure if you look hard enough, you can find free programs esp. on the linux side of the wall that can do this.

Re:Key theft != cracking encryption

[Synerg1y]

on hibernation, pretty sure memory and everything else shuts down, the hibernate file saves the state to reload into mem on power up, I'm curious, why don't you name some of these "a lot of ways", cause I can't think of any, besides truecrypt removing the feature and making you re-enter your password on power up from hibernation, I wonder if there's an option somewhere in there to already do so, but not feeling like checking atm.

Re:Key theft != cracking encryption

[Synerg1y]

I'd argue it's how the user configures it to behave (besides the mem part, that's always been a weak point, but the attacker has to have physical access to the computer, so ya...). You can set your computer to not hibernate & you can even set up a trusted external devices policy to only accept those it recognizes, but that's only for truly paranoid. And as I've said before, there's nothing revolutionary going on here, these types of attacks have been available forever and require physical access.

Re:Key theft != cracking encryption

[Anonymous Coward]

hiberfil.sys is not scrubbed or deleted after resuming from hibernation, therefore it will persist after a subsequent shutdown. So if the hibernation feature was used while an encrypted filesystem was mounted, the keys will remain in it.

Re:Key theft != cracking encryption

[Anonymous Coward]

They never claim to crack anything, the poster does in the heading.

Re:Key theft != cracking encryption

[mumblestheclown]

so, this is one of the slashdot "encryption standards are still secure" threads, not one of the "DRM is impossible / nothing is crackproof" threads, right?

so hard to keep track sometimes.

Re:Key theft != cracking encryption

[flayzernax]

This is why hardware with encryption at the chip levels is the military holy grail and why you destroy your equipment if you can and your going to be captured by the enemy. But even that is not perfect.

Re:Key theft != cracking encryption

[Anonymous Coward]

Hibernation stores the current ram contents to disk then powers off. You can hibernate a computer then yank the power cord, move the computer 200 miles, plug it back in, and resume from hibernation. You are confusing hibernation with S1/S3 sleep modes that put the computer into a low power mode.

Re:Key theft != cracking encryption

[icebike]

So, there is no difference between "off" and "hibernating."

The difference is the lack of a resume file. The computer is not hibernating if this file is missing or was never written because the power was switched off without taking the time to hibernate the computer.

Re:Key theft != cracking encryption

[nogginthenog]

Can you really trust the encryption chip? With software I (or someone I trust who is more skilled!) can analyse the source code for backdoors and bugs.

Re:Key theft != cracking encryption

[mrbester]

Windows deletes a hiberfil.sys if found after a shutdown (or a restart if updates require it) but only by the wiping of the allocation table entry. The contents are usually still on disk as the file tends to be placed at the end of the drive so it is possible that the sectors can be analysed.

Re:Key theft != cracking encryption

[wierd_w]

Make sense.

then again, hibernation is epic fail from a security POV anyway. This is just another reason to disable hibernation if security is the objective.

(Personally, I would use a knoppix live DVD with a dual ISOLINUX entry to also load memtest. Feds bang on the door, restart -now that bitch, then pop into memtest. Let them freeze that memory and get something out after running the random write/read test on it!)

Re:Key theft != cracking encryption

[lister king of smeg]

the difference is in an encryption the attacker and the intended recipient are two different people. What DRM does is simply try to obscure and obfuscate the decryption buy hiding the keys that they give you but if you are determined you can dig around and find them. where with properly implemented encryption scheme you trust the recipient and give them the public key(or perform an handshake involving several key exchanges) and simply have to keep everyone else from seeing it.

Re:Key theft != cracking encryption

[Jane Q. Public]

"memory retains data for a while after the PC is powered off creating some interesting situations if the feds are banging on your door"

"A while" is generally limited to a few seconds: the amount of time it takes for your power supply and/or capacitors on the board to discharge.

Re:Key theft != cracking encryption

[wierd_w]

By not storing the plaintext key in memory, but instead storing an encoded form. Eg, dynamically create a computation that produces the key, and storing that. (Easily defeated as well, but it's still a way to frustrate fishing attempts like this. Introduce some random and unnecessary feature to the computation as well, and structure it to look like some other decryption algo as cammoflauge. At this level, it would require human operators manually inspecting the hibernation file to gleen how the key is being stored.)

Computing the key that way and then relying on cache hits with a check for cache miss would would help keep the key out of dumpable memory in a cleartext form.

Re:Key theft != cracking encryption

[Jane Q. Public]

Others have mentioned that it does not attack the actual encryption, but they did not summarize what it does do:

This only works if the encrypted item (drive or file) is in a mounted state at the time of "attack". And that applies if it is in a mounted state when the machine goes into hibernation. It gathers the encryption key from memory (or resume file if hibernating), it does not even try to "break" the encryption.

Still, it must be said that this is a clever approach, and could be a nice tool in some (very limited) circumstances.

Re:Key theft != cracking encryption

[Rakishi]

"A while" is generally limited to a few seconds:

No it's not, regular RAM retains memory for up to a few minutes (sort of) with no refreshes at regular temperatures. Freeze the memory and it's a lot longer than that.

http://zedomax.com/blog/2008/09/29/memory-hack-how-to-hack-encryption-keys-by-freezing-memory/

Re:Key theft != cracking encryption

[Rakishi]

Of course there's an option for that (delete all keys before hibernate/sleep) and if your system disk is encrypted then the hibernate file will be encrypted as well making it a non-issue mostly).

Re:Key theft != cracking encryption

[icebike]

But if you are worried about this, you simply run after awakening from hybernation mode:
POWERCFG -H OFF
POWERCFG -H ON

That turns off hibernation, which deletes hiberfil.sys then enables hibernation which will allow its recreation.

Re:Key theft != cracking encryption

[icebike]

Oh, forgot to mention, you could also run a competent operating system....
Nah, that would never work!!

Re:Key theft != cracking encryption

[realityimpaired]

If the feds were banging on your door and you expected them to give you the time to reboot into memtest, you'd have enough time to simply power off and let the memory drain. Just push the power button and let the system shut itself off. Use hardware-level full disk encryption, and your data will be safe.

Or you could, you know, not do anything with the system that would give the feds a reason to be banging on your door.

Re:Key theft != cracking encryption

[icebike]

I am not confusing anything, you are.

Hibernation is a choice you make every time you shut down your computer.
Stop doing that.

Just choose shutdown instead of hibernation.
In fact you can disable hibernation all together, and simply use sleep for short trips to the bathroom, and actually shut the damn thing down when not using it.
Security conscious people never hibernate a machine.

Re:Key theft != cracking encryption

[Anonymous Coward]

That's why it has to be destroyed: since it's hardware, you're mainly looking at transistors that do the encryption. If you get a chance to analyze the hardware, you can definately write a decryption program. It just won't be as efficient.

Re:Key theft != cracking encryption

[Anonymous Coward]

Windows 8: the shutdown option is really just hibernate with programs closed. Knowing is half the battle...

Re:Key theft != cracking encryption

[Hunter Shoptaw]

Ah well when you put it that way it's just plain simple! Seriously, yes you CAN get data from this, but your not likely to come up to this situation at any point in your life. Also, if this is truly a fear of your and you don't understand how to protect your keys better then you kind of deserve to get it where ever they want to put it.

Re:Key theft != cracking encryption

[Hatta]

Seriously, yes you CAN get data from this, but your not likely to come up to this situation at any point in your life.

Why wouldn't law enforcment agencies use this technique?

Re:Key theft != cracking encryption

[EdIII]

If Windows notifies programs about suspends/shutdowns (not sure it really does), TrueCrypt needs to dismount immediately and do whatever it needs to do to protect its key.

I run Windows 7 Pro 64-bit for some dev work, and annoyingly, it forces some windows updates on occasions. When it resumes, all the TrueCrypt volumes are dismounted, and whatever programs that were running and accessing the data complain about the loss of the drive.

Whether or not TC is protecting the key in memory, destroying it, whatever, I don't actually know.

Re:Key theft != cracking encryption

[Jane Q. Public]

"No it's not, regular RAM retains memory for up to a few minutes (sort of) with no refreshes at regular temperatures. Freeze the memory and it's a lot longer than that."

I stand corrected. I remember reading about that a while ago.

Re:Key theft != cracking encryption

[EdIII]

Or you disable hibernating completely.

Re:Key theft != cracking encryption

[EdIII]

Or you could, you know, not do anything with the system that would give the feds a reason to be banging on your door.

More, and more, just living free and being vocal about others living free, and god forbid, helping others living free, is more than enough reason to have the feds banging down your door .

Let's not forgot that moron FBI guy that took out hundreds of companies in a data center because he could not understand how hundreds of different companies and legal entities could cohabitate in the same space.

At this point just being innocent and never doing anything wrong is not protection enough to be raided by the feds.

Re:Key theft != cracking encryption

[Anonymous Coward]

That doesn't wipe the data, only frees the sectors.

Re:Key theft != cracking encryption

[AmiMoJo]

Doesn't work with BitLocker and a TPM chip. The key is kept in protected memory on the chip and only authenticated code can use it. It was specifically designed to defeat attackers with full access to the contents of RAM, including rootkits and the like.

Shame TrueCrypt doesn't support TPM as well.

Re:Key theft != cracking encryption

[tempmpi]

Not really, even if you power off, the memory will still hold its contents for many minutes. Some bits may flip but that is not such a problem, because even with some flipped bits you can still recovery the key. Most of the time the memory image contains not just the key, but also an AES key schedule which is an expanded version of the key with huge amounts of redundancy. Even if a little bit more than 70% of the bits contain random values instead of bits from real key schedule the real key can still be recovered within a few minutes: Applications of SAT Solvers to AES key Recovery from Decayed Key Schedule Images

Re:Key theft != cracking encryption

[Anonymous Coward]

They would not because most of them sucks

Re:Key theft != cracking encryption

[Anonymous Coward]

Windows 8 uses hibernate by default now to reduce boot-time. So even if you tell it to shut down, it typically hibernates unless there is a specific reason to actually restart.

Re:Key theft != cracking encryption

[gmueckl]

Hibernation in Linux uses a swap partition. So depending on the size and usage of the swap space the key may be overwritten almost instantly or sit in swap space for eternity.

Re:Key theft != cracking encryption

[laron]

AFAIK on Windows, the hiberfil.sys is not deleted after resuming from hibernation. It will still be there if you wake your machine up from hibernation and shut it down normally.

Re:Key theft != cracking encryption

[gmueckl]

Are you sure about this? I never use hibernation and I have a hilberfil.sys in C:\ all the time unless I disable hibernation explicitly.

Re:Key theft != cracking encryption

[Gr8Apes]

Note the basic misunderstanding embedded in that last sentence: Turned off != Hibernated.

First, depends upon the hibernate mode - mine's set to not write to disk. Yes, that means if power is interrupted I get the joy of a cold boot. It also means there are no unintended items on disk, although for me that was a secondary consideration - 24+GBs was taking up more space than my OS and page file, which is set to be comically small. As for accessing a running systems random memory without hosing something - if they have that much skill to make the proper connections on a running non-persisted system and extract the keys from a fully ASLR system, you probably have bigger problems than I hope to ever have.

Re:Key theft != cracking encryption

[Eric Smith]

Doesn't work with BitLocker and a TPM chip. The key is kept in protected memory on the chip and only authenticated code can use it.

I don't think that's true. The passphrase (perhaps hashed?) pay only be in the TPM chip, but the actual cryto key used to decrypt disk sectors is in main memory, because the main CPU is used to do the decryption. There's nowhere near enough bandwidth to and from the TPM chip to let it do the actual disk encryption/decryption. There's not even enough bandwidth to ask the TPM for the key each time you want to do a disk transfer, and erase it from memory after the disk transfer is completed.

This means that software that extracts the encryption key from memory probably can't turn it back into the passphrase that the user enters, but if you have a copy of the disk and the key, you don't actually need that passphrase.

The TPM is not a high-performance device and doesn't do anything but give out the keys on (authenticated) request. What the software does with those keys is up to the software. If someone has privileged or physical access to the machine while the keys are in use, all bets are off.

Re:Key theft != cracking encryption

[lgw]

Or you could, you know, not do anything with the system that would give the feds a reason to be banging on your door.

You know, I don't do anything in any given year that would have the Feds bangin on my door by the laws of that year. But we've about reached the point when all Internet traffic information will be logged and available to the Feds forever. And who knows what content a site I visit today will have in 10 years. And who knows what the laws will be in 10 years.

You have an attitude of "the government is my friend, and would never search for far-fetched reasons to come hurt me" that is rare in history. I hope it's common in the future, too, but our government doesn't seem to be getting less powerful, nor less arrogant, so who knows?

Re:Key theft != cracking encryption

[wierd_w]

The idea is to activate memtest when they first knock and say "police, open up."

Once running, you get up and answer the door like alaw abiding citizen. (Never trust or talk to cops without a lawyer though.) Be pleasant, and superfiscially compliant. Stall for time while memtest does its first pass.

One pass on random data read/write should be more than adequate.

Re:Key theft != cracking encryption

[gweihir]

Not really. It is exploiting retarded users that either use hibernation on a system with encrypted drives or hand running systems with mapped (decrypted) drives to attackers.

In order to be secure some level of understanding the risks and attack vectors is required. Those that do not have that understanding will never be secure. There is no way around that.

Re:Key theft != cracking encryption

[Anonymous Coward]

Oh yes... A few years ago when some douches, calling themselves "security researchers", decided to discover the obvious by recovering encryption keys from RAM. So first they tried turning off their computer and pulling out the RAM and putting it in something else to recover the key, but the key was long gone. So then they tried freezing the chips soon after turning the computer off, but still, the key was long gone. So then they tried freezing them before turning the computer off, but still, the keys were long gone. So then they tried some RAM from 1995, since in the past, manufacturing tolerances weren't as fine, and so there's more substance to each bit for it to retain data. Finally, they could read the keys -- or at least some of the keys. Seems they still encountered data corruption, and so had to write a utility to randomly toggle bits, attempting to use many similar keys to the one they read from memory. Finally, they had a process that worked, sometimes.

Re:Key theft != cracking encryption

[Anonymous Coward]

You're trying to wiggle out but you're failing. You thought a hibernated computer is not turned off, while in fact it is. You got called on that and instead of being honest about it, you're trying to weasel out by wordplay.
Well, a hibernated computer is turned off.
Furthermore, telling people not to hibernate their computer is unproductive since hibernation is too useful to do away with. In XP and earlier it was possible to trigger clearing the key from memory before suspension, but in Vista and later this is no longer reliably possible (Windows still sends the message, but I don't think there's a guarantee that the process gets enough time to process it). Possibly Windows should provide an alternative way to ensure that keys never end up in the page file, for example by marking the memory with the key as discardable, so that the memory is deallocated before suspension. After system resume the key is gone and TrueCrypt would have to ask for the password again.
Other options which wouldn't require modifying the operating system:
- Recognise that most passwords are weak and use a key fob on USB that you don't store in memory. Of course that makes the key fob the item that an attacker is after.
- Forget the password after a set time interval and display a notification on the taskbar when the key is in memory.
- Disable hibernation while a TrueCrypt volume is mounted (this can be done through powercfg). TrueCrypt could provide UI to automatically forget the key, turn hibernation back on and hibernate.

Re:Key theft != cracking encryption

[10101001 10101001]

Which is precisely why (1) the hibernation file should be encrypted by default--symmetrically encrypt with a randomly generated key encrypted with a system public key--and (2) the swap file(s) should be encrypted by default--symmetrically encrypted with a randomly generated key that need not be stored but in memory.

As for how Linux hibernation working...it generally doesn't..nor does sleep. Oh, I'm sure there are some people who have gotten it working, but the issue of firmware loading on reboot was only recently solved--sort of--and the lack of aggressive analysis of every driver actually reinitializing properly... *sigh* Yet another inconvenience I put up with Linux. But, then again, I don't have to worry about key leaking.

I'd imagine the year of Linux on the Desktop would go a lot faster if Google devoted itself to ChromeDistro instead of ChromeOS. Then again, I think people already have enough issues with what Ubuntu is doing. I guess this would be the perverse opportunity for a BingDistro.

Re:Key theft != cracking encryption

[KookyMan]

Security conscious people never hibernate or sleep a machine.

FTFY.

Or at least they don't do it leaving their encrypted containers in an accessible state. You can sleep and hibernate all you want, so long as you dismount your containers prior to doing so, and ensure the keys are wiped from RAM.

Re:Key theft != cracking encryption

[KookyMan]

And, while I forgot about it at first, TrueCrypt should be encrypting the hibernation file if you are using System Encryption (on Windows) and the hibernation file is stored on the system drive (generally is). So again, this appears as it would be even more limiting for finding keys in a file, since someone who is "security conscious" most likely has their system drive encrypted, and is making sure hibernation file is on it.

As a result, you would actually be further ahead to hibernate your computer for your little bathroom break than you would be to sleep it (Since sleep leaves everything in RAM).

*I say should because there are various little nuances to that, OS, hibernation file placement, TrueCrypt Version, etc that may result in your key being written in a non-encrypted state.

Re:Key theft != cracking encryption

[jimshatt]

Hibernation in Linux uses a swap partition.

Which is something to be aware of when you're setting up a multi-boot system with shared a swap partition...

Re:Key theft != cracking encryption

[Anonymous Coward]

Yeah, but the exaggeration really serves the community. While the encryption used by Truecrypt needs no improvement, the user protocols need to be constantly monitored for weaknesses.

Elcomsoft firstly reminds everyone of the danger of 'hibernate', and the purposeful move to 'always on' 'hibernate' by Microsoft in new versions of Windows, as yet another form of back-door for the security services.

The attack on a 'live' system is less interesting, since 'keyloggers' have existed forever. One must always assume that a powered system with a currently active decryption key is vulnerable.

Look, consider a high value target. The key will be extracted by simple secret observation methods.

Now consider a target who only becomes high value after the computer is first examined, with no success at breaking encrypted files found on the system. Simple. You give the computer back, pretend to have lost interest, and once again extract the key by simple secret observation methods.

So what exactly is Elcomsoft up to? FUD is what. Like the people who troll forums stating that shattered HDD platters can still be 'read', or that erasing the data on a HDD does not prevent the security services from being able to recover it, Elcomsoft is in the business of discouraging people from using first-class security protocols. A psychological game.

Without a shadow-of-a-doubt, fewer people will use programs like Truecrypt because of Elcomsoft's FUD. They may, instead, use one of the back-door riddled commercial solutions that Elcomsoft conveniently doesn't target (no need, they all have back-doors used by the major security services).

Re:Key theft != cracking encryption

[KiloByte]

It'd be pretty pointless to use whole-partition encryption without encrypted swap. At least the Debian installer doesn't even support that unless you go out of your way; if Windows fails to encrypt swap and request the key on unhibernating, then you shouldn't touch it with a ten foot pole. Which, from the sound of the article, is indeed the case.

Re:Key theft != cracking encryption

[KiloByte]

Don't forget that TPM allows recovering the keys by parties related to the Trusted Computing Group.

Re:Key theft != cracking encryption

[Cederic]

I own some RAM that's held state for approximately 38 years so far.

It's pretty. I have it framed and on the wall in my spare room.

Re:Key theft != cracking encryption

[Gordo_1]

Unless you type this at the command line: powercfg -h off

Bye bye hiberfil.sys

Now you know.

Re:Key theft != cracking encryption

[Zan Lynx]

You need hardware support to securely encrypt a hibernation file. Otherwise it is a chicken and egg problem. Where do you get the key to decrypt the hibernation file? It would have to be in the hibernation file.

Either that or ask the user for the security code on resume. Which is valid but obnoxious.

Re:Key theft != cracking encryption

[raymorris]

"easily defeated as well" is the key phrase in that whole post. Doing some arbitrary computation on the key gains you nothing. Anyone who is going to find a key in a memory dump isn't going to be the list bit deterred by some trivial encoding of the key.

Re:Key theft != cracking encryption

[wierd_w]

I actually had a great idea a few weeks ago for a fairly trivial enhancement to open firmware based routers. (General category. Covers even the "not completely open" ones, like DDWRT)

Basically, the router attempts to negotiate a transparently encrypted communication stream with remote hosts, and does so silently so that user level applications get all the benefits of secure communications, without having to be rewritten.

The idea was for the router itself to "stall for time" a few hundred MS before actually sending the first live datagram to any unknown remote hosts, while it attempts a secret handshake. (Depending on the result of the handshake test, it won't stall again on subsequent transactions.)

First stage of the handshake has the router send an ICMP datagram to the remote host. The ICMP packet's "padding" contains a magic number, and some random data.

If the remote host replies with the same data in the padding, the remote host fails the handshake, and secure connections won't be further attempted. (Eg, normal PING reply.)

If the remote host is running the enhanced firmware, it checks incoming ICMP for the magic number, and when it finds it, generates a OTP to replace the random data in the padding, preceeded by the "understood" magic reply number.

When the initiating router gets this reply, it uses the OTP to distribute an on-the-fly generated 4096 bit RSA public key to the remote host, proceeded by a magic number.

The remote host replies with the "understood" magic number again, and distributes its own on-the-fly public key in the return packet.

After that, the router encrypts the data field portion of all packets destined for that host using its private key, and forms a memory entry containing the key pair and the host's address. All packets received by that host have the data field portion decrypted using the received remote host's public key, before being presented on the connected interface.

Because the keypairs would be volatile, random, and constantly changing/with expiration built in, it would greatly frustrate monitoring attempts. Eavesdroppers would have to listen to the initial handshake to get the needed keys. (Perhaps somebody better at crypto could come up wit a more secure handshake..)

The idea was that most home NAT routers have plenty of CPU and RAM in them, and could easily do this kind of thing totally transparently.

Imagine, for instance, double encrypted voip. (Encrypted at the application level, and encrypted at the transport level.)

Being random keys, generated on the fly, "rubber hose" approaches wouldn't be effective.

I am quite surprised something like this hasn't already found its way into OpenWRT.

Re:Key theft != cracking encryption

[10101001 10101001]

You need hardware support to securely encrypt a hibernation file. Otherwise it is a chicken and egg problem. Where do you get the key to decrypt the hibernation file? It would have to be in the hibernation file.

Precisely, in the first block is the previously encrypted private key and the current hibernation files public key encrypted symmetric key.

Either that or ask the user for the security code on resume. Which is valid but obnoxious.

Which is precisely what you should and actually must do or you're vulnerable to the above mentioned attack. The point is that without a security code, anyone who has access to the hibernation file can scour it for whatever keys were in memory at the time of hibernation and possibly even get stuff from previous hibernations (it all depends on if Windows securely wipes the hibernation file when you ask it to delete/recreate it, which unfortunately I don't know).

But backing up, the swap file is also potentially a vulnerable outlet if Bitlocker, PGP, TrueCrypt or whatever every have parts of the key in unlocked memory or just generally once files are unlocked since trolling the swap file for partially read in files may be enough of an issue (imagine otherwise encrypted patient records being recoverable from the swap file because invariable to update them there's a time when a copy of patient records may be in memory, altered, then swapped out before being commited back to the encrypted filesystem; the only way around that is to either lock all memory for programs that access encrypted files, disable swap, or encrypt swap). All that I mentioned has been a known issue for years and is a main reason why Bitlocker was pushed so heavily. But, then, Bitlocker encourages (requires?) TPM to avoid having to enter a security code on resume/startup precisely to be less obnoxious and relies upon TPM being secure enough to protect the Windows OS startup and hence allows Windows permissions to protect the hibernate file. Clearly, that's a failure.

Re:Key theft != cracking encryption

[icebike]

I don't think Windows uses Swap for hibernation image storage like Linux does. Windows uses a memory sized file named hiberfil.sys.

But you point is valid, if you are using whole drive encryption, True Crypt or some such, even the hiberfil.sys should be encrypted, since it resides in the file-system, as does swap.

Re:Key theft != cracking encryption

[lgw]

Maybe I'm missing somehting, but it doesn't sound like it would do much to hide traffic information. Your home modem connects to a Fed-friendly router ISP port. Even if Slashdot cooperated with their onsite gear, and the connection was perfectly secure, the Feds would still know you visited Slashdot.

Also, if by "RSA key" you mean a "product of prime numbers-based keypair", as is commonly meant, you should know that the NSA publically deprecated product-of-primes based encryption almost a decade ago now, suggesting ECC be used instead. The NSA has been both way ahead of the curve and honest when they've made such mysterious pronouncements in the past.

Re:Key theft != cracking encryption

[cduffy]

You know, I don't do anything in any given year that would have the Feds bangin on my door by the laws of that year. But we've about reached the point when all Internet traffic information will be logged and available to the Feds forever. And who knows what content a site I visit today will have in 10 years. And who knows what the laws will be in 10 years.

I'm pretty sure the Constitutional provision against ex post facto laws isn't going away any time soon, though.

Re:Key theft != cracking encryption

[wierd_w]

I admit that the handshake is insecure. I am not a crypto expert, and haven't worked in IT for some years (and am thus, in all reality, no longer even employable). My intent here was to float a prototype idea.

As for ease of interception, consider this scenario:

Syria.

Rebels create ad-hoc VPNs over transient wireless connections with collaborating proxies operated in foriegn countries.

Consider: tunneled communications through these connections are multiple layer redundantly encrypted, due to the encapsulated nature of VPN communications. (Eg, Alice and Bob correspond with each other using their secret keys, using the secured service provided by Rodger and Robert. Eve has access to the Rodger-Robert transfer network. She breaks their encryption easily by intercepting the weaksauce handshake. However, the weaksauce handshake between Alice and Bob may or may not have been completed over Rodger and Robert's tunnel. (Could just as easily have been Raul-Rufus, depending on how the ad-hoc network routes the traffic.)

Listening to Alice and Bob therefor presents a more difficult problem.

RSA public-Private pair encryption (which uses prime factoring) was suggested, because it makes it very hard for Eve to impersonate either Alice or Bob and do a man in the middle. (Eve lacks the private keys to properly sign the transactions, and those keys are never transmitted.)

That the NSA could effectively force the security on a single transaction, gets complicated by widespread adoption. "Omnipresent information awareness" requires constant, realtime access to data feeds. Volatile keypair generation with enforced random keys would greatly overwhelm this goal under an oppressive computational burden, even with known exploits.

Re:Key theft != cracking encryption

[Anonymous Coward]

Can anyone confirm if this is true? If so, then it's just like the claims of being able to read hard drives that were overwritten. Maybe, if the drive is an old 10MB MFM beast from 1988, but a 2TB modern drive? No way.

Re:Key theft != cracking encryption

[StillAnonymous]

Great, another reason not to switch to Win8. I disabled hibernation on my Win7 laptop because it was faster to do a straight boot than to recover from hibernation file (8GB RAM and SSD).

Re:Key theft != cracking encryption

[Anonymous Coward]

Windows deletes a hiberfil.sys if found after a shutdown (or a restart if updates require it) but only by the wiping of the allocation table entry. The contents are usually still on disk as the file tends to be placed at the end of the drive so it is possible that the sectors can be analysed.

If it's a disk and thus round, how does it have an end?

Re:Key theft != cracking encryption

[Anonymous Coward]

The encryption key can be kept in various rarely used registers within the processor (debug registers for instance).

Re:Key theft != cracking encryption

[socceroos]

Ah, yes - security through obscurity! Brilliant!

Re:Key theft != cracking encryption

[Anonymous Coward]

That is completely incorrect. shut down is most definitely NOT a hibernate on windows 8. The hibernate option is hidden in desktop installs by default but can be easily turned back on.

Re:Key theft != cracking encryption

[lgw]

Oh, you haven't been watching tax policy then. Tax changes retroactive to the start of the year aren't even surprising any more. And the law passed way after the fact to the seize the bonuses from bank execs who received stimulus funds? Both ex post facto and a bill of attainder, for the double word score! But no one complained because hatred for bank execs runs so high.

In any case, when there's a whichhunt mentality around something, you're punished by accusation, and there's little protection in the US system against that - even if the case is later tossed out your life may be ruined. Over the past few decades it was Communism then Drugs then Terrorism and now Pedophilia - who can guess what the next target will be? For each of those in their time you could be accused (and ruind by accusation) of being a witch due to actions taken long before the particular moral panic began, which weren't noteworthy at the time.

Re:Key theft != cracking encryption

[FutureDomain]

If Windows notifies programs about suspends/shutdowns (not sure it really does), TrueCrypt needs to dismount immediately and do whatever it needs to do to protect its key.

It does. Just make sure the options "Dismount all when: Entering power saving mode" and "Wipe cached passwords on auto-dismount" are checked in the TrueCrypt settings (Settings -> Preferences) and you should be good. This will automatically dismount all TrueCrypt drives and wipe any cached passwords from memory when sleeping or hibernating.

Re:Key theft != cracking encryption

[PReDiToR]

I don't like Starter Linux any more than the rest of the bearded ones here, but if you are having trouble hibernating/sleeping in Linux, try running up their live CD and see if it works out of the box on there.
You might find that more systems do support it than you thought.

Re:Key theft != cracking encryption

[Anonymous Coward]

Not a problem, when they take your computer all the need to do is freeze the memory modules and dump the contents.

Re:Key theft != cracking encryption

[10101001 10101001]

"Out of the box", I have issues with the radeon driver causing nasty flicker problems or simply giving me a fully black screen--of course a live CD run might use the vesa driver and hibernate might work great. On top of that, "out of the box" my wifi adapter isn't supported and I presume it is a major hurdle for the hibernation issue--and yes, I could probably find supported hardware to make this a non-issue. In any case, my main concern is more than a generic live CD run but a real desktop/laptop run which likely with use a nvidia/fglrx driver and that tends to hose any presumed expectation of stability when it comes to sleep/hibernation. Then again, Intel Integrated Graphics are selling well, so you might be technically right.

Still, I don't personally count on sleep/hibernate on my own system since it's simply not worth the headache of it might/might not working. Personally, I'd rather see more advanced user space checkpointing be developed and used, anyways, since hibernate is a pretty gross hack and user space checkpointing has a lot of versatile uses--like pause/quit/start/resuming long-running tasks--with a lot more granularity and avoids most the headaches with much fewer downsides. And as an added bonus, it makes much more reasonable full system shut downs instead of sleep mode which is a gross waste of power as a general point.

Re:Key theft != cracking encryption

[Anonymous Coward]

Either you are totally uninformed, or your copy of Windows is totally broken. *MY* Windows absolutely does not have a hiberfil.sys. That's because I removed it with "powercfg /hibernate off" You should either get a clue, or buy a Mac.

Re:Key theft != cracking encryption

[fnj]

Of course simply "deleting" a file from disk does not remove the data from the sectors on the disk, and recreating a file of the same size as the deleted one does not necessarily overwrite those same sectors.

Re:Key theft != cracking encryption

[mrchaotica]

Either that or ask the user for the security code on resume. Which is valid but obnoxious.

How else would you stop an attacker from resuming the system?

Re:Key theft != cracking encryption

[Anonymous Coward]

This wipes the 4GB+ hibernation file with all zeros, or merely marks it deleted?

Re:Key theft != cracking encryption

[icebike]

It's an encrypted file on an encrypted file system.

Re:Key theft != cracking encryption

[Anonymous Coward]

What makes you so sure? They've taken away habeas corpus.

Re:Key theft != cracking encryption

[BeTeK]

On side note Arch Linux encrypts the hibernation file also if you do root encryption with arch linux wiki instruction. On resume it will ask pw for decryption.

Re:Key theft != cracking encryption

[mrbester]

Whenever I use a XP VM - IE testing, don't ask - after a mandated reboot (I use hibernation otherwise to save time on startup) it is always deleted and I have to re-enable it.

Re:Key theft != cracking encryption

[Anonymous Coward]

You can have secure hibernation, like it's done on Fedora (and probably other distros). You are simply asked the encryption key at boot for decrypting swap and everything else. Just /boot is unencrypted.

Re:Key theft != cracking encryption

[fatphil]

That is a pointless distinction to make. Off is off, it's a property of the power subsystem. When the device is off it doesn't know or care whether there's a hibernate resume file on the hard disk, or *even if there is a hard disk*. "Hibernated" is not an intrinsic property of the computer.

"Hibernated" is not even an intrinsic property of the disk, as it's perfectly possible to boot off a different medium into a completely different OS, or insert that disk into another machine as a second drive (and then sniff for keys, and stuff).

"Hibernated" is a property only of the subsequent boots.

Re:Key theft != cracking encryption

[fatphil]

> or ask the user for the security code on resume. Which is valid but obnoxious.

Or vital.

I wouldn't want it any other way. Nor would my clients.

Re:Key theft != cracking encryption

[Anonymous Coward]

Ah, yes - security through obscurity! Brilliant!

Sigh. The registers don't retain their contents after power has been removed. They behave differently from current RAM chips.

Re:Key theft != cracking encryption

[MikeBabcock]

The truly security minded don't use Hibernation on Linux and instead use randomly encrypted swap partitions to avoid memory analysis. Its easy enough to create a swap partition based on a /dev/random key at boot-up.

Re:Key theft != cracking encryption

[Anonymous Coward]

If it's a disk and thus round, how does it have an end?

The spindle and rim are ends kinda like a roll of toilet paper has ends...

Re:Key theft != cracking encryption

[Smallpond]

If it was ever previously hibernated, there might still be a recoverable hibernation fle. So even if the computer was powered off there's no guarantee this hack still won't work. The problem is allowing keys to stay in memory and not properly overwrite them when no longer needed.

Re:Key theft != cracking encryption

[Anonymous Coward]

Interesting, but wait .. this is for Windows stuff, right?
How does the various Linux distros fare in this type of environment, namely an SD card only inserted and mounted when needed, then unmounted followed by

sudo rm -rf /home/user/.thumbnails | sudo rm -rf /tmp

That would get rid of any thumbnails should there be images involved and get rid of everthing in the tmp area. Then do a cold reboot of the workstation and gesticulate and genuflect to the statue of St Jude, Patron Saint of the Impossible.

Re:Key theft != cracking encryption

[Anonymous Coward]

Just deleting the file isn't enough. It needs to be securely overwritten.

Re:Key theft != cracking encryption

[icebike]

Why? Its in an encrypted partition.

Re:Key theft != cracking encryption

[lsatenstein]

Yeah, this is really just exploiting retarded key control. The encryption standards themselves are still secure

===
Is it possible that the way to determine the encryption or decryption keys is to provide specific clear data, and then examine the encrypted results. Do it with enough carefully constructed data, and you will learn the keys.
Is the software as good as Bruce Schnierer at breaking algorithms?
I devised an encryption algorithm whereby a timestamp and some other fixed keys determined the encryption key. Every program run using the same fixed keys produced different outputs. You have to know what the secret is that made it unique.
The fixed keys were changed daily, and the timestamp field likewise. Data is cypher block chained as well.

The whole idea of security is to make certain that the secret information has no value or is obsolete by the time it is decrypted.

Re:Key theft != cracking encryption

[Hunter Shoptaw]

Because A) The complexity of the on site skills needed are likely to be missing in the agents hitting your house for, well, whatever you fear they would search you for. B) This only works within the last few seconds of a power off scenario on your pc. Count how long it take you to kick in your door, reach your pc, pull off the cover and "freeze" your RAM. Then count how long it take you to power off your pc - physically - and add 3-5 seconds for PSU discharge. This is more an espionage technique than a LLE job. C) How many enforcement agencies search a pc on site? I think you'll notice that most will rip out your pc and take ti back for examination. So really the idea of "freezing" your RAM to exercises an encryption key from it is a bit more sci-fi than real life. Most likely, they'll just brute force your HDD, or you, to get the passcode.

I bet EFDD is...

[Anonymous Coward]

...just a hammer.

Obligatory: http://xkcd.com/538/

Re:I bet EFDD is...

[Anonymous Coward]

...just a hammer.

%s/hammer/wrench/g

FTFY

Re:I bet EFDD is...

[mar.kolya]

In Russia this often called 'thermorectal cryptanalysis' and soldering iron is a tool of choice for this sort of job.

Re:I bet EFDD is...

[Anonymous Coward]

In Soviet Russia cracker cryptoanalyses you!

Going to need some proof.

[Anonymous Coward]

Pics or it didn't happen.

Re:Going to need some proof.

[Anonymous Coward]

http://xkcd.com/538/

Re:Going to need some proof.

[Janek Kozicki]

(Pics) || (didn't happen):

False

Re:Going to need some proof.

[Anonymous Coward]

class It(){

if (Pics){

happen();

}

}

Re:Going to need some proof.

[socceroos]

class it(){ // MOAR CODES } var happen = new it; if(!instanceOf("it", happen)){ print("PHALE"); }

What kind of access?

[menegator]

Access to some information or access to encrypted data?

Re: What kind of access?

[menegator]

Ok, now the page is accessible. I won't however believe it if i don't test it myself.

Re: What kind of access?

[snemarch]

Acquires protection keys from RAM dumps, hibernation files

What's not to believe?

Not as clever as it sounds

[Anonymous Coward]

It reads the encryption key from memory.

Re:Not as clever as it sounds

[blueg3]

What did you expect it to do? Magic?

Re:Not as clever as it sounds

[smittyoneeach]

I, for one, expected a pagan ritual involving Cthulhu; Natalie Portman, naked and petrified and covered in hot grits; and a traveling salesman walk of all your base.

Re:Not as clever as it sounds

[HeckRuler]

Yeah, I would consider the ability to crack hard-encryption in a reasonable amount of time and processing power as a good definition for "magic". I'm under the impression that such a feat is mathmatically impossible. At least as far as we know. And the summary lead me to believe that they had somehow found a flaw in the underlying encryption scheme.

Re:Not as clever as it sounds

[Anonymous Coward]

yes! duh!

Re:Not as clever as it sounds

[gmuslera]

The first thing you think about "PGP encryption cracked" is that a random .pgp file that you got isolated somehow (i.e. intercepting a mail with it attached) could be cracked and decrypted in minutes, no extra hardware required.

But this goes to the RAM of the computer where still resides somehow the passphrase to decrypt the file. Is a bit more serious, but not so much different than claiming that you cracked pgp encryption because you had a keylogger installed.

Re:Not as clever as it sounds

[Anonymous Coward]

I would like to subscribe to your newsletter.

Re:Not as clever as it sounds

[blueg3]

That would, in fact, basically be magic. Which is why it's always likely that an article that says some encryption "is cracked" usually has some big caveats. Or they're actually talking about something that is not, in fact, "cracked" at all.

Re:Not as clever as it sounds

[blueg3]

Security articles pretty much always dramatically overstate what they are capable of. Generally "cracked" gets used any time something is decrypted and the person who encrypted it didn't intend for it to be.

It sounds like it should be super easy, since the encryption key is "just sitting in memory", but it's not. A lot of those programs actively take steps to try to prevent the key from being captured from memory. Elcomsoft is by no means the first person to demonstrate this attack, but they like to aggressively promote whenever they make tools for applying techniques that researchers have already developed.

Re:Not as clever as it sounds

[Anonymous Coward]

What a generic route to take with the conversation.

Re:Not as clever as it sounds

[spazdor]

I was expecting anything which is properly referred to as a "crack" which is what TFS called it.

A known-key attack is not a "crack", it's just a "decrypt."

Re:Not as clever as it sounds

[Anonymous Coward]

Have you no regard for tradition?

Re:Not as clever as it sounds

[crazyjj]

My father was a pagan, you insensitive clod!

Re:Not as clever as it sounds

[Anonymous Coward]

It's not magic. I can guess any encryption key in one try*.

*assuming I'm lucky

Re:Not as clever as it sounds

[wierd_w]

Cthulu?

Don't be silly! Clearly you didn't actually graduate from Miskatonic U.

All the 300 level students know that Yog Sothoth holds all the keys!

Honestly.....

Re:Not as clever as it sounds

[Anonymous Coward]

That's only possible using a beowulf cluster in soviet russia.

Re:Not as clever as it sounds

[Anonymous Coward]

Cthulu?

Don't be silly! Clearly you didn't actually graduate from Miskatonic U.

All the 300 level students know that Yog Sothoth holds all the keys!

Honestly.....

I see HTML formatting isn't a required course at Miskatonic. Too much of a dark art even for them?

Re:Not as clever as it sounds

[wierd_w]

Of course not! Nothing newer than basic stoichiometric chemistry and mechanical engineering at good old M.U.!

But, it's still the only place you can get a properly decorated degree in otherworldly geometry, paleohistoric literature, or in the eldritch arts.

If you want that new-fangled information technology, you'll have to go to MIT or Stanford! (As if anyone would!)

(Lol! Really, I just forgot to preview before posting.)

Re:Not as clever as it sounds

[jopsen]

What did you expect it to do? Magic?

Well, you never know what santa is up to :)

Re:Not as clever as it sounds

[blueg3]

This isn't a known-key attack. You start off with a large set of data that you know to contain the key.

Also, Elcomsoft likes calling everything "cracking". Pretty much anything that is not simply using the original software with the regular password or key is "cracking".

Re:Not as clever as it sounds

[EdIII]

Cthulhu?

Really?

If your hamburger was mouthing off to you about there is no way you can guess its secrets, would you give two shits about it?

Of course not. Cthulhu would just eat you and destroy the entire contents of your house, as the meaningless trifles they are in his endless existence.

He would remember you no more than I remember the Jack In Box Cheeseburger I had 5 years ago.

Re:Not as clever as it sounds

[Anonymous Coward]

I, for one, run Linux, you insensitive clod!

Re:Not as clever as it sounds

[gewalker]

Well, with the JackBurger could have triggered a memorable trip to the ER for a quick stomach pump.

Re:Not as clever as it sounds

[Eivind]

Not quite magic. It'd be either insane compute-power, or it'd be new math. We don't actually have any proof that there's no easier way to crack AES than brute-forcing for all possible keys. We've been unable to find better ways, but that's not proof there exist no better way.

Re:Not as clever as it sounds

[EdIII]

Sure..... Tell me one hospital set up to take Cthulhu in as an emergency patient? :)

Re:Not as clever as it sounds

[lgw]

No one ever finds a flaw in the underlying encryption scheme - other than a few math geeeks, no one bothers to look. It's not a practical avenue of attack. Practical attacks focus on either key distribution or side channels. An encryption product is flawed/broken if the attacker has a recipe to gain access to the "encrypted" data, reguardless of how.

Every time a break like this is announced, there's always a horde to run and pots "but the math wasn't broken!" While the math being borken would be far worse, real-world breaks involving key distribution or side channels are just that: what breaks look like in the real world.

The TrueCrypt guys certianly care about attacks like this, and I'm really surprised they don't handle this better - I thought Windows notified running software on a hibernation events. But then, there are several checkboxes in the TrueCrypt setting related to caching passwords - I wonder if those are relevent here?

Re:Not as clever as it sounds

[russotto]

This isn't a known-key attack. You start off with a large set of data that you know to contain the key.

Assume you have a full memory dump and you know the key is in there in some known format. How long will a brute force attack based on trying every possible key in the memory dump take?

Answer: Not long at all. Your encryption scheme may take 2^128 or worse time to hack brute force, but trying every possible key in memory is going to be less than 2^40. And it doesn't really take much to do it smarter than that.

Re:Not as clever as it sounds

[Anonymous Coward]

Mmmmm... Hot Grits....

Re:Not as clever as it sounds

[blueg3]

Insane compute power wouldn't cut it. It needs to be a fundamental but previously-undiscovered flaw in the AES design, or a brand-new mathematical or computational trick that the designers could not have conceived of.

Re:Not as clever as it sounds

[Anonymous Coward]

How about her and Mila instead? Nom nom nom.

Re:Not as clever as it sounds

[smittyoneeach]

Naked & Petrified. . .Natalie Portman. . .it's all NP complete, get it?

Re:Not as clever as it sounds

[spazdor]

If you know what the stack frame of the software you're targeting looks like, you don't even have to try every n-bit string in the whole memory dump, you can just go straight to whatever memory offset the key's always stored at. It's not like TrueCrypt just puts the key at a random spot in the middle of some other program's RAM page.

With a huge exception

[Anonymous Coward]

It requires a memory dump of the system where the keys are used. Bad submitter. Is anyone filtering the submissions? This is starting to look like reddit.

Re:With a huge exception

[BradleyUffner]

It requires a memory dump of the system where the keys are used. Bad submitter. Is anyone filtering the submissions? This is starting to look like reddit.

Which you can get VERY easily if the computer has a firewire port.
http://blogs.gnome.org/muelli/2010/04/reading-ram-using-firewire/

Re:With a huge exception

[ColdWetDog]

Except that only things in recent history that routinely have Firewire are Macs - which this software (apparently) doesn't deal with.

(But Saint Jobs is thinking of the Faithful and deprecating Firewire, just in case).

Re:With a huge exception

[Anonymous Coward]

The only laptops worth purchasing all have firewire ports. {Thinkpad W500, W510,W520, W530}

Re:With a huge exception

[Jeng]

That can be easily disabled in the bios and no one will miss the functionality since no one uses firewire.

Ok, some niche professions use firewire, so probably under 2% of those who have firewire use it.

Re:With a huge exception

[AliasMarlowe]

My Dell M6400 (work laptop) even has a Firewire port, and so did the Dell M4400 which it recently replaced. In both laptops it's a 6-pole IEEE1394 port, not the 4-pole DV port that my home laptop has (8½ year old Sony VAIO A117S).

Re:With a huge exception

[jchevali]

Today slashdot has let me down.

Re:With a huge exception

[kagaku]

This works with anything that provides DMA access - including FireWire, ExpressPort, PCMCIA, Thunderbolt, etc..

Re:With a huge exception

[torkus]

That article is 2+ years old and deals with XP. Also the author chews on words for the first paragraph or two and makes me want to shoot myself (not to mention being wrong on a few points...) but anyhow..

Does the memory dump apply to Win 7/8? Fully patched XP? FW ports are a niche and rather uncommon. Of more interesting concern - are hibernate files encrypted on a bitlocker encrypted drive?

I agree with GP - this is a terribly written submission (and/or just an advertizement.) Bitlocker, PGP, and trucrypt ALL decrypt in realtime already - if you provide them with keys!!!

Re:With a huge exception

[Anonymous Coward]

But Saint Jobs is thinking

Not bloody likely.

Re:With a huge exception

[GodBlessTexas]

The OS has nothing to do with it. Firewire ports are DMA, as are Thunderbolt ports if I remember correctly, which means access to the port means direct access to the RAM. That means you can not only read the data, but you can also potentially manipulate it (killing processes, injecting code into already running processes, etc.).

Re:With a huge exception

[amorsen]

That attack is going obsolete. On modern systems with IOMMUs, Linux will not allow the Firewire controller to access memory which has not been set up as a DMA source or target.

Re:With a huge exception

[DriveDog]

2%? Don't know, but 3 of 4 in my household use firewire, to capture video from DV and Hi8 camcorders. USB 2.0 will not suffice, and the recorders do not have USB 3.0, whether that would avoid dropping frames or not.

Re:With a huge exception

[amorsen]

Only on systems without an IOMMU or with an OS which does not properly limit access. Both of which are becoming rarer.

Re:With a huge exception

[threephaseboy]

Recent MacOS blocks DMA from Firewire when the user is not logged in:
http://support.apple.com/kb/HT5002 (search CVE-2011-3215)

Re:With a huge exception

[AmiMoJo]

Just disable the Firewire port in the BIOS. Ditto the PC Card slot on your laptop (which is actually a hot-plug PCI/PCI-e slot and vulnerable to similar attacks).

Also even Firewire DMA attacks won't break BitLocker if you have a TPM chip installed, since it can't read the protected key out of it. TPM was specifically designed to defeat that kind of attack where someone has access to the entire RAM.

Re:With a huge exception

[lgw]

It also works on hibernate files, which Win8 uses by default now when you tell it to shut down, so the attack has gotten easier in that sense.

I'm pretty sure everything is encrypted on a bitlocker encrypted drive, and bitlocker uses the TPM which actually helps here. That still leaves you vulnerable to an "evil maid" attack, but that attack is just generally hard to deal with.

Re:With a huge exception

[butlerm]

The OS has nothing to do with it. Firewire ports are DMA, as are Thunderbolt ports if I remember correctly, which means access to the port means direct access to the RAM. That means you can not only read the data, but you can also potentially manipulate it (killing processes, injecting code into already running processes, etc.).

Serious computers, running serious operating systems, use an IOMMU to restrict the access of externally accessible DMA devices to main memory, in much the same way a regular MMU is used to restrict access by user processes, by making other memory basically invisible.
http://en.wikipedia.org/wiki/IOMMU

soo?

[Anonymous Coward]

qoute from website: "Elcomsoft Forensic Disk Decryptor needs the original encryption keys in order to access protected information stored in crypto containers. The encryption keys can be derived from hibernation files or memory dump files acquired while the encrypted volume was mounted."

Not

[Maximum Prophet]

So, how does it work? Elcomsoft Forensic Disk Decryptor acquires the necessary decryption keys by analyzing memory dumps and/or hibernation files obtained from the target PC. You’ll thus need to get a memory dump from a running PC (locked or unlocked) with encrypted volumes mounted, via a standard forensic product or via a FireWire attack. Alternatively, decryption keys can also be derived from hibernation files if a target PC is turned off.

That's not really cracking. It's more like looking under the keyboard for sticky-notes.

Re:Not

[Anonymous Coward]

So, how does it work? Elcomsoft Forensic Disk Decryptor acquires the necessary decryption keys by analyzing memory dumps and/or hibernation files obtained from the target PC. You’ll thus need to get a memory dump from a running PC (locked or unlocked) with encrypted volumes mounted, via a standard forensic product or via a FireWire attack. Alternatively, decryption keys can also be derived from hibernation files if a target PC is turned off.

That's not really cracking. It's more like looking under the keyboard for sticky-notes.

Net result is the same. If there's a whole in the security, it's a flaw regardless of whether you think it's k3wl or not.

Re:Not

[Kjella]

Yes, except certain standards basically give your peripherals practically free reign to roam through your memory, specifically Firewire and Thunderbolt or if the attacker can add such a port through extension cards and the drivers are installed automatically. This is rather well documented behavior, and the small price you have to pay for closing this loophole:

The drawback of this mitigation is that external storage devices can no longer connect by using the 1394 port, and all PCI Express devices that are connected to the Thunderbolt port will not work. Because USB and eSATA are so prevalent, and because DisplayPort often works even when Thunderbolt is disabled, the adverse effect caused by these mitigations should be limited.

Re:Not

[bill_mcgonigle]

Net result is the same. If there's a whole in the security, it's a flaw regardless of whether you think it's k3wl or not.

Yes, there's a hole in the security, but not in the WDE products. Identifying the correct attack surfaces allows the security-minded to mount proper defenses.

From this perspective, the article title is misleading and counter-productive.

Better: "ElcomSoft Demonstrates Bypass Tool for BitLocker, PGP, and TrueCrypt".

Re:Not

[Maximum Prophet]

Except that if they really can crack the underlying encryption of PGP, they can crack anything like PGP. Since this exploits keys lying around in memory or page space, only those products that don't actively manage keys have the vulnerability.

AFAIK, the machine encryption used at the company I work for, scambles and re-encrypts the keys when you suspend or hibernate your machine. It also clears the CPU caches and registers. Any attacker with a Lead Pipe could take your machine while you were working on it, but that's a problem for all mobile computing.

Re:Not

[drinkypoo]

Yes, except certain standards basically give your peripherals practically free reign to roam through your memory, specifically Firewire and Thunderbolt or if the attacker can add such a port through extension cards and the drivers are installed automatically. This is rather well documented behavior, and the small price you have to pay for closing this loophole:

Well, you're wrong, and also, you're wrong. The price you pay for closing this loophole is the small premium for a system with a working IOMMU. That means you need processor and BIOS support...

of course, misleading topic

[Anonymous Coward]

This reads keys from RAM, it doesn't actually break encryption.

Also, first post.

Re:of course, misleading topic

[Anonymous Coward]

This reads keys from RAM, it doesn't actually break encryption.

Also, first post.

nonono, mine is the first one!!1!

Re:of course, misleading topic

[Anonymous Coward]

This reads keys from RAM, it doesn't actually break encryption.

Also, first post.

You must be using some academic definition of "breaking encryption" that I'm not familiar with.

The typical use of that term is to mean "we can read your encrypted data without you choosing to divulge your key to us". If this software can reliably retrieve keys from arbitrary computers I'd say it has defeated the encryption in question.

Re:of course, misleading topic

[Bert64]

It still doesn't break encryption, the encryption part is still performing exactly as it's supposed to.
What's broken is the method of protecting the key, ie the means by which you "choose not to divulge the key"...

Re:of course, misleading topic

[Java Pimp]

If this software can reliably retrieve keys from arbitrary computers...

It can't retrieve keys from arbitrary computers. There are specific circumstances that need to exist before they can do anything.

If the computer is on, it can potentially read the decrypted key from RAM. The computer must have been first turned on AND the correct passphrase entered to decrypt they they key to decrypt the volumes. If it's turned on but the decryption hasn't been performed yet, they gain nothing. They can't just turn on the computer and expect to crack it.

The other method they mention is reading it from hibernation files if the system is not powered on. However, if the system drive is encrypted they can't get to the hibernation files.

If you shut the machine down when you walk away you are pretty safe. Of course this doesn't prevent anyone determined enough to install a hardware key logger or something...

Re:of course, misleading topic

[viperidaenz]

Shutting down writes data to the hibernation file. How do you think think Windows boots faster now than it used to, while getting bigger and bigger.

Shutdown = Log off user, hibernate kernel, turn off power.
Boot = Try and resume kernel from hibernate file first.

Putting your Windows 7 laptop in standby also hibernates too. Try removing power while in standby then booting it up again. it'll resume where you last were, but it'll just take longer.

Re:of course, misleading topic

[cbhacking]

Both the "hybrid" sleep (where the data is written to hiberfile, then the system enters sleep) and the hybrid shutdown (where the system shuts down but writes startup data to the hiberfile) are easy to disable in the Windows power settings. More importantly, though, if they are enabled then when the system enters Hibernation you're protected anyhow. The hiberfile is on the system (encrypted) volume! They can't pull the key out of that...

This attack only works if for some reason you are using full drive encryption, but not on the system volume. By default, Windows won't even let you configure BitLocker that way; you'd have to do it manually or encrypt the drive using a different PC (one that does have its system volume encrypted) and then transfer it over and provide the decryption key.

DRM?

[Voyager529]

At $300 and being from Russia, one would assume that they wouldn't just release it as a DRM-free application...which raises the question whether they add DRM to it, and how they're going to protect it, especially if they've got the means of decrypting all of these high-security encryption mechanisms.

I'm wondering if there isn't an alternative business model here - a bounty for encrypted laptops, decrypting the data internally, and using that data for ransom. I'm pretty sure it'd work much better than selling licenses at $300 a pop.

Re:DRM?

[NemosomeN]

Elcomsoft is a legitimate business, at least I always had that impression. (They are well known, in fact I've known of them for years, I think. Never knew they were Russian).

Re:DRM?

[AvitarX]

I think Dmitry Sklyarov (PDF decrypting software, arrested in US for work done in Russia when going to a conference) worked for them.

How it works

[Anonymous Coward]

*Requires* a memory dump or hibernation file to scan for the decryption keys. So it can decrypt Bitlocker, PGP, and TrueCrypt, if it can find the decryption keys.

Misleading title

[RenHoek]

Unlike the title claims, it doesn't _crack_ in real time, it just allows you to mount the encrypted volume and lets you decrypt it with the keys you found. I.e. make it work just like truecrypt when you mount a partition.

If they were able to _crack_ in real time, then they'd have just solved P = NP.

Re:Misleading title

[GodBlessTexas]

EXACTLY! Mod parent up please! This is not exactly new. Snagging encryption keys from hibernation files or RAM dumps is nothing new. And the Truecrypt win32 binary will allow you mount the volume in read only mode if you want to view the contents and have the acquired key. So, this does everything you can already do for free, but with the added benefit of being a $300 product. I guarantee you that law enforcement is going to be the biggest purchaser of this product, even though this capability already exists and has existed without spending a dime.

Re:Misleading title

[Anonymous Coward]

And they would have to change their name from Elcomsoft to Setec Astronomy.

Re:Misleading title

[snemarch]

Auto-locating the decryption keys (for multiple products) rather than manually digging through a 16gig ram dump is easily worth $300 :) - I'd kinda expect law enforcement companies to have already come up with tools, though (or, perhaps more likely, be paying (lots more) for already-existing products).

Re:Misleading title

[Anonymous Coward]

If they were able to _crack_ in real time, then they'd have just solved P = NP.

Neither AES nor Public Key Crypto (atleast as far as I'm aware) has ever been shown to be polynomial-time reducible to an NP-Complete problem..

So your claim is not tue...

Re:Misleading title

[torkus]

There aren't any tools today that do key mining from memory dumps? Free ones too I'd guess. Granted they probably have cheezy MIDI music and scrolling 'credits' to ignore so obviously not appropriate for gubermint agencies.

I'm sure I could google a half dozen quite easily if my proxy server didn't block those sites.

Re:Misleading title

[Anonymous Coward]

Especially since AES uses fixed key sizes. There's no variable problem size on which to compute a polynomial function, so P and NP don't even enter into it.

I can do that too...

[Anonymous Coward]

.. if I have the keys.

Re:I can do that too...

[Impy the Impiuos Imp]

I can build walking robots, too, if I have the algorithms.

System drive encryption?

[Anonymous Coward]

My setup is the following: win7, encrypted system drive, and one encrypted drive where I store all work-related stuff (including private keys to production servers etc).
Lets suppose my laptop get stolen.

I understand that:

a) if it was turned off I'm safe
b) if it was put in sleep mode then I'm not safe. To this date I assumed that the thief would just bounce off the login screen and restart the machine, sooner or later. Is is possible to obtain a memory dump on a running machine? Of course, USB auto-run is off
c) the same as b)

is that correct?

cheers,
jan

Re:System drive encryption?

[marcello_dl]

>My setup is the following: win...

first mistake? ;)

Re:System drive encryption?

[Anonymous Coward]

Herpity derpity. I r clevar1!!1111!

Re:System drive encryption?

[snemarch]

If you've got a firewire port in the machine, you're game over.

Otherwise, it depends on whether there's any direct remote exploits on the version of Windows you're running - I haven't heard of any of those for a long time.

Re:System drive encryption?

[Hatta]

b) if it was put in sleep mode then I'm not safe. To this date I assumed that the thief would just bounce off the login screen and restart the machine, sooner or later. Is is possible to obtain a memory dump on a running machine? Of course, USB auto-run is off

If they have physical access to the computer, they can just blast the RAM with compressed gas to freeze it. At low temperatures, the RAM keeps its data for a few seconds. Then they pull the RAM and stick it in a device that dumps it.

Re:System drive encryption?

[BLKMGK]

If your machine has FireWire ports they can be used to directly access memory and obtain the keys - it would not be safe in this case. This is a well known forensic technique for doing memory dumps. Do not allow the machine to sleep or hibernate as this will also write memory to disk where it can be examined offline.

Re:System drive encryption?

[Jeng]

He most likely has absolutely no use for firewire and can simply disable it in the bios.

Re:System drive encryption?

[Bert64]

Hibernate but don't sleep, and only if you are sure that your hibernation file will be stored encrypted.

Encryption is not broken

[RatRagout]

They are simply extracting the encryption keys from the memory of a running computer using DMA and firewire. @breaknenter has been doing this with inception and some scripts for years.

Re:Encryption is not broken

[RatRagout]

Link to inception: http://www.breaknenter.org/projects/inception/

Re:Encryption is not broken

[SeaFox]

You didn't include the link in your first post, and make us go deeper to get to Inception? ;-)

Re:Encryption is not broken

[viperidaenz]

They didn't claim encryption is broken. They claimed they've broken three different encryption tools.

Not the whole story

[Anonymous Coward]

If you note, in the article, it even says you have to do a few very specific things. For the most part, that includes either mounting the partition/drive beforehand (second two methods), which defeats the purpose of someone wanting to do that. The first method is access the hibernation file. I doubt, with a full-drive encryption, that you'd be able to access it. Even if you only had an encrypted container, you'd still have to be stupid enough to leave it mounted and allow the computer to go into hibernation at least once. If you're leaving your encrypted partitions/drives mounted that long and leaving the computer to go afk and let it hibernate, keeping the data secure must not mean that much to you.

Encrypted swap?

[Anonymous Coward]

I don't use windows, but on other OSs, the swap where "hibernation" data goes, is encrypted to avoid such trivial exploits.

As for the firewire attack, that was first developed on Linux, and immediately prevented on Linux. On Windows, it has been available since XP days, and MS notified of the issue back then. So, no excuse it is still trivial to unlock, disk dump, mem dump a windows box through the DMA firewire hack, now 3 major versions on since this attack was well known.

Re:Encrypted swap?

[cbhacking]

Windows uses a hibernation file on the system partition, rather than using a separate swap partition, but the point is the same. You see, when BitLocker is active, the whole system volume is encrypted. So... yeah the key *might* be on there (though it also might not; it's supposedly stored in security-sensitive memory space that doesn't get written to disk) but since the hibernation file itself is encrypted, good luck digging it out!

As for the attacks using a RAM dump or a Firewire (or other DMA) connection, that's just silly. Sure, you can get a key out of that, but that's been known for approximately the entire lifetime of full volume encryption. The obvious solution is to not leave the computer running where an attacker can get hold of it. Sleep mode counts as running, here (the RAM is maintained, and BitLocker at least doesn't prompt for the unlock passphrase on resume from sleep) but hibernate is a different matter entirely, and should be fine.

Re:Encrypted swap?

[Anonymous Coward]

On Windows as well, if you use Full Disk Encryption.

After all, the hibernation file is on the root of the %SYSTEM% drive, which you should be encrypting considering how revealing it can be not to encrypt it.

This tool requires catching the encryption key

[Anonymous Coward]

... with three ways to locate it:

  By analyzing the hibernation file (if the PC being analyzed is turned off);
  By analyzing a memory dump file *
  By performing a FireWire attack ** (PC being analyzed must be running with encrypted volumes mounted).
  (or sniffing it with a key-logger, using a rubber hose, etc.)

To thwart it: Don't hibernate, don't leave a memory dump laying around, disable fire-wire, and power-down.

Re:This tool requires catching the encryption key

[torkus]

...or just unmount your encrypted volume (assuming it's not the system partition) when you're not in front of your computer.

Leaving anything truly sensitive in an 'always open' state is poor security practice to begin with.

Dear Slashdot,

[Anonymous Coward]

How did it come to this?

Mounted or dismounted?

[Anonymous Coward]

So the volume would need to be mounted at the time the decrypter is running? So a dismounted encrypted volume should be secure?

But only if you have the key

[AmiMoJo]

What TFS does not mention is that you need to acquire the encryption key for it to work. Hardly trivial.

Elcomsoft suggest attacking the hibernation file (Windows only, encrypted along with the system drive so probably inaccessible anyway, may not actually have the key) or using a Firewire attack on a live system with the volumes already mounted (useless for an offline attack, easily circumvented by disabling Firewire, not all machines even have it).

Nothing to see here.

Well, duh.

[Anonymous Coward]

Three Ways to Acquire Encryption Keys

Elcomsoft Forensic Disk Decryptor needs the original encryption keys in order to access protected information stored in crypto containers. The encryption keys can be derived from hibernation files or memory dump files acquired while the encrypted volume was mounted. There are three ways available to acquire the original encryption keys:
By analyzing the hibernation file (if the PC being analyzed is turned off);
By analyzing a memory dump file *
By performing a FireWire attack ** (PC being analyzed must be running with encrypted volumes mounted).
* A memory dump of a running PC can be acquired with one of the readily available forensic tools such as MoonSols Windows Memory Toolkit
** A free tool launched on investigator’s PC is required to perform the FireWire attack (e.g. Inception)

So it uses well-know techniques to access encrypted data. Whoop-dee-doo. Tag: slashvertisement

Disable hibernate, wipe dumps with ccleaner and?

[Anonymous Coward]

So no mem dumps, no hibernate file (I hate hibernate anyway)...

Does that render this $300 wasted, without those two options?

No.

[Anonymous Coward]

This tool IS NOT capable of "cracking" disks encrypted by these methods. It is capable of locating the keys, should you be able to get a memory dump of the running system or obtain hibernation files, and decrypting the disks using the keys. In short, if you have something to hide, do not use hibernate and always power off your machine when you are not actively using it.

I'm I secured ?

[faustoc4]

If I use a keyfile in Truecrypt, does this file also get loaded into RAM? Say, the keyfile is stored in a USB key that is removed after the Truecrypt partition is mounted.

Re:I'm I secured ?

[Hatta]

Yes, yes it does. The key is used to do math with the data on your hard disk. It has to be in RAM to do that.

Re:I'm I secured ?

[snemarch]

AFAIK, the keyfile is only useful to avoid brute-force attacks against your passphrase - it is still derived down to the same encryption/decryption key length as would have been derived from your passphrase. If you've got encrypted partitions loaded, the key is in memory, and the keyfile is utterly irrelevant.

extracting keys from RAM

[interiot]

This tool extracts the keys from RAM dumps. There are free tools that do this too, of course.

But isn't it difficult to get a RAM dump, you say? Not really:

• Hibernating a computer writes this data to disk. Starting in Windows 8, "shutdown" actually writes some hibernate data by default.
• VMs also have their own suspend functionality that does a RAM dump, as well as non-SAN VM migration.
• Firewire ports actually allow devices to scan RAM of the machine they're connected to.
• Obviously, if you have access to a live machine, you can get the keys directly from RAM.

Re:extracting keys from RAM

[Anonymous Coward]

All of this assumes that you haven't encrypted the system volume. Good luck getting my key from a hibernation file on an encrypted partition.

Re:extracting keys from RAM

[Anonymous Coward]

So how does a TruCrypt user defend against these sorts of tools?

Re:extracting keys from RAM

[TheSpoom]

Unmount the TrueCrypt volume before hibernating / shutting down. Don't let people attach random Firewire devices to your system. Lock your system before walking away (really, unmount the TrueCrypt volume then, too, if you can). Don't run it in a VM unless you know what you're doing.

Common sense stuff, really.

Re:extracting keys from RAM

[bill_mcgonigle]

Also many new devices have Intel Rapid Start which uses a memory-sized partition on SSD to do a hardware-level hibernate (very fast).

I'm the kind of guy who uses swap on LUKS to do secure hibernation and even I started to setup up a Rapid Start partition, thinking it would be very useful, before the little security lobe of my brain started shouting "no, your keys!". There's precious little about this risk on a Google search save a Dell tech document that says that it might be incompatible with software-based encryption like TrueCrypt.

And with block remapping, even using Rapid Start once is enough to potentially contaminate the SSD forever.

It would be nice if the kernel had a mode where it could encrypt all the memory pages that weren't needed for resume and do the inverse on the way back up to take advantage of the BIOS-skipping benefit of this feature.

Re:extracting keys from RAM

[bill_mcgonigle]

Disable Firewire in your BIOS if you can.
If you can't, snip the leads on your motherboard.
If you can't, fill the port with hot glue.

Re:extracting keys from RAM

[nogginthenog]

Does the OS completely overwrite the hibernate/swap file each time? All it would take is to forget to do this once and those bits could be floating around on the drive (especially if the filesystem uses wear leveling).

What about that time a driver crashed and the OS wrote a dump file? You sure you deleted them?

Re:extracting keys from RAM

[TheSpoom]

I believe TrueCrypt tries very hard to avoid swapping the key to disk; I don't know about the hibernation file (though I bet you could script something to shred the file on resume, if you were paranoid about it).

One would hope you would have set your highly secure system to not dump core on a kernel panic.

Re:extracting keys from RAM

[gweihir]

Starting in Windows 8, "shutdown" actually writes some hibernate data by default.

Urks. Another reason not to use that fundamentally broken piece of trash!

funny

[Anonymous Coward]

Does it work on Linux? If it doesn't, it's good or bad?

Re:Disable hibernate, wipe dumps with ccleaner and

[alen]

not if you're law enforcement

use the swat team and take control of computers while they are still on. or turn them on at suspect's home. transport in hibernated state and then "crack"

Sucks for you

[Anonymous Coward]

Sucks for those who auto mount their encrypted drives at startup, or those who leave them mounted when they go get coffee.

Now show me a tool that can crack truecrypt with an encrypted volume not mounted, and a disk simply handed to you.

I have a question

[Anonymous Coward]

This sounds like they are only able to open an encrypted file if they have access to a machine where the file has been accessed already. This sounds like an operating system security issue. The operating system is creating garbage that includes sensitive information that is available to anyone. Not good.

But then does anyone really believe computers are secure?

Don't be a Bear

[Anonymous Coward]

Can you say -- set your system to NEVER hibernate....

It's really a decryption key finder

[girlinatrainingbra]

I would actually call this more of a "finder of the decryption key if left hiding in RAM or hibernation file while encrypted partition is mounted":
It works only if
(1) you can get a volatile memory dump while the encrypted partition is mounted and the decryption key currently resides in the volatile memory or
(2) if you can get access to a hibernation partition/file which contains the decryption key from when the encrypted partition was mounted.
From the linked article So, how does it work? Elcomsoft Forensic Disk Decryptor acquires the necessary decryption keys by analyzing memory dumps and/or hibernation files obtained from the target PC. Youâ(TM)ll thus need to get a memory dump from a running PC (locked or unlocked) with encrypted volumes mounted, via a standard forensic product or via a FireWire attack. Alternatively, decryption keys can also be derived from hibernation files if a target PC is turned off. So saying that this software is capable of decrypting PGP / Bitlocker / Truecrypt partitions is hyperbole. A more accurate assessment of this software is capable of finding the decrpytion/encryption key in RAM or hibernation files.

I thought Truecrypt, et al were smarter about RAM

[swb]

I thought TrueCrypt,et al were smarter with their RAM-based keys than that and made them more difficult to sniff in RAM, as this has long been a well-known weakness of any encryption software.

Or is there something about whole-disk encryption software that makes this more difficult (which I can see from a performance perspective)?

You would think they would randomize memory locations or have some kind of method of encrypting the keys in-memory and decrypting them and wiping as they did disk I/O. A race condition that would expose them, but with a smaller window for exploitation than leaving them in memory.

My Experience

[Anonymous Coward]

off topic but.. was using encrypted usb touted as military grade secure encription. Just booted the system in linux and the text file was transparent. So... easy to defeat inline encryption in that case.

Re:My Experience

[Lumpy]

That is military grade... That's exactly how military encryption works.

Fuck you, timothy

[Anonymous Coward]

this isn't "real time cracking" and you know it

These guys make IT people look like gods....

[Lumpy]

I used to have their password kit for enterprise and it would make me look like a complete computer GOD to the users.

"I lost the password to my spreadsheet...."
"what is the password I used on this zip file?"
etc....

I would crack about 5-10 passwords a week with their tools and ended up never having to buy drinks when going out with office workers after work because of it.

I LOVE literature!

[Anonymous Coward]

If they were able to _crack_ in real time, then they'd have just solved P = NP.

To Pee or Not to Pee! That, is the fundamental computer science question.
  Tis' nobler to drink coffee or coke, one cannot say.

Shit, I can't remember the rest of my Shakespear!

Setup

[Anonymous Coward]

W7:

Control Panel\Hardware and Sound\Power Options\System Settings
Control Panel\Hardware and Sound\Power Options\Edit Plan Settings
    Set all to Never or Do Nothing

Control Panel\System and Security\System
Click to open system
Advanced system settings
System properties/Advanced tab
Performance/Settings...
Performance Options/Advanced tab
Virtual memory/Change...
Click 'No paging file' and be sure to press 'Set' button

Clean out current page file (however there is always a small page file used anyway for what I don't know):
Regedit
Go to: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
Right click and modify: ClearPageFileAtShutdown
    Set 'Value data' to 1 to ClearPageFileAtShutdown, bck to 0 to not ClearPageFileAtShutdown after cleaning shutdown.
    Probably only need to do this once and then change back to zero for faster shutdowns. Done this several times.

Immediately use the free CCleaner/Advanced/Check: Wipe free space
http://www.piriform.com/ccleaner

Re:Disable hibernate, wipe dumps with ccleaner and

[Anonymous Coward]

Yeah exactly. Kill a few bits, and the other bits will get in line.

Sounds like an advertisement for Tresor

[Wrath0fb0b]

Keep all your AES keys in registers -- no affiliation, except that I'm a user and I would much prefer that it be mainlined to streamline my rebuild process. Given that there's such little performance penalty on x64/AES-NI, this should be the defacto standard.

Re:Sounds like an advertisement for Tresor

[gweihir]

That does not help. a) the key-setup is too large for registers and, more importantly, b) the drives is mapped and decrypted. Just read it directly and forget about the keys.

Oblig. Yakov

[CanHasDIY]

In Soviet Russia...

Nevermind; too easy.

"Posted by timothy"

[Swampash]

Says it all really, doesn't it?

PrivateCore is the solution

[Anonymous Coward]

Now there is a solution to that attack, see here

http://www.privatecore.com/

been done before, mitigations well known

[Anonymous Coward]

As per MS recommends for secure BitLocker...disable hibernate, sleep, FireWire in BIOS, &c. Now you have to get the laptop powered and logged in...at that point the disk encryption is irrelevant anyway...

Strong Doubt About "Cracking" PGP

[DERoss]

OpenPGP as implemented in Pretty Good Privacy (PGP), Gnu Privacy Guard (GPG), and possibly other applications is a private-key/public-key encryption method. You encrypt with the public key, which cannot decrypt what it encrypts. Thus, the whole world can have copies of your public key. You decrypt only with your private key, which does not encrypt. Thus, you try to keep your private key truly private.

However, there is another consideration. You have a pass phrase that is used to encrypt your private key for storage on your computer. That is, your private key exists on your computer only in an encrypted form that cannot be used without first decrypting it with your pass phrase. My pass phrase has well over 30 characters (over 240 bits), including blank spaces and special characters. It exists only in my head plus on a piece of paper in a very secure and remote location in case I drop dead.

I use PGP. To decrypt a file, I must enter my pass phrase, which PGP then uses to decrypt my private key. PGP then uses the decrypted private key to decrypt the file. The decrypted key is in a cache and can be reused so that I do not have to keep typing my pass phrase. The cache is automatically purged after a user-set interval of time. I can also manually purge the cache, which I always do when I am through decrypting. Purging the cache should be standard procedure for anyone concerned about keeping encrypted data secure.

Thus: (1) Even if my private key is compromised (e.g., captured), it is really useless without my pass phrase, which does not exist electronically. (2) Proper procedures prevent access to the cached decrypted copy of my private key.

Of course, all this is overcome if a key-logger or other means is used to capture the input of my pass phrase. If that happens, I have greater problems than someone decrypting files I want to protect.

Re:Strong Doubt About "Cracking" PGP

[Swampash]

This is "cracking PGP" in the same sense that finding a passphrase on a post-it note stuck to the monitor is "cracking PGP".

Re:Strong Doubt About "Cracking" PGP

[Enigma2175]

OpenPGP as implemented in Pretty Good Privacy (PGP), Gnu Privacy Guard (GPG), and possibly other applications is a private-key/public-key encryption method. You encrypt with the public key, which cannot decrypt what it encrypts. Thus, the whole world can have copies of your public key. You decrypt only with your private key, which does not encrypt. Thus, you try to keep your private key truly private.

However, there is another consideration. You have a pass phrase that is used to encrypt your private key for storage on your computer. That is, your private key exists on your computer only in an encrypted form that cannot be used without first decrypting it with your pass phrase. My pass phrase has well over 30 characters (over 240 bits), including blank spaces and special characters. It exists only in my head plus on a piece of paper in a very secure and remote location in case I drop dead.

I use PGP. To decrypt a file, I must enter my pass phrase, which PGP then uses to decrypt my private key. PGP then uses the decrypted private key to decrypt the file.

Sure, this is how individual file encryption works but with partition or whole disk encryption (which is what the article is talking about), there is a symmetric key that is encrypted to either a passphrase or a asymmetric key on a hardware token and the disk is encrypted to this symmetric key. When the computer boots, it prompts the user for either the passphrase or token which it uses to decrypt the symmetric key located in the boot sector. It then puts the symmetric key into memory and uses that key to decrypt blocks of the disk as they are read.

The decrypted key is in a cache and can be reused so that I do not have to keep typing my pass phrase. The cache is automatically purged after a user-set interval of time. I can also manually purge the cache, which I always do when I am through decrypting. Purging the cache should be standard procedure for anyone concerned about keeping encrypted data secure.

In this case it doesn't cache the decrypted key, it caches the passphrase. When it need to access the key again it will load it from disk and decrypt it with the passphrase. If you always purge the cache after decryption, why not just turn the caching feature off?

Re:Strong Doubt About "Cracking" PGP

[DERoss]

In this case it doesn't cache the decrypted key, it caches the passphrase. When it need to access the key again it will load it from disk and decrypt it with the passphrase. If you always purge the cache after decryption, why not just turn the caching feature off?

When I do a backup of my PC, I encrypt and sign the backup files before storing them on a removable hard drive, which I then store remotely. The version of PGP that I use needs my pass phrase for the signature at the end of the process, but it has to be input at the start. Thus, the pass phrase is cached. The files are so large that the cache was expiring before PGP was done. I extended the expiration interval to 25 minutes to get a good completion of the process. Since the process always takes less than 25 minutes, I then purge the cache.

In soviet russia..

[Anonymous Coward]

Software must break you. To the end.

Oblig. Drago

[CaptainStumpy]

Software must break you. To the end.

This is really old

[gweihir]

The possibility of pulling keys from memory-images has long been known. The possibility to get memory images via the brain-dead firewire design is also well known. Stealing keys is not breaking any encryption.

In addition, I doubt this can break PGP/GnuPG because if used properly, the passphrases for these reside in memory only for a fraction of a second after entered. As for the others, anybody that bothered to read anything about disk encryption knows that while a container is mapped, the keys can be pulled from memory. Bit wile the container is mapped, the decrypted disk can be read directly, so that is not that much of an additional problem.

regarding true-crypt and the hibernation file

[clovis]

I don't think that it is interesting that someone has figured a way to hack a running computer that they have physical access to.
However, the hibernation file inspection hack had bothered me, or rather didn't bother me after I read the document.

Check out http://www.truecrypt.org/docs/hibernation-file

from the link:
Note: The issue described below does not affect you if the system partition or system drive is encrypted* (for more information, see the chapter System Encryption) and if the hibernation file is located on any of the partitions within the key scope of system encryption (which it typically is, by default), for example, on the partition where Windows is installed. When the computer hibernates, data are encrypted on the fly before they are written to the hibernation file.

When a computer hibernates (or enters a power-saving mode), the content of its system memory is written to a so-called hibernation file on the hard drive. You can configure TrueCrypt (Settings > Preferences > Dismount all when: Entering power saving mode) to automatically dismount all mounted TrueCrypt volumes, erase their master keys stored in RAM, and cached passwords (stored in RAM), if there are any, before a computer hibernates (or enters a power-saving mode). However, keep in mind, that if you do not use system encryption (see the chapter System Encryption), TrueCrypt still cannot reliably prevent the contents of sensitive files opened in RAM from being saved unencrypted to a hibernation file. Note that when you open a file stored on a TrueCrypt volume, for example, in a text editor, then the content of the file is stored unencrypted in RAM (and it may remain unencrypted in RAM until the computer is turned off).

Note that when Windows enters Sleep mode, it may be actually configured to enter so-called Hybrid Sleep mode, which involves hibernation. Also note that the operating system may be configured to hibernate or enter the Hybrid Sleep mode when you click or select "Shut down" (for more information, please see the documentation for your operating system).

To prevent the issues described above, encrypt the system partition/drive (for information on how to do so, see the chapter System Encryption) and make sure that the hibernation file is located on one the partitions within the key scope of system encryption (which it typically is, by default), for example, on the partition where Windows is installed. When the computer hibernates, data will be encrypted on the fly before they are written to the hibernation file.

Note: You may also want to consider creating a hidden operating system (for more information, see the section Hidden Operating System).

Alternatively, if you cannot use system encryption, disable or prevent hibernation on your computer at least for each session during which you work with any sensitive data and during which you mount a TrueCrypt volume.

* Disclaimer: As Windows XP and Windows 2003 do not provide any API for encryption of hibernation files, TrueCrypt has to modify undocumented components of Windows XP/2003 in order to allow users to encrypt hibernation files. Therefore, TrueCrypt cannot guarantee that Windows XP/2003 hibernation files will always be encrypted. In response to our public complaint regarding the missing API, Microsoft began providing a public API for encryption of hibernation files on Windows Vista and later versions of Windows (for more information, see the Version History, section TrueCrypt 5.1a). Since version 7.0, TrueCrypt has used this API and therefore has been able to safely encrypt hibernation files under Windows Vista and later versions of Windows. Therefore, if you use Windows XP/2003 and want the hibernation file to be safely encrypted, we strongly recommend that you upgrade to Windows Vista or later and to TrueCrypt 7.0 or later.

Re:I thought Truecrypt, et al were smarter about R

[gweihir]

There is no way to hide keys in RAM. TrueCrypt is not stupid here in any way, it is just impossible to hide the keys for a decrypted drive. It is also unnecessary, after all, you can just access the drive directly. Encryption only protects disks while they are not mapped (i.e. decrypted). It is not a solution at all for mapped disks.

Simple solution

[Anonymous Coward]

Auto-dismount when the computer enters hibernation?

Re:Simple solution

[socceroos]

Auto-dismount on idle timeout, I'd say. So many people will "lock" their laptop (read: CTRL-ALT-DEL+Enter) and leave themselves vulnerable.

What would be the point?

[Anonymous Coward]

Whatever truecrypt stores in memory, some other program can read and do whatever truecrypt does to it to get the key. Even if they encrypt the key, they still need to keep the key they encrypted the key with around so that they can decrypt it later. So what are they going to do to protect that key? Encrypt it too?

Re:deleting hiberfil.sys

[Anonymous Coward]

deleting a file does not erase its contents, just the directory entry

Re:I thought Truecrypt, et al were smarter about R

[L4t3r4lu5]

From the notes in the Truecrypt Documentation for Unencrypted data in RAM:

** Before a key can be erased from RAM, the corresponding TrueCrypt volume must be dismounted. For non-system volumes, this does not cause any problems. However, as Microsoft currently does not provide any appropriate API for handling the final phase of the system shutdown process, paging files located on encrypted system volumes that are dismounted during the system shutdown process may still contain valid swapped-out memory pages (including portions of Windows system files). This could cause 'blue screen' errors. Therefore, to prevent 'blue screen' errors, TrueCrypt does not dismount encrypted system volumes and consequently cannot clear the master keys of the system volumes when the system is shut down or restarted.

Keys for non-system volumes are securely wiped from memory on dismount, which is automatic as part of the restart / shutdown procedure.

DMCA Violation?

[qeorqe]

Would selling or using this product be a DMCA violation?

Things you write have an implicit copyright. Suppose your system encrypts your writings. Their software is promoted to be used to defeat that encryption.

Hardware token

[badzilla]

It's a shame none of these disk encryption systems can use hardware (USB token for example) as part of the crypto. Then pulling out the token would remove the key, at least if the software behaved itself correctly with no caching. Truecrypt does go halfway in the sense that the hash of a file stored in hardware can form part of the key but it would be nice to see it done properly.

Time for a modern processor

[drinkypoo]

Modern systems have a working IOMMU and aren't vulnerable, if it is used, to stuff like snooping through memory via 1394. You need both processor and BIOS support and maybe chipset support too.

Now, if I had any idea which combinations would work, I would tell you. Linux complains about a disabled IOMMU which is supposedly costing me 64MB RAM, which might well mean that my Phenom II X6 has one but my BIOS doesn't support it.

Re:With a huge exception to the exception

[Anonymous Coward]

Actually, the IOMMU will only defend you if the CPU is running in x2apic mode. But the usual suspects (BIOS/EFI retarded monkeys) often *DISABLE* x2apic mode because their crap hangs the box when it is used. Examples are latest Thinkpads (like the T430), and even some piece-of-shit servers. Linux will tell you about it during the boot messages, as it always want to use x2apic, and complains to the syslog if the !@#$ BIOS/EFI disabled it.

So, firewire attacks are a lot harder to defend on may supposedly enterprise-grade laptops. Ah, and you need to run Linux, FreeBSD, or Windows 8. Windows 7 and earlier doesn't use x2apic mode, Micosoft never cared for device-level attacks.

The GPU is another problem, Linux actually has a firewall in the open GPU drivers that checks every command sent to the GPU, plus the IOMMU filters. The proprietary drivers (for Linux, and Windows) from ATi and Nvidia don't, as that slows down the thing considerably. So you can just tell the GPU do dma all over the memory if you want, directly from a user application.

Won't work with TrueCrypt FDE

[epp_b]

The hiberfile.sys attack won't work with TrueCrypt full disk or system encryption for Windows: the hibernation file itself is encrypted, as it's stored in the encrypted system partion.

TrueCrypt replaces the Windows boot loader with its own and requires the key to decrypt the system upon awakening.

So, if the computer is off or hibernated, they'll access the hiberfile ... how?