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