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. |
21st May 2007, 07:09 | #241 | Link |
Registered User
Join Date: Dec 2006
Posts: 5
|
Subset difference issue
Let we assume:
root ..............................................A level 1 ............................B..........................C level 2 .....................E...........F.............G............H level 3 (devices) ....d0..d1....d2..d3......d4..d5.....d6..d7 d1 and d6 are revoked and collude As it was written: d1 has device keys A-d0, A-F, A-C d6 has device keys A-d7, A-G, A-B I probably missed something because I thought that non-revoked device d0 has device keys: B-d1, C-d6. Am I right? Thus to encrypt a message M for user d0 only I'll encrypt the message by keys L(rooted in B and processed to d0 position) But - if so - each device that has any device key of subset rooted at B will be able to process any device key and thus decrypt the message. Am I right or not? Please could anyone clarify it to me? How does subset difference work in this sense? |
21st May 2007, 18:37 | #242 | Link | |||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
Quote:
[edit]On reflection, I suppose you just want to know how to revoke d6 and d1. The answer is to use B-d1 and C-d6. Does that answer your question? Last edited by FoxDisc; 22nd May 2007 at 12:45. |
|||
23rd May 2007, 15:04 | #243 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
The notation used above (like B-E) refers to a single device key. You can think of the device key as being located at the second node (E node) on one of arnezami's parking garage floors defined by the first node (B-node). A parking garage floor includes the root node for which the floor is named (the B-node) and all nodes on the tree below it (like E and F), but no other nodes. Thus, every device key that starts with a B is on the B floor. The B floor is distinct from the C floor and from the E and F floors. You can't get from one floor to another, even if they are at the same level - you have to start with a DK on the correct floor. There is one and only one device key for every node on every floor, except for the root node on that floor. If you have a device key (say B-E) located at node E on floor B then you can calculate all the device keys on that floor for all the other nodes on the tree below the DK you have (but not above due to the "one way function" relationship). If you have B-E, then you can calculate B-d0 and B-d1, but not B-F, B-d2 or B-d3. If you have B-d0, you can't figure out B-E or B-d1. For every device key there is one and only one processing key and you can calculate that associated PK from the DK. Thus, there's one and only one PK for every node on every floor. Since the same node is on lots of floors, each node has lots of DKs and PKs, but only one per floor. What about the root node on a floor? I said above there is no DK for that node, but I lied. Take the root node B on the B-floor. The DK for that node would be B-B. What does that DK refer to? It refers to the set of all devices below B minus all devices below B. IOW, it refers to a set of devices with no members. Since there are no devices assigned to that set, no devices get that device key, but it does exist. If you had the DK for B-B, you could calculate the DK for B-E and B-F, and from those, you could get all the PKs on the B-floor. Guess who has the A-A and B-B and C-C DKs? Yep - it's the AACS LA. If you had the DKs at the root node of each floor, you'd have all the keys and AACS would be broken. Last edited by FoxDisc; 7th June 2007 at 19:21. |
|
17th June 2007, 01:38 | #245 | Link |
Country Member
Join Date: Sep 2004
Location: is everything!
Posts: 6,499
|
@paranoid87
Do you have a question. You have posted a lot of meaningless stuff today and have received 2 strikes. The next one gets you a suspension so be very careful. Regards
__________________
Les Only use genuine Verbatim or Taiyo Yuden media. |
18th October 2007, 21:34 | #246 | Link |
Registered User
Join Date: Feb 2007
Posts: 49
|
I read all these and I cannot seem to find what countermeasures they have against a virtual HD DVD drive. I mean with the "hacked" xbox360 addon every sector that needs to be read can be read so what stops a 1:1 copy and a virtual HD DVD drive?
|
19th October 2007, 04:46 | #251 | Link |
Registered User
Join Date: Jan 2007
Location: Internet
Posts: 378
|
First, despite the hack the XBox 360 HD-DVD still cannot read everything off the disc, e.g. it cannot read the Copyright Data Section where the second part of the VolumeID is stored. It is still (and probably will never be) possible to make a 1:1 image of a HD-DVD.
Second, for such a virtual drive to be able to perform the AACS authentication stuff it needs a Drive Certificate, and this can be revoked just like a found processing key. So there is no way/makes no sense to build such a virtual drive. |
22nd October 2007, 20:05 | #252 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
1) Can the XBox hack read everything off the disc, including the volume id? My understanding is that it can read everything. I know it can read the KCD, which is in the Lead-in Area right after the lsb_64 of the volume id. It can also read the adjacent lsb_64 of the volume id and it can read the msb_64 of the volume id which is in the Burst Cutting Area. My understanding is that the XBox hack is a direct sector read. (If I'm wrong on this, please tell me) 2) Is it possible to make a 1:1 image? No, it's not possible. The writers and discs available do not write into all the required areas - BCA, Lead-in, etc. 3) Would it be possible to simulate a 1:1 image? Yes. One could probably store the VID/KCD data in some other way and write a player for your copied encrypted disc, but it would still need device keys that could be revoked. If you've got the VID and device keys, you might as well decrypt and store it unencrypted, rather than fool with decryption every time you want to play it. |
|
22nd October 2007, 23:38 | #253 | Link | ||
Registered User
Join Date: Feb 2007
Posts: 49
|
Quote:
Quote:
|
||
23rd October 2007, 02:17 | #254 | Link |
Registered User
Join Date: Jan 2007
Location: Internet
Posts: 378
|
@FoxDisc
@ 1) The hack enables some special commands. Indeed it enables a command that allows to read out each raw sector, but this does not work with these special areas we're interested in. Currently we use another command to do a memdump of the ram of the drive to get the goodies we like to get. So yes, you can get the VolumeID and all that stuff but you can't get the sectors which contain these information. Therefor it is not possible to make a true 1:1 image. @ 2) Yes, exactly because of that reason this stuff was invented, prevent 1:1 copies to "copy" the copy protection . @ 3) This is a possible solution and remembers me of the game backup scene when they used physical disc density files (don't know anymore how this was called, its been a long time ago for me) to give the emulator the required extra information which was not inside the image file. And to make something clear, device != drive. If i understood bcrabl corretly he wanted to avoid the need of device keys because he wants to emulate an aacs enabled drive, like daemon tools emulates various game protections. He just missed the drive certificate that such a drive must have, and because of that the whole emulation stuff is useless. The only benefit of such a virtual drive would be if its easier to find a drive certificate than a processing key and maybe later sequence keys. But right now we have a MKBv3 processing key and still no MKBv3 host certificate and we never had a drive certificate. Last edited by KenD00; 23rd October 2007 at 12:50. |
23rd October 2007, 14:34 | #255 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
|
|
23rd October 2007, 15:09 | #256 | Link | ||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
The XBox drive is a special case - its actually both of the above. When the XBox talks to it, it acts like a standalone using a player built into the drive firmware that sends decrypted video to be displayed by the XBox. When PowerDVD talks to it, it acts like a PC disc drive without a player and enters into an AACS authenticated session where both sides authenticate the other. So back to your question. If you want a "virtual drive" that holds previously decrypted video - yes, that's easy. I suspect however, you want the "virtual drive" to act like a PC disc drive that talks to a normal player like PowerDVD. For that to work, the host software (PowerDVD) and the drive would have to enter into an AACS authenticated session. Both the player and the drive need to be authenticated with their AACS signed certificates. The player is easy - PowerDVD has everything it needs - it's legal. The virtual drive would need a drive certificate, and AFAIK, no one has one. Even if they did, the AACS would just revoke it using the DRL (drive revocation list) on the next release. As KenD00 says: "The only benefit of such a virtual drive would be if its easier to find a drive certificate than a processing key and maybe later sequence keys." No one is going to disclose their work on drive certificates and the AACS authentication process until current decryption techniques begin to fail. |
||
24th October 2007, 16:00 | #260 | Link |
Registered User
Join Date: Jan 2007
Posts: 274
|
Either the XBox or the XBox drive would have to have device keys to perform decryption. It seems likely that they are in the drive, but it's not publicly known for sure. It's reasonable to believe that Microsoft set it up this way so they don't have to pay AACS fees, they don't have to update keys and they can point the finger at the drive mnfr if it gets cracked.
Since the drive has a built in player and is treated as a standalone, its device keys don't directly lead to the normal processing and media keys that people are familiar with here. The results of its device keys (like other standalones) have to be decrypted using the KCD (which can't be read when the drive is in an AACS authenticated session with host software on a PC. This wrinkle is intended to prevent device keys found in standalones from being used with software players. |
Thread Tools | Search this Thread |
Display Modes | |
|
|