t byfield on Mon, 3 Jan 2000 20:33:06 +0100 (CET)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

<nettime> (fwd) CSS/DeCSS/DVD/DVDCCA: closed systems versus open systems


----- Forwarded 

To: Lucky Green <[email protected]>
Cc: "cypherpunks@Algebra. COM" <[email protected]>,
	"Cryptography@C2. Net" <[email protected]>,
	John Gilmore <[email protected]>
Subject: Re: DeCSS Court Hearing Report
From: Andreas Bogk <[email protected]>
Date: 01 Jan 2000 22:37:18 -0500

Lucky Green <[email protected]> writes:

> 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 we
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 2^16 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 2^16 attack had been rediscovered
later.

> o coordinate our actions with those who have been down this road before. It
> probably would be best to contact Robin Gross <[email protected]>, 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/
http://www.ccc.de/tvcrypt/dvd/
http://dvd.flatline.de/

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


----- Backwarded

#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: [email protected] and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: [email protected]