Slashdot Mirror
Solution Against Cold Boot Attack In the Making
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."
Good idea, until they figure out how to cold boot the CPU as well.
Man I've been waiting for this! Lately the risk of a cold boot attack has really scared me, it's to the point where I don't even turn my computer on anymore!
I love it when Slashdot automatically rips open a troll post.
Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
According to the blog, the Proof of Concept would work on "most" x86 architectures.
To someone who knows more about the down-and-dirties: will this approach work on non-X86 systems?
FTA: "Disabling/freezing" the CPU's cache severely degrades the performance. However, this seems acceptable if one considers that this special mode only needs to be set whenever the screen is locked (all efforts are pretty much worthless if an unlocked laptop is stolen).
br/>Sounds like a tiny back door fix with a hell of a cat flap in it.
"Violence is the last refuge of the competent, and, generally, the first refuge of the incompetent" - Thing_1
Wouldn't it just be easier to set the BIOS to erase all of main memory to 0's during power-off (presumably on battery power if the power-cord is unplugged). That way no keys exist when the cold boot occurs
The cold-boot attack was one of the biggest security news items last year. This is news for nerds, not news for idiots.
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.
Or could a stale copy still be in some dirty page in RAM left over from the key generation process.
Confused...
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...
Stop putting encryption into memory.
In the old days, computers would ask for a code when you wanted to decrypt something -- no caching necessary.
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.
Engineering is the art of compromise.
This is supposed to protect the key while the system is locked, and a password is used to unlock the screen. But if a password is required to unlock anyway, the key doesn't even have to be accessible while the system is locked, the password itself could be used to decrypt the key while unlocking. Of course there is a drawback in that any disk operations would have to be delayed until the system is unlocked, that might not be acceptable for all users.
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).
Do you care about the security of your wireless mouse?
... 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.
I drink to make other people interesting!
There is an underlying problem with this strategy; in that it is that it's targeted at locked laptops... which need to shut down and power off the CPU cache in order to not run out of power in the next 30 minutes.
And to answer another common question here; CPU cache is power-hungry SRAM (a set of transistors per-bit), rather than DRAM (a capacitor per-bit) - so it does lose it's state when unpowered.
Also, as soon as you turn it back on, it'll be overwritten with the BIOS/POST/bootlader/whatever instructions and data... that's what it's there for, and that's its default mode.
Not to mention, this is posted on the internet. Select the text you don't know about, right click and choose search google for "text". Firefox automagically opens a search on the topic in a new tab, and chances are the Wikipedia article is one of the top five results which should be a good enough starting point to see if the topic is of any interest to you. Magically, the old style of handholding journalism where authors are forced to assume the reader has the education of a 5th grader goes away, and society can actually advance further than the lowest common denominator.
Couldn't have been that important, I found one slashdot article in February of 2008 about it (no dupes?!). I'm not a security researcher, and don't care to be, sorry if I don't follow every possible obscure way of someone with physical access to my machine getting at my datas. I guess you're right, this is news for nerds, not news for people who have other shit going on in their lives. Thanks for clearing that up. Nerd.
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 reaches Windows marketshare, "typical" Linux users will do the same.
Of course, this turns a Windows/TPM computer into something akin to a game console. I personally don't think there is anything wrong with this - until M$ convinces the government to outlaw real computers because they are "insecure". Or more likely, convinces banks and online merchants to only do business with TPM computers.
http://slashdot.org/article.pl?sid=08/07/20/1624253
http://slashdot.org/article.pl?sid=08/02/21/1543234
It was also on Wired: http://blog.wired.com/27bstroke6/2008/02/encryption-stil.html
Engadget: http://www.engadget.com/2008/02/21/cold-boot-disk-encryption-attack-is-shockingly-effective/
Schneier's blog: http://www.schneier.com/blog/archives/2008/02/cold_boot_attac.html
Information week: http://www.informationweek.com/news/personal_tech/showArticle.jhtml?articleID=206801184
The Register: http://www.theregister.co.uk/2008/07/21/cold_boot_utilities/
Cnet: http://news.cnet.com/8301-1009_3-10003167-83.html
PC World http://www.pcworld.com/video/id,762-page,1-bid,0/video.html
Boing Boing http://www.boingboing.net/2008/07/19/cold-boot-encryption.html
It was even on reuters: http://www.reuters.com/article/pressRelease/idUS163325+27-Feb-2008+PRN20080227
It's not an obscure thing, you are just ignorant of major technology news. Perhaps the summary should define "CPU" and "linux" for you as well, just in case you don't what they are either.
What's really important here is that the key would be kept in SRAM(CPU Cache), not DRAM(Memory). With DRAM the stored bit is stored in a capacitance and in SRAM the bit is stored in a latch(usually a D-type latch from what I understand). I would guess that it's harder to freeze SRAM and keep the bit in place.
Don't be arrogant and put the blame on the reader. It's called journalistic writing and typing a good summary does take a bit of care. Adhering to some basic writing principles, like the inverted pyramid, would go a long way even for a lowly summary writer/story submiter: http://en.wikipedia.org/wiki/Inverted_pyramid
so how often are these cold boot attacks actually performed in a hostile situation (as opposed to under controled conditions for demonstration, or to legitimately recover lost passwords or whatever)
Please stop posting here, nobody likes you.
Seriously.
Troll or actual idiot, we don't want you here.
To quote a(n) (in)famous 4chan quote, "lurk moar".
Additionally, if your that fucking concerned about this attack, wait 30 sec to 1 min after shutdown when logic gates loose electrical charge and are defaulted to zero.
Perhaps I don't fully understand the details of this attack, but it seems as if this would be impractical as a way to steal data. My understanding is that the data only exists for a short period of time after shutdown.Please correct me if I'm wrong...
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 attacks, even if it costs twice per MB as normal chips.
Here's Jake's unedited response:
10 of the last 11 posts were by AC's, the last 7 in a streak. WTF? why bother making folks sign up for accounts, let's all be AC's by default?
the significance of a signature is insignificant
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.
Cold boot attacks on laptops are interesting and all, but me, I'd just use the firewire port
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 thread. On Windows machines, who knows, maybe we'll see a convenient hardware dongle to assrape the DRM path while it's looking the other way...
Don't even have to move the laptop somewhere secluded to rip it apart. Just plug in your 'music player.'
"Strangers have the best candy" -Me
That's why I set my thermometer to 30 C and leave it on all day.
Knowledge is power. Knowledge shared is power lost.
Lock all computer components in ballistic steel case using internal, welded piano hinges.
Booby trap the mechanism in several places with small charges (like those used to sever bolts on rocket stages on a smaller scale)
place these warnings on the side of the box.
Armor the hard drive bay against the blasts, and have a retractable "key" which can be used to cut the link between the input ports and the motherboard when you leave.
Anyone who tries to access the components for cold boot attacks gets a sting, perhaps some shrapnel at the skin level, and then gets to stare at the powder that was once the ram, cpu, and major avenues on the motherboard.
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?
"City hall" in German is "Rathaus" Kinda explains a few things......
This does not sound like such a hard problem,
Just erase the decryption key from memory when the computer goes to sleep (or lock screen) and ask the user to reenter the decryptkey on wake up of the system.
Of course this requires that the operating system needed to get out of lock is not on the cryptodisk, but there are solutions for that.
- Only use a crypto-disk for data.
- Put wake-up portion of operating system in RAM disk.
Now the disk-encryption program just needs to be really careful where it stores the key in RAM and you're done.
For a server this will not work, but for laptops I don't see why not....
Although it does raise the question: How do you search the Internet for tips on how to search the Internet?
You click the help button (@ google.com).
$ make available
nuf sed.
-1 Troll/Offtopic
In many cases, all you need is the right Firewire device 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 RAM as a set of 32-bit words, sort it, remove the dupes, and use that as a dictionary. On a machine with 4GB of RAM, that'd probably net me a dictionary with only a dozen million "words," tops. Say, for the sake of argument, there are 2^24 unique 32-bit words.
With this "dictionary", I could then try to brute-force all the 128-bit AES keys picking 4 entries out of the dictionary. That nets me a keyspace of 2^(24*4) = 2^96. That's still huge, but I've truncated the keyspace dramatically. If I wanted to squeeze it further, I'd take as much RAM out of the system prior to dumping as I could to limit my dictionary size. Less RAM is sometimes better.
If I wanted to get WAY smarter about it, though, I'd realize that the key is probably stored contiguously or nearly contiguously, so I'd only pick combinations of words that were near each other in the original dump. In that case, the key space drops down to something I could probably try over lunch.
Program Intellivision!
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
"almost all programming can be viewed as an exercise in caching"
It seems it is not possible to 'lock' lines to prevent them from being written back.
Now if they could be mapped to nonexistent memory, wouldn't that prevent them from being written out? I guess the keys would be lost in the error if that were to happen, or they would become vulnerable being dumped to a stack trace, but this way of gaining cache control might be worth exploring.
Locking one 'way' of the cache like embedded CPUs can would be a lot easier :)
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 a valid disk user/password combo can the real disk key be decrypted, so until that happens any "Cold Boot" attack will be just as useless as against a machine which has been powered all the way down.
The only question seems to be if it is actually possible to stop _all_ disk activity, or if a small unencrypted partition must be set aside for absolutely required background activity?
Terje
"almost all programming can be viewed as an exercise in caching"
You were doing so well until you wrote this paragraph. There's no need to disparage someone else just because you know something that they do not.
O RLY? Help button where? I see no help button...
It is default, until you login anyway
"Could this really turn out to be a working solution?"
You'll find out a few years down the line, when your computer finishes booting with its cache disabled. Modern CPUs have caches for good reasons: without them they don't run very fast.
I am sure that there are many other solipsists out there.
ouch...
the significance of a signature is insignificant
"google.com? What the heck is that? Don't give me all this technobabble crap.
All I want to do is find something on the internets."
See my point?
"City hall" in German is "Rathaus" Kinda explains a few things......
If I understood right, the main problem is that even though an entire disk is encrypted, unencrypted data is often stored in RAM, and this fact could be used to access private data stored in the computer. But wouldn't this be solved by writing random bits to RAM at shutdown?
Two questions:
What is the world coming to?
You could probably type 'How do I search the internet?' in your address bar and get something useful.
If corporations are people, aren't stockholders guilty of slavery?
Might have found it
"out a way of forcing down patches, and figuring
out what the effect of those patches will be,
de-conflicting their effects, and having them
applied.
"
http://web.archive.org/web/*/http://www.bsa.org/resources/2002-03-16.99.pdf
In case http://www.mediafire.com/?aj093xoyjyw
I for one want to test to see if my machine has a tpm chip (suspect so) and unlock it to use the capabilities to do some calculations can you point me towards some stuff to do that?
The Singularity is closer than you think
Quant
You mean how the "capacitors" are just etched parallel wires and the silicon is used as the dielectric? (or something like that) So the transistor will also have capacitance because the traces which make it will also have the same effect? This sounds correct to me...
Sort of how any wire is an antenna, because an antenna is just a wire. Radio waves are just electro-magnetic waves which will create a small electric current in any conducting substance. And a modulating electric current will create radio waves. In fact, this is why computers can interfere with your TV. It all fits together, doesn't it?
What about using the performance monitor counter registers? I just thought of this earlier today, so I haven't had the time to investigate further, but as far as I know, those registers should only change if performance monitoring is actually set up via the event selection registers; otherwise you can just store a value into them and read it back later. Depending on the CPU model, you can store either 32 or 40 bits per register. They aren't included in context switches, so they should never be written to RAM, and access to them from user space can be disabled (in fact I think it is by default). But I don't know if they survive when the CPU is put to sleep, or if they get overwritten for any other reason.
Assuming they can be used to store information, we could put the AES (or blowfish or whatever) key into them and use it to regenerate the round keys when needed, erasing them from RAM again after a short timeout. Or the registers could be used to store the key for a simpler cipher, which is then used to encrypt the round keys in RAM. Even just putting random bits into the PMC registers and XORing them with the round keys would provide some protection, and would be very fast. There's generally quite a bit of redundancy in the round keys, though, which might give an attacker enough information to figure something out if, say, every 128 bits of the round key table is XORed with the same value.
Obviously this breaks the use of performance monitoring (although some CPU flavors have 18 or more PMC registers, so it should still be possible to use the ones that aren't storing crypto stuff), and will have a performance impact on encrypted disk I/O (regenerating or decrypting the round keys before you can encrypt or decrypt the disk data). But the performance impact should be MUCH less than disabling the memory cache. And I don't think very many people actually use the performance monitoring features of the CPU on their personal machines, so that shouldn't be much of a loss (and anyone who does use them can just skip this idea).