Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
15th February 2007, 18:03 | #261 | Link | |
Registered User
Join Date: Dec 2006
Posts: 202
|
It's about this:
Quote:
2) Title keys are encrypted with the Volume Unique Key. 3) There is only 1 copy of the titlekeyfile in the backup folder. He has no clue about the processing key ... just like me in the beginning to be honest ! Last edited by evdberg; 15th February 2007 at 18:10. |
|
15th February 2007, 19:01 | #262 | Link |
Registered User
Join Date: Sep 2006
Posts: 390
|
I can confirm that it is possible for “them” to make Processing Keys (found in the future) far less valuable.
This is because they can use different but equivalent Explicit Subset-Difference Records. In order to decrypt discs with different of these Records you really need Device Keys (because they can choose different Processing Keys). But since that wasn’t required (AACS screwed up here big time) only the Processing Key was released (which doesn’t identify the software player it came from btw). Whether they will actually do this “shuffling” inside this Record in the near future (do they even understand how this works? I started to doubt when I saw this record for the first time) is not clear. Maybe they have some (stupid) policy or their program to create these records isn’t up to this yet. I don’t know. We’ll see . Not that any of this really/fundamentally matters though… Last edited by arnezami; 15th February 2007 at 19:29. |
15th February 2007, 19:48 | #263 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
@evdberg: Thanks for the comments. |
|
16th February 2007, 01:26 | #264 | Link |
Registered User
Join Date: Jan 2007
Location: Tel-Aviv, Israel
Posts: 185
|
Some more Volume IDs
The following look totally random to my untrained eye:
Dates are MM/DD/YYYY Code:
Title: Rambo I Studio: Studio Canal Volume ID: 40 00 e0 d8 46 1e cd ff 74 50 92 11 0c dc 00 00 Timestamp: 10/4/2006 12:05 AM <= Must have been a late night render Title: Rambo II Studio: Studio Canal Volume ID: 40 00 18 54 3b d6 24 9b 59 f3 31 1e 49 ee 00 00 Timestamp: 10/3/2006 11:38 pm Title: Rambo III Studio: Studio Canal Volume ID: 40 00 95 ad 18 64 b0 4a 47 9a d2 11 b7 df 00 00 Timestamp: 10/4/2006 10:53 pm Personal Comment:Ordering all three Rambo HD-DVDs from Amazon.fr set me back ~160 USD (including shipping) and showed up in my neck of North American woods in 4 days. Studio Canal also released Basic Instinct and Total Recall on HD-DVD, so I urge anyone who liked old Sly to get a legal HD-DVD version :-) Last edited by awhitehead; 16th February 2007 at 01:27. Reason: s/copy/version/ to reduce ambiguity |
16th February 2007, 13:26 | #265 | Link | |
Registered User
Join Date: Oct 2002
Posts: 65
|
Quote:
All I see is a place for title hash and vuk. |
|
16th February 2007, 14:49 | #266 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
This is a Device Key tree: Code:
1 / \ / \ / \ / \ / \ / \ / \ / \ / \ 2 3 / \ / \ / \ / \ / \ / \ / \ / \ 4 5 6 7 / \ / \ / \ / \ / \ / \ / \ / \ 8 9 10 11 12 13 14 15 BTW, AACS specification clearly states that any lower key is a one-way result of any higher key. If an attacker gets the root key, he can get any Device Key and any Processing Key. I suppose it is far hard to get that root key, but an equivalent effect should be to get the 2 keys at level 1 (keys 2 and 3), or the 4 keys at level 2, and so on. Supposedly, any set of Device Keys includes one of the 2 keys at level 1. |
|
16th February 2007, 15:08 | #267 | Link |
Registered User
Join Date: Jan 2007
Posts: 274
|
I realize that I've been making some assumptions that I'm now uncertain of. Has anyone been able to calculate a title key/volume unique key from the Processing Key? If so, is it necessary to use the sniffed volume ID or is there enough info in the processing key to read and decrypt everything on the disc that is required?
It seems reasonably certain that all device keys for HD and BD lead to the same processing key, but is there some other required encrypted component from the disc that still needs the device key to decrypt? Perhaps I'll have time this weekend to read the specs again and answer these questions for myself. Basically, my Qs are: 1) Does this thread conclude that the processing key is currently equivalent to a device key allowing all discs to be fully decrypted? This would be the most powerful. (Originally, I wasn't sure, then I thought this was the case, now I'm not certain again.) 2) Or do we still need other encrypted content from the disc that is disc dependent that must be USB sniffed in order to get to the title key? (I really need to go back and look at the volume ID and C data stuff) This would make the processing key and the USB sniff procedure an alternative to the mem dump procedure, but require a different type of key DB. 3) or is it not yet possible to calculate the title key/volume unique key from the processing key and sniffed data? |
16th February 2007, 15:19 | #268 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
|
|
16th February 2007, 15:51 | #269 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
You had exactly the same question I had, and like me, you confused the leaf/node keys in the tree with the device keys and simplified the system way too much. A device key is not a leaf or node key. The tree shown in the AACS system is a tree of node and leaf keys, not a tree of device keys, like you drew. In fact, there is a master tree that starts at the AACSLA root and ends at all devices, but there are other subtrees, that start one down from the root, and two down from the root, etc. These are not subtrees within the master tree, they are separate subtrees that are parallel to the master subtree, with another set of leaf keys and node keys. Device keys allow you to get the answer when the data is encrypted with anyone elses leaf key or any node key for a node above their leaf that is not also in the path from your own leaf to the root. You can't get the answer when it's encrypted with your own leaf key or any node key above you, at least not for this subtree. Here my own knowledge of the details goes hazy. I'm not sure if one media key is encrypted multiple ways using keys from different subtrees, or if multiple copies are encrypted using different subtrees/keys, but I do know that the decryption process keeps trying, cycling through different decryption attempts until it reaches an end. It's only after it gets to the end and hasn't gotten a valid decrypted answer, that it can conclude its own set of device keys has been revoked. |
|
16th February 2007, 16:09 | #270 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
I should probably point out to anyone reading this, that I'm much like Professor Felton and the "Freedom to Tinker" guys. I'm simply interested in fair use, crypto, copyright and the social effects of the battle between those who are in favor of DRM and those who are opposed. I find this thread particularly interesting - pitting the most advanced and expensive DRM crypto system ever implemented against the real world of people who want to enjoy their fair use rights by watching their discs on Linux based systems or systems that have everything except HDCP. |
|
16th February 2007, 16:31 | #271 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
Its purpose is to avoid bit-by-bit (verbatim) home copying of the disk. You can not do a verbatim copy of all the disk because you (supossedly) don't know the VolumeID. |
|
16th February 2007, 16:55 | #273 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
|
|
16th February 2007, 17:57 | #276 | Link |
Registered User
Join Date: Jan 2007
Posts: 274
|
I'll look at it, but am I right to think you have to give your MKB tool the sniffed volume ID (plus the processing key, which you probably have hard coded in)?
It occurs to me (obvious things sometimes do that :-) that even with a device key, a player would need the volume id to get from the processing key to the media key and on to the title key. So this means the software player can get the volume id, presumably by asking the drive to send it over from the disc. I don't see any reason why hacked firmware or sniffing would be required to get the volume id if the player can get it. Perhaps this has been solved (does your tMKB ool do that?) or there's some part of this that hasn't sunk in yet. |
16th February 2007, 18:20 | #277 | Link | ||
Registered User
Join Date: Dec 2006
Posts: 202
|
Quote:
Quote:
Last edited by evdberg; 16th February 2007 at 18:25. |
||
16th February 2007, 18:22 | #278 | Link | |
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
In principe: to decrypt a disc you need two things: Device Keys and a Private Host Key (+Certificate). We can replace the Device Keys with one Processing Key but we still need the Private Host Key to give us the Volume ID. Otherwise we have to sniff it (or guess it etc) |
|
16th February 2007, 18:48 | #279 | Link | |
Registered User
Join Date: Dec 2002
Posts: 86
|
Quote:
|
|
16th February 2007, 19:37 | #280 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Someone asked about size - Section 4.2 seems to say the whole host certificate data block is 92 bytes long. The Host ID is 8 bytes, the key is 40 bytes and the signature is 40 bytes. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|