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.