The DRM Problem

Early in Immunity's history, almost a decade ago, we were approached by a company building a new DRM system. Back then, there was a LOT of buzz about DRM. Everyone was patenting and building great big DRM systems that were going to conquer the world and generate huge piles of revenue.

This never happened.

But in the meantime, lots of security companies looked into various DRM systems for people (@stake and early Immunity being two of them) and I assume always said the same thing - "You can break this a lot faster and easier than you'd think." Everyone was surprised and amazed at your ability to use a debugger, and you got paid, and they shipped it without changing a thing.

You get similar problem sets all the time in modern day security consulting. Here's some examples:

1. "Bring your own computer/phone" policies essentially require that the corporation trust that your host computer is secure. So they either try to load some anti-virus-type system on your host that helps you secure it (this doesn't work), or they put themselves into a VM and hope that you can't attack a VM guest from the host (this also doesn't work). Usually there is a sandbox or weak encryption layer to help protect them in theory.

Whole companies (aka, Good) are built on this premise.

2. DRM to protect against a nation-state stealing your IP from your hosting provider in China. In fact, it's not uncommon for some of our larger financial customers to have someone walk into a facility, request a machine, and then bring it back later and plug it back in. There's really no set of DRM-style cryptography that's going to protect you against people having physical access.

3. DRM to distribute software on PCs or pseudo-PCs. The best DRM engagements are ones in which people want to know the scale of effort it would take to break a DRM scheme. What we usually recommend here is that they schedule twice the amount of effort that they think they will need, and have an actual plan for what they will do if it takes half the time they think they will need. This can alter their security stance in important ways, as Sony found out. (In Sony's case, they assumed no one could send encrypted traffic to the PSN network because it was covered by fairly decent DRM - but that meant they failed to properly secure the backend network).


In general though, Immunity's goal with engagements is to be able to offer SURPRISING results. Breaking DRM schemes should never be surprising, but too often is, in a sort of 90's flashback kind of way.