But let's say you're not encrypting media files, I mean there's not much point in that since it takes so long and who encrypts their mp3s or movies anyway? Let's say it's sensitive data. How about you encrypt it on your machine then upload it to an online server or 5 just to be sure. Make it more fun and use a program to hide your ip address while you upload your data. Then do a clean install if necessary, if not, just wipe your ram a few times. Problem solved, right?

Is it possible to use a USB drive that reads/writes to itself to run the encryption program like using portable apps thereby saving the key to the flash drive yet still being able to copy the contents that are encrypted to the internal hard drive and using the flash drive to unlock it?

What about a biometric key? Would that work?

1) Don't allow physical access to the machine.

2) Power down when not in use. AKA don't use hibernate or suspend.

Problem solved.

A criminal is someone who commits or tries to commit a "crime" which is an action or conspiring to action in contravention of "laws".

Now we need to ask - what are laws? Laws are directives or rules forced upon the "people" by those who are supposed to "represent" them. When was the last time any law was made involving any inkling of your representation?

What we have with encryption is parallel to the 2nd amendment which states that because an Army is necessary to protect the state therefore the people should be able to have armaments to protect themselves against that Army should it fall into a condition where it is no longer "well regulated".

No wonder encryption was/is classified as "munitions". So now you cannot even have a private discussion about self defense. This way the Guv-Mint kills two freedoms at the same time - 1st & 2nd.

Workaround:
Embed memory within an thermal insulator? This could be defeated by removing the insulator in a cold environment, but if done well could dramatically increases the cost to the attacker.

http://mcgrewsecurity.com/projects/msramdmp/

@Paeniteo,
I'm also talking about securing/affixing my memory to the motherboard (see above).

One would simply yank out your system's RAM and put it into another system.

I liked the idea of solder in the RAM, cover it, for cheap returns, although ways to hit that. Helps against your 12 year old sister attacks, at least until she is 16...

It is a lot more than 10 people who knew about it.

As I said there is actualy two problems not one...

The first is the ordinary random data hold, this tends to be quite short in reality (just a few seconds on average)

The second is data "burn in" if any RAM chip (static or dynamic) holds the same value for an apriciable time then the semiconductor actualy becoms damaged and develops a detectable bias to the data value when compared to random data storage cells. This burn in can be effectivly permanant and always readable even days or weeks after the chip was powered down.

This is why it is important that the key bits are always being changed to aparantly random values.

Most old school hardware design bods (ie +50yrs) are well aware of this problem.

There are solutions they are reasonably efficient to implement but they most definatly are not obvious.

Ultimatly though you do have to store a secret somewhere and the only (semi) safe place is in a CPU register that does not get flushed on a stack or task swap op.

The main threat that is relevant to real life is a laptop that is powered on and stolen. If it is unlocked the encryption is irrelevant. If it is powered off [for a few minutes] the encryption works fine. If it is on, and locked then it is currently vulnerable but the fix is for the software to encrypt the keys while the user locks / suspend / etc the PC.

Eric made this point but it seems to have been missed:

"I'd expect drive encryption to encrypt keys when you lock the console, using your user password or keys, and then decrypt them when you unlock it by typing your password again, which would help the laptop security case a lot. I don't know if they actually do this."

The main threat that is relevant to real life is a laptop that is powered on and stolen. If it is unlocked the encryption is irrelevant. If it is powered off [for a few minutes] the encryption works fine. If it is on, and locked then it is currently vulnerable but the fix is for the software to encrypt the keys while the user locks / suspend / etc the PC.

Eric made this point but it seems to have been missed:

I'd expect drive encryption to encrypt keys when you lock the console, using your user password or keys, and then decrypt them when you unlock it by typing your password again, which would help the laptop security case a lot. I don't know if they actually do this.

The main threat that is relevant to real life is a laptop that is powered on and stolen. If it is unlocked the encryption is irrelevant. If it is powered off [for a few minutes] the encryption works fine. If it is on, and locked then it is currently vulnerable but the fix is for the software to encrypt the keys while the user locks / suspend / etc the PC.

Eric made this point but it seems to have been missed:

I'd expect drive encryption to encrypt keys when you lock the console, using your user password or keys, and then decrypt them when you unlock it by typing your password again, which would help the laptop security case a lot. I don't know if they actually do this.

After all the attack is possible only when you are not using your computer.

"But that leaves the software..."

Yes and its not a lot of good to you. As I said you need another piece of information to build the key which in a fast evolving crypto pool would be the pointers and the whitening. This is stored else where such as a CPU register or IO chip which is not available to the memory bus etc.

