We have met the enemy and he is us: Why current DRM is doomed from birth

Despite the best efforts of a lot of intelligent people in the content distribution business, pirates continue to break new DRM schemes. While the debate on whether DRM is a good thing or not is both heated and has been going on for a long time, there is a more fundamental problem with basically all DRM schemes, and it is this problem that allows them to be broken: DRM is based on the principle of encrypting the content to be protected in a way that ensures that only legitimate consumers may access it.


Cryptography is “…the practice and study of techniques for secure communication in the presence of third parties…” (Wikipedia). In common cryptography, there are three parties: A sender, a receiver and an adversary. The two first parties want to exchange a message without the third party. But in DRM, there are only two parties: A content rights owner and a content consumer. The first can be thought of as the sender in the chryptographic world. The rights owner wants to transmit a piece of content to a consumer in a way that ensures that noone but the consumer is able to access the content. The consumer can be thought of as the receiver. They want to access the content. Incidentally, most consumers don’t really care about keeping the content secret from everyone else.

By using cryptography to ensure that the content cannot be shared, the content rights owner must also make sure that the intended receiver can access the content. This means that the consumer must be given the means to decrypt the message. In some DRM schemes, this can be achieved through dedicated hardware, such as the Kindle ebook reader from Amazon, or even early DVD players (before the DRM on DVDs were broken, that is). In other shcemes, it is merely a piece of software, such as iTunes from Apple.

But we’re missing the adversary from the chryptographic world. And the problem is that the content consumer may act as the adversary. In the perfect world, the consumer would respect the rights of the content rights owner, but in reality, the consumer might want to share the content with a close friend (or everyone on the internet). This is what DRM is intented to prevent, but it is in this scenario that the critical flaw of DRM is revealed: The adversary is now the consumer, and consequently knows how to decrypt the message. And while this is certainly a flaw in the protocol, it is there by design.

Breaking DRM

Even in situations where a direct digital copy of the content isn’t immediately available, everyone (born before 2000) would still be able to make a copy of a piece of DRM-protected music throug the use of a casette tape recorder. This copy will not have the same digital quality as the source, and some would argue that the DRM isn’t really broken, as a perfect copy hasn’t been made, but the fact remains that the content sought to be copy-protected has been copied.

But even if we only consider perfect digital copies to be a breach of DRM, there is still a giant problem. Cryptography for the sake of keeping something secret relies on a shared secret between the sender and the receiver, which should be unavailable to the adversary. The moment the adversary obtains this shared secret, the message can no longer be considered secret either. Which means that the only task left for a pirate is to extract the shared secret, write a utility that can decrypt the content and save it in decrypted form, and the DRM scheme is oficially broken.

So the battle between DRM makers and pirates is really a matter of making it hard to extract the shared secret, but since it must still be possible for legitimate consumers to access the content, the DRM makers are severely limited in this endeavor.

The battle is lost in advance for software-based DRM, as the means of decrypting is readily available to the pirate. For hardware-based DRM, it is a bit harder for the pirate, but since there are a lot of people dedicated to break DRM, it is usually only a matter of time, and the fundamental problem remains that the content must be accessible by the consumer.

Online DRM

So far, the only approach to DRM that seems to be invulnerable is schemes based on the consumer being online while accessing the content, which will allow the content rights owner to tightly control access in real time. This has been implemented for computer games, but have other flaws. The content rights owners now force the consumer to be online in order to access the content. If transferred to music, this would mean that it would be impossible to load the music on a portable music player for a hiking trip to an area without internet coverage, which most hikers would probably not like. And even worse: It means that the content will become unavailable if the server that controls access should ever become offline for any reason.

Whether this is a problem depends entirely on the terms of the agreement between the rights owner and the consumer. As we currently understand a purchase, this is entirely unacceptable, but changes to property law and new kinds of rights transfer may change that. That is a task for the future, but right now, DRM, as we know it, is broken.


The song of the mockingbird

I have a new favourite drink: Mockito!

For my Computer Science thesis, I worked with the annotation processing framework of the java compiler. It is actually a pretty cool framework that allows you to extend the compiler by processing annotations at compile time, and it can be set up to work simply by including a jar on the classpath. The API is actually pretty nice, using fancy stuff like  mirror-based reflections and whatnot. But it was a pain in the ass to unit-test. As my components lived in the middle of a compiler pipeline, there was a huge environment of objects that it assumed the existence of, and while the courses i took on test-driven development taught me to use a test stub to factor out components that I wasn’t testing, it just seemed like an overwhelming task in this case. So I created a lot of Java source code and wrote some jUnit-fu to turn it into test cases for my compiler extention. It wasn’t pretty, but it got the job done.

Now, imagine my joy, and the feeling of facepalm, when I started in my new job, opened up the relatively new Java codebase and discovered the concept of a mocking framework! The ability to hot-swap objects with mocks that just returns whatever you tell them to does not sound like such a big deal until you’ve tried to test small components in a big world, but boy, does it change the way testing works.

To those who unit-test and haven’t yet tried a mocking framework, I urge you to try it out. It works particularly well with some sort of dependency injection scheme, as you can mock the dependency injection and through that inject your mock objects whereever you want them. As for frameworks, I have only personally tried Mockito, but there are several out there, all with strengths and weaknesses.