Digital Rights Management: Putting the Genie Back in the Bottle

Some of y'all might be familiar with DRM, some might not. Let me break it down thusly.

Digital Rights Management, or DRM, is the concept that the copyright owners of the contents of digital files should have control over how they are used on your computer. This is where things like iTunes' FairPlay® system come in. In FairPlay you're allowed to play your music files you've purchased on your computer and four other computers, and you're allowed to burn the files to CD a limited number of times. It sounds okay but kind of restrictive, right? This is the least restrictive of all the DRM formats that I've seen. The rabbit hole goes much deeper; let's take a look.

One of the earlier forms of DRM copy protection was CSS. That's not Cascading Stylesheets, but Content Scrambling System. CSS was the copy-protection scheme used for DVD players. This turned out to be ridiculously easy to break, requiring about 17 lines of code written shortly after DVDs became popular. The scheme consisted of a "region" encoding, that would restrict the playing of DVDs to players that had the same region. This way the cheaper DVDs produced in Japan could not be played on American DVD players, cheap American DVDs couldn't be played in England, etc. In addition, the contents of the DVD, the actual video, were scrambled according to a simple cryptographic scheme, protected pretty much only by its obscurity (stay tuned for more cryptographic articles later). This system provided the content providers with control over where their content could be sold (or at least viewed) and thus how much it would cost; it also protected the digital content of the DVDs from immediate ripping like was experienced with CDs. CD audio is just an integer stream representing the sound wave it aims to reproduce; ripping it to a computer just means transferring that information to the computer from the CD. Digital to digital; easy, right?

There is an incredible weakness in CSS, though, so easily exploitable that it becomes laughable. And as I will argue in a moment, this weakness is inherent in any DRM scheme imaginable, for a multitude of reasons. Look at this from a cryptographic perspective. Say Alice sends Bob a movie, but requires that the information remain secure in transit. However, she and Bob have nevere spoken before. So, they follow an established protocol for talking so that it's secure; they have a key with a limited keyspace (I totally can't remember what it is for CSS; maybe 512?) and when Bob receives the movie, he'll test all the keys really quickly and see which one decrypts the stream properly. In this little imaginary scenario, Alice is the DVD content provider and Bob is a DVD player. The weakest link that I was referring to above is that there has to be some way for Bob to guess the key intelligently, and we can guess it, too.

Therein lies the insurmountable hurdle for all content providers who wish to use any DRM of any kind: at some point, the purchaser has to be capable of hearing the music or viewing the file or watching the movie, and it's at this moment that it all breaks down. Let's back up, first, though.

For any secure channel (for the sake of argument, let's move away from the DVD analogy and move on to a TV episode you've purchased as a .mpv file), the recipient must at some point have both the cryptotext (the file, protected), and the key (presumably stored on their computer or sent via the internet and cached) at the same time. The actual data received in the end is the plaintext (in this case, our TV episode). If the user doesn't have the key, they're not authorized to view that content. Fine. But this entire scheme relies on the "trusted" nature of the program used to view the file. But what if we wrote a program that pretends to be the trusted program, opens the file, receives the key, and performs the decryption using the key, storing the plaintext on the hard drive rather than viewing it? It sounds, actually, a lot harder than it really is. iTunes 7 encryption was compromised in this way less than eight hours after the release of iTunes 7.

The only other real options for content providers are rootkits (see also: Sony's huge fuckup of this past year), which would attempt to enforce DRM on the operating system level, a hugely controversial move, or trusted hardware. Trusted hardware brings the same idea as trusted software down to the parts of a device you can kick. A DVD player is a simple example of one such device; the content providers have an agreement with the DVD player manufacturers that they will build their product with these certain features to limit users' ability to copy DVDs. But what if some enterprising hacker were to build an untrusted device that behaved like a trusted device? In Australia, for example, it's illegal to sell DVD players that aren't "regionless" (i.e., they must ignore the region encodings of DVDs); an Australian DVD player will act like a trusted device this way, but will not act in the way that content providers wish it to act.

There's a central fallacy here. At some point, the user must be able to view, listen to, or otherwise enjoy the content they've purchased. Whether at the speaker output, as it's being decoded for play, or elsewhere along the chain of DRM goodness, the plaintext data must reveal itself in order for this to happen. It is not possible for the user to be able to hear a song they've purchased without the data that makes up that song passing through some untrusted hardware or software along the way (like, for example, a pair of headphones). So at some point the file is bare and naked, and can be cached that way. Also, no DRM scheme can be overly complicated, because at some point a portable device may be expected to play files, and overly complicated DRM both slows down playback and also drains batteries. Because of the combination of these two things, no DRM scheme will ever be unbreakable; it is much more likely that every DRM scheme will fall into the "trivially breakable" category like FairPlay and CSS both are.

In conclusion, the music industry is now forced to undergo a radical shift in how they sell music. In the good old days, you'd buy your music on vinyl. Though you had in your hands an extremely high-quality analogue recording, lovingly reproduced with excellent fidelity, the owners of the copyright on that recording were guaranteed that you could only play it so many times before it would wear out. A 7-inch 45rpm single would wear out with a few hundred plays sometimes. So you'd buy a new record when that happened. Now, with digital formats, the music is encoded as binary and stored on a hard drive or backed up to CD, and the bits never die. The only way you could lose a recording is if you actually lost it via hard drive crash or otherwise. There is no longer any way for content owners to fully control what is done with their materials, and there is still a limitless market for content. When strained, consumers will find other ways to get what they want, and these consumers have rights, too. This DRM business is silly. All it does is limit honest consumers, and for those of us who want to exercise absolute control over our data, it has turned us into outlaws (see also: the Digital Millennium Copyright Act), and it doesn't even work.

New Blog

Since the shitty little move that Richard pulled a few weeks ago—namely the destruction of www.maxstahl.com—I haven't had a good place to put techy blog things.

So, you can expect things here kinda like were on my old site. Sort of theoretical and analytical articles on the Web, on programming (particularly for the web), on development in general, and also just on computer science and the sciences in general.

For more detailed commentary on web-specific topics, you'll want to stay tuned. We of the Great and Powerful Development Team at VSA are all going to have blogs soon and when I get that one I'll actually make a pretty good effort to keep it up. Until then, space cadets.