Tech Insider					     Technology and Trends


	      Linux Video & DVD Project Mailing List Archives

From derek@spider.com Mon, 4 Oct 1999 16:58:08 +0100
Date: Mon, 4 Oct 1999 16:58:08 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Re: CSS

[ CC'ed back to livid list ]

On Mon, Oct 04, 1999 at 04:43:39PM +0100, Dr. David Gilbert wrote:
> On Mon, 4 Oct 1999, Derek Fawcus wrote:
> 
> > It's still a hard problem 408 key slots (how many have real keys), each
> > of 40 bits (2 ** 40 combinations) that have to be run through the decrytion
> > algo to get the result. The only advantage one has is a known plaintext
> > result.
> 
> Well I'm not a cryptologist, but don't you end up actualyl being able to
> simplify the cracking process because you have potentially multiple
> results which must generate the same result?

Not sure. Possibly.

> Also can you take advantage of knowing the format of the recovered stream
> (like wanting to find an MPEG start code in there?)

It's simpler than that. The CSS decode algo is basically:

D = 2048 byte disk key (array of 409 40 bit texts)

P = 40 bit player specific secret key
d = 40 bit text from disk key
T = 40 bit title key

we have a function F, such that:

X' = F(X,K) decrypts the text X using key K to give X'

D (thus d) and T come from the CSS authentication process and are
fixed for given disk and title.

The process is basically:

d' = F1(d,P)

T' = F2(T,d')

S' = F3(S,T')

Where F2 is similar to F1, and F3 is the stream decoding of the encryted
2048 byte sector S.

Since for a given title T' (and thus d') is fixed, all we have to do is
the first stage decryption of the private key slots to find the fixed text
d' i.e.