With regard hardware yup been there still do it. And guess what a Maxim Engineering Journal landed on my desk today with an artical about their DS3600 family of chips designed for exactly this problem the artical is by Swati Joshi and its called "addressing physical security of encryption keys". Maxims website is www.maxim-ic.com

> Would it be possible to have the encryption keys
> stored in a video card's ram instead of the main system ram

Up to this point, in principle, yes.

> to defeat this type of attack against the encryption keys stored in
> the system ram?

No.
The reason is pretty simple: It must be possible to extract the key from there to use it. Therefore, an attacker can extract it as well.

> As to defeating brute force attacks, would it be possible to have password
> entry attempts tied directly to a time ratio written into the code of the
> encryption software,

What good would this do? If the encryption software is open source, an attacker can simply remove the artificial delays and re-compile his own version. If it is closed, the decryption algorithm could be re-implemented anyway without artificial limitations.

There are approaches to make deriving an encryption key from a password time-consuming in order to frustrate dictionary searches.
Say, do not use SHA-256(password) to obtain the key, but repeat the hashing a few thousand times and use the final output.
Note how this limits brute-forcing by increasing the complexity of the operations instead of introducing artificial limits.

As a DSP embedded system designer, I've often had to use static ram to avoid the truly horrible latency delays of dram when accessing memory out of order (often required, just try doing an FFT in linear order of access). Static ram doesn't come up all zeros or ones, but generally comes up with (nearly) the same pattern each time, due to one side of each (sort of) flip flop being a little faster than the other, pretty reliably. In a given system, you can almost count on the static ram content being the same on each power up cycle, with blocks of all 1's and zeros tending to be in the same places every time. Anything stored last time power was up...gone. I may have seen almost one exception to this in perhaps the entire history of solid state memory (shows my age, started out with core and vacuum tubes).

The error rate of this predictability is low enough (but not zero) that many flaws in embedded software due to not initializing completely often go unnoticed for quite awhile. You learn all this kind of thing when trying to go well past 5 or so 9's. Or you aren't successful at it.

But that leaves the software to build the key in RAM. It's a little harder to find the starting point for that code, but not impossible.

Sometimes a little physical security is necessary.

As to defeating brute force attacks, would it be possible to have password entry attempts tied directly to a time ratio written into the code of the encryption software, something like 6 attempts per minute maximum regardless of input method.

If a system like this could be implemented than an attacker would only be able to try 8,640 (6*60*24) different passwords in a 24 hour period.

Yup I missed the ;-) I have been away from a desktop computer using a Motorola Sidekick Slide Phone for the past few days. Lets just say my eyes are not what they once used to be some 40(hurmp) years ago and a tiny screen does not improve things in the slightest (now what did I do with that 100" LCD pannel 8)

With regard to the passwords even if they have not been "explicitly" stored by the software they are probably in a "buffer" somewhere either in kernal or user space memory. And being mainly single user MS OSs tend to create buffers and not clean them up.

And as any forensic bod will tell you the one thing that MS OSs are realy good at is writing blocks of memory to the HD via the swap space and slack space from buffers etc (even when they don't need to). It's one of the main reasons users complain computers are noise, not from fan noise but from the OS using the Hard Drive for swap etc.

If you are feeling bored one day DD your swap partition from an MS machine to a Linux box and go searching on things like your name credit card passwords and other stuff you use on a daily basis (but might not want others to know).

The chances are the results will give you cause to think hard about what you do on your computer, and who you let have access to it.

Mind you, you could end up overdo things 8)

I still "type" things on a manual typerwriter from time to time, "it sure ain't pretty" but it can be quicker that turning on a PC. Also when it comes to very confidential info it makes controling the information a lot lot easier (and old habits do die very hard or not at all).

I also have a Knoppix box with no HD that I tend to use for web browsing and such like. I made it almost as a joke after I was asked by a friend to recomend a "Safe Web Surfing PC" for their children. It's made from an old Pentium box that the hard disk died in and was chucked from work (I also use it totaly diskless with my "SafeServ").

If you have read some of my previous posts to Bruce's blog you might have also noticed that just for fun and curiosity I actually built a PXE/ headless terminal/app server and UPS into a small table top safe (old Hotel type) as a project one weekend. It all started with the name "SafeServ" after chatting over a few beers one friday night with someone about the Knoppix disskless client. Saddly I have not yet managed to get the RAID array to work in it, (it generates just a little bit to much extra heat to be reliable and I realy don't want to start bending heat pipes).

