There’s been a published paper about what I’ve been calling “the FREON attack” for many years now. Schneier and a bunch of other folks are treating it as if it’s news, which it isn’t.
Seth was one of the writers, and I really like Seth. But this isn’t news!
We first ran into this handy little attack back in about 2000 when we were thinking about whether or not we should do memory encryption for Palladium. We knew there were things like dual-ported memory and/or memory harnesses, and then we were talking to some guys at Intel and they told us about how they thought it was funny that you could freeze memory and wake it up again. They did this very thing internally for us and reported back to us that yep, you could take a can of FREON and squirt it generously all over the place and voila! You have keys.
And to show how not news this is, we built mitigations into BitLocker, way back in 2005, to address it. I wrote some very, er, insistent emails about this very attack to make sure that we did the right thing and added +PIN and +USB as features. There was shouting, even. But in the end MSFT did the right thing.
The simple solution to this in BitLocker is to make sure that :
-
your machine is never left un-attended with the keys resident in memory – you can do this using hibernate, which is what I do
-
you need to add something with crypto goodness to the boot process that stops the keys from loading into RAM without you – in my case I use +PIN
So really, calm down. This isn’t news. There are some other features in BitLocker to address this as well (eg memory scrubbing), and in SP1 there will be +PIN and +USB at the same time, which makes it even harder. I call this “the Thames feature”: if I toss my USB dongle into the Thames, sure you can waterboard the PIN out of me, but you’re going to be diving for my dongle…
In the Thames no less. Yuck.
Obsessed 
So, you built mitigations in 2005, but the default in 2008 mode is still vulnerable?
As we point out in our paper, Microsoft did know about this and did build some mitigations into BitLocker — unlike the other vendors.
The fact that you had private knowledge about this doesn’t mean it’s not news to most people. To put it bluntly, this is news to your customers — especially those who are using BitLocker in “basic mode”, who are not protected.
Joe – we offered our customers a security vs. PITA (Pain In The Ass) trade-off with full disclosure around what you would need to protect against specific attacks. I spent a long time looking into who steals laptops and why, and this led to scalar protection, which I have very clearly described to every customer I’ve ever spoken to about BitLocker.
Most people don’t want things to be harder, they want them easier or the same. They want airbags, and BitLocker in it’s default configuration is like airbags. It isn’t foolproof – you can’t drive off a cliff with it – but it will make you safer.
Generally speaking, this kind of attack is most interesting to bg’s (bad guys) if they are already pretty sure of what kind of data is on the laptop. Putting in the work to find out that you’re just getting a bunch of wedding photos is going to be a waste of time. It’s probably not worth even a single identity theft.
So this means that if you are the kind of person whose laptop is going to be targetted, then you are the kind of person who needs to use the advanced modes.
Security is never about providing total protection against all attacks. It’s about mitigation based on a reasonable view of likely attacks.
A. Because it is not news to you does not mean it is not news.
B. If the mitigation built into BitLocker is effective why did this attack work on BitLocker?
C. The point of the attack is that even if you use hibernate to write to disk and power off the computer the key is still in memory as a remnance artifact. The decay rate at room temperature is slow enough that a recoverable key can be isolated after 5+ minutes, according to the paper. The paper discusses both a memory decay rate plateau at ~50% a few minutes after power down and techniques for generating a key with 50% degradation. With cooling added to the equation recoverability increases considerably as the decay rate is slowed.
One of the most surprising points in the paper was that BitLocker using TPM in the basic configuration meant that the key was always recoverable. The TPM implementation in BitLocker actually made it less secure in use. Using BitLocker with a PIN or a key on USB would mitigate this particular problem but not the cold boot attack. The relevant passage:
“BitLocker differs from other disk encryption products mainly in the way that it protects the keys when the disk is not mounted. In its default “basic mode,” BitLocker protects the disk’s master key solely with the Trusted Platform Module (TPM) found on many modern PCs. This configuration, which may be quite widely used [20], is particularly vulnerable to our attack, because it allows the disk encryption keys to be extracted with our attacks even if the computer is powered off for a long time. When the machine boots, the keys will be loaded into RAM automatically (before the login screen) without the entry of any secrets.”
I find it hard to understand why anyone would use TPM without requiring authentication but there you have it. It’s like buying a safe, planning your security on the basis of the safe being highly secure then deciding it’s too much trouble to lock it.
If the article is correct these are serious problems.
Ed – thanks for pointing out that you gave BDE some props.
My knowledge wasn’t private – I’ve been telling enterprise customers about how BDE scales for years. I can’t say what MSFT has been telling people since I left, but I can say absolutely what I said to customers myself when I was still there.
As BitLocker is targetted at enterprise data loss, this lets the IT security guys answer this question: “how much security do we need to sufficiently reduce our risk in laptop thefts across 10K laptops with the minimum amount of potential disruption so that I can get a little bit more sleep at night?”
As far as BDE users in basic mode not being protected – in a normal car with airbags and seatbelts I am not protected against RPG’s. I’m not even protected against small-arms fire.
This doesn’t mean I’m not protected, it just means I’m not protected against RPG’s and rifles. I know people who have been shot at in cars – they gear up if they think they are going to get shot at, they gear down if they think they are safe.
In some parts of the world, for some people, a normal car is insufficient protection. For some people, in some parts of the world, a normal car is sufficient protection.
Dan
A) Erm. Okay. I guess this gets down to some tipping point where if I’m the only one it’s not news to, then it is seriously news, but if enough of the right people know about it, then it isn’t news. I thought it was the latter, you think it’s the former. You figure out the formula, we can figure out if it’s news. I don’t think it is.
B) It’s mitigated if you choose to implement BitLocker so that it’s mitigated. You, as the customer, get to decide, just like you can decide if you want a deadbolt on your front door.
C) Last I knew (and this was still true after we shipped) BDE wrote over memory on hibernate. So no, the keys won’t be there, not unless you are talking about doing a really cool attack like you can do on HD magnetic decay…
As to why use TPM-only, because it moves the attack vector to hacking Windows login, or to hardware attacks (in which I include FREON, TPM hacking, LPC bus sniffing, dual-ported memory, BIOS hacking, secret laptop “feature” hacking, hyperjacking prior to BDE being turned on, SMM hacking, and other stuff I can’t remember right now). This is sufficient to deter many attackers under many circumstances. Certainly not all, but enough to make the use of the technology provide sufficient peace of mind.
And as I point out, and as I have said to every customer I’ve ever spoken with about BDE: I have a Lenovo with a really good TPM in it (Infineon), I use TPM +PIN and I hibernate.
A. There’s room to disagree as this is a matter of perspective. Let me put it this way, I have been involved in computer security on and off since my teens (I’m 37), am okay at technical analysis of threats and make an effort to know about possible threats. The knowledge of this attack may have been available to those with domain knowledge but I had not heard it was a viable exploit.
B. True. I’d say that the basic configuration should follow the default to secure rule but that’s another argument entirely.
C. I was wrong in saying that hibernation did not offer protection. Does BDE overwrite memory on power down too?
I think that the vulnerability of BitLocker depends on three variables; power state, TPM presence and BitLocker mode. From what the paper reports the breakdown looks like this:
Power State TPM BDE Mode Outcome
G0, S1, S2, S3 Y Basic Vulnerable
G0, S1, S2, S3 Y Advanced Vulnerable
G0, S1, S2, S3 N Basic Vulnerable
G0, S1, S2, S3 N Advanced Vulnerable
S4, G2, G3 Y Basic Vulnerable
S4, G2, G3 Y Advanced Secure
S4, G2, G3 N Basic Secure
S4, G2, G3 N Advanced Secure
Of course if BitLocker doesn’t overwrite memory on power down (as opposed to hibernate) then the last four lines would be expanded, list different findings and introduce a fourth variable, time since shutdown.
I agree that this is type of attack offers a fairly low likelihood of exploitation as it requires a number of unusual conditions be met. My comments on this over at Free-To-Tinker.com page put it this way, “a thief would need to be motivated, technically skilled and have foreknowledge of valuable data presence to make the effort worthwhile.” Unfortunately that’s still a viable threat which has to be considered and mitigated against in certain situations. Once tools become commonly available for this exploit then even more so.
I will disagree with you on one more point, that this is sufficient to provide peace of mind. Peace of mind should be reserved for when things are either secure in fact or you know where vulnerabilities are and can mitigate your risks. I don’t think this counts.
Dan – I’m almost in total agreement with you – the only area where you are going to have to change your mind so we are in total agreement is around peace of mind. : )
You don’t have to mitigate vulns to be better off. You need the truth to make a choice though. It’s rude if there are vulns and you don’t know about them as you might have altered your behavior in different ways. But you can decide to do something based on an un-mitigated risk. We do it all the time, every day. (Some of us choose to mitigate more vulnerabilities than others – if you are at eTech I can show you the stuff I carry around in my manpurse on a daily basis and depending on who you are, you can either laugh or ask me where I got some of it…)
BitLocker is primarily targetted at ENTERPRISE customers. So there’s a guy – I’ll call her Sue – somewhere in the enterprise whose job is to deal with lost and stolen laptops. We had a real, live customer tell us that they lost, on average one laptop a day in one just one city.
Sue had a miserable job in that company, and I can guarantee you that with BitLocker, Sue had more peace of mind. I personally told Sue about this attack, and she said she didn’t care about it enough to not us it. Why? Becuase she knows that she’s losing a laptop a day in one city! If this stops a few people from reading those hard drives, she’s ahead of the game.
Pingback: Another BitLocker Exploit? | Obsessed