« Neuroeconomics and Innovation | Main | Exam Characters »
May 13, 2008
The De-Pressing Truth About DVDs
Yesterday, I told a simplistic story about DeCSS—indeed, the self-same simplistic story about DeCSS that I told my classes this year, and that I suspect a lot of other professors tell their classes—and asked what was wrong with it. The way I put it, if DeCSS really is about preventing only decryption of DVDs, what’s to stop pirates from simply making copies of discs in their encrypted forms? The story simply doesn’t make sense without some additional fact.
Sarah L. (“[T]he CSS disk’s descrambling keys are in sectors that aren’t copied when you make a copy of the disk using a noncompliant player.”) and Bruce Boyden (“[T]he whole scheme depends on licensed drives, which must play by the licensing rules.”) both had important parts of the answer, but what I was looking for is that it is physically impossible to produce CSS-encoded DVDs using home equipment. Sarah’s and Bruce’s points are both true, but even taken together, they wouldn’t explain why DVD Jon or someone else similarly disinclined to care about licensing doesn’t just write a program that writes the descrambling keys to the special sectors. They don’t because they can’t.
To decrypt a CSS-encrypted DVD, you actually need two kinds of keys. One is universal but nominally secret; it’s baked into every DVD player. This is the one that DVD Jon found. The other is different for every disc. But this second key isn’t really secret; it’s written out on the disc, plain as day for anyone to see, in a special “lead-in” sector. Ordinarily, your DVD player reads the public disc key, combines it with its own secret player key, and uses the two together to decrypt the disc contents.
Here’s the twist. There are two ways to make readable DVDs, and they use completely different technology. The large-scale industrial method is to “press” the DVD: that involves encoding the data as a series of tiny three-dimensional bumps on a mold used to stamp a corresponding pattern of pits into metal blanks, which are then encased in a layer of lacquer to make DVDs. This process, as you might imagine, has high fixed costs; the equipment alone will run you upwards of a million dollars. In contrast, the home method is to “burn” the DVD. Here, the blank disc comes from the factory prelacquered and containing an optically sensitive dye on the surface of the metal. Focus the right kind of laser on the dye and its transparency changes. From the perspective of the DVD player that will later read the disc’s patterns of opaque and transparent regions, the results are much the same as if the disc had pits and non-pits. Some areas reflect; others don’t. Ones and zeroes, more or less.
The trick that makes CSS “work” is that you can’t burn lead-in sectors. DVD-Rs (and DVD+Rs) come from the factory with the lead-in sectors zeroed out. Thus, a would-be pirate can easily read an entire encrypted disc, disc key and all, but can only burn back the data portion of the disc, without the disc key. The resulting disc is useless in a standard DVD player; there’s no disc key to be read, which means the player is at a loss in trying to decrypt it. While one could manufacture and distribute home-copied DVDs without having to bust CSS, those DVDs are only going to work on specially-coded software DVD players, not on the mass-produced home players most people have.
That’s why everything does in fact depend on CSS, and why DeCSS really is a big deal. It goes back to the control that the DVD cartel has over their hardware platform, specifically over the manufacturing format of blank media. And that control, in turn, is backed up by patent pools. Yes, you could in theory press (not burn) exact-copies of encrypted discs, or mass-produce your own non-standard blank DVD-Rs with writable lead-in areas, but to do either, you’d need some significant (and hard-to-move) capital, which makes you vulnerable if the cartel comes after you. It’s an ingenious technologico-legal trap.
Tomorrow: Some thoughts on the implications (including responses to comments).
Posted by James Grimmelmann at May 13, 2008 08:53 PM
Trackback Pings
TrackBack URL for this entry:
http://www.concurringopinions.com/movabletype/mt-tb.cgi/3647.
Comments
This explanation makes sense. But what about playback on computers? Why can't pirates make an unencrypted DVD-R using software DVD players and a clever video driver (the digital version of the analog hole)?
Posted by: Archit Shah at May 13, 2008 09:55 PM
What you're describing is the general version of an attack on any DRMed media object: it ultimately has to be presented to the user in unencrypted form, so one can merely snoop on that unencrypted bytestream and go from there. That's definitely more work than simply making a bitwise copy of the disc, though. It occupies the same techico-ecological niche as DeCSS.
One way of putting it might be that it's unclear why the cartel expected CSS to survive first contact with the general-purpose computer. It's "secure" as long as all DVD-reading hardware consists of sealed special-purpose boxes, but once you put a computer in the process, it's obviously feasible to control the decryption process or monitor the playback.
Posted by: James Grimmelmann at May 13, 2008 11:10 PM
I could imagine the DVD people trying to bootstrap their technologico-legal protections into general purpose computers by relying on the fact that Microsoft and Apple both need patent licenses for their DVD playback software. The DVD people could require the OS to provide some protected output and limit software playback licensees to using that output. Alternatively, they could devalue unencrypted DVDs by requiring sealed box playback systems to treat unencrypted DVDs as second class DVDs, maybe by limiting playback to 90 minutes.
Posted by: Archit Shah at May 14, 2008 11:09 AM
Great series of posts, James.
It's worth noting that the licensing protections on home users making playable CSS-encrypted disks go beyond just the manufacture of recordable disks, but also involve design constraints on licensed recorders. For example, I believe DVD+R disks *don't* come from the factory with the lead-in sectors zeroed out, meaning that if you could burn a key there, you could make bit-for-bit copies of a prerecorded disk. See here:
http://www.cdfreaks.com/reviews/Increased-compatibility-DVD-bitsetting
The reason why DVD+R recorders aren't a massive security breach is that there's an additional protection, which is that licensed recorders aren't supposed to *write* to the lead-in area where the disk key is located, even if it is blank. Evidently they can, however, write to the lead-in area that contains the DVD+R's "book type," which I believe was also supposed to be an additional protection -- licensed players and drives should ignore CSS data present on a recordable book type. In all, I think the DVD+R situation shows that, although you refer to a "DVD cartel," it's a pretty reluctant and unruly cartel.
So it's true that the whole system depends not just on technology, but also licensing requirements and legal protections. I'm curious, why do you describe that as a "trap"? It could be described as "blocking" or "inhibiting," maybe, but I don't get what the "trap" is that catches the unwary. No one hopes for a license violation.
[I]t's unclear why the cartel expected CSS to survive first contact with the general-purpose computer. It's "secure" as long as all DVD-reading hardware consists of sealed special-purpose boxes, but once you put a computer in the process, it's obviously feasible to control the decryption process or monitor the playback.
"Hoped" might be a better word here than "expected." Playback in computers was still relatively new in the mid-1990s. Obviously monitoring decryption and playback is easier in a computer than it would be in a stand-alone machine. But "easier" doesn't mean "easy." The CSS hack resulted from a particular implementation in one software player. It might be more accurate to say that the reluctant nature of the "cartel" was more the problem than a technological flaw in CSS.
Re: Archit's comment: The DVD people could require the OS to provide some protected output and limit software playback licensees to using that output.
The politics of the DVD "cartel" wouldn't allow this. Computer manufacturers, including OS manufacturers, are typically adamant that there be no obligation on their part to scan all content to figure out what it is just by virtue of their handling it (but not decrypting or otherwise using it). So content is protected as it transits through a computer either by encryption or by being transmitted through channels that are thought to be physically difficult to tap. Each device or program that decrypts CSS data must have a license and thereby play by the license rules, which include restrictions on outputs (from the device or program, not necessarily from the piece of tin that wraps the computer). But there's no general obligation on the part of an operating system manufacturer, just from the fact that the OS handles communications between devices and programs, to determine what is in the communication and protect it accordingly.
Posted by: Bruce Boyden at May 14, 2008 04:02 PM