Even though done for fun the work behind both the diskless client and headless server has subsiquently gone on to be used by a school to re-use old hardware for their under 12's.

Your previous post gave me some food for thought. I mostly use encfs for disk encryption, which I load manually after starting the computer. On my rarely used laptop, I had at one time been using the same password for logon and encfs. In your airport scenario, maybe I don't want to let them walk away with the laptop in that case.

Although I have no idea if the logon password is floating around in memory or otherwise exploitable after the fact. And I don't know if there would be pressure to divulge the logon password, but I might not mind giving it up if it couldn't be used for much.

*And,* not that I would have anything particularly interesting on this laptop, but it's none of their business.

"But why would anyone ever remove a RAM chip from a running computer? All of the documentation says to *never* do this."

Why would a auto thief smash the window of your car?

The answer is the same in both cases, even though it's against the manufactures warrenty the thief wants to steal something that is contained within, that they cannot as easily any other way get at.

In the case of the auto thief it's the car contents / house keys (you've left inside) they want, (so they might go on to burgle your house).

In the case of the Data thief it is information in the memory such as the keys to your hard disk (where you "house" your private data), so they can go on to steal from that.

The real reason the manufacture says don't pull stuff out is two fold,

The first is that unless you are carefull you can damage the chip by leaving the power and data lines connected but not the ground connection. Although as a R&D design engineer of amongst other things Com/Sec equipment I haven't managed to do this yet. And for the past 30 years I've been pulling chips faster than an 1800s midwest dentist.

The second is that it has an undesirable effect on the computer and the rest of the data storage in it such as the Hard Disk etc. Imagine you are driving fast down a crowded shopping street and you sudenly lose all memory of how to drive / see / speak / control your bodily functions. Basicaly you are going to be in a mess one way or another, and so might a lot of other people.

cdmiller (and others who alluded to similar): excellent point about disclosure considerations.

If the RAM is powered it does not need ti be removed from the PC.

Back in the (not so) old days of DIL chips you could get a clip that went ower them. This alowed Hardware ICEs to be used. These manipulated the CPU reset and IO control lines and effectivly took it out of circuit and replaced it with the ICE CPU. At this point you owned the RAM and all IO chips and could do what you liked with them.

Step forward to today CPUs are mainly Grid Array pins which makes an ICE clip not easy to affix. However how many laptops have the multi pin extender port on the back?

Alot of these have are the equivalent of a PCI connector or worse have the required control lines to out the CPU.
Likewise the laptop memory expansion is just under a little cover with a standard socket which again has the control lines required.

Now how many of you have arrived at the airport and been told to power up you laptop to prove it is not a bomb?

And how many of you have had it taken away from you in this state so it can be "checked"?

Now ask yourself just how long in seconds it would take to read out every memory location?

IS IT CLEAR NOW WHY THIS IS,

1, a very real threat
2, very easy to do
3,a very difficult technical problem to solve
4, A real difficult user training issue.

Any questions?

Back ground reading Ross J Andersons book, Bruces and Nieles Furgussons books and the colective papers of Peter Gutman.

Hopefully I have spelt their names correctly and if I was not away I would have posted the links can somebody else oblige?

I'm not an electrical engineer but couldn't the attacker just stop the CPU clock, then they would have all the time in the world to develop ways of extracting the data from the registers and on-die cache. As long as power was maintained the data would remain; you could even perform surgery on the machine.

as far as sophisticated attackers, this introduces a damned if you do/don't scenario. if your computer is on, it is vulnerable to this attack. if it is off, it is vulnerable to other, more trivial attacks - after messing around with the Ubuntu installer's dm-crypt/LUKS implementation, i was surprised to discover the ease with which a LUKS passphrase could be intercepted and written to a hidden area of disk (add ~10 lines to a bourne shell script in the initrd).

this really reinforces the idea that disk encryption is only really good for protecting data in instances of theft (and of course, unsophisticated attackers).

The catch is that this requires the attacker to physically show up and manipulate the computer. It takes at least one agent per computer. The first time I saw this, somebody claimed to always kill power before leaving his computer (and was ridiculed for his tinfoil hat).

The catch is that almost all attackers capable of mounting an attack that obtains the unit (laptops excepted)* are also quite capable of mounting a rubber hose attack. I thought of paybacks for a Cal Tech-style prank, someone else here suggested checking a spouse's encrypted partition (I think the prank payback most likely because the method is part of the goal, most times it is breaking the strongest link).

I'm curious to know exactly what attackers you are afraid of and why rubber hose decryption won't be a very quick "plan B".

