Slashdot Mirror
Cold Reboot Attacks on Disk Encryption
jcrouthamel writes "Contrary to popular assumption, DRAMs used in most modern computers retain their contents for seconds to minutes after power is lost, even at operating temperatures and even if removed from a motherboard. Although DRAMs become less reliable when they are not refreshed, they are not immediately erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system memory images. We show that this phenomenon limits the ability of an operating system to protect cryptographic key material from an attacker with physical access. We use cold reboots to mount attacks on popular disk encryption systems — BitLocker, FileVault, dm-crypt, and TrueCrypt — using no special devices or materials. We experimentally characterize the extent and predictability of memory remanence and report that remanence times can be increased dramatically with simple techniques. We offer new algorithms for finding cryptographic keys in memory images and for correcting errors caused by bit decay. Though we discuss several strategies for partially mitigating these risks, we know of no simple remedy that would eliminate them."
Could probably implement an algorithm at the operating system level that attempts to clear out DRAM except for what is actually needed for the operating system to power down/boot up. I am not sure of the exact logistics but it seems silly to just power down and leave the DRAM however it was, no matter if its instant cleared or take a few minutes.
Crackin' Wise - Blogging about whatever we want
Time for memory controllers with hardware encryption.
So how long does this information persist in the RAM? They say "seconds to minutes" but -how many- seconds? And what brands/types of RAM have longer or shorter latency?
In Xanadu did Kubla Khan
A stately pleasure dome decree
If you steal my laptop, and try to boot it, it doesn't magically decrypt anything for you to steal by reading the RAM shortly thereafter.
So you'd need me to log & open up the TrueCrypt protected data. Then, as I see you coming to kill me, I pull the plug on the machine, but in the next 3-35 seconds, you manage to read all of RAM.
Interesting point about DRAM holding onto memory after power is removed, but hardly a reason to worry.
I want to delete my account but Slashdot doesn't allow it.
Seal the computer case in such a way that it takes (decay_time * safety_factor) minutes to go from "physical access" to "memory module in hand". How? Standard office safes usually take about 5 minutes to break... put your sensitive computer(s) in those.
Bonus points for thermite of course.
So lets thing what physical access means in these cases.
1) They have your desktop computer
2) It is on
3) You've entered your crypto keys
Is it me or is this just a little tenuous? In a data centre they'd have to drag the thing off the rack and on your personal machine they'd have to physically take it off you, because waiting for you to shutdown and then walk-away would be too long. So the solution is to shutdown the machine and THEN put your coat on and pack your bag.
I can also get people's Crypto keys by threatening them with a knife or putting a CCTV camera over their workstation. There are "easier" ways to get the keys if you have physical access to the environment that are much simpler and reliable.
An Eye for an Eye will make the whole world blind - Gandhi
From TFA:
Our research shows that data in DRAM actually fades out gradually over a period of seconds to minutes, enabling an attacker to read the full contents of memory by cutting power and then rebooting into a malicious operating system.
But then, just reset the CPU and boot into a memory analysis program, without powering it down. Why bother with potential DRAM errors?
New! Improved! Our memory forgets!
Seriously, between overwriting data that is no longer needed, storing sensitive data such as keys encrypted in a daisy-chained manner that includes chain elements on different chips and even in different subsystems such as the graphics controller or on-cpu buffers, and having a small amount of memory storage that really does disappear the minute you pull the plug, this should be a non-issue.
The latter may require extra hardware but the rest can be done on existing equipment.
--
Daisy chained encryption:
Old way: Decryption keys for your opened encrypted disk are stored in RAM.
New way: Decryption keys for your opened encrypted disk are stored in RAM but in an encrypted format. These encrypted keys have a few bytes stripped out to make decryption impossible. The stripped bytes are stored somewhere else, such as in the CPU cache. The keys to unlock the decryption keys are stored somewhere else, such as on the graphics card.
The only place everything is brought together for any length of time is in the CPU or CPU cache. During actual disk access, the cleartext key to the disk is stored in the CPU or its cache, then immediately erased.
Such a system isn't foolproof but it's a lot less vulnerable to a "I had my container open when the cops came to my door equipped with forensic RAM-reading equipment so I pulled the plug on my computer" attack than the old way.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
This is just an excuse for some company to sell some kind of snake-oil "RAMWiper" product and try to scare rubes and idiot nontechnical CTOs into believing that they need it.
We've said it time and time again. If the bad guys can get physical access to a machine (which it seems they would need here), all bets are off, and there's nothing you can do about it. Period. The trick is preventing physical access.
Intel has a technology called TXT that would clear the memory in situations like this before handing control over to the boot medium.
http://www.intel.com/technology/security/
That's the hard part, so any hack using this method almost has to be an inside job. How many hackers can actually walk into a location, take down the system, open it up and remove the memory DIMMS? In every data center I've worked at someone with that level of access is pretty well checked out, or if they are a vendor they are escorted and watched carefully. Pulling DIMMs out an puting them into liquid nitrogen is surely going to be noticed. It's not like you carry a Dewar in your pocket. Sure you can spoof the system once in a while but you got to be a damned good imposter. If it was your personal/corporate laptop/desktop and you had "Geek Squad" working on a problem you may have an issue. Also, consider the data in RAM is binary and could be anything from OS Code to App Code to data, you really have to know how the layout of how the chips store and access info as well as the structure of the information (what's code, whats data) and how to identify each type of information. Bit decay is also a problem, when you reach a certain time the bits start to decay, and you can't always tell with certainty it's a 1 or a zero. That decay time will vary by mfg, technology, speed of chips, etc. Once you have access to a machine deep enough to pull chips there are MUCH easier hacks, backdoors, trojans, malware, booting your "custom" OS off a thumb drive, burning files to a "backup CD", etc. are all much easier. It's RESEARCH not (yet) a reasonable way to hack the system.
You could use a capacitor to power this mechanism instead of a battery. It wouldn't need to last very long -- just long enough to scramble the RAM on power-down. It would be more reliable than a battery.
If the attacker has physical access to your system, it's not your system.
Best Slashdot Co
One potential workaround, which would probably require support from Intel/AMD: store a short encryption key in L1 cache. It doesn't need to be big, or use "proper" encryption - just enough to make the DRAM key useless unless you've got the cache memory.
I would hope that the CPU could clear this cache as it powers down (even in a non-orderly manner).
Then again, I realise that people who aren't experts (and I'm definitely not an expert) very rarely make suggestions which actually fix significant security holes...
At some point, data needs to be in its plain original form to be operated on. I guess it all depends on how close to the heart of the "execution core" you want the encryption to be used. The closer you keep the data encrypted, the bigger a performance hit you're going to have. Call it the "plain-text hole" if you will.
The class of devices most likely to be affected(and I'm really not sure that I mind at all) will be the various systems designed with the assumption that the user is the enemy(many cellphones, set top boxes, etc, etc.) Those tend to have fairly small amounts of memory and, since the "attacker" is the owner, plenty of leisurely physical access. I just can't get too worried about that class of attacks, though. When "security" means locking me out of my stuff to benefit some third party bottom line, insecurity is good. This comment applies to the majority of attacks that require somewhat exotic physical access. Remote vulnerabilities and trivial physical attacks are dangerous; but more sophisticated local attacks are what we used to call "user tinkering" and I have every desire for their success.
Another option -- just make DRAM that drains all of its memory cells to ground when the power goes off. Every bit of DRAM is just a tiny capacitor, so this would erase the whole chip in an instant. If you could arrange for this to happen, then the DRAM would be be erased, unless you somehow supplied your own power to the DRAM chips.
Heck, with physical access to a running machine, jack into the firewire or USB port and you have clear access to reading and writing all the memory you want.
I wrote a small paper here http://www.friendsglobal.com/papers/FireWire%20Memory%20Dump%20of%20Windows%20XP.pdf for a forensics class on using firewire to access memory, subverting the operating system.
All bets are off once physical access is gained. Best bet would be to store the keys, somehow, in the CPU's caches and never let it stay in main memory.
there's no such thing as absolute security
all security does is build a wall. someone can always climb over it, somehow. the question for you is merely do you want a white picket fence? or do you want a 10 foot chain link fence with barbed wire on top?
locks on doors merely keep honest people honest. anyone determined to break into your house will find a way
don't invest your energy in a failed concept: i can have absolute security. you can't, it's always an arms race, forever
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
However, for grins one day, I decided to run "dd if=/dev/mem bs=1m count=[mem size] | strings | grep [whatever]" and found not only various passwords, but URLs for sites visited *weeks* ago, even after reboots. So, I installed the "secure_delete" port and ran "smem". No luck -- some stuff got wiped, but some remained in memory. So I booted to a memtest86 CD-ROM, and ran the full test (this test does all kinds of writes/reads to memory). Then, I booted *back* to the normal system, and I was *still* able to recover juicy bits from /dev/mem. WTF?
We need a kernel module for the common OSes that can encrypt virtual pages (is that the right term?) so that whether in core or paged, they won't be vulnerable.
Method of processing duck feet
we know of no simple remedy that would eliminate them...
As part of a secure programming course I recently took, we were instructed to overwrite keys with zeros when done using them. It's that simple - you don't leave the key in memory for any longer than you need it.
When the machine is powered down, your application's exit routine zeros all of the memory, and then free()s it. Nothing that good programming practices can't address.
Generally speaking, it's the keys on the disk(!) that are the problem. Without two factor authentication, you need merely to scan disk sectors...
The society for a thought-free internet welcomes you.
This attack is very powerful.
It's not possible to "clear the DRAM" (as others have suggested), because the attacker will boot his own CD and not give control to your OS after the reset. Thus you won't be able to clear anything.
Anything? Not so quick, my dear! For the CD to boot, first there is the BIOS. And BIOS needs memory as well (for the menus, the screen, the ElToro floppy image etc).
Now the countermeasure is obvious: Keep the sensitive key material in memory areas that is erased during the early boot procedure. Then the attack complexity is raised from "no hardware required" to "specicialists hardware necessary, no guarantees given".
It might seem difficult to find out which memory is of that category. But it isn't, either! Just prepare two boot CDs. One that fills all memory with a known pattern (eg 0x55). Boot it. Then reset and insert the second CD, which identifies all memory areas that have lost the known pattern. These areas have either suffered DRAM fade, or they have been overwritten during the BIOS boot process. Use heuristics to find out which of the two was the cause. Done!
As simple as that.
Regards,
Marc
Time for memory controllers that just zero out RAM on power up. I think most do anyway.
Worse, on most running OSes there are all kinds of deallocated and leaked chunks of memory that have god-knows-what in them. As root, you could browse through all this, or just trigger a dump.
This is fun to know, but really, if someone is going to get physical access and rip the RAM out of your machine for its secrets and then plop them into a specially-crafted dead-RAM reader, you've got bigger problems, like the CIA or FSB is on your ass already, and you probably have guys with guns at the data center door anyway they'd need to take out to get at the machine.
Otherwise, just steal the whole machine and read the disks. Much easier, and there's probably just as much interesting stuff on the disks.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
But the auto-turret I have guarding my computer would get you before you escaped.
Solder RAM to board.
Password the BIOS, boot only from local disk.
If somebody has the kind of access to cut power to your system and then immediately reboot with a malicious thumb drive, they probably have enough access to install something like an inconspicuous hardware keylogger, which I would be much MUCH more worried about than this if you're doing something sensitive enough to warrant it.
And aside from that, couldn't you just encrypt the important parts of your memory and swap as well as your hard drive? Seems like that would defeat this quite handily, and again, if I were doing something so sensitive I'd probably be taking such precautions.
Honestly though, aside from people doing stuff like maybe international or corporate espionage, I can't imagine where any of this would be a problem.
Full memory encryption. Set a chip on the memory buss, it encrypts/decrypts all the data as it passes between the CPU and RAM chips. At first this would be something like old MMUs before they were built into the CPU itself. They sit on the address bus and add/subtract offsets. This would sit on the data bus and do some simple crypto. Put a capacitor right next to it, first time the chip powers up it selects a random key, when the motherboard looses power the capacitor keeps the chip running long enough for it to overwrite the key that it was internally storing.
Then if they manage to break into your super secure datacenter, wheal in their tank of liquid nitrogen and pump your server full of it just so they can steal your RAM chips...it still doesn't get them anything.
(If you read the paper, they talk about how if you cool the chips with liquid nitrogen they keep their contents with power off and removed for 'several hours'...they argue that simply modifying the bios to zero at startup isn't sufficient as they may physically *remove* the ram chips before you have a chance to zero them)
END
I pulled a PIC-4 uP out from a circuit. The DRAM stayed non-refeshed for 2 minutes...
You are assuming that...
a) Your average cop who is seizing your PC is well-read enough to know about this technique
b) The cops came totally unannounced to you
c) Your PC is left on all the time with your encrypted partition mounted, or that the cops moved through your house so fast (30 seconds according to the article) that you don't have enough time to turn the machine you are using off for long enough for the DRAM to lose it's charge.
d) You don't have a BIOS boot password set on the PC (any BIOS password would take at least 30 seconds to bypass by opening the PC and clearing the BIOS)
In short - if you have data that is important enough to keep secret that it is on an encrypted partition, you shouldn't be leaving it mounted all the time ANYWAY. You should mount it when needed and unmount it as soon as you don't. Thus there won't be any keys in memory to steal.
... at least those that are worth their money. What was unknown is the exact amount of time you have and what can be done to extend it. Interesting reseacht for those alone. The basic vulnerability has been known for a long, long time.
Fix: None, really. Just don't overestimate the capabilities an attacker needs to get your data. Also note, that if a computer has been switched off for some time, the risk fades. Protecting laptop disks with disk encryption is not a lot less secure now and still a good idea.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
If you lost the machine and someone else can now be reasonably assumed to have taken the machine, you have already lost the war and the data contained within. There are other ways to bypass encryption methods on HD's. The real trick is to not keep valuble information on local hard drives. There is a reason Jesus invented TCP/IP and network storage. Not only do you get the bonus of having all your "special stuff" backed up, but your laptop is basically a dumb terminal and the loss or theft of it only incurs the cost of having to replace the laptop. Your data then lives safely in your data center
It's called a good set of policies and procedures with an informed staff. Hell you don't even need an informed staff, just map their home directories or "my documents" folder to the network. Then even the monkeys get it right.
Easy fix: install a BIOS/boot ROM with a non-bypassable memory test of all memory. This will clear all memory at power-up before reading the boot device.
It is not possible to secure anything from an attacker with unlimited physical access to a system whether or not it is a bank vault or computer. I would have thought this is obvious. The best you can hope for is making the attacker's time and the expense required prohibitive or preventing physical access in the first place. Unfortunately attacker's tools tend to improve over time like the technique descibed here.
If it was such a big deal that your RAM be secure why dont RAM makers make special "Secure RAM" kits with a small (I am not an engineer, please forgive my ignorance)battery and have it detect power down, and then expend the battery to alter the RAM contents, write all 1's or something? An OS solution wouldn't work if the power was pulled, I expect nearly all legitimate uses of RAM dont need the contents after power down so chances are anyone trying to get at em has nefarious plans.
They don't run the shutdown scripts, they cut the power to a running system. that's why it typically only works when the computer is on. Also, Dram ~is~ cleared at boot, as it will be over written by new data, but their boot-time software takes care of that.
This is an easy fix. Simply put a PLD between the RAM and the memory controller, and have a battery backed supply that runs the memory for a short time after poweroff. When power goes away, the battery backup circuit holds up the PLD and the RAM long enough for a state machine in the PLD to scrub the memory.
has the RAM soldered in the motherboard! I knew Apple was thinking of our security all along!!!
/*ducks*/
Where is that guy who'd die defending what I had to say when I need him?
Put the key in a small piece of SRAM. When it gets used to encrypt something, be sure the place of its usage gets wiped back off real fast to minimize the chance of it being exposed to the cold attack. Split data up with different keys for different data, so if a key is exposed, only a minimal amount of data is lost. Another option is to double or triple encrypt the data being sure never to have more than one key at a time in DRAM.
So where do we get this SRAM? A CPU register that is not used, and not saved, for any current purpose is one possible place. For a large amount of SRAM, check out your video card buffer.
now we need to go OSS in diesel cars
Make the BIOS clear RAM on power-up.
Wait, doesn't it already?
Wait, did the researchers bypass BIOS?
Well, if they did, then adding some crap to DRAM to kill it on power loss is the only way. Probably.
It was once an axiom of system security, that if you gained physical access, all was lost. This evolved from keyboard and console attacks to floppy- and CD-boot attacks, USB keys, stealing the hard drive, you know the drill.
Ultimately, if you can cart away pieces of the machine, your last line of defense is gone.
The only other variable to control is time. Make the DRAM die quicker, or is it time for a 'better' memory technology?
And this is such great stuff, the TEMPEST guys will now have to re-write their procedures, with both a power-off and wait 30 seconds, and a re-power-on and wait for login prompt, then shutdown again.
Sometimes I hate h@xrs, and sometimes I realize they do me a service, albeit while they intend to just do me.
How ironic. My captcha is 'honest'. This cannot be coincidence.
deleting the extra space after periods so i can stay relevant, yeah.
This attack is probably very real and interesting research, but you have to ask yourself who are you protecting yourself from. A stolen computer with an boot password protected, encrypted hard drive will be formatted long before it hits the streets and that will be the end of it. If you are concerned about government agencies reading your encrypted files, there so many other way to get to it... Especially if you have access to the hardware. Old school ICE (in circuit emulation) will give you 100% reliability and defeats Bitlocker/TPM. Password protect your encrypted drive and move on...
While an issue for whole-disk encryption, this is also an issue for DRM. Just flick the power while the interesting media is being decrypted, and even if the OS had been protecting the key in some "safe" location, you can now find it. It might be little more tricky, but if you can pull the RAM on a video game console, you can do the same thing.
...someone canceled their WoW account, and has free time on their hands ;)
- Is the Cardbus slot always enabled or must the OS enable it? (If the OS has to enable the cardbus slot you can be safe if the OS doesn't probe the slots when the screen is locked.)
- If the OS enables the Cardbus slot can it stop the device from doing bus mastering before the device has been identified and a driver has been loaded?
(If so you only have to mimic a card which the OS has drivers for to work around it though.)
Creating a cardbus card isn't exactly rocket science. You could probably do it in a weekend with off the shelf components for less than $200 unles Murphy is feeling creative...To everyone saying 'if someone has physical access you're hosed anyway'... that simply isn't true. If you have a laptop and encrypt your data correctly, it was thought that it was mathematically infeasible to recover the data if your laptop was stolen. But with this (new?) technique, if it works well enough to be reliable, you could still be fucked even if you took the precaution of encrypting everything.
This is yet another attack that the developer of loop-AES thought about while typically every other disk encryption tool out there is vulnerable. Loop-AES is the 3rd most popular disk encryption tool in Linux. See the KEYSCRUB=y option in its README file:
I have used loop-AES as a full disk encryption tool on my laptop for 2+ years. I am glad I took the time to carefully research which tool would the most secure before deploying it ! For example even TrueCrypt and dm-crypt are vulnerable to other (arguably minor) security issues that loop-AES is impervious to: http://article.gmane.org/gmane.linux.cryptography/2321
Surprisingly, the research paper TFA talks about doesn't even directly mention loop-AES (its name only happens to be in the title of a webpage in the reference section describing a safe suspend/resume setup when using disk encryption).
That was a rubbish troll. Sorry, but you fail it.
I found (admittedly some 20 years ago now) on a very simple computer with SRAM memory that, after powering it off and on again, a significant percentage of the contents of the memory were still the same. Naturally, the longer you left it the more random the results became. Of course, it was CMOS RAM, so the transistors would have some capacitance which would account for the, err, memory.
Look, this is not about "our" ability turn off the PC and pop out the RAM while the Department of Homeland Security is busting down the door. This is about thieves, corporate saboteurs, or Evil Gubbermint Agents bypassing or breaking drive encryption when they already physically own your box. No hardware module is going to help - your drive won't even be in your PC in many cases, it'll be in their box which they will keeping rebooting until this technique (or similiar) works.
It seems like the best defense would be applying epoxy to the memory so it couldn't be removed from the slot. If you make sure all the connections are covered as well, they wouldn't be able to place a tap, either. (At least without a lot of time being spent slowly drilling through the epoxy.)
It would make it impossible to replace your memory, but you could always move the HD to another system. If you care that much, then you should be willing to pay for a new system if someone tries to compromise your data.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
I'm sure there's some way to hotswap a normal RAM module without frying it, even if it involves attaching extra ground wires for a while.
I'm surprised no one has mentioned the Cell processor yet. I guess everyone hates it.
The first power word that a toddler learns is "mine!" It's the capstone to a complete working vocabulary: mommy, daddy, more, enough, and mine. My laptop, my hardware, my data, my privacy. The word "mine" has a direct bypass to the neurological circuit "you can't make me", which as adults lingers as a deeply-rooted fascination with rubber-hose cryptography, and bravado propositions such as "if the Feds bust through your windows". Wrong answer.
Let's look at this from Sony's perspective: my media, my hardware, my design, my copyright, my profits. But guess what? They have a small physical access problem. Millions of zit faced kids with access to liquid nitrogen can get their paws inside the PS3.
This is why an entire SPU is locked down on the PS3 for security / DRM purposes. The SPU contains 256K of SRAM which is carefully guarded. The instruction set is synchronous and deterministic to guard against timing attacks. They were aware of power attacks as well. These can be partially mitigated in software for critical routines by executing non-conditional instruction sequences and then discarding the portions of the computation you didn't want. By design, the SPU doesn't dance on the power line the way most modern speculative out-of-order processors do to begin with. You can't use latency effects, because the local SRAM has constant access time. You can't use contention effects because there aren't any below the level of DMA bursts, which are controlled by a companion processor within the SPU. Plus I think it is possible to schedule SPU-SPU and SPU-memory DMA transfers deterministically, if you really need to. None of this was accidental.
The hardest part of the problem is bootstrapping the secure SPU with the security kernel. I've forgotten how they went about it. There must be some kind of decrypt key buried in the Cell hardware which functions during initial code upload during processor initialization.
In the long run it might be an unwinnable battle, but the PS3 certainly has a far better facility to maintain data security in the complete absence of hardware security than your average PC.
Why can't the average hacker Harry wants to enjoy the same security as Sony/IBM, why can't you achieve this? You've already got the PS3 in your living room. Impediment: the secure system init decrypt key is probably burned into the silicon. It's probably a one-way key, so even if you crack the key, you won't be able to encrypt a replacement block of your own code that matches the decrypt key. But let's suppose you break that too. Problem: Sony knows the decrypt key for the SPU initialization sequence. Game over.
Let's suppose you figure out how to physically change the silicon with an initialization decrypt code known only to yourself. Congratulations, you now enjoy the same protection for your secrets that Sony enjoys for "Untraceable". In doing so, you have now upgraded yourself to a sufficiently threatening fish to swim in a tank in Syria, where your nervous system will be similarly reconfigured.
Ew, I feel like I've just written the script for "Adaptation".
HIB can be disabled in most OSes. This disables USB mice.
Hardware shock-detectors can be added. If your computer moves, the OS knows and can take appropriate action.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Even better solution: Provide cryptographic support in the CPU and store the keys there, or lacking that just some extra storage for key schedules. Only 240 bytes of storage are needed for a full AES-256 key schedule, twice that for fast encryption and decryption with the most common implementation.
It would be much harder to extract the key schedule from the CPU hardware with the system running, and much easier for the CPU to wipe the storage upon loss of power. As long as the OS wiped the key and passphrase (or any other key source) from RAM upon startup, the key should remain secure.
This could probably be implemented with a few MSRs (model specific registers) for backward compatibility while still retaining a high speed software implementation of the cipher.
I think the word you're looking for is "tenet".
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
The class covered those things as well: lock the page in memory, and ensure that the compiler doesn't elide the call to memset(buffer,0,len) by reading back the data. A recent discussion on a crypto mailing list discussed this latter issue at great length, and the consensus was that while theoretically possible, no compiler actually elided calls to memset(), even if the compiler could prove that the memory would never be accessed again.
The society for a thought-free internet welcomes you.
Static RAM remembers only as long as it has power. But it does not need an active refresh signal, just power. Flip flops need power to retain their state.
http://en.wikipedia.org/wiki/Static_RAM
Dynamic Ram needs both power and an active refresh signal.
http://en.wikipedia.org/wiki/Dynamic_RAM
You may be thinking of Flash ram, as is used in thumb drives. This uses electrically erasable programmable read only memory (eeproms)
http://en.wikipedia.org/wiki/Flash_memory
Memory is reliably addressed -- writing to the address you wrote to earlier will change the same physical part of the ram. There are already existing tools that erase passphrases after a certain period without use. All you need to do is make those tools also scrub the addresses used to store it. A simple patch would cover that.
What's more of a problem is: how to make this timeout+prompt for passphrase thing work with disk-level encyption regardless of whether you're a console or in a GUI, on an otherwise decent OS like unix? I wouldn't trust Windows to implement disk-level encyption safely anyway, so all bets are off there. But unix still has serious issues regarding the simple presentation of a dialog box to the user no matter what part of the system they're looking at, in a reliable and secure way.
This seems most useful as a way to help crack DRM and bypassing OS level 'trusted computing' type measures. Since it requires a machine operating with the key active it isn't much use for things like decrypting a stolen laptop.
This program was made possible by a grant from the Ultra-Humanite, and viewers like you.
way back when i was working on sparc 10s there was a battery backed sram board you could buy that would queue up all your disk writes to... if you lost power it would flush once the driver reloaded thereby preventing your journal-less fs from going fubar.
could there be an adaptation like this? is sram vulnerable? is there a sram/cache area of the machine that you could allocate to store keys that would be assured of corrupting when you lost power?
Zombie Memory attacks! Seriously, for most people this is a non-concern. The effort required to develop an attack this way is comparable to your average IMF mission. I suppose it might conceivably be an issue for those in high-security environments, like those who use NSA linux, but damn if anybody else really needs to worry about it.
Where does this really have much of a security risk? Seems to me you would have to have a ready system setup to receive the ram and copy the data. And since you want data that someone was working on they would have just barely finished working on it. So inorder to really get anything valuble you would have to shut down someones computer within minutes of them accessing something, open the case, remove the ram, insert it into another system or what ever you have set up to copy it, and then copy it all in only a few minutes. That looks highly unlikely to me.
Is that absolute security? Well, an outsider couldn't break the encryption. To do so requires the pad. There are no shortcuts. That's pretty absolute. And even with the pad, you need the offset and stepsize. I've been told of systems where these were mechanically random - the one-time pad tapes synchronized themselves remotely at a speed that was effectively non-deterministic, consuming a non-derministic amount of tape to do so, giving you the random offset and step size.
Ok, well is that perfect? Since not even the people with the machines could tell you in advance at what speed or at what point the synchronization would lock, that's pretty damn secure and could not possibly be known in advance. Thus, an attacker cannot have prior knowledge of the key being used. Nobody can, even if they have all of the physical components.
Yes yes yes, it's secure, but is it perfect? It all depends on what you mean by perfect:
It is not "perfect" in the general sense, because if person A can decrypt the message with some information in their posession (A'), then person B can also decrypt the message with that same information (A').
If you have N people in a group, how many of that N must be honest in order to guarantee that information from A to C reaches C even if at least one traitor B exists in that group, where C is not a traitor? The answer is (N/2)+1.
Now, if (N/2)+1 out of N must be honest, can we improve on our encryption system? In order to get the pad to C, we could make a copy and break it down into random-sized fragments (that may or may not have holes), such that you need (N/2)+1 fragments out of the original N in order to rebuild the tape in the correct sequence. Even if everyone else was a traitor and cooperating with each other, they could not reconstruct the key.
Now, to prevent said traitors tampering with the key, each fragment needs to be securely digitally signed. This means that A must have a key that everyone else can test against (and therefore decrypt) but nobody else can derive. Both the intended target and all traitors will thus know which fragments are real, but a traitor will not be able to make a fictional fragment look real.
Is this perfect now? It depends so much on what you mean by perfect. It's now impractical to attack in transit, provided the algorithms themselves do not have weaknesses which push below the assumed security threshold. Provided both source and destination are themselves genuine, AND provided both source and destination have internal compartmentalization such that if/when attacked, the attacker will not be exposed to the encrypted message, the decrypted message or the decryption key, you have an admirable level of security.
But is it perfect? Define perfect. I would consider any system that is so secure that it would never form a part of the attack vector for the forseeable future to be - in any practical sense - perfect. No matter how much you added to it, it would make no difference to what anyone did or how anyone acted. It's perfect in that attackers would spend their resources attacking anything and everything else. Even if it were "perfect" in some abstract, theoretical sense, it would not add ANY additional security to the system. To me, that is perfect in the meaningful sense.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
If I just
1. pull the plug
2. pull your RAM
3. insert your RAM into my computer
How about
1. use a master password to generate a passphrase at login-time. This passphrase is stored in and only in the memory controller.
2. this key will be used to real-time encrypt the RAM contents with a symmetric key cipher - so plaintext would only exist on the FSB between the CPU and the Northbridge.
3. this small, special storage in the memory controller is guaranteed to be zeroed within a short hard limit if not powered.
Of course you can design new RAM that does this, but assume this new RAM is more expensive, sparing a KB or two of some special storage just for the key would be enough.
Of course, the short key vs the large memory capacity, and the fact that memory is used piece-by-piece, would mean a lot of potential for known-ciphertext-attacks.
However, cracking with partially-damaged ciphertext is quite a bit more difficult than with either intact ciphertext or damaged plaintext.
Yes that was the word I was looking for, thank you.
Curiosity was framed, Ignorance killed the cat.
It would be relatively easy for DRAM to be augmented with internal circuitry that nukes the ram cells if they have not been placed in slef-refresh mode.
Engineering is the art of compromise.
context is key i guess
in the realm of casual slashdot comments, i think my words ring true and yours paranoid
but in the realm of a healthcare company's IT dept discussing what to do about the laptops of travelling executives containing member's medical information, my words would ring irresponsible and lazy, and yours ring prudent and exemplary
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
What a nifty idea! Plug a UPS into the power strip to provide power, and unplug power strip from wall. Voila, UPS kicks in and portable power. I wonder what it would take to DIY that concept. Love the mouse jiggler USB plugin to keep the target computer 'active'
Note to self: plug all computers directly into wall socket. That way, they have to tap into the power from behind the wall outlet before moving the computer. (They already thought of that.)
(retrieves fresh tinfoil hat from microwave)
It is NOT a capacitor. Mod parent -1 misinformation
Modern day hard drive uses the disk platter(s) as a fly wheel and use regenerative braking energy via drive motor + driver circuit to park their drive heads.
Now, type three lines of code: Scan the screen printout and see if there is anything that scares you! Sure managed to scare my computer teacher and muck up my HS's lab computers back in the 1980's, hee hee. Good old Corvis.
Slashdot "libertarians": Small government for me, big government for those I disagree with. -1, I disagree with you
While interesting from the standpoint of creating Teh Ultimate Secure System (tm), this is really nothing for anyone to get their panties in a bunch about.
If an attacker has physical access to your machine, it's pretty much game over anyway. HOW they go about exploiting that compromise of security just becomes academic.
The computer part is, realistically speaking, the lowest level of importance for security anyway. The top level would be securing access, the next level would be user training (to protect from social engineering attacks), and then far lower in importance is the actual technical computer or networking issues. Because if an attacker can get neither local nor remote access, they can't even start.
Remnants in memory are a known problem. I worked for a while at a big hardware company, and when designing systems with national security clients in mind we did worry about this.
I believe that the C3 processor made by VIA and probably other processors in that family allow some of the cache to be configured as SRAM and mapped into physical memory. So, you could store the key in SRAM, which I believe really will lose its data upon power loss, although you may also want to take countermeasures such as those used in loop-AES to avoid detection by physical changes to the chip if key is store for a long time in the same place.
Newever VIA processors also have some hardware AES support available under Linux, which they call "Padlock. So, if they still retain the SRAM feature, then, at that would make a pretty good choice for the little fanless mini-ITX Linux box that receives your email.
I have done this before when i was using a Live Linux (Slax) for file recovery purposes.
When i booted up the OS, when the GUI was turned on, i saw some of the remains of my desktop from Windows.
And several other times in booting up the GUI, i saw the previous image stored.
I am honestly surprised this hasn't been done more than this, or maybe it has and it just hasn't been documented...
I 'll compute on my head
they need to gain access withing 60 seconds of turning off the power, and that's best case. Most likely they need access within seconds.
That mean as soon as you shut down, someone would have to jump in and reboot. really not going to happen is it?
If someone has gotten in, they would just point a gun at your head and make you give them access..or just step away from the keyboard.
Not a big deal.
The Kruger Dunning explains most post on
To your machine or your hard drive? Most disk encryption is for protecting "data at rest".
Another effective attack against disk encryption is a Trojan: when you mount the encrypted drive the Trojan, running under your credentials, can access the data just as easily as you can. They don't even need physical access, only logical access.
One could rig the wall outlet with a pressure switch to kill power if the plate is tampered with. Actually I'm surprised this isn't a safety feature on existing outlets. Or you could set it up so that only one of the outlets is hot, in which case the "outlet seizure" method wouldn't work. Or use a relay to kill power through one plug if current flows through the other.
Sounds pretty cat and mouse to me. They think up an attack, someone else will think of a defence.
For this reason anyone who is worried they might suddenly be raided might want to install a panic button. Pressing it would erase the encryption key from memory instantly, then set about wiping the rest of the computers RAM.
Have it also activate if the case is opened or a special suicide password is entered (in case you leave your PC on at the login prompt or screen saver).
Either that or just wire your doorbell to small bomb strapped to your RAM. That way when the CIA ring your bell...
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I read the paper today and was rather depressed that this seems to be all bad news for us folks who value our privacy in that it makes our encryption more vulnerable. Then I saw the bright side: It makes *everyones* encryption more vulnerable including DRM schemes. So even if they do lock us out using DRM you can cool the RAM and get it out of the machine (or just clip on and read it out after power-off of the host system) and read out the encryption keys used by the DRM.
Overall I think this may be a very worthwhile trade. The chances of someone actually performing this attack on my physical hardware while the encryption key for my encrypted volume is in RAM are slim. I keep it unmounted when it is not needed. And they need to have physical access which means they are either feds or really determined crooks.
But my chances of being able to benefit from cracked DRM via this method are great. It only takes one person to do it and millions of people will have access to the hardware.
I don't care if somebody does get my files...It's my password I want to protect! I'd be embarrassed if anybody knew it was L3zp0Rn. Do mom's read Slashdot?
I disagree. If you've read the paper, you'll see that the researchers use refrigerant (compressed air bottle turned outside down so contents come out in liquid form and very cold) to sustain the contents of the DRAM for several minutes (rather than the seconds that that data would last at room temp). The Princeton researchers seem to know what they're talking about in their paper, so I'd say this is a credible threat.
Having said that, it still requires a certain amount of effort, timing, and, ideally, luck. Also, it does not appear possible at all (using this attack vector) when using on-board encryption such as Seagate's Momentus drive.
What to expect in the future? The attack is hardware-based, and a real solution will be hardware-based as well. FDE software can go so far as to use obfuscation tactics to make analysis more difficult in the meantime, though the threat will still exist so long as the hardware is vulnerable.
This story is another reason why state legislatures should not mandate encryption as a data security procedure.
Benjamin Wright, Dallas, Texas, benjaminwright.us
So, one more thing to do when the authorities come bangin' at the door, you now have to dismount all your open encrypted volumes first. (as well as secure erase */tmp, */temporary internet files, */cache, erase and clean restore registry files etc etc etc etc etc )
Wiping the password cache is not enough: the password/keyfile is only used to decrypt the master key, which is then used to decrypt the volume. The password itself does not decrypt the volume.
If you got the wrong sort of garbage in RAM on a Commodore 128 there was no way to reset it. You had to unplug it and go for lunch while the RAM lost its contents.
No sig today...
Sure this is an interesting idea, but lets be honest, it's not plausible. If you have physical access to a sensitive machine, or network for that matter, there are plenty of other avenues to explore that would require 1/100th of the complexity this article speaks of with a greater "success" rate.
The immediate solution is obviously to just make it hard enough to open the case of the computer - make it take too long to get at the RAM and extract it.
So... Make sure all enclosure screws are in, add the padlock there's usually a eyelet for, and obviously make sure to cut the power as soon as you realize it's a raid. I know TrueCrypt has a very nice hotkey mechanism that will dismount one or all crypto drives upon activation, and I know most OS's are able to actually power down the system at the end of the shutdown sequence. So, make it possible to use a hotkey or (even better) an external trigger (like a physical intrusion detection system) to dismount drives, scramble the memory used for keys and go straight to a full powerdown. That would competely invalidate this cold attack.
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
Maybe. But just imagine an office full of people who've wandered off to lunch leaving their clients locked. Shove in a small USB key and hit the power button - grabs keys and dumps drive to disk in a reasonably short time (and you can just wander off out the way whilst it's dumping). They come back and all they notice is that their machine has mysteriously rebooted. Alternatively you could just install an FTP client that'll happily trickle out the contents of their machine throughout the afternoon. Brute force decryption, as far as I'm aware the only previous way of cracking the HD would involve removing the machine and making the theft easily visible ("Where's my laptop gone?"). I'm not quite sure why the linked article was so excited about cooling the memory to keep it stable for minutes - yes it's very clever being able to move it to another machine, but somewhat pointless. Should've just focussed on "I can rip off your encrypted drive with a reboot"
A virtual machine that owns the encrypted drive and fills its allocated memory with 1s on own shutdown should do the job. There are zillions of ways to get it quickly down, you can even use a timeout.
I'd like to know who marked "theaveng" posting as a troll?
That wasn't a troll. In fact it was quite informative to learn how the U.S. government protects its laptops.
The government is not your daddy. Its purpose is not to raid middle-class neighbors' wallets and give it to you.
Hard connect the RAM sticks to the motherboard. Oh, and armor the connection path so that cracking it off destroys the RAM.
Hi all, can anybody please send me the original paper? It's not accessible anymore: http://citp.princeton.edu.nyud.net/pub/coldboot.pdf wget http://citp.princeton.edu.nyud.net/pub/coldboot.pdf --16:14:16-- http://citp.princeton.edu.nyud.net/pub/coldboot.pdf => `coldboot.pdf' Resolving citp.princeton.edu.nyud.net... 140.192.249.204, 128.6.192.156, 128.31.1.13 Connecting to citp.princeton.edu.nyud.net|140.192.249.204|:80... connected. HTTP request sent, awaiting response... 502 Bad Gateway 16:15:04 ERROR 502: Bad Gateway. Thanks a lot Jiri
Twitter, is that you? The only thing missing is the dollar signs.
what if you dident store the key in the ram instead you store it in a removable flash memory maybe one where you nead your finger print and password to unlock the key and its is only unlock so long the flash memory is connected or the computer is on? The flash memory should also be tamper proof and impossible to read whit out the korekt finger print and password.
Comment removed based on user account deletion
http://toolmonger.com/2007/10/25/thermite-fixes-everything/
Try also my gallery: http://photo.net/photos/AntrygRevo
Good discussion above. For the fun of it, here is one way sensitive data might be destroyed when your lair is under assault. You already know this if you've seen the dumbest movies of 2007.
http://youtube.com/watch?v=5F6W7U2Mwuo
Jump to about 4 minutes.
Comment removed based on user account deletion
My personal favorite way to fight this would be wire up the outlet the computer is running from to 230V, while of course giving no indication that it's anything other than a standard outlet. Most computer equipment will run on that, but it stands a pretty good chance of blowing up their UPS if they don't check for it first.
If I remember correctly, when setting up PGP, it mentioned this type of attack and their countermeasures. From the Help File: ..."
...."
" Passphrase Erasure
When you enter a passphrase, PGP Desktop uses it only for a brief time, then erases it from memory. PGP Desktop also avoids making copies of the passphrase. The result is that your passphrase typically remains in memory for only a fraction of a second.
" Memory Static Ion Migration Protection
When you mount a PGP Virtual Disk volume, your passphrase is turned into a key. This key is used to encrypt and decrypt the data on your PGP Virtual Disk volume. While the passphrase is erased from memory immediately, the key (from which your passphrase cannot be derived) remains in memory while the disk is mounted. This key is protected from virtual memory; however, if a certain section of memory stores the exact same data for extremely long periods of time without being turned off or reset, that memory tends to retain a static charge, which could be read by attackers. If your PGP Virtual Disk volume is mounted for long periods, over time, detectable traces of your key could be retained in memory. Devices exist that could recover the key. You won't find such devices at your neighborhood electronics shop, but major governments are likely to have a few.
PGP Desktop protects against this by keeping two copies of the key in RAM, one normal copy and one bit-inverted copy, and inverting both copies every few seconds.