3 January 2000
To: Lucky Green <shamrock@cypherpunks.to>
Cc: "cypherpunks@Algebra. COM" <cypherpunks@Algebra.COM>,
"Cryptography@C2. Net" <cryptography@c2.net>, John Gilmore
<gnu@toad.com>
Subject: Re: DeCSS Court Hearing Report
From: Andreas Bogk <andreas@andreas.org>
Date: 01 Jan 2000 22:37:18 -0500
Lucky Green <shamrock@cypherpunks.to> writes [see full report: http://cryptome.org/dvd122999.htm]:
> other individuals distributing copies of [De]CSS source code. DeCSS was
> originally published to allow for playback of DVD's on computers running the
> Linux operating system.
I think it's about time to clear up some issues. DeCSS is not Linux software. But DeCSS would not have been possible without the Linux DVD development, and CSS playback under Linux would have been much harder without the release of the DeCSS source code.
To make sense out of what I'm saying, it helps to take a look at how CSS works. The basic idea is that the DVD is encrypted, and the decryption key is stored on the disk, at a place where it isn't directly readable on an ordinary PC DVD drive.
Now to play back a DVD, the decoder software or hardware runs a two-way authentication and key exchange with the drive. Now the key material is transmitted from the drive to the decoder, obfuscated with the negotiated session key.
How to do this key exchange has been known to the Linux community for almost a year, after an anonymous member of the livid (LInux VIDeo) mailing list posted reverse engineered assembler code of the key exchange to the mailing list. This code does not come from the Xing player. The code had been analyzed and re-implemented in C by the livid members.
The interesting point here is that this information is already sufficient for copying a DVD: just copy all of the sectors and the key information.
The second step is the actual decryption of the DVD sectors. For that, there's a so-called player key required. The idea is that the title key (the actual key used for decryption) is encrypted with a disk key, which in turn is encrypted with 408 player keys, and all 409 encrypted disk keys are stored on the disk. The idea is that every player contains one of the 408 player keys, and if any of the keys gets published, you can just omit that slot on all future DVDs and thus limit the impact of the problem.
Now one of those player keys, as well as the actual bulk cipher, were reverse engineered by two independent parties: one released a tool called SpeedRipper, the other a tool named DeCSS. Both tools used the source code developed by the Linux community. Cipher and key in DeCSS were recovered from Xing's player. The fact that Xing didn't take steps to make reverse engineering harder only made that step faster, it had not been crucial for the success.
Now someone anonymously mailed the DeCSS source code to the livid list, where in turn the code was analyzed. After a very short time, cryptanalyzers blew a couple of deadly holes into the whole scheme, making the encryption breakable without even knowing any player key in under 20 seconds.
At that phase, the DVD consortium started to get really pissed. No, not because of copyright issues; as I have shown above, copying a DVD had been possible before, and tools to capture and re-encode DVDs to MPEG1 (which makes pirating a DVD manageable, in contrast to the 4.7GB files DeCSS will give you) also existed before.
The only reason that justifies the existence of the player keys in the CSS scheme is control of the DVD consortium over the licensees: they can always threaten to revoke the player key of a given licensee if that licensee doesn't play by the rules (Macrovision, Region Codes, etc.).
Now that the scheme has been published and broken, it's possible for anybody (and that distinctly includes the Linux folks) to build a DVD player. That's what they were afraid of. Piracy has been possible before, and they didn't care.
> The lines appear drawn rather clearly: a "Copy Control Association" vs. the
> Open Source community. But the hearing left the audience, and I suspect the
Their use of the word "Copy Control" is heavy spin-doctoring. It's about closed vs. open standards, about monopolies vs. open markets, control vs. freedom.
> 1. CSS was reverse engineered from Xing's DVD player.
Only parts come from the Xing player.
> The line of argument made by the plaintiff left the audience rather puzzled.
> First, basing the litigation on trade secret seems sub-optimal. Not that a
> different legal argument would be anywhere near compelling, but it appears
> that an argument based on copyright would have been a better approach. In
But the party whose copyright would have been violated is Xing (plus some other unknown manufacturer), not the DVDCCA; and it wouldn't have been possible to use copyright issues to go after sites like http://crypto.gq.nu, which only contain a description of the process, not actual code.
> The first comment was that the DVDCCA attorneys allege that since the /sole/
> purpose of the DVDCCA is to license CSS, a freely downloadable CSS
> implementation would put the DVDCCA out of business. I would be inclined to
Is it just me, or did the DVDCCA not exist when DeCSS was released? I've never heard of them, and when I tried to obtain a CSS license, the information I had was that CSS is licensed by some Japanese company (which by the way didn't bother to respond to my request to license CSS for the purpose of building a Linux DVD player. Mistake.).
> The second, and probably more significant, comment made repeatedly by both
> the plaintiff and the attorneys for the Motion Picture Association in the
> affidavits accompanying the complaint, is that the studios would not have
> agreed to releasing movies on DVD if it hadn't been for the DVD consortium's
> assurance that DVD technology implements an effective copy protection
> scheme. It appears the DVD consortium is experiencing a lot of heat from the
So in other words, the DVD Consortium lied to the movie industry, and are now trying to keep a straight face by legal moves. And they knew about the weaknesses. At the ISSE 1999 security conference in Berlin I've talked to the guy from Intel who designed the key management mechanism for DVD (and the Pentium III RNG btw.), and asked him if he didn't consider the 40 bit keylength a little weak. His answer was (and this was before the DeCSS release, and before public analysis) that there's a 216 attack on the bulk cipher, and that his part of the scheme was one of the strongest parts overall, and that the DVD Consortium knows about this. The 216 attack had been rediscovered later.
> coordinate our actions with those who have been down this road before. It
> probably would be best to contact Robin Gross <robin@eff.org>, the EFF's
> lead attorney for this case, if you are (or intend to) be involved in this
> case in any way.
I can't come to the US at the moment for personal reasons, but I'm available for expertise, phone conferences etc. I think I know quite a bit about CSS, and I know most of the people involved.
Andreas
P.S.: Interestingly enough, the following pages were not on the list of URLs in the legal documents, even though they contain lots of information about CSS and the whole story:
http://www.fefe.de/dvd/
All three contain a German text giving an analysis of the issues, some only relevant to Germany, but most of them for anybody, as well as copies of the relevant postings to the livid mailing list.
Andreas
--
"We should be willing to look at the source code we produce not as the end product of a more interesting process, but as an artifact in its own right. It should look good stuck up on the wall."
-- http://www.ftech.net/~honeyg/progstone/progstone.html