Tech Insider					   Technology and Trends


			   USENET Archives

[LinuxDVD] CSS Encryption
Johan Addis johanaddis@hotmail.com
Tue, 13 Jul 1999 11:17:23 CDT 

I have reverse engineered the CSS algorithm for the disk/decoder key 
exchange. I am working on (but haven't finished) the frame decoding. But I 
am successfully able to negotiate the keys under Linux and unlock the disk.

The key exchange work by an authentication process working on both the drive 
and the decoder. I.e. the decoder first authenticates the drive and then 
the drive authenticates the decoder for CSS compliance. Once that is done, 
a Bus key is generated whereby the disk key can by safely exchanged. In 
this process, the alogorithm used is an asymetrical DES encryption.

The authentication process starts with the decoder generating a random 
80-bit challenge key. This challenge key is sent to the drive which 
encrypts it into a 40-bit authentication key. The decoder encrypts the 
80-bit key also and if the result matches, the drive is authentic. The 
40-bit key generated will be used later.

The Drive then also generates a random 80-bit challenge key. This challenge 
key is sent to the decoding devices where it is encrypted into a 40-bit 
authentication key and returned to the drive. If the key checks out, the 
decoding device is authentic and the the drive will trust sending sensitive 
information (like the disk key) to the device.

In order to safely send the sensitive information, however, a bus key is 
needed. This is created by concactenating the 2 40-bit keys that were 
generated in the authentication process into a new 80-bit key and then 
enctypting it. This new 40-bit key is the bus key. When the drive wants to 
send sensitive information, it is simply XOR'd with the bus key before it 
goes out onto the bus and the receiving device will XOR it again to get the 
information back.

And that's how it works.

Like I said, I am working on frame decryption which will allow me to view an 
encrypted DVD (assuming I had a good software MPEG-2 player for Linux!). 
The item that is really holding me up is the lack of understanding of the 
MPEG-2 format. I need to know how the stream layer works.

But, if anywone is interested in the code that I have, I could post it as it 
is not very big. I have actually had this working almost since the 
beginning of the year but only just recently found out about the work going 
on with DVD and Linux through this list.

Thank you,
Johan

_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com

[LinuxDVD] CSS Encryption
Derek Fawcus derek@spider.com
Tue, 13 Jul 1999 17:41:23 +0100 

On Tue, Jul 13, 1999 at 11:17:23AM -0500, Johan Addis wrote:
> I have reverse engineered the CSS algorithm for the disk/decoder key 
> exchange. I am working on (but haven't finished) the frame decoding. But I 
> am successfully able to negotiate the keys under Linux and unlock the disk.

[ Algorithm snipped - very interesting ]

> In order to safely send the sensitive information, however, a bus key is 
> needed. This is created by concactenating the 2 40-bit keys that were 
> generated in the authentication process into a new 80-bit key and then 
> enctypting it. This new 40-bit key is the bus key. When the drive wants to 
> send sensitive information, it is simply XOR'd with the bus key before it 
> goes out onto the bus and the receiving device will XOR it again to get the 
> information back.

Do you mean that this 40 bit key is simply concatenated together and XOR'ed
with the data. i.e the XOR pattern repeats every 5 bytes?

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

[LinuxDVD] CSS Encryption
Johan Addis johanaddis@hotmail.com
Tue, 13 Jul 1999 12:04:27 CDT 

> Do you mean that this 40 bit key is simply concatenated together and 
>XOR'ed
>with the data. i.e the XOR pattern repeats every 5 bytes?
>

There are 2 40-bit keys that are generated by both devices when they get 
authenticated. Because the authenticator and the authenticatee go through 
the same process, both the have the 2 40-bit keys. These keys are 
concatenated together to make a 80-bit key and then encrypted to create the 
40-bit bus key. The XOR pattern repeats every 5 bytes with the 40-bit bus 
key.

Notice, however, that the original process to get the bus key began with 
both devices generating random 80-bit keys. The bus key is different each 
authentication cycle. Overall, the encryption algorithm in not very 
complex. The frame decyption doesn't look that way either except that the 
frame decryption uses symetrical DES.

If they didn't wan't CSS cracked, they shouldn't have allowed software 
decoders, IMHO. :)

Johan


_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com

[LinuxDVD] CSS Encryption
Derek Fawcus derek@spider.com
Tue, 13 Jul 1999 18:13:26 +0100 

On Tue, Jul 13, 1999 at 12:04:27PM -0500, Johan Addis wrote:
> > Do you mean that this 40 bit key is simply concatenated together and 
> >XOR'ed
> >with the data. i.e the XOR pattern repeats every 5 bytes?
> >
> 
> There are 2 40-bit keys that are generated by both devices when they get 
> authenticated. Because the authenticator and the authenticatee go through 
> the same process, both the have the 2 40-bit keys. These keys are 
> concatenated together to make a 80-bit key and then encrypted to create the 
> 40-bit bus key.

Got that.

> The XOR pattern repeats every 5 bytes with the 40-bit bus key.

That's what I thought you meant. However...

> Notice, however, that the original process to get the bus key began with 
> both devices generating random 80-bit keys. The bus key is different each 
> authentication cycle. Overall, the encryption algorithm in not very 
> complex.

> The frame decyption doesn't look that way either except that the 
> frame decryption uses symetrical DES.

Now I'm a bit confused again. Some data is XOR'd with this Bus key, and
some is DES encrypted.

I guess this means that the Bus key XOR'ed stream is used to pass the
Disk key (DES key for data?) to the decoder? Then one simply uses that
key with DES to decrypt the data frames. I assume that this is using
DES in the Block as opposed to Stream mode?

Hmm - is the DES encrypted data sent over the bus also XOR'ed with
the Bus Key. A bit pointless to do so, but I could see them adding
that to the spec!

> If they didn't wan't CSS cracked, they shouldn't have allowed software 
> decoders, IMHO. :)