for (each slot)
pick d from slot
for (P = 0; P < 2 **40; ++P)
if (F1(d, P) == d')
print(got key P)

However even that is a lot. Now can it be speeded up? I don't know.
Now if the above is done and all keys found - what sort of effect do you
think it'll have on the DVD industry?

DF
-- 
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034

From derek@spider.com Mon, 4 Oct 1999 17:48:26 +0100
Date: Mon, 4 Oct 1999 17:48:26 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Re: CSS

[ CC'ed back to list ]

On Mon, Oct 04, 1999 at 11:59:27AM -0400, dvd@bdemskysgi.mit.edu wrote:
> What we'd really want to do is be able to encrypt data. Then we
> cycle through possible keys, use them to encrypt d'. Once we got
> encrypted(d') we'd compare it to the 400 keys. We'd only have to go
> through a fraction of the keyspace to find a key. It is the same way
> those password crack utils work...

I don't think that'll work. Remember that despite a small key size,
this is using proper encryption.

The 409 values in the disk key are actually encrypted texts which are
decrypted with the secret player key to generate a known plain text.

What needs to be done is to recover one of the player secret keys.

In general key recovery is a harder problem then message recovery. Thus
the reason they picked that method.

Compare to the UNIX password method. It uses the login password as
the key for encrypting a (salted) known plain text. Reversing this to
recover the _key_ is a hard problem, thus people guess the key,
encrypt the data and then check the result.

> My personal opinion [take it at a grain of salt] is that dvd has
> hit critical mass [player prices are dropping fast, etc]... I don't think
> it is politically feasible to drop the PC market. [However, they might be
> able to get away with including patches on the DVD to switch encryption
> standards.]

I don't know, but sepeculated that they could kill PC based decoders,
while leaving standalone player boxes functional. Does anyone know if
this is really the case?

DF
-- 
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034

From kju@flummi.de Mon, 4 Oct 1999 18:57:24 +0200
Date: Mon, 4 Oct 1999 18:57:24 +0200
From: Michael Holzt kju@flummi.de
Subject: [Livid-dev] Re: CSS

On Mon, Oct 04, 1999 at 05:48:26PM +0100, Derek Fawcus wrote:
> I don't think that'll work. Remember that despite a small key size,
> this is using proper encryption.

I would like to see the algorithm myself, please. You said you would 
release it today, did you already? I think the algorithm would be
an interesting topic for these cryptography and cryptoanalysis guys.
If we will send them the algorithm i suggest they will be able to
make a quick check if their are any obvious flaws and make a 
reasonable guess about the possibility to brute force or break
it to find out different / all decoder keys.

From derek@spider.com Mon, 4 Oct 1999 18:02:40 +0100
Date: Mon, 4 Oct 1999 18:02:40 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Re: CSS

On Mon, Oct 04, 1999 at 06:57:24PM +0200, Michael Holzt wrote:
> On Mon, Oct 04, 1999 at 05:48:26PM +0100, Derek Fawcus wrote:
> > I don't think that'll work. Remember that despite a small key size,
> > this is using proper encryption.
> 
> I would like to see the algorithm myself, please. You said you would 
> release it today, did you already?

Not yet - it'll be a few hours. I've got to go home, eat, grab the
code and bring it back.

> I think the algorithm would be an interesting topic for these
> cryptography and cryptoanalysis guys.

I remember hearing some people say it's already been analysed - wasn't
there a comment from B.Schreiner (sp?) about it not being too good?

> If we will send them the algorithm i suggest they will be able to
> make a quick check if their are any obvious flaws and make a 
> reasonable guess about the possibility to brute force or break
> it to find out different / all decoder keys.

This is the one thing that still worries me - that a crack may kill
things off. Oh well - we'll see.

DF
-- 
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034

From aholtzma@ess4.engr.UVic.CA Mon, 4 Oct 1999 10:08:32 -0700
Date: Mon, 4 Oct 1999 10:08:32 -0700
From: Aaron Holtzman aholtzma@ess4.engr.UVic.CA
Subject: [Livid-dev] Re: CSS

The CSS algorithm has already been cryptanalyzed and broken. The
results just weren't published. There was a link to an offhand
remark made by Bruce Schneier regarding this posted to the list 
some time ago. It's now up to the airchair cryptanalysts to find
the hole. The first release of a software based CSS implementation
spelled doom for concealing the flaws of the algorithm.

cheers,
aaron

From kju@flummi.de Mon, 4 Oct 1999 19:13:33 +0200
Date: Mon, 4 Oct 1999 19:13:33 +0200
From: Michael Holzt kju@flummi.de
Subject: [Livid-dev] Re: CSS

>   This is the one thing that still worries me - that a crack may kill
> things off.  Oh well - we'll see.

If they won't dump the whole DVD system, i see no risk. Macrovision
(video tape copy protection) was cracked too, but Video tapes are
still manufactured. 

Their whole system seems to be deniced well, but it won't stop
the professional copiers. They simply won't reveal which key
was cracked and therefore this key won't be disabled in future DVDs.

German c't magazine had following interesting snippet about a 
propable full crack of CSS. Translation is by me, so excuse any
errors.

  Manufacturers and the movie industry are already planning the
  next step in dvd copy protection schemes. They are thinking
  about adding a so called watermark into the video data stream.
  The water mark could contain information about the producer
  as well as additional disc recognizing data. The way of art is
  to add the watermark into the picture in a way that will not
  affect the picture quality but cannot be removed. Additional
  the dvd could get a hardware checkable mark, which will not
  be writable by dvd writers which may appear on the market 
  somewhere in the future. A new player would need to check
  for this mark and deny playing if it is missing. A possible
  mark would be a signal which is modulated on the track, eg.
  a track which is not straight circle. As recordable media
  will very likely have to have premanufactured tracks as the 
  CD-R this mark could not be copied.


This sounds good. I just want to view the video, not to copy
it. So the should add this water mark or track mark as soon
as possible and dump CSS completely.

From kju@flummi.de Mon, 4 Oct 1999 19:17:23 +0200
Date: Mon, 4 Oct 1999 19:17:23 +0200
From: Michael Holzt kju@flummi.de
Subject: [Livid-dev] Re: CSS

On Mon, Oct 04, 1999 at 07:13:33PM +0200, Michael Holzt wrote:
> Their whole system seems to be deniced well, 

should read "designed".

From derek@spider.com Mon, 4 Oct 1999 18:41:26 +0100
Date: Mon, 4 Oct 1999 18:41:26 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Re: CSS

On Mon, Oct 04, 1999 at 07:13:33PM +0200, Michael Holzt wrote:
> German c't magazine had following interesting snippet about a 
> propable full crack of CSS. Translation is by me, so excuse any
> errors.

[ snip of translation of c't text ]

> This sounds good. I just want to view the video, not to copy
> it. So the should add this water mark or track mark as soon
> as possible and dump CSS completely.

Good - as long as it allows us to view the picture, I'm all for
it. I want to buy and view DVD's not copy them. However the mentioned
method does not seem to deal with pirated copies on DVD-R (when it arrives)
being played by PC based decoders. Or have I missed something?

DF
-- 
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034

From kju@flummi.de Mon, 4 Oct 1999 19:45:15 +0200
Date: Mon, 4 Oct 1999 19:45:15 +0200
From: Michael Holzt kju@flummi.de
Subject: [Livid-dev] Re: CSS

On Mon, Oct 04, 1999 at 06:41:26PM +0100, Derek Fawcus wrote:
> However the mentioned method does not seem to deal with pirated 
> copies on DVD-R (when it arrives) being played by PC based decoders. 
> Or have I missed something?

You did. Reread the sentences about the modulated track.

Genuine DVDs would have a track which is physically in a special
shape (not fully circle, but maybe in sine-waves). As long as the
track is inside the physical limits, this may be done.

DVD-R will most likely have to have a premastered track, like
CD-Recordable has today. This premastered track would simple not
be in this special shape. So it could be used to record data and
even the movies, but the player would miss the shape and won't 
play it.

Of course old PC-based equipment would still be able to play this,
as well as old consumer players, but any new equipment could be
forced by the DVD forum to include this. This is basically the
same way they did with Macrovision on video tapes. Some old VCRs
weren't affected by Macrovision so JVC as the patent holder of VHS
forced all manufacturers to keep their AGC so, that it will respond
to Macrovision.

From derek@spider.com Mon, 4 Oct 1999 19:01:18 +0100
Date: Mon, 4 Oct 1999 19:01:18 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Re: CSS

On Mon, Oct 04, 1999 at 07:45:15PM +0200, Michael Holzt wrote:
> On Mon, Oct 04, 1999 at 06:41:26PM +0100, Derek Fawcus wrote:
> > However the mentioned method does not seem to deal with pirated 
> > copies on DVD-R (when it arrives) being played by PC based decoders. 
> > Or have I missed something?
> 
> You did. Reread the sentences about the modulated track.

You missed what I meant. Assume that someone (with any PC-DVD drive)
copies the data. This is then recorded (unencrypted) on a DVD-R. From
the point of view of a PC reading this - it's just data. So no method
will stop it reading - otherwise DVD-R for data will be killed.

Now any PC (with any DVD-ROM drive, old or new) will read the data
and decode it.

How is that problem dealt with.

DF
-- 
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034

From pvolcko@concentric.net Mon, 4 Oct 1999 15:07:45 -0400 (EDT)
Date: Mon, 4 Oct 1999 15:07:45 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Re: CSS

> > On Mon, Oct 04, 1999 at 06:41:26PM +0100, Derek Fawcus wrote:
> > > However the mentioned method does not seem to deal with pirated 
> > > copies on DVD-R (when it arrives) being played by PC based decoders. 
> > > Or have I missed something?
> > 
> > You did. Reread the sentences about the modulated track.
> 
> You missed what I meant. Assume that someone (with any PC-DVD drive)
> copies the data. This is then recorded (unencrypted) on a DVD-R. From
> the point of view of a PC reading this - it's just data. So no method
> will stop it reading - otherwise DVD-R for data will be killed.
> 
> Now any PC (with any DVD-ROM drive, old or new) will read the data
> and decode it.
> 
> How is that problem dealt with.

Honors system. DVD Forum says, please don't produce a player that will play
discs without the watermark or wiggly tracks. If they give out the
watermarking detection scheme freely then I see no problem with this. If they
charge you for it then we will have the same situation as we have now with a
rouge group of people :) thwarting the efforts of the oppressive
authoritative regime hell bent on making money under traditional industry
structures.

Because DVD is a media readable on PCs the movie industry is in trouble with
this format. With VHS/BETA and macrovision there was no VHS reader for PCs
(at least not without paying a whole pile of money). They could control the
copying and playing because there was only dedicated hardware playback
available. With DVD, however, they have the problem of low cost hardware for
playback being available. It's an uncontrolable situation. They can only
make it aggravating to crack or take the smart route and make the technologies
for players freely available and make their money on increased sales of
titles.

But since the people who control the player technology don't make money on
media sold (at least no where near as much as on players directly) they will
be hard pressed to make this leap of logic. Even though they can still charge
for official verifications (which will be sought after in the recording sector
as well as the theatrical/professional playback sector) and tech support to
those creating players and authoring tools. The companies involved here have
always considered services such as these as being secondary business
necessities to the primary goal of selling hardware and IP/technology rights. 

It's all a big mess. They will deal with it however they want, but we can be
relatively sure that they will not do anything to obsolete the established
base of standalone players. That being the case there isn't really a reason
to go ahead with LIVID and all of it's sub-projects, including opening up CSS
decryption for them. 

As far as publishing player keys goes... perhaps the better solution would be
to create a program that would attempt to crack a random key on a disc in the
drive. The key found is used by that paticular installation. In this way the
player that ends up being created doesn't actually "ship" with a key in it and
it becomes impossible for the powers in control of the keys to simply get rid
of one key in newly produced discs...

Heres a quesiton I haven't seen brought up yet... the algorithm depends on
each player having a built in key as well as a known plaintext. This plain
text is encrypted and put into the disc key along with 408 other texts for
other players. Is the encrypted plaintext the same across all keys/players or
is there a similar one-to-one player to plaintext relationship as is found
with the player keys?

Paul Volcko
LSDVD

From dvd@bdemskysgi.mit.edu Mon, 4 Oct 1999 14:53:08 -0400 (EDT)
Date: Mon, 4 Oct 1999 14:53:08 -0400 (EDT)
From: dvd@bdemskysgi.mit.edu dvd@bdemskysgi.mit.edu
Subject: [Livid-dev] Re: CSS

Here is one thing I just don't get about the entire CSS decryption
scheme. Why have T? Why not just use d'? Are we sure that T is
invariant across players? [If it wasn't, that would make brute forcing
all of the keys 409 times harder than brute forcing one key instead of
just a small constant factor harder.]

Any thoughts?


> It's simpler than that. The CSS decode algo is basically:
> 
> D = 2048 byte disk key (array of 409 40 bit texts)
> 
> P = 40 bit player specific secret key
> d = 40 bit text from disk key
> T = 40 bit title key
> 
> we have a function F, such that:
> 
> X' = F(X,K) decrypts the text X using key K to give X'
> 
> D (thus d) and T come from the CSS authentication process and are
> fixed for given disk and title.
> 
> The process is basically:
> 
> d' = F1(d,P)
> 
> T' = F2(T,d')
> 
> S' = F3(S,T')
> 
> Where F2 is similar to F1, and F3 is the stream decoding of the encryted
> 2048 byte sector S.
> 
> Since for a given title T' (and thus d') is fixed, all we have to do is
> the first stage decryption of the private key slots to find the fixed text
> d' i.e.
> 
> for (each slot)
> pick d from slot
> for (P = 0; P < 2 **40; ++P)
> if (F1(d, P) == d')
> print(got key P)
> 
> However even that is a lot. Now can it be speeded up? I don't know.
> Now if the above is done and all keys found - what sort of effect do you
> think it'll have on the DVD industry?
> 
> DF
> -- 
> Derek Fawcus derek@spider.com
> Spider Software Ltd. +44 (0) 131 475 7034
> 
> 
> _______________________________________________
> Livid-dev maillist - Livid-dev@livid.on.openprojects.net
> http://livid.on.openprojects.net/mailman/listinfo/livid-dev
>

From andreas@andreas.org 04 Oct 1999 22:21:27 +0000
Date: 04 Oct 1999 22:21:27 +0000
From: Andreas Bogk andreas@andreas.org
Subject: [Livid-dev] Re: CSS

<dvd@bdemskysgi.mit.edu> writes:

> Here is one thing I just don't get about the entire CSS decryption
> scheme. Why have T? Why not just use d'? Are we sure that T is

So that you can't snoop on the key. Basically T' varies from disk to
disk, and d' is the key used to encrypt T' to send it to the
player. Otherwise you could just record d' on it's way to the decoder
and use a replay attack.

> invariant across players? [If it wasn't, that would make brute forcing
> all of the keys 409 times harder than brute forcing one key instead of
> just a small constant factor harder.]

No, T even varies for multiple tries on the same player. But T' is
constant across players, it's the plain encryption key.

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

From derek@spider.com Tue, 5 Oct 1999 15:16:29 +0100
Date: Tue, 5 Oct 1999 15:16:29 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Re: CSS

On Mon, Oct 04, 1999 at 10:21:27PM +0000, Andreas Bogk wrote:
> 
> No, T even varies for multiple tries on the same player. But T' is
> constant across players, it's the plain encryption key.

No both T and T' are constant for a given disk. Otherwise we couldn't
decode the data. I am assuming here that all data has had the bus key
obfuscation removed.

DF
-- 
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034

From andreas@andreas.org 05 Oct 1999 17:39:26 +0000
Date: 05 Oct 1999 17:39:26 +0000
From: Andreas Bogk andreas@andreas.org
Subject: [Livid-dev] Re: CSS

Derek Fawcus <derek@spider.com> writes:

> > No, T even varies for multiple tries on the same player. But T' is
> > constant across players, it's the plain encryption key.
> No both T and T' are constant for a given disk. Otherwise we couldn't
> decode the data. I am assuming here that all data has had the bus key
> obfuscation removed.

I'm confused. I though that T was the title key obfuscated by the bus
key, which is called d' in that scheme, no?

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

From derek@spider.com Tue, 5 Oct 1999 17:37:14 +0100
Date: Tue, 5 Oct 1999 17:37:14 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Re: CSS

On Tue, Oct 05, 1999 at 05:39:26PM +0000, Andreas Bogk wrote:
> Derek Fawcus <derek@spider.com> writes:
> 
> > > No, T even varies for multiple tries on the same player. But T' is
> > > constant across players, it's the plain encryption key.
> > No both T and T' are constant for a given disk. Otherwise we couldn't
> > decode the data. I am assuming here that all data has had the bus key
> > obfuscation removed.
> 
> I'm confused. I though that T was the title key obfuscated by the bus
> key, which is called d' in that scheme, no?

No. I'm assuming all bus key obfuscation has been removed. The
description was for just the CSS stream bits.

When one reads the disk key and title key from the drive, they are
obfuscated by the bus key. Once this obfuscation is removed we are
left with:

D = unobfuscated 2048 byte "disk key"
T = unobfuscated 5 byte "title key"

Also:

P = secret 5 byte player key

To apply the stream decoding we pick 5 bytes from D (call these d) and
run them through the functions I described. The thing to remember is
that the actual title key used to decrypt the VOB stream has been encrypted
twice.

d' = F1(d,P) This yields a player independant "encrypted title key"

T' = F2(d',T) This yields the actual VOB decryption key

DF
-- 
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/