BitLocker, DarkNet, Development, Enterprise, Microsoft, Palladium, Security, Windows

Threat Model Irony

I do want to say that it is a well-written and thoughtful paper. The practical application of reconstructing keys from memory is cool. (But it’s the overall attack vector is still not news, though. : ) I feel vindicated in some ways, actually. EVEN IF IT ISN’T NEWS! : )

It’s worth noting that back when we were debating what HW should, and shouldn’t, go into Palladium (late 90’s into 2001-ish) we spent quite a chunk of time talking to Intel and AMD about encrypted memory. There were some simple and wicked fast solutions that would have made this attack WAY harder as the keys to decrypt memory itself would live in the CPU or memory controller rather than RAM, and they could be de-persisted much more efficiently than RAM could.

However when we threat modeled it the only attack we came up with at the time was based on DRM.

To justify RAM encryption we needed to treat the “owner” of the machine as an absolute persistent and viable threat, and that bothered me for two reasons:

  1. It meant that the notion of people being able to hack their own machines could become extraordinarily more difficult. I am hugely in favor of people at least having the potential to hack their own machines, so this really bugged me. I count on plucky rebels to keep evil empires in check.
  2. The only serious reason we could come up with back then to go so far in protecting memory was to protect DRM keys from machine owners, and so long as the analog hole existed it seemed particularly crazy to go so far to protect something that was used to protect data that was leaking like as from a sieve everywhere else. Darknet FTW, as it were.

So I decided no encrypted memory for Palladium.

Not sure, in hindsight, if that wasn’t a mistake? Oh the irony!


4 thoughts on “Threat Model Irony

  1. Hi Jacob – No, I can’t. If people were saying that was the news in your paper, then I think I’d be whole-heartedly agreeing with them. I think it’s cool AND neato.

    Prior to shipping BitLocker we worked on various DRM-style key obfuscation techniques, in particular ones which would split the keys and make them dependent on things like time and location. That would make it much harder to find them in a static image as the snapshot of memory would never contain a single plaintext key or keys.

    But clearly this isn’t bullet-proof – it may have just been a speed-bump for you. You could tried a VM to load up the image and watched it chunk away to find the keys, as cearly they have to be in memory in some form.

    So while you might have said “it was harder to get at the keys in BDE than in the other FDE systems we attacked” you might still have been able to publish a paper very similar to the one you published, complete with algorithms to break the obfuscation tricks we added…

    Why didn’t we do this? Added complexity, which added risk, and we had other mitigations to work on. I still think that MSFT should do it, though.

  2. Biddle,

    I wish you would write more about “Palladium”. It was one of my favorite aspects of “Longhorn” and I wish it had made it to Vista. It’s a shame that “Palladium” received such an undeserved reputation.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s