True. All one needs to do now is to parse the DVD data stream (more
reverse engineering), and have support for the filesystem to get a
Linux software DVD player. That and a SMOP :)

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

[LinuxDVD] CSS Encryption
Michael Holzt kju@flummi.de
Tue, 13 Jul 1999 19:43:00 +0200 

On Tue, Jul 13, 1999 at 11:17:23AM -0500, Johan Addis wrote:
> But, if anywone is interested in the code that I have, I could post it as it 
> is not very big. 

I think, that would be the best you can do. Spread the work (and the word), 
and no one will be able to stop it...


-- 
mit freundlichen Grüßen,

Michael Holzt kju@flummi.de
58566 Kierspe, Germany kju@debian.org

[LinuxDVD] CSS Encryption
Johan Addis johanaddis@hotmail.com
Tue, 13 Jul 1999 12:26:24 CDT 

>From: Derek Fawcus <derek@spider.com>
>To: Johan Addis <johanaddis@hotmail.com>
>CC: linuxdvd@linuxdvd.corepower.com
>Subject: Re: [LinuxDVD] CSS Encryption
>Date: Tue, 13 Jul 1999 18:13:26 +0100
>
>On Tue, Jul 13, 1999 at 12:04:27PM -0500, Johan Addis wrote:
> > > Do you mean that this 40 bit key is simply concatenated together and
> > >XOR'ed
> > >with the data. i.e the XOR pattern repeats every 5 bytes?
> > >
> >
> > There are 2 40-bit keys that are generated by both devices when they get
> > authenticated. Because the authenticator and the authenticatee go 
>through
> > the same process, both the have the 2 40-bit keys. These keys are
> > concatenated together to make a 80-bit key and then encrypted to create 
>the
> > 40-bit bus key.
>
> Got that.
>
> > The XOR pattern repeats every 5 bytes with the 40-bit bus key.
>
> That's what I thought you meant. However...
>
> > Notice, however, that the original process to get the bus key began with
> > both devices generating random 80-bit keys. The bus key is different 
>each
> > authentication cycle. Overall, the encryption algorithm in not very
> > complex.
>
> > The frame decyption doesn't look that way either except that the
> > frame decryption uses symetrical DES.
>
> Now I'm a bit confused again. Some data is XOR'd with this Bus key, 
>and
>some is DES encrypted.
>
> I guess this means that the Bus key XOR'ed stream is used to pass the
>Disk key (DES key for data?) to the decoder? Then one simply uses that
>key with DES to decrypt the data frames. I assume that this is using
>DES in the Block as opposed to Stream mode?
>
> Hmm - is the DES encrypted data sent over the bus also XOR'ed with
>the Bus Key. A bit pointless to do so, but I could see them adding
>that to the spec!
>

You assumed mostly correct. The bus key with all it's simple XOR'ing is 
only done to send disk info such as the disk key. After that the disk key 
is used to decrypt the frames and that uses DES. I'm still working on that 
part of it, though, but it does look like block DES which I thought was odd.



_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com

[LinuxDVD] CSS Encryption
Derek Fawcus derek@spider.com
Tue, 13 Jul 1999 18:30:49 +0100 

On Tue, Jul 13, 1999 at 12:26:24PM -0500, Johan Addis wrote:
> 
> Derek Fawcus wrote:
> > I guess this means that the Bus key XOR'ed stream is used to pass the
> >Disk key (DES key for data?) to the decoder? Then one simply uses that
> >key with DES to decrypt the data frames. I assume that this is using
> >DES in the Block as opposed to Stream mode?
> >
> 
> You assumed mostly correct. The bus key with all it's simple XOR'ing is 
> only done to send disk info such as the disk key. After that the disk key 
> is used to decrypt the frames and that uses DES. I'm still working on that 
> part of it, though, but it does look like block DES which I thought was odd.

