Solution Against Cold Boot Attack In the Making 260
Bubba writes "I just discovered this blog: Frozen Cache. It describes a concept for preventing cold boot attacks by saving the encryption key in the CPU cache. It is claimed that by disabling the CPU cache the key will remain in cache and won't be written to memory. The blog says they're working on a proof-of-concept implementation for Linux. Could this really turn out to be a working solution?" Update: 01/19 20:26 GMT by KD : Jacob Appelbaum, one of the authors of the cold boot attack paper, wrote in with this comment: "It's not a solution. It simply seeks to make it more obscure but an attacker would certainly still be able to pull off the attack. From what is on that blog, there's still a full keyschedule in memory at this time. This is how we reconstruct the key, the redundant information in memory; it's not just the 128/256 bit key itself. For older methods, they needed the actual specific key bits but we don't need them because we recreate them. Basically, the CPU is acting as a ghetto crypto co-processer. Emphasis on ghetto. It's a nice suggestion but the devil is in the details and sadly the details in this case aren't really up to snuff. It's a bogus solution."
Freeze the CPU (Score:5, Insightful)
Re:Freeze the CPU (Score:4, Interesting)
why are you modded funny? is there any reason that the cpu memory cannot be attacked in a similar way to standard memory? The hardware you need to pull it off is probably a bit more obscure but is there a reason that you cant stick a cold CPU in a multicpu board and read its memory from a second CPU?
Re:Freeze the CPU (Score:5, Informative)
You need to understand that there are different types of RAM. The main memory, that of which you have gigabytes, is DRAM. CPU caches are SRAM.
DRAM is, essentially, a tiny capacitor that is regularly recharged. If you cool it down, it doesn't lose its charge as fast, so you can read it even after power loss.
SRAM works differently. The data is stored by a few transistors wired together in a way so they can maintain a specific set state even when the external input goes away. There are no capacitors involved here, so once the supply voltage drops, the data is lost.
Re:Freeze the CPU (Score:5, Informative)
Or perhaps the slight residual voltage kept the SRAM contents intact. (Even though it was probably less than one tenth of a volt.) SRAM draws very little current when the voltages are reduced. Thus the power rails can maintain some small voltage for a very long time. .
Re: (Score:3, Insightful)
Carefully repowering SRAM can maintain the contents. I have seen SRAM come up with essentially 99% of the contents still intact after the SRAM had been powered down for over a week. I guess that once powered up, the SRAM has a preference to come back the way it was before powerdown. Or perhaps the slight residual voltage kept the SRAM contents intact. (Even though it was probably less than one tenth of a volt.) SRAM draws very little current when the voltages are reduced. Thus the power rails can maintain some small voltage for a very long time. .
I would really like to see any citation to support your point. If true, this is really an interesting concept.
Re: (Score:3, Informative)
Re:Freeze the CPU (Score:5, Interesting)
Most cache is implemented as a flop, which loses its state on power down almost immediately. I don't think it's possible.
Re: (Score:2)
i thought CPU caches were mostly implemented through SRAM, which does possess a certain level of data remanence.
otherwise, there's always rubber-hose cryptanalysis [wikipedia.org].
Re: (Score:2)
An SRAM cell is typically a cross coupled inverter (from what I've seen). There's not much potential for memory there. When the power supply reaches zero, the bit is gone.
With DRAM that's not quite the case, which is why the cold boot attack works. Even though the power supply is zero, the bit is still there on the cap.
Re:Freeze the CPU (Score:5, Insightful)
Sorry, flop == flip-flop.
Re:Freeze the CPU (Score:5, Funny)
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
I think he means flip-flops.
Re: (Score:2)
Different kind of memory. Normal memory, DRAM, is more or less a capacitor and a transistor. You store the charge for the state in the capacitor. So that's the idea as to how you can get at it later. While they do discharge when power isn't applied, it is not linear, so some residual charge can still be picked up. Cache memory is SRAM. That's a combination of six (or more in some cases) transistors, no capacitor. So when power dies, there isn't any residual charge left.
Not saying that maybe something couldn
Re: (Score:2)
The only thing with SRAM is that when its powered on it'll flip to one of its states and supposedly (Ive never tested this out myself) it will be biased to the state it had when it was powered off. Of course the effect that causes this bias is so small that any fluctuation will get rid of it and leave you with random data. I figure the simplest way to be sure is too simply add a bit of logic to the CPU initialization that wipes the caches the moment power is applied.
Re: (Score:2)
This initialization is called BIST (built-in self test) and it has been a standard feature on processors since caches were introduced.
Re:Freeze the CPU (Score:4, Interesting)
Well fuck me in the ass and call me Sally, why the hell are we discussing this then?
Re:Freeze the CPU (Score:5, Interesting)
Although marked as Funny, you could quite easily open the PC take out the BIOS ROM whilst the machine is running (the BIOS is shadowed in normal operation), stick a new custom one in that probes the cache and do a hard reset.
Re:Freeze the CPU (Score:4, Interesting)
Additionally this could also be used to get a near perfect dump of RAM too.
Re:Freeze the CPU (Score:5, Insightful)
Thus, if the attacker has physical access to your box, you're screwed!
Re: (Score:2)
if the attacker has physical access to your box, you're screwed!
Yeah... especially if you're the RIAA/MPAA and the "attacker" is the owner having physical access to his own box.
I love these stories on physical-access attacks. They are great techniques for an owner to get around hostile Trusted Computing on his own computer. Cold-boot or warm-boot your own computer and read your data and your keys out of your RAM, even when Trusted Computing tries to deny you this sort of access to your own keys and data.
-
Re:Freeze the CPU (Score:4, Informative)
Except that real "trusted computing" using a TPM chip doesn't store the key in the CPU or in RAM, it is stored in the TPM.
Re: (Score:3, Informative)
This is a dangerous belief. It is true that some keys remain inside the TPM, at least as long as the chip is being accessed only through its wire interface. However, the TPM ist not suitable for bulk encryption. Applications therefore typically use the TPM only to store keys, which are extracted to memory when needed.
Re: (Score:3, Interesting)
Trusted Computing is built on an entire tree of keys. You're right that the master pair of keys (PrivEK and RSK) never leave the chip. You're right that reading RAM will not give you a simple full crack of the Trust system on your computer. However by reading RAM you can snatch the lower levels keys peicemeal, and you can read out decrypted files piecemeal. For example you play some DRM music and do a RAM grab. If you're lucky that RAM grab will give you the key to decrypt all of the DRM music files on your
Re: (Score:2)
I imagine what prevents this kind of attack being useful is the limitation to a specific make and mode
Re: (Score:2)
http://en.wikipedia.org/wiki/CIH
Note, though, that some (all?) motherboards these days tend to have a tiny region that's either ROM or not normally flashed for recovery if the checksum doesn't match up. You might need to flash that as well, or just go along fooling it with a proper checksum (I don't think they employ any real signing.)
Re: (Score:2, Informative)
"Most"(1) PC BIOSes are socketed for the very reason that they are nasty to replace otherwise, and it doesn't really affect the cost too much to do so.
That's the case for desktops but not for laptops.
Great! (Score:5, Funny)
"general purpose?" (Score:2)
To someone who knows more about the down-and-dirties: will this approach work on non-X86 systems?
Re: (Score:2)
It depends on the architecture, of course.
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
It is still alive, with its sibling the SH-5, for the embedded market. Its core is licensed in the same way as ARM and MIPS.
Re: (Score:2)
Depends. It wouldn't work on any architecture that doesn't do caching, of course. Don't know that there are any of those, but if there are, well then they are out. Also won't work on any architecture that you can't control the caching on. If it always caches memory and you can't mess with how, the trick won't work. I would guess it would work on most architectures out there, but I don't know.
a hack on a hack (Score:4, Insightful)
br/>Sounds like a tiny back door fix with a hell of a cat flap in it.
Re: (Score:2)
If the laptop is unlocked you just copy the drive to some other device. That's been the gaping hole in every OS back to the abacus.
If you want to fix that have some sort of longer range proximity card that locks or otherwise shuts off access when the user is not present.
Considering that most /.ers mold their butts to a chair put a switch in it to detect said butt.
Re: (Score:2)
Why not just store it in a couple of locked cache lines?
Adds another layer to hardware solutions? (Score:5, Interesting)
Or the converse, I suppose (hardware solutions can add another layer to this). This looks like some very interesting work, and may have more applicability in general beyond this one scenario. I'm certainly looking forward to following their implementation as it comes along. But with that said, if this attack was a serious concern for a given entity there seem to be some obvious potential hardware solutions. The attack essentially depends on being able to shutdown the computer but keep the memory cold enough that the randomization time is slowed down tremendously, giving enough time to perform a dump of the contents onto another system for further analysis. Therefore, it can be prevented by, for example, having electric heater units surrounding the memory connected to a dedicated capacitor bank and temperature sensor, as well as a sensor to detect if someone tries for force open the machine (intrusion alarm). Then the system can perform a scram shutdown (or if it is just shutdown normally), and the heaters can assure that the memory is kept hot for a couple of seconds afterwards even in the face of attempted cooling. It only needs to manage it very briefly and then all the contents are scrambled. Other similar methods (maybe a really micro EMP inside a shield memory space) would be possible to, but basically they just need to deny an attacker for a very short amount of time or ensure entropy in the RAM and then the attack is useless.
Ultimately a dedicated hardware secure key store would be better and easier to integrate across all systems, and this more software solution of course has the massive advantage of being able to run for free on existing hardware. But the above could at least be retrofitted on nearly anything, and while it is more esoteric, then again so is the attack since it requires physical access.
Re: (Score:2)
Good idea. If we can get the manufacturer promises there aren't any government backdoors, we'll be perfectly safe from any and all conceivable attacks.
But I guess it is an improvement at least.
Re: (Score:2)
Now now, I'm sure we can trust companies to act in good faith rather than self interest at the cost of morality and the interest of their customers. No need to be so cynical, Commie scum.
Re: (Score:2)
The linux kernel does (I believe, IANA Kernel Hacker) scramble the key storage at least on shutdown, but it is possible to interrupt the power to the system before the kernel can react.
Re: (Score:2)
Actually, scrambling the whole RAM sounds like a good idea. The encryption key is probably not the only thing you want to keep a secret.
Re: (Score:2)
Re: (Score:2)
I thought Slashdot was against the TPM chip?
The Slashdot community is made up of varied views on everything, but yes the majority here do object to the TPM.
That said, the grandparent post did not mention the TPM. He described some features similar to the TPM, but that's kinda like saying a home security system is similar to a prison security system. Both might have bars on the windows, but they are fundamentally different designs. Designing a security system to protect and benefit the person living there (a
Re: (Score:2)
I would (if I were seriously worried about this sort of thing), do something like the following for a desktop unit:
1) Get a thick case that can be locked.
2) Get a "giant fuck-off padlock".
3) Apply #2 to #3.
4) Place the case somewhere somewhat distant from monitor and input devices. Ensure that case is in location that is very inconvenient to access.
5) Wire up phase lines of the power supply directly to the RAM sockets, controllable by a switch. Also add a killswitch that cuts all power to the inside of th
I don't understand... (Score:4, Insightful)
Wasn't the "secure computing" preached by Intel/MS and others a "secure" platform that would solve all the security issues?
To me seams that it was only a farse to disguise DRM into everyones computers...
And fail...
Secure computing works (Score:2)
If you consider that the primary goal was really to make people *think* that they were doing something useful, then , yes, the exercise was successful.
Re: (Score:2)
TPM only solves the PEBKAC issue (Score:2)
The "secure computing" preached by MS does not protect against OS bugs, buffer overflows, or any of the myriad local or remote attacks based on software flaws. The only "security" it offers is a way to prevent end users from downloading and installing the software of their choice. I don't mean to minimize the value of this - it is an important base to cover. The "typical" Windows user sees a free screen saver and goes "Ooh! Shiny!" and installs it - thereby joining yet another botnet. When/if Linux reac
Re: (Score:2)
It can be used for good, as well as evil. Microsoft also used it to implement BitLocker (whole-disk encryption), with the TPM used to store the decryption key.
So when your mobo gets fried by an errant cup of sysadmin coffee (or mountain dew) you lose all your data! YAY!
Re: (Score:2)
Re: (Score:2)
Yes, all data would be rendered inaccessible. However, the user or sysadmin should be making backups of their data in the first place. Under no circumstances should a user keep all of their important data in one place. There is simply no excuse for it.
bitlocker is marketed to small-time users. Commercial companies already had encryption solutions.
Re: (Score:2)
Wasn't the "secure computing" preached by Intel/MS and others a "secure" platform that would solve all the security issues?
No
To me seams that it was only a farse to disguise DRM into everyones computers...
And fail...
No again. Here is some useful information [ibm.com] on this from IBM.
Re: (Score:2)
Then explain why I cant have my private key to the TPM I may own?
Or, who knows the proper private key to unlock any TPM?
A safer alternative (Score:4, Interesting)
The simplest way to implement my proposal would probably be to suspend the system instead of just locking the screen (like you do if you are not going to be using your laptop for a few hours). It just has to be implemented correctly such that the key really isn't available until decrypted using the password that you enter when waking it up.
If you want to lock your laptop and leave it doing things in the background requiring disk access, then the idea from this article might be valuable. There are other possibilities, one alternative is to store the key in special cryptographic hardware from where it can't just be read out (I haven't thought through the details of such a design, there are obviously some hurdles that would need to be sorted out). Or you could make some use of asymmetric cryptography, I don't think any storage encryption currently does that, since it could have a performance penalty, but it would provide some protection against attacks like this. You could also use ciphers that are less vulnerable to this kind of attack. Part of the attack is to use the key schedule as a kind of error correcting encoding that will help recovering the key. Key schedules are typically designed with performance in mind, and this kind of attack is not considered. But for most storage encryptions the performance of the key schedule isn't important, so a different key schedule could be designed to have no error correcting properties. (I think that just means the function mapping from key to key schedule would have to be a PRNG).
Re:A safer alternative (Score:4, Insightful)
Re: (Score:2)
Public-key encryption would resolve that issue. Only the decryption key need be protected by a passphrase; encryption can take place non-interactively via the public key.
Re: (Score:2)
Or preparing the password-encrypted key when the password is used to log in. It seems fairly uncommon these days to have a screen-unlock password that is not the login password.
Disable CPU cache... (Score:2)
... so the solution to a cold boot attack is make your computer so damned slow that you don't want to use it. Therefore you won't want to create encrypted volumes to store your world domination plans anymore.
Re: (Score:2)
Re: (Score:2)
Only if it also stars Captain Kirk as an ocelot.
Only needed when the machine is locked (Score:2)
The scenario is that someone steals a running, but locked laptop, and wants to read your encryption keys stored in RAM. If it's not running, then the encryption keys aren't in RAM. If it's not locked, then you're SOL anyway.
So the idea is to move the keys out of RAM and into the cache temporarily while the machine is locked. When you log back in, the cache gets re-enabled so you won't notice any difference in performance.
Re: (Score:3, Interesting)
The scenario is that someone steals a running, but locked laptop
Let's assume a REAL scenario. The real scenario is not everyone runs Windows and not everyone runs laptops, and not everyone uses X86 architecture. Just because the screen is locked doesn't mean the encrypted volume is not in use. Come to think of it, Windows + Laptop + Locked doesn't even mean it's not in use. The cold boot attack is also more useful against desktop machines because it's much easier to freeze up the memory good because you usually have unrestricted access to most of its surface area.
E
Re: (Score:2)
Just because the screen is locked doesn't mean the encrypted volume is not in use.
It will if you want to use access highly sensitive information on that machine.
The cold boot attack is also more useful against desktop machines because it's much easier to freeze up the memory good because you usually have unrestricted access to most of its surface area.
Desktop machines are typically covered by site security. Traveling diplomats, CEOs, dissidents, etc. want to be able to access their sensitive data in situations where they don't completely control site security. This gives them some additional protection if implemented with secure user practices (i.e. locking your workstation whenever you are not present).
I leave my computer calculating possible attack vectors for that exhaust port and lock the screen while I go make a coffee; it's going to take a couple of hours to compute, you see.
You do that on a separate server under physical lockdown. Obviously this o
Re: (Score:2)
secure user practices
You do that on a separate server under physical lockdown
Are you so naive to assume that the user will actually follow secure practice all of the time?
Are you so naive to believe that physical lockdown will save you from an invasion by the feds/rival drug dealers/etc?
how often are these actaully done? (Score:2)
zero on power up? (Score:2, Interesting)
This sounds like quite an over-complicated solution. Isn't it possible to design "secure" memory chips that zero their contents when power is first applied? I mean, memory chips are pretty "dumb" (from a design logic perspective, which is why cold-boot attacks work) so how hard would it really be to add this function to the chip? If it significantly adds to the manufacturing cost, sell it as a feature. I know of many agencies and individuals who would be interested in memory that's secure against cold-boot
Re: (Score:2)
How exactly would a memory chip define "power first applied"? And how would the memory itself erase anything?
Afaik RAM is just a bunch of cells that are either charged or they're not and it's all decided by the memory controller.
Re: (Score:2, Funny)
How exactly would a memory chip define "power first applied"? And how would the memory itself erase anything?
Well, I might be taking a stab in the dark here, but perhaps it has something to do with THE ADDITIONAL CIRCUITRY proposed by the Parent?
Nothing ever gets done in the world anymore because those of us with an understanding of our surroundings are too busy facepalming ourselves constantly.
Re: (Score:2)
How exactly would a memory chip define "power first applied"?
How exactly would we integrate color into a tv set?
How exactly would we go to the moon?
Re: (Score:2)
Memory chips contain a lot more logic than you think they do. For starters, the miniscule charge stored in the capacitors has trouble getting through a microscopic bitline in the DRAM chip, so there's no way it would make it out to a chip pin much less the memory controller - that's why DRAM has highly sensitive differential amplifiers (one for each bitline pair). Modern DRAM uses relatively interesting interfaces that, while still closely related to the actual operations needed to read out the charge in th
Firewire (Score:2)
Cold boot attacks on laptops are interesting and all, but me, I'd just use the firewire port [hermann-uwe.de]
It is applicable on a smaller number of laptops, but you also have write access and the machine continues running (less suspicious). Somewhere (perhaps in my link, can't remember) I saw a nifty python script that patches winlogon to allow unlock by entering an incorrect password. If you're an exceptionally slick bastard, you might squeeze a keylogger/downloader/etc into some dark corner of RAM and hijack some unlucky
I am terrified of this attack vector (Score:2)
That's why I set my thermometer to 30 C and leave it on all day.
Some issues (Score:2)
In many cases, all you need is the right Firewire device [wikipedia.org] to scan memory, for one thing.
The other is that saving the keys in the register file doesn't help much if context switches can still happen. Guess where the keys get saved on a context switch? RAM, naturally. And don't forget paging behavior--although if the page holding the keys was allocated within the kernel with kmalloc(), you're ok there.
If I were going to try to brute-force a key based on a chilled RAM, I'd just dump the entire contents of RA
Much easier/safer solution: Register-only storage? (Score:4, Interesting)
In the day of multi-core everywhere, a possible solution seems to be:
Dedicate one core to handle both screen unlock and disk encryption, but only when locking the machine.
On this core I would use one (128 bit) or two (256 bit) SSE registers to hold the disk key, and another register to hold the unlock credentials, then setup a static communication area where the other core(s) can leave messages, in particular an attempt to unlock the machine.
The dedicated lock core would stay in a loop, comparing the content with the unlock creds (i.e. hashed/salted password) and write the disk key back to memory upon receipt of a valid entry.
Using this approach means that you don't need to mess around with MTRRs or other cache control instructions, you just need to schedule everything else onto the other core(s), including all interrupts (which would (lazily?) writeback SSE register content on a task switch).
OTOH, there are of course some obvious downsides to this approach as well, in particular the fact that the locked core cannot go into a regular sleep mode, if said mode requires an interrupt to get back out of. :-(
Terje
Solved problem: Encrypted disk key storage (Score:2)
As long as (most) disk activity can be stopped while the screen is locked, there is a solution which is both easy and safe:
The disk key in any reasonable full disk encryption setup is stored in encrypted form, meaning that the disk password is required to decrypt/retrieve it, right?
So what's stopping us from "simply" freezing all disk activity, then erasing the disk key from memory? (Keep the encrypted key from the disk master block if you want to, otherwise just re-read it when needed.)
Only after entry of
Owned by Slashdot link protection (Score:2)
Re: (Score:2)
Re: (Score:2)
A capacitor inline to the memory controller could give it enough time to execute an emergency erase/scramble if the power fails. It's probably not that expensive to develop either.
Re: (Score:2)
It would probably require a specialized B
Re: (Score:3, Interesting)
Memory wipe on case intrusion event.
Back to you.
Re: (Score:2, Informative)
Cut hole in case wall so your "intrusion switch" doesn't trip.
Oh the fun cat and mouse game of security.
Re: (Score:3, Interesting)
Re: (Score:2)
If you're using full-disk encryption, turn off your computer when you'd not sitting at it. Hit the switch on the power strip if someone shows up at the door to seize your computer.
An unsecured machine with an mounted encrypted disk compromises the security of the encrypted disk; in this case, "unsecured" includes situations where other parties can gain physical access to the machine.
Re: (Score:2)
Re: (Score:2)
Yeah, then when your RAM fails, instead of a $25 DIMM you're replacing a $400 motherboard.
Even a desktop board, this strikes me as a bad idea.
Modular is good, for a number of reasons. Security may not be one of them, but there are other ways to deal with it than essentially making your computer a black box.
Re: (Score:2)
I think the shutdown consists of a hard off (power cut off), not an ACPI shutdown. The bios wouldn't have time to zero the memory. At least thats the way I understand it.
Wouldn't it only need to zero the memory that contains the key?
Re: (Score:2)
Zeroing probably isn't the best idea. There will likely still be residues left over that allow you to distinguish what used to be a one and what used to be a zero.
Re: (Score:3, Insightful)
Yes, but the benefit of a cold-boot attack is that the data is just there; you don't need to remove the DIMMs and read tiny electrical fields with special machinery; you just read the bytes.
There is no CPU instruction for *any* architecture that will give you the voltage level of a memory cell.
Re: (Score:2)
Heh, no caching, eh. How did it *use* the code?
Re: (Score:2)
Re: (Score:2)
Why worry?
If they have your machine, its only a matter of time before they discover a way to access your porn.
You can't cold boot attack a machine without physical access. If "they" have your machine for long enough to pull off a successful cold boot attack, chances are they could just as easily take your hard drive back to their lab, in which case all bets are off.
Re: (Score:2)
Why would you assume my machine would be set up to boot from any USB device?
Good luck with that.
Re:Write a summary that's useful, kthx. (Score:4, Informative)
Re: (Score:2)
No kidding. I've always wondered how people can be on the Internet, and not know what the heck something is talking about.
You've got the combined intelligence of the entire planet at your fingertips, and you can't figure out what a "cold boot attack" is?
Although it does raise the question: How do you search the Internet for tips on how to search the Internet?
Re:Write a summary that's useful, kthx. (Score:5, Insightful)
Re: (Score:2)
As I understand it...the attack their method is trying to prevent is the case where you have a locked machine (not necessarily a laptop, but it could be), but the encryption key is stored in RAM. The attacker powers off the machine and immediately cools the RAM right down and plugs it into anoth
Re: (Score:2)
Well the simple version of the attack is to put a microkernel in a netboot/usbkey and boot their computer to it, if they didn't disable that in BIOS. Hope you don't overwrite key storage with the microkernel (unlikely), then just dump ram for later analysis. Grep it for the linux key storage struct...and you win. It could be made almost plug and play.
Against a disabled boot order, it would take someone with undergrad-ish electrical engineering and computer science training to pull off such an attack, given
Re: (Score:2)
Unfortunately operating systems don't behave too well when you play with disk availability like this. It's also very dangerous to use the encrypted disk only for data, since the OS and applications rarely cooperate, but rather leave many traces of your actions on the unencrypted disk.
Re: (Score:2)
Um...physical access only is owned if you have an unencrypted root. Against an encrypted root on an unpowered system you're pretty much SOL short of adding a hardware keylogger. Or I suppose you could modify their kernel, but a TPM can thwart that.