The Logic of Open DRM
In his recent essay, Thoughts on Music, Apple CEO Steve Jobs has called for the labels to stop requiring him to sell their music with DRM. Most of his argument is that the labels already sell the vast majority of their music perfect digital copies without DRM — namely, CDs — but he also argues that the alternative of having an “open” DRM system is impossible.
Jobs is less than clear here. He writes: “There is no theory of protecting content other than keeping secrets. In other words, even if one uses the most sophisticated cryptographic locks to protect the actual music, one must still ‘hide’ the keys which unlock the music on the user’s computer or portable music player. No one has ever implemented a DRM system that does not depend on such secrets for its operation.”
Since this is a fairly important point and no one else is explaining what he means, I thought I’d give it a try.
DRM works by encrypting songs. Encryption works by performing a mathematical scrambling operation that can only be reversed with the right “key”. As a very simple example, imagine you have the message “hello” and the key “5”. One simple encryption system is to simply move each letter five letters forward (so “a” becomes “f”) and you get “mjqqt”. To decode it, you just need to know the number 5 and move each letter back that far. (This is a very bad encryption system, for a lot of reasons, but it works the same basic way as the good ones.)
The way DRM works, essentially, is that when you buy a song from the iTunes store it’s encrypted with a certain secret key (presumably one a lot bigger than the number 5). To play the music, you need the key to decrypt it. But the only software that has the key is iTunes and iTunes will only decrypt it if you’re following their rules — only playing it on 5 separate machines, for example.
For “Open DRM” to work, Apple would need to give the key to other people who made music players. But as soon as Apple gives the key to someone, they can do whatever they want with the music. If the key gets out on the Internet, anyone can decrypt the songs. DRM only works because the key is secret. Open DRM is an oxymoron.
You should follow me on twitter here.
February 7, 2007
I thought this was such a smart move on Apple’s part, not only as a negotiating tactic with the labels (his note got top left attention on the cover of today’s Wall St. Journal—but will it work?), but as a good-will winner for the public, especially after that NY Times article a few weeks back. I think the labels already know the DRM game is up, I think they have long known it’s up, and it’s time to move on.
posted by Carl Tashian
on February 7, 2007 #
On this subject there is Cory Doctorow’s DRM talk at microsoft, http://www.dashes.com/anil/stuff/doctorow-drm-ms.html
posted by Damien Pollet
on February 7, 2007 #
Aaron, the typical DRM system is a bit more complex.
Besides secret (aka symmetric) keys there are public and private keys (aka asymmetric) of which only the private one has to be kept secret and hidden and the public one can be known and shared.
Content is typically encrypted by a secret key. This is an individual key per content and not known to the device prior to receiving the content. It’s not a shared key as you assumed.
Now that key is wrapped by a public key and can only be extracted again by using the matching private key. Which public key? Each device must have a unique key pair. The private key might be stored on a smart card which is generally considered tamper proof. Most mobile devices work this way nowadays.
The associated public key is know sent to the service that will issue the wrapped key to the device. That service will be able to check whether that device is allowed to receive the wrapped key. It then wraps the encryption key so that only the identified device can unwrap it.
A device must never disclose the content key. Its manufacturer can be forced to assure this by contract. Using the smard card (or a trusted computing module) is one good way. The manufacturer will be sued if he creates a device that leaks the secret key. It is his responsibility to fix the leak or pay.
All affected devices - identified by the public key - can be excluded from further service. Because all keys are individually protected, one leaked private key cannot harm the system in general.
This is the way for example Microsoft’s DRM works. It IS practical to license it to third parties. It’s more a thing of control and user lock-in than a technical problem.
posted by DRM
on February 8, 2007 #
Quite ironic coming from Jobs, considering no one is forcing him to put DRM on iTMS albums like Sleater-Kinney’s “Dig Me Out.” (eMusic sells the same album DRM-free.) Jobs chooses to use DRM, presumably because it’s in Apple’s best interests (for the time being).
On a related note, Mike Hearn has an interesting post about the difficulty (impossibility?) of breaking hardware-based DRM systems:
http://plan99.net/~mike/blog/2007/01/25/on-drm/
posted by Alan
on February 10, 2007 #
Agreeing with Alan, I was confused about why Apple did not offer ANY songs without DRM. It seems likely there are a number of artists who would not mind boosting their sales by selling their songs without DRM, and it can’t be too impossibly technical to do this iTunes, since all they’d be doing is NOT encrypting songs that were flagged to be not encrypted.
I couldn’t figure out a good explanation of why they would be doing this. The thing from Jobs seems to indicate that they want music fans to direct their displeasure at the music industry giants. It seems that if Jobs was at all anti-DRM he would have this option for publishers to not have DRM on their songs. Any ideas?
posted by Christopher Hesse
on March 8, 2007 #
DRM: I was only addressing software systems (like iTunes) in this piece, in which tamperproof cards are impractical and the public/private key bit is kind of irrelevant.
Alan: It looks like time has proved you entirely wrong about that.
Chris: My assumption was that the interface complexity for having both DRM and non-DRM wasn’t worth it to Jobs for just a handful of indie artists.
posted by Aaron Swartz
on April 12, 2007 #
You can also send comments by email.
Comments
I thought this was such a smart move on Apple’s part, not only as a negotiating tactic with the labels (his note got top left attention on the cover of today’s Wall St. Journal—but will it work?), but as a good-will winner for the public, especially after that NY Times article a few weeks back. I think the labels already know the DRM game is up, I think they have long known it’s up, and it’s time to move on.
posted by Carl Tashian on February 7, 2007 #
On this subject there is Cory Doctorow’s DRM talk at microsoft, http://www.dashes.com/anil/stuff/doctorow-drm-ms.html
posted by Damien Pollet on February 7, 2007 #
Aaron, the typical DRM system is a bit more complex.
Besides secret (aka symmetric) keys there are public and private keys (aka asymmetric) of which only the private one has to be kept secret and hidden and the public one can be known and shared.
Content is typically encrypted by a secret key. This is an individual key per content and not known to the device prior to receiving the content. It’s not a shared key as you assumed.
Now that key is wrapped by a public key and can only be extracted again by using the matching private key. Which public key? Each device must have a unique key pair. The private key might be stored on a smart card which is generally considered tamper proof. Most mobile devices work this way nowadays.
The associated public key is know sent to the service that will issue the wrapped key to the device. That service will be able to check whether that device is allowed to receive the wrapped key. It then wraps the encryption key so that only the identified device can unwrap it.
A device must never disclose the content key. Its manufacturer can be forced to assure this by contract. Using the smard card (or a trusted computing module) is one good way. The manufacturer will be sued if he creates a device that leaks the secret key. It is his responsibility to fix the leak or pay.
All affected devices - identified by the public key - can be excluded from further service. Because all keys are individually protected, one leaked private key cannot harm the system in general.
This is the way for example Microsoft’s DRM works. It IS practical to license it to third parties. It’s more a thing of control and user lock-in than a technical problem.
posted by DRM on February 8, 2007 #
Quite ironic coming from Jobs, considering no one is forcing him to put DRM on iTMS albums like Sleater-Kinney’s “Dig Me Out.” (eMusic sells the same album DRM-free.) Jobs chooses to use DRM, presumably because it’s in Apple’s best interests (for the time being).
On a related note, Mike Hearn has an interesting post about the difficulty (impossibility?) of breaking hardware-based DRM systems:
http://plan99.net/~mike/blog/2007/01/25/on-drm/
posted by Alan on February 10, 2007 #
Agreeing with Alan, I was confused about why Apple did not offer ANY songs without DRM. It seems likely there are a number of artists who would not mind boosting their sales by selling their songs without DRM, and it can’t be too impossibly technical to do this iTunes, since all they’d be doing is NOT encrypting songs that were flagged to be not encrypted.
I couldn’t figure out a good explanation of why they would be doing this. The thing from Jobs seems to indicate that they want music fans to direct their displeasure at the music industry giants. It seems that if Jobs was at all anti-DRM he would have this option for publishers to not have DRM on their songs. Any ideas?
posted by Christopher Hesse on March 8, 2007 #
DRM: I was only addressing software systems (like iTunes) in this piece, in which tamperproof cards are impractical and the public/private key bit is kind of irrelevant.
Alan: It looks like time has proved you entirely wrong about that.
Chris: My assumption was that the interface complexity for having both DRM and non-DRM wasn’t worth it to Jobs for just a handful of indie artists.
posted by Aaron Swartz on April 12, 2007 #
You can also send comments by email.