DRM: January 2007 Archives

Ed Felten and Alex Haldeman have a nice series of posts about AACS, the content control system on HD-DVD and Blu-Ray. You should really go read the posts, but here's what you need to know (somewhat simplified)

• Each player has its own key (actually set of keys, more detail here).
• Because of the way disks are manufactured you need to have the same content on each copy, or at least to produce large batches of identical disks. So, there are a lot of movies encrypted with the same key (what's called the title key).

Given the title key, BackupHDDVD can decrypt the content of a disk. If you can compromise a single player and recover its key, you can use that to recover title keys which, of course you can use to decrypt disks.

Where this all went wrong with CSS was there were only a small number of keys, so once you compromised one player and published the key the game was pretty much over. But with AACS each player has a unique set of keys and the AACS includes a scheme for revoking compromised players. When a player is revoked you stop encrypting disks under its key, so it's useless for all future disks, but all disks printed before that time are (at least potentially) compromised. So, if you compromise a player and publish its key, it has a finite window of usefulness.

However, if software players are widely available, the situation is different. There's a large population of keys already available to people and all the attacker needs to do is release a piece of software which extracts the player keys from a player or patches an authorized player to either disclose title keys or the unencrypted data on a disk (as Felten observes), WinDVD already more or less is such a player, but that's presumably a somewhat temporary situation). There are of course techniques you can use to make it harder to hack software, but as far as I can tell none of them stand up to dedicated attack.

It's of course possible for the manufacturers to revoke all the players by a particular manufacturer and force them to download a new player with better tamperproofing. This has two drawbacks. First, the cost is much higher than just revoking the compromised unit because you're not just inconveniencing the attacker but everyone who happens to have a vulnerable player and most of those people are totally innocent. Second, because it's comparatively easy to break the tamperproofing the attacker can force you to incur this cost more or less whenever he wants.

It's hard to see how the studios can really solve this problem as long as purely software players are allowed.

OK, I have to admit that the Not Yet Released Device Potentially To Be Known As The iPhone (NYRDPTBKATi) looks pretty sweet, but the level of lockin significantly detracts from the overall coolness. There are actually two issues here, one bogus and one real.

DRM
The bogus one, raised by Randall Stross in the Times is the FairPlay DRM:

Here is how FairPlay works: When you buy songs at the iTunes Music Store, you can play them on one and only one line of portable player, the iPod. And when you buy an iPod, you can play copy-protected songs bought from one and only one online music store, the iTunes Music Store.

The only legal way around this built-in limitation is to strip out the copy protection by burning a CD with the tracks, then uploading the music back to the computer. If youre willing to go to that trouble, you can play the music where and how you choose the equivalent to rights that would have been granted automatically at the cash register if you had bought the same music on a CD in the first place.

This is, of course true, but sort of irrelevant. First, you're quite free to buy physical CDs and rip them yourself. iTunes will even rip them for you. At least with the iPod and presumably with the NYRDPTBKATi, there won't be any copy protection on them at all. It's true that the iPod file format obfuscates the locations of the files on the disk, but they're all there and you can get 3rd party programs which know how to read the format. The vast majority of music gets into iPods by being ripped, not downloaded.

Second, the issue isn't the iPod or NYRDPTBKATi, but rather iTMS, which imposes the DRM on the way out the door. Stross says this in the article but some misses the implication:

This claim requires willful blindness to the presence of online music stores that eschew copy protection. For example, one online store, eMusic, offers two million tracks from independent labels that represent about 30 percent of worldwide music sales.

Unlike the four major labels Universal, Warner Music Group, EMI and Sony BMG the independents provide eMusic with permission to distribute the music in plain MP3 format. There is no copy protection, no customer lock-in, no restrictions on what kind of music player or media center a customer chooses to use the MP3 standard is accommodated by all players.

In other words, it's quite possible to play non-DRMed files (what else is a podcast, after all?), it's just that (1) the music users want isn't available (2) the users don't know where to get it or (3) the UIs for getting it are too annoying. if it's really true that the major labels are willing to go non-DRM than this sounds like a great marketing opportunity for someone to make a really good non-DRM online music store. In any case, Stross's quarrel isn't with the iPod but with iTMS.

Programmability
This brings us to the real issue: programmability. According to this article the NYRDPTBKATi isn't going to be an open platform. I.e., you won't be able to load your own applications onto it. Apple has advanced two major arguments for why this is OK: protecting the network from rogue applications and protecting the stability of the device.

Here's Jobs advancing the first reason:

But its not like the walled garden has gone away. You dont want your phone to be an open platform, meaning that anyone can write applications for it and potentially gum up the provider's network, says Jobs. You need it to work when you need it to work. Cingular doesnt want to see their West Coast network go down because some application messed up.

Look, this is mostly nonsense. Yes, it's true that programmable computers can do damage to the Internet (cf. zombies, spam, DDoS, etc.) but this isn't primarily an issue of people installing the wrong third party software but rather of their machine being remotely compromised via vulnerabilities in the existing software—primarily stuff installed by the OS manufacturer. I should mention that Apple isn't giving out SDKs for the iPhone, so it's going to be harder for malware authors to program to it than (say) Windows, but that's only a temporary obstacle if it becomes an attractive attack target. There are of course ways to stop third-party malware from being loaded on at all (e.g., signed code) but the level of defense that Apple employs on the iPod doesn't suggest that they're too likely to have done anything like that here. I'd imagine they're just hiding the specs and the SDK and maybe churning the API/ABI occasionally to make it more inconvenient to write a real product.

More importantly, the danger in rogue applications isn't primarily to the access network but rather to machines other places on the Internet. It's actually very easy for Cingular to detect when a device is doing something dangerous to their network and shut it down. And to the extent to which it's not easy, Cingular has much bigger problems since they're already quite willing to sell you Windows Mobile and Palm smartphnes, which are programmable.

The second argument Apple is advancing is that letting end-users run arbitrary third-party apps will potentially destabilize the handset, contributing to a bad user experience.

We define everything that is on the phone, he said. You dont want your phone to be like a PC. The last thing you want is to have loaded three apps on your phone and then you go to make a call and it doesnt work anymore. These are more like iPods than they are like computers.

The iPhone, he insisted, would not look like the rest of the wireless industry.

These are devices that need to work, and you cant do that if you load any software on them, he said. That doesnt mean theres not going to be software to buy that you can load on them coming from us. It doesnt mean we have to write it all, but it means it has to be more of a controlled environment.

So, this is vaguely more reasonable, especially considering Apple's well-known fetish for the providing the optimal UI experience. Still, it's not particularly convincing. I've loaded several 3rd party apps on my Treo and haven't noticed it destabilizing the phone functionality. A modern O/S like OSX should be quite capable of protecting applications from each other—that kind of process isolation is one of the major functions of the OS. I haven't noticed any of the 3rd-party apps I run on my OS/X boxes being a source of massive instability.

Does it matter?
I'm probably unusual in that I'd actually like to be able to do some development on a handheld device, which would obviously be a problem if there's no SDK. That would be a big motivator for getting something based on a real operating system rather than PalmOS. But even ordinary users may find this kind of lockin inconvenient. I don't know what applications Apple intends to provide on the NYRDPTBKATi, and the truth is that they provide a pretty reasonable set on your Mac, but even so I've installed Firefox, MS Office, the Palm software suite, and Windows Media Player. Apple offers their own versions of some of this stuff and it will be interesting to see if they decide you should have to run Safari instead of Firefox or Keynote instead of PowerPoint. One of the nice things about having a general purpose computer is that you get to make these decisions for yourself rather than having Steve Jobsa make them for you.