Security versus DRM
DRM is often talked about as being a security measure, especially with its reliance on cryptography.
DRM isn’t really a security measure in any real sense, though. Let me explain why.
In a security system, you have two parties: A and B. Sometimes both parties will need to verify each other’s identities (mutual verification) together, but quite often these are distinct steps from each other and are conceptually the same thing just done once in each direction.
Security systems are based on the notion of A confirming that B is who they claim to be. Over a network (and indeed in most other settings), this is accomplished by way of B sending A something that only A and B know. Generally, one isn’t concerned with what B is, only that it has access to the necessary secret information. If B is an ordinary computer program, it boils down to the user typing their credentials into it, or allowing it access to some certificate or similar; ultimately, the user is in control. Much the same applies in the opposite direction: the server program A has access to some file or similar which is used to provide verification to B.
DRM, on the other hand, doesn’t work this way. It’s primarily concerned with what B is, rather than who B is. The “who” part is straightforward, and as above—but DRM systems don’t want the user to be in control (because the user—i.e., you—can’t be trusted). Thus, along with sending information to A about who the user is, B will also send information about what it is. Perhaps it will be some hard sums which only it can apparently calculate and A already knows the answer to, for example. If there’s no user authentication involved (for example, as is the case with 4oD or BBC iPlayer), then all the server cares about is that B is the program it thinks it is. (Note that requiring user authentication doesn’t complicate things much—the security aspect is straightforward).
This is where it all breaks down, though. A can only go on what it receives over the network from B to confirm that it is really a legitimate request. B is a program running on a remote—untrusted—computer, and A will essentially take its word for it. The issue is that there’s no avoiding this: the user running B theoretically has absolute access to everything that B itself does, and so all it can do is try to hide the pieces of information it uses to confirm its identity to A and hope nobody stumbles across it.
In terms of security, a simple analogy would be that DRM is like having username and password authentication, but that you write down the username and password on a Post-It note and hide it somewhere in your office (assume for the sake of the analogy that there are no locked cabinets or anything else like that). Then you tell everyone that you’ve hidden the username and password away and that they won’t be able to find it.
You hope that nobody will find the Post-It note, but ultimately you know that if somebody were to, they would be able to pretend to be you.
That’s the technical flaw in DRM systems: everybody knows that when they send requests to servers they identify themselves in some way. Sometimes it’s just as simple as sending identical-looking requests, other times you need to hunt down that Post-It note. The client program, B, is running in an environment controlled by you (rather than the people in charge of A), and you can do whatever you want, including look high and low for the Post-It note until you find it. Generally, there are a limited number of places it could be, not to mention the fact that you also have the ability of secretly spying on B to watch where it puts the aforementioned Post-It note.
There are systems (so-called “Trusted Computing”) which allow computer programs to securely hide information from the person who owns the computer itself. These aren’t in particularly widespread use for this purpose, for obvious reasons.