The reason I assumed Block mode is simply that one want's to have random
access, if one was using Stream mode this would be quite slow!

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

[LinuxDVD] CSS Encryption
Johan Addis johanaddis@hotmail.com
Tue, 13 Jul 1999 12:35:41 CDT 

>From: Aaron Holtzman <aholtzma@ess4.engr.UVic.CA>
>To: Johan Addis <johanaddis@hotmail.com>
>Subject: Re: [LinuxDVD] CSS Encryption
>Date: Tue, 13 Jul 1999 10:13:26 -0700
>
>Cool. Can you send me the code? I had a link to the ISO-13818 specs
>online somewhere, but I can't find it anymore. I think it was posted to
>the list though, so check the archives. Let me know if you can't
>find it and I'll see if I can dig up at least the bitstream format
>for you.
>
>What tools are you using to reverse engineer the (presumably) Windows
>CSS implementation?
>
>cheers,
>aaron
>

I will email it tonight when I get home or I'll bring it in to work tomorrow 
and email it then. I want it to be distributed so that everyone can make 
use of it to further the work for Linux and DVD.

Tools? I used IDA (interactive disassembler) and SoftICE. It appears that 
the CSS license requires that software developers make it difficult for 
people to reverse engineer. The .dll that had the encryption algorithms in 
it was itself encrypted. It wasn't too hard to crack that, though. Then I 
could just yank out the useful encryption algorithms.

Johan


_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com

[LinuxDVD] CSS Encryption
Paul Volcko pvolcko@concentric.net
Tue, 13 Jul 1999 14:26:26 -0400 

On 13 Jul 99, at 12:04, Johan Addis wrote:

> > Do you mean that this 40 bit key is simply concatenated together and 
> >XOR'ed
> >with the data. i.e the XOR pattern repeats every 5 bytes?
> >
> 
> There are 2 40-bit keys that are generated by both devices when they get 
> authenticated. Because the authenticator and the authenticatee go through 
> the same process, both the have the 2 40-bit keys. These keys are 
> concatenated together to make a 80-bit key and then encrypted to create the 
> 40-bit bus key. The XOR pattern repeats every 5 bytes with the 40-bit bus 
> key.

> Notice, however, that the original process to get the bus key began with 
> both devices generating random 80-bit keys. The bus key is different each 
> authentication cycle. Overall, the encryption algorithm in not very 
> complex. The frame decyption doesn't look that way either except that the 
> frame decryption uses symetrical DES.

How often does this authentication series happen? Once a secure 
session is established does the process get run again only once a 
new disc is put in or once a time limit has expired (5 mintues? 5 
seconds?) This method of establishing a secure channel is not 
unsimilar to that used in hardware network encryptors that are 
used to make secure IP tunnels over public networks. The key to 
the security they provide though is that if they use a weak 
algorithm (which many do) such as 40 bit DES, then they make up 
for it by establishing new session keys from anywhere between 1 
second to 1 day (usually definable by the net admin). If CSS is 
designed to be secure in the least I would expect that they would 
have built in that kind of session (bus) key recycling.

> If they didn't wan't CSS cracked, they shouldn't have allowed software 
> decoders, IMHO. :)

Well the algorithm is weak and the keylength is apparently very 
weak as well. Software or no software, they didn't put too much 
forthought into the strength of the encryption algorithm used (40bit 
DES). It remains to be seen if their key refreshing makes up for it 
though. If the key refresh is implemented and done often, then this 
will be very tough to crack. I say this because of my previous 
statements about the use of similar channel negotiation and 
encryption techniques in VPN encryptors. These encryptors are 
used by major corporations and even the US and Canadian 
governments and military for up to confidential/classified (not top 
secret) data. They remain unchallenged in maintaining data 
security. 

Bottom line, hope that they do not recycle session key. It makes 
this a lot easier to break (at least a session key would be able to 
be broken allowing some kind of bus sniffing and dumping the disc 
key and encrypted disc data to file for later decrypting.

This of course gets us no where for actually playing a disc in 
realtime with software decoding, unless the publc key algorithm 
used in the authentication and session key establishment is known 
(80 bits is pretty whimpy for an asymmetric algorithm). Then it 
may become possible to actually fake being a device. And since 
we can break the session key previously, we will be able to figure 
out what the two 40 bit replies had done to them to arrive at the 40 
bit session symmetric key.

DVD and cryptography all in one. I love this job. :)

Paul Volcko
LSDVD Project

[LinuxDVD] CSS Encryption
Andreas Bogk andreas@andreas.org
13 Jul 1999 15:54:15 -0400 

"Paul Volcko" <pvolcko@concentric.net> writes:

