Dear Sharon,
This is a very interesting question -- and I am looking forward to
work on it. Please bear with me, or have a look at the quick and
concise answer at the end of this text.
If people were able to create DVD+/-RW with a standard CSS on it
(acceptable to DVD-ROM readers) this would allow 'home users' to make
true DVD clones which become indistinguishable from the orignal DVD to
average DVD players. This is a strong argument for the fact that
content protection system was designed such that this DVD cloning is
not possible.
Let us first look at how CSS works in off-the-shelf (pressed) DVD's:
Each CSS licensee is given a key from a master set of 400 keys stored
on every CSS-encrypted disc. The theory was to allow a license to be
revoked by removing its key from future discs. The CSS decryption
algorithm exchanges keys with the drive unit to generate an encryption
key that is then used to obfuscate the exchange of disc keys and title
keys that are needed to decrypt data from the disc. DVD players have
CSS circuitry that decrypts the data before it's decoded and
displayed, and computer DVD decoder hardware and software must include
a CSS decryption module. All DVD-ROM drives have extra firmware to
exchange authentication and decryption keys with the CSS module in the
computer.
(Excerpt from http://www.dvddemystified.com/dvdfaq.html#1.11 )
The critical question is: Where are those 400 keys stored on the disk?
If you can not store them in the same place on a DVD+/-RW that would
be a simple way to prevent the creation of 'cloned' copies.
There is a dedicated 2048 byte block on the DVD, which holds encrypted
disk keys. The host requests this block from the drive, and the drive
will only deliver it if a prior authentication of the host has taken
place. (see
http://www.extremetech.com/article2/0,1558,1230030,00.asp for the
simplified protocol) Similarly, encrypted title keys are stored in
sector headers. It is important to note that the keys are not part of
the UTF file system payload, but stored as meta-data to it. Even if
you can write title keys (assuming disks are not pre-sectored) you
will also have to write to the hidden disk key area.
Now, depending on the actual media, this area may already have been
pre-written, or be unwritable. In that case. You can not create a CSS
protected disk, since you can not provide an encrypted disk key
(region code seems to be stored in the same place?) for the drive and
player to read.
The relevant media specifications appear to be ECMA-267, -337, and
-338 for DVD-ROM, DVD+RW and DVD-RW respectively. Unfortunately, they
go into physical, optical, and encoding characteristics only, and do
not specifically address our question of the 'hidden sector'.
However, reading some drive specs, the DeCSS source code, and the
cdrom/dvd driver of the linux kernel lead me to believe that the
'hidden sector' is in fact part of the control data zone (section 26.5
in ECMA-267 DVD-ROM). Please understand that this is a speculation on
my part, altough educated speculation. The same control data zone in
DVD-RW (ECMA-338, 26.1.6) is explicitly stated to be embossed, i.e.
not to be writable by the end-user device. Something similar holds
true for DVD+RW (ECMA-337, 17.11). In fact, there is a very explicit
statement to be found there:
] 17.11.3 Content provider information
] These 28 672 bytes shall be set to all (00). Under no circumstance may data
] received from the host be recorded in this field. Circumvention: Recorders and
] recording drives shall be considered as circumvention devices when these are
] produced to record, or can easily be modified to record, in any manner, a
] user-defined number in this field.
So that is very likely it. However, now the writing to this area is
under software control, and not a-priori prevented by the media. And
software can be changed...
Let me summarize my longish answer, going directly to the points of your
question:
Q: Is it technically impossible to apply CSS on DVD-RW?
A: Yes.
The relevant areas on the media are embossed, and can not be recorded on.
Q: Is it technically impossible to apply CSS on DVD+RW?
A: No, just very hard.
The relevant area is in fact recordable, and the drive is supposed to make
sure that the area is always set to 0. That said, one could speculate that
a modification of the drive firmware might enable one to create custom
content in this area.
I hope this answer addresses your question in a sufficient manner. If
you require more information, or are dissatisfied with this answer in
the slightest, please ask for clarification before rating it. I must
say it was interesting research -- I had not looked into this matter
with so much detail before. Time used: Approx. 3.5 hours.
Friendly greetings,
Philip Lynx
Sources have been derived from Google searches based on 'DVD' 'CSS'
'key' 'format' 'stored' in several combinations:
http://cyber.law.harvard.edu/openlaw/DVD/resources/crypto.gq.nu.html
http://www.dvddemystified.com/dvdfaq.html#1.11
http://www.lemuria.org/DeCSS/decss.html
http://www.dvdcca.org/data/css/CSS%20Proc_Spec%20ver%202_2.pdf
http://cyber.law.harvard.edu/openlaw/DVD/dvd-discuss-faq.html (section 4.3)
http://www.manifest-tech.com/media_dvd/dvd_compat.htm
http://www.extremetech.com/article2/0,1558,1230030,00.asp (protcol suggestions)
http://www.disctronics.co.uk/technology/manuf/rep_master.htm
(statement about CSS keys)
http://www.mplayerhq.hu/DOCS/HTML/en/dvd.html (DeCSS behaviour)
http://www-2.cs.cmu.edu/~dst/DeCSS/Kesden/ (lecture on DVD layout, good!)
http://le-hacker.org/dvd.html (pointers to reference books and specs)
http://www.ecma-international.org/publications/files/ecma-st/Ecma-267.pdf
http://www.ecma-international.org/publications/files/ecma-st/ECMA-338.pdf
http://www.ecma-international.org/publications/files/ecma-st/Ecma-337.pdf |
Clarification of Answer by
philip_lynx-ga
on
08 Jun 2004 06:10 PDT
Dear Sharon,
let's see how far I can help you ;-)
] 1. I saw some claim about CSS with another question i had asked that said:
] "CSS requires sectors with 2053 bytes,recordable DVD sectors have 2048 bytes"
] do you have any comment about this ? it is not some certified answer
] but i would like to know where such claim come from ?
If you look in ECMA-267, section 4 (Data Format) and specifically 16.3 CPR_MAI
these are the bytes we are talking about. Basically, there are six bytes in the
header (of which five are used) that are not part of the normal payload of 2048
bytes. If the disk is hard-sectored (e.g. headers have been embossed, and can
not be rewritten) or if the drive writes sector headers by itself and you can
not control what is stored into them, then those bytes are out of your control,
and you can not store the CSS sector keys that would need to be stored there.
However, for DVD+RW I am 100% confident that the DVD image is not hard-sectored,
as almost everything gets written by the drive. Back to the firmware issue.
For DVD-RW, the same holds true (section 17.3). There you can find a statement
that the application can set these six bytes. This would seem to make them fully
user-controlled...
] 2. I took a quik look at the DeCss source and didn't find part that
] deals with reading the 400 keys from the "hidden area" , I think these
] keys are hard codded in the source. correct me if i am wrong .
] if i am right ,how did you know to guess where is that hidden area located ?
] I also want to understand if this area can be read at all by linux ?
The keying protocol of CSS protected drives is a bit complicated. The 409 keys
you are talking about are just one key (the disc key) encrypted in 409 different
player keys. The reasoning was that if a player got hacked and the key stolen,
then it would simply not be used anymore to encrypt disk keys.
So, deCSS does indeed read those 400 keys from the hidden area, and then tries
to decrypt or break one of them. It is the easiest way on how to get vob tracks
to play correctly. However DeCSSPlus and other (newer) implementations don't do
this anymore, they can quickly break the track keysif needed. But this would be
leading too far away from the original question.If you look at css-auth/tstdvd.c
you can find a procedure named GetDiskKey which issues the ioctl you are
looking for. A grep for 'DVD_STRUCT_DISCKEY' might also help.
] 3. theoretically,do you imply that bit-by-bit copy of DVD-ROM to
] DVD+RW (supposing data size is less the 4.7GB) is possible ? that if
] the burner supports writing to the "hidden areas". note that if the
] answer is yes that means that the claim in 1. is false and the answer
] to 2. is that the "hidden area" can be read (maybe by altering the
] firmware of the drive).
Let's be careful here. A DVD player can *always* tell whether the inserted
medium is a read-only DVD, a DVD-R, a DVD-RW, or a DVD+RW. The question is
if the DVD player cares about this information. So a true copy can not be
made. However, in the context of DRM and CSS information, a true copy can
be made, and the reading of all data that you need for that can be done
without altering drive firmware. It is the writing that would be a bit more
tricky, and only possible on a DVD+RW.
I hope this clarification is satisfactory, and certainly look forward
to any further comments or rating :-) that you may want to give me...
Friendly greetings,
Philip Lynx
|