* laptops are likely to be either off or suspended (not applicable to this attack). If the laptop is running, it can be assumed to be grabbed off the lap of the victim, and the attacker can simply mount a USB drive and copy the entire disk at his leisure.

The key is used all the time, constantly -- every disk access to an encrypted partition requires that you have that key (somewhere) so that you can decrypt the data just read from the disk (or encrypt the data about to be written to the disk).

So it has to be stored somewhere while the computer is in use--somewhere instantly accessible (not e.g. on a different disk). In practice it needs to be stored in some kind of RAM or some kind of dedicated key-storage space from which the CPU can still load it into registers (and the difficulty of preventing those registers from then being spilled out to regular RAM on a context switch is pretty large also).

This is also the reason that it doesn't matter if you use a 20-character passphrase or something, to protect your key. At boot time, you enter the passphrase, the key is decrypted and then it stays around somewhere in memory the whole time you use the computer. At best we can obfuscate the key somehow in memory, but we can't really protect it in "strong" ways without physically-tamperproof key storage and software that knows how to access it safely and not allow any key data to "leak out" into the unsecured environment, where it could be captured by this kind of attack.

Actually most states in the US have pretty stringent disclosure laws for lost "PII data". The costs of a disclosure program are pretty high, depending on the amount of data (staffed call centers, mailings, lawsuit settlements, etc.). Presently the full disk encryption industry is serving those customers who fear having to go through a disclosure scenario. Previously a lost laptop with personal data on it triggered disclosure procedures, now a lost laptop with personal data using full drive encryption might need to trigger disclosure... Whether the thief accesses or uses the data matters not.

BTW Any company that would like use this idea may. Just give me credit for it in the footnotes unless someone thought of it before this.

Essentially if a thief were to acquire a laptop that was in suspend, standby, or otherwise on with a password protected screensaver they could theoretically reboot the machine use either a network or USB boot to drop the contents of the RAM and acquire the key. Alternatively they could super cool the RAM remove it from the computer and place it another computer and read the contents. The key are stored in RAM as they are used to decrypt anything that is encrypted. It really shouldn’t come as a surprise to anyone that this is possible. These guys have just refined it and produced some tools to make it simple to try. That said, it all depends on what happens in the courts (after all we are encrypting based on legislation and regulation). If someone tries to argue that encryption isn't good enough to protect stolen data and the courts agree based on the fact that it could be theoretically cracked it could become an issue. For now I would say we are ok with it. It will be fun to see what PGP and others say as a response. Really computers should be clearing RAM on reboot and not waiting for it to happen over time.

http://peternbiddle.wordpress.com/2008/02/22/...

Besides, I have a hard time believing it will remain for hours, sorry I don't buy that part. 10 minutes, okay.

The difference is that key-loggers must be put in place beforehand. Adding a keylogger after the fact is useless.

This attack is significant, because you can mount it on ANY machine, even those without a keylogger. And you can do it at relatively low cost.

Which one is the bigger threat? Probably neither one, when compared to the self-inflicted damage that users do to themselves with Trojans of any kind.

I think you are dead wrong

> Who uses these products and actually has things to hide?

> a.) Criminals - Who cares?
Crypted data on criminals laptop can harm other people and you should care!
-> .li

> c.) Corporations and Gov'ts. - This isn't much of a problem.
-> .co.uk

> ...Unless you have some really sensitive data...

really sensitive is so really relative

-

i think the discovered vuln DOES MATTER A LOT and I SCREAM FOR PHY PROTECTION.

(high voltage screws f.e.)

I havent rebooted my laptop since more than 2 months - i just put it sleeping and switching it off when its "out of sight" ll cost me bunch of time or a major lack of caffaine!

I realy dont care if my laptop hardware is stolen - But I would care if someone ll be able to recover my sleeping crypted data.

gimme phy security solution or a HOTSWAP RAM i can take with me all the time ill fetch some coffee.

Here is PGP's response:
http://blog.wired.com/27bstroke6/2008/02/...

This is not an "edge condition" attack! Lots of users (maybe even most) leave their machines unattended when they are screen-locked, and even transport them when they are in sleep mode or hibernated. These are all vulnerable conditions because when restored from sleep or hibernation, the machine is essentially in a "screen-locked" condition and vulnerable. A stolen laptop still represents a significant liability and companies need to stop treating stolen laptops that happen to be encrypted as "non-events."

I'm coming around to supporting Bruce's two level encryption proposal.

http://www.schneier.com/essay-199.html

Encripting the disk still protects against your laptop being stealed during transportation, that is the real risk here.