> How often does this authentication series happen? Once a secure 

Once per disk.

> This of course gets us no where for actually playing a disc in 
> realtime with software decoding, unless the publc key algorithm 
> used in the authentication and session key establishment is known 
> (80 bits is pretty whimpy for an asymmetric algorithm). Then it 

It's, as far as I can tell from the descriptions, a symmetrical scheme
based on a shared secret. Which is inside the software decoder, and
thus reverse-engineerable. This has apparently happened.

Or, in simpler terms, all the DVD drives in the world use the same
encryption key, and this key is in every software decoder, and all the
DVD copy protection depends on that key.

I can't wait to see the actual code ;).

> DVD and cryptography all in one. I love this job. :)

Let me say I am... pleased.

Andreas

-- 
"We show that all proposed quantum bit commitment schemes are insecure because
the sender, Alice, can almost always cheat successfully by using an
Einstein-Podolsky-Rosen type of attack and delaying her measurement until she
opens her commitment." ( http://xxx.lanl.gov/abs/quant-ph/9603004 )

[LinuxDVD] CSS Encryption
Paul Volcko pvolcko@concentric.net
Tue, 13 Jul 1999 18:19:10 -0400 

> > How often does this authentication series happen? Once a secure 
> Once per disk.

This is good for us.

> It's, as far as I can tell from the descriptions, a symmetrical scheme
> based on a shared secret. Which is inside the software decoder, and
> thus reverse-engineerable. This has apparently happened.

> Or, in simpler terms, all the DVD drives in the world use the same
> encryption key, and this key is in every software decoder, and all the
> DVD copy protection depends on that key.

This is not how it works, I think. If it is I can't believe the CSS 
developers bet the bank on it. Here's my take on this.

Phase 1 - shared secret negotiation
Device 1 sends request to device 2 in the form of it's randomly 
generated public key (80bits, very small, easy calcs). Device 2 
replies by encrypting a randomly generated 40 bit number (which is 
remembered as SKPart1) and sends it back to device 1. Device 1 
decrypts the 40 bit SKpart1 and remebers it. Device 2 then does 
the same with device 1, except SKPart2 is traded. 

Phase 2 - Secret Key composition
Both devices now have two 40bit keys. And the DVD drive (device 
2 for the sake of argument) is probably unlocked (meaning you can 
read encrypted info from the disc, which normally you can't). 
Somehow these two keys are combined to form a secret key that 
device 2 uses to transmit the disc key with and device 1 uses to 
decrypt and store internally for the length of the disc being in the 
drive. The mechanism that these two keys are combined has not 
been said. I'm guessing it is a simple XOR. I don't know though.

Phase 3 - Disc Key transmission
Device 1 requests the disc key, device 2 encrypts it with a DES or 
modified DES algorithm with a key as made in phase 2. 

That is it. The drive then delivers all data on the disc in it's written 
form. It is up to device 1 to do the decrypting if needed. I sayif 
needed because it is likely that the ifo files are not encrypted (as 
they never get passed through the decoding device). Only VOBs 
are encrypted. 

No where in that is there a "master key" that is common to all 
drives and cards. If there were it would constitute a major lack of 
security and robustness. While I don't doubt for a second that 
CSS was an illconcieved method, I can't believe that they would 
make the algorithm that weak.

> I can't wait to see the actual code ;).

Same here.

[LinuxDVD] CSS Encryption
Jason Castonguay castongj@wam.umd.edu
Thu, 15 Jul 1999 00:38:01 -0400 (EDT) 

I go on vacation and miss such a breakthrough! I would love to see the
code. How does it compare with the code on livid? (or is it the same
thing, I havn't looked yet) Now I am pressed to finish up adding mpeg2
video to smpeg. CSS, AC-3, and mpeg2 is a good portion completed.

Now for a question, I notice that some dvds only have video_ts, but some
have audio_ts as well. What is the deal with this? Audio_ts doesn't seem
to have anything in it, so should I not worry about it?

--
Jason Castonguay		I teleported home last night
castongj@bigfoot.com		With Sid and Ron and Meg
				Ron stole Meggie's heart away
				And I got Sidney's leg

[LinuxDVD] CSS Encryption
Matthew R. Pavlovich mpav@purdue.edu
Wed, 14 Jul 1999 23:52:28 -0500 (EST) 

> I go on vacation and miss such a breakthrough! I would love to see the
> code. How does it compare with the code on livid? (or is it the same
> thing, I havn't looked yet) Now I am pressed to finish up adding mpeg2
> video to smpeg. CSS, AC-3, and mpeg2 is a good portion completed.

The CSS code is the same on LiViD. We are looking to merge projects. OPN
has a lot of resources available, and there is already a lot of good
content on this list, so we are looking into options. 

Matt

			   USENET Archives


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/