Has anyone else seen this?
http://blog.wired.com/27bstroke6/200...chers-dis.html

This might be the wrong forum for this particular question. I was thinking that this must be an easy fix in the Linux kernel. I took a quick look and from what I can tell all that really needs to happen is (files referenced are in 2.6.21.5 sources, but shouldn't have changed much since then):

• Add a function pointer at the end of struct cipher_alg in include/crypto/crypto.h. The appropriate modules (such as aes.c) will just add a function to hash the key-space and place the pointer at the end of its callback structure before loading, and those modules that don't do that shouldn't be hurt any (as far as functionality and compilation.)

• Add a call to the new function pointer in the crypto_exit_cipher_ops function of crypto/cipher.c.

I haven't tried it yet because I don't do much kernel hacking and I only have one system to work with. Does anyone see a problem with this?
ta0kira

The essence of the problem is that in any encryption scheme if the cracker has both the encryption key and a sample encrypted document then the cracker can eventually break the code. The cracker does have to put some work into figuring out the algorithm of the correspondence between the encryption key and the encrypted data. This is why DRM can never work. The playing device contains both encrypted music and the encryption key.

When the encryption scheme is widely used then whenever somebody cracks the algorithm and publicizes it cracking the code becomes trivial. Remember DVD Jon? So DRM and Microsoft's various anti-pirating schemes are quickly and universally cracked.

The solution is to keep the encryption key separate and under lock and key or else memorize it. Something like having the encryption key on a floppy locked in a vault. Insert it into the computer when needed and remove it after use. The computer only remembers the encryption key long enough to encrypt or decrypt the data and then erases all traces of the encryption key from the computer.

I haven't worked through the logic of your proposed solution but it does not get around the basic problem that both the encryption key and encrypted data are available at all times in the computer. Your solution might make the encryption algorithm more complicated or it might make it simpler but it will not make the encryption unbreakable.

---------------------
Steve Stites

I think the problem is that the computer's RAM has a residual image of the key once turned off, but if you overwrite that key when you're done with it then the residual image won't be accurate. That's what I intend to do. I always keep my keys on a flash drive, and in fact they're even encrypted there with a password. The article is stating that when I turn off my computer to go to work in a few minutes, my encryption keys will still be somewhere in RAM, meaning someone with the right equipment and expertise can locate that key.
ta0kira

This "attack" is really getting far too much press.

If you have physical access to a machine, it's game over, pure and simple. We've always known this.

Yes, if you're encrypting your hard drive properly you hope that even if someone gets hold of it without the key, they can't access it. But the limited scope of this attack is the killer here - you have to get complete physical access to the machine, quickly, only a few minutes after it was last powered off, open the covers and remove the RAM and encrypted hard drive, recover the RAM into a compatible machine, rewrite the BIOS/OS on that machine to not clear memory at boot, suck the memory data into a file and analyse it for places where the encryption key *may* have been stored. Then connect the hard drive and try to decrypt. We talking "well-funded, clever attackers" here, who already have a million and one ways into your machine.

It's all very interesting from a theoretical point of view, but it's already well known. For the same reason we don't leave traces of encryption keys on hard disks, USB disks, floppy disks etc. people have generally avoided leaving encryption keys in RAM past their useful life. You can zero any storage medium but you can't guarantee that someone with a certain amount of funds can't recover the info. Memory is no different except in the fact that the "fade time" is quicker. This "attack" takes advantage of that fact. It's been known about for years, all they did was make the "fade time" more practical.

It's fixed by simple measures - store encryption keys in RAM at random places (some software already does) - this puts a big spanner in the statistical works but is merely a hindrance because the software has to know WHERE they are to use them. Overwrite encryption keys in RAM as soon as they have been finished with (some software already does) - this is a bit of a killer but assumes that the attack can't be performed on a live/"suspended" PC - this is basically what the main attack requires, given the times involved, and then it's just easier to stick a bus analyser on the motherboard.

Design chips that "short" the RAM after power-down/power-loss to prevent the physical attack - that's the real fix. But your average desktop PC doesn't need it. Nor do servers. Physical access in good time is the limiter there. Laptops with encrypted hard drives are the ones that need it, because physical access is actually possible. And now you're carrying important data, with the encryption key, around with you.

Much easier for an attacker who WANTS to target you to just threaten you personally to hand over what you have if they think you have important data. Left your laptop on the train accidentally which is immediately picked up by a "casual" thief? More likely its RAM dies before anyone can do anything useful, even if they are aware of this attack and try it ASAP.

My bet is that anything important, like military applications, already does all of the above circumventions and more. Even arcade machine manufacturers have had all sorts of "Intellectual Property" protection techniques in hardware and software to stop things like this for years. But it's just that the generic x86 architecture has never really cared about it, even as a theoretical attack. Physical access is the key on "normal" PC's, not any fancy attack.

It's an impractical attack. There is only limited scope to prevent the physical attack without a redesign of the motherboards/RAM chips (which you'll already find most military etc. designs already have)... and hey, maybe they should redesign it. Why not?

But there's bugger-all that we can do about it at the moment, on any current PC or, indeed, on anything about to be produced in the next 12-18 months. The practicalities of doing this "outside the lab" are so enormous as to make it near-impossible. And the average business laptop already has a million and one security problems anyway - they are called users generally - that make this attack pretty worthless.

We can try some software trickery and make the encryption software do what we should have been doing from day one, which some software already has done. There is a lot of scope to prevent the software side from leaving things lying about and a lot of software already does them. But there's nothing on the software side that can't be circumvented by clever analysis of the RAM and/or ripping the RAM out while the key is in use.

Just thinking off the top of my head, it'd probably be easier to stick a keylogger or a new BIOS chip with an edited BIOS on the laptop and give it back to the user (today, tomorrow, next month, who cares?) and then have that send you any typed passwords back - you'd already have imaged their hard drive when you took it from them. That way is even better because there would probably be no clue as to where the information came from, because it would still be "in their possession".

There's really no point panicking about this whole thing unless:

1) You encrypt ALL laptops routinely.
2) You have systems in place to ensure that secure information can ONLY go onto an encrypted laptop.
3) You're using badly-designed and infrequently updated software to implement the encryption.
4) Physical access to the laptop is likely, such that an attacker could physically remove bits of the computer without you having a choice in the matter (a gluegun helps defeat this) or having noticed.
5) The data on the PC is incredibly important such that a determined attacker (who would probably just threaten you first) would know about it and want it.
6) You're already protected against every other theoretical attack there is (including that one where people can read information off your screen by the radiation patterns they can measure from across the street, the audio-recording of your typing being turned into possible keyboard combinations for passwords etc.)

And if you're in that small select group, you really shouldn't be letting the information out in the first place, or you'd already have a better architecture for it.