[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