In Your DReaMs

Sun’s DReaM project, billed as an open source DRM format, smells like something that was dreamed up by Sun’s management without sufficient input from its engineers. It seems to me that if we use the term “open” in its ordinary sense–i.e. a publicly available standard that anyone is free to implement–“open DRM” is a contradiction in terms. DRM depends on its implementation details being secret in order to prevent unauthorized parties from accessing the content. My guess is that Sun’s management is on a kick to make all of their products more “open” and figured that if we can have open operating systems and open processors, why not DRM?

This hunch was confirmed by their recently released overview of the project. Consider this passage, for example:

Historically, proprietary end-to-end architectures have relied upon obscurity to avoid being cracked. Such systems are based upon a false foundation of security promises. Such systems have been cracked and will continue to be breached. Additionally, the opaque nature of these systems has led to monolithic system architectures (by nature) that presume delivery by a single vendor, which inherently increases costs through the lack of interoperability and adds difficulty when attempting to substitute one supplier for another.

DReaM promotes the view that open system architectures will present greater opportunities for review and discussion of technology choices so that shortcomings can be better evaluated and corrected (“review & repair” versus “hope & pray”) to provide the greatest protection possible.

This is an argument that you’ll commonly hear in defense of open encryption standards. And in that domain, it’s absolutely correct: today’s best encryption standards rely on only the encryption key being a secret. Everything else about the internal workings of the standard are publicly available. That allows security researchers to examine and correct any flaws discovered in the algorithm. The oldest and most widely-used encryption standards are the most likely to be secure, because they’ve received the most scrutiny, and so the odds of someone finding a flaw in the future are quite small.

Whoever wrote this DReaM overview clearly took the standard argument for open crypto and applied it to DRM. He missed the fact that the problem that DRM is trying to solve is fundamentally different from the problem that traditional crypto is trying to solve.

With ordinary cryptography, you’ve got a sender, Alice; a recipient, Bob; and an eavesdropper, Connie. Alice encrypts her message with an encryption key, and transmits the encrypted message to Bob. Bob has a secret decryption key that he uses to decrypt the message. If the encryption algorithm is secure, Connie won’t be able to decode the message, even if she is able to record the entire conversation between Alice and Bob, and even if she knows everything about the algorithm they used to encrypt and decrypt the messages.

Open cryptography works well because the more people who’ve looked at it, the lower the likelihood that someone will find a flaw. With an algorithm that’s been around for decades, such as RSA or DES, you can be reasonably confident that, barring a major mathematical breakthrough, Connie won’t be able to read Alice’s message without Bob’s key.

The challenge of DRM is that Bob and Connie are the same person. Or rather, “Bob” is software running on Connie’s computer–for example, a copy of iTunes. We want to transmit content in a way that “Bob” (let’s say “Bob” is iTunes software) can access it, but Connie can’t decrypt it for unapproved uses.

If Connie has the ability to examine or modify the software, that’s logically impossible. Because if the Connie’s software has the key, she can modify it to share the key with her. Or she can study what the software does and write her own software to perform the same series of steps. On a general-purpose computer it simply doesn’t make sense to treat a user and his or her software as separate entities, since the user can always modify the software to do what she wants it to.

For this reason, there’s no point in having security researchers examine DRM schemes they way they examines encryption schemes. All DRM schemes are insecure, because the client software can always be modified or reverse-engineered to produce a cracking method. The only question is whether a programmer has taken the time to develop software making this process user-friendly.

Which makes “open source DRM” a contradiction in terms. DRM depends on users being unable to study or modify software. But the point of open source software is to encourage modification by end users. Hence, if a company were ever stupid enough to release an “open source DRM” product, it would be “cracked”–that is, modified to eliminate the DRM restrictions–in a matter of days. With open-source software, there’s no coherent distinction between a user and his software. Yet DRM depends on that distinction in order to function.

In short, DRM is “security through obscurity.” I assume the engineers at Sun understand this. Somewhere in Santa Clara, there’s probably a team of DReaM engineers banging their heads against their monitors in frustration. It makes sense that the music and movie industry executives would be technologically clueless, but we should expect more from technology company executives.

SHARE: