neuhalfen.name

A random collection of posts

Frozen Cache on /. And Applebaum Being Huffy About It

Permalink

Frozen Cache made it to /.!
This is a good thing, as it shows that others see the problem of Cold Boot attacks as important. Don’t want to complain about the state of the world or that most slash-doters just don’t read the article they are about to comment on. What really irritated me was Jacob Applebaums comment.

First, the comment from Slashdot:

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.”

What Applebaum basically says is

  1. It is not enough to protect just the key, you also need to protect the schedule.
  2. I (Applebaum) am able to reconstruct the key from the key-schedule.
  3. And anyway, Frozen Cache just misuses an expensive processor as the crypto device it was never meant to be.
  4. Therefore the Frozen Cache approach is rubbish.

Let’s look at each of the points:

1) It is not enough to protect just the key, you also need to protect the schedule.

That is just a true statement. No arguing about that. Although the Frozen Cache blog did state expressiv verbis that the key schedule needs to be protected as well.

Anyway: To me it was always clear that protecting the key means to protect all key related sensitive information.
The thing is: The Frozen Cache blog is a blog dedicated to work on a proof of concept. It is not, as you might guess from Applebaums answer, a scientific paper proposing “the final solution” or a shrink wrapped product, ready to be sold.

Taking the words blog and proof of concept into account, this answer sounds a bit like “(pointing a finger and singing) na na na na na na, but you forgot to protect the key schedule as well!”. This might be just my impression, though.

2) I (Applebaum) am able to reconstruct the key from the key-schedule.

For the interested: Wikipedia does a nice job on explaining how the encryption is done in AES.

The important bit ist the role of the AES Key Schedule when something gets encrypted. It is the expanded version of the key and the only thing that makes encrypting “Hello World” with two different keys produce different output.

Looking at it from that angle, there is no difference between key schedule and key. Strictly speaking, it is not even neccesary to “reconstruct” the key, once you have the key schedule.

3) And anyway, Frozen Cache just misuses an expensive processor as the crypto device it was never meant to be.

He gets full marks for that one. This is basically my main (economical) point of critique on Frozen Cache.

4) Therefore (1 & 2) the Frozen Cache approach is rubbish.

This statement really made me angry. Shouldn’t he be glad (maybe even proud) that so many people think about the problems he discovered? Instead he bashes a possible solution – that surely is more hack than anything else – without any constructive argument. Without any non-nitpicking argument at all, to be precise.
With a lot of technical problems still to be solved, Frozen Cache still has a good chance to effectively work in practice. I am still waiting for a real (read: scientific) argument against Frozen Cache.

EOR – End Of Rant

So, the rant is over and I feel slightly better. Mission accomplished. I’ll send Applebaum a link, so that he has a chance comment, fair is fair.

Comments