views:

297

answers:

5

I am curious to know if anyone has figured out a way to create the server portion of DRM in an open source manner while allowing for DRM clients to be closed. I understand that if the client were open source, it would be easy to remove the DRM checks, but I believe the server doesn't suffer from the same challenge.

+6  A: 

It is possible but like any DRM, it's broken by nature. ;)

Mehrdad Afshari
+2  A: 

I wouldn't be at all surprised. Although I have no formal theories about this, since the popular encryption and hashing functions are open source and very well studied, most have withstood the test of hackers for a reasonable time. And I figure DRM is somewhere in the same category of problems as ciphers and hashes.

I mean, the now-looked-down-upon MD5 was first published at 1992 and only at 2005, a first manufactured and practical collision was demonstrated (according to wikipedia). Blowfish was published 1993, and there's still no effective cryptanalysis on it.

So, sure, why not. The problem here is that the open source community, per se, has no incentives in building such a device...

Edit: My answer has gotten some arguably well-deserved criticism, basically stating that DRM is, in a nutshell, security by obscurity, where the obscurity is blown away by making it open source. And, sure, as said earlier, who am I to disagree. But, still, I wouldn't be surprised that, while today's DRM is done by obscuring stuff, one given day, some brainiac comes along, and designs a DRM that actually works.

Sure, dismiss as much as you want, and this is actually more of a play of thoughts, but I've learned to never say never.

Henrik Paul
The thing is, DRM is basically security by obscurity. And obscurity cannot be hidden in open source software.
Mehrdad Afshari
DRM isn't "somewhere in the same category of problems as ciphers and hashes" - it's obfuscation, nothing more. You can use the most secure cipher you like, but you have to provide the decryption key with it, so it's pointless.
Nick Johnson
Do you also believe that one given day, some brainiac comes along, and designs a perpetuum mobile?
Anton Tykhyy
+4  A: 

There's also Project DReaM, Sun's open source DRM framework.

Chris Jester-Young
+2  A: 

Depends on what you mean -- do you think closed-source DRM that runs on client machines out of your control is "possible"? Everything I've seen suggests that it is not: they all get broken sooner or later.

If you think it is, then I suppose an open-source DRM is equally possible. :-)

Ken
+5  A: 

Not in any practical fashion.

To understand why it's helpful to compare DRM with Encryption. Encryption is a mechanism to share secrets with trusted second parties without the possibility of a third, untrusted party receiving the secret message. Encryption is built upon a very solid background of mathematics, and works because the second party is considered to be trustworthy of the key to unlock the secret message.

DRM, on the other hand, assigns no trust to any party except the original source. The assumption is that the second party has a limited, revocable right to the secret message, and is not to pass the message to any other party, even if they want to. The problem with that is the second party must somehow still decrypt the message, even though they are not trusted with the ability to do so. This is the basic conceptual challenge of DRM.

DRM accomplishes this using two techniques. First is obscurity. The mechanism, algorithms and keys used to encrypt or decrypt the managed message are themselves kept secret. Second, Patent encumbrance is used on some aspect, usually the decoding algorithm, so that the parties that do know that part are prevented legally from disclosing it to other parties, or using it at all without proper license.

Both of these features are in opposition to Open Source. By its very nature, Open source discloses algorithms. Any bit of code released under supposedly open source that happens to also be patent encumbered fails to in fact be free software.

TokenMacGuy