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 February 2007, 14:23 | #41 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
You can download this document (and the rest of the spec) from here: http://www.aacsla.com/specifications/ I think we have a problem of understanding, sometimes you and FoxDics say you don't understand some of the things I wrote, although I am always using the same language, terms and concepts of the spec. So please, read section 3.2.1. It is just one page. BTW the document you linked is not part of the spec. I think that if you (FMalibu and Foxdisc) read section 3.2.1 you will understand what I say, and probably you will agree. Even if you don't agree, at least you will understand what I am saying. Best regards :-) |
|
21st February 2007, 14:46 | #42 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
"A given set of Device Keys enables derivation of every key in the master tree except the keys between its leaf and the root" and also (see figure at page 12 of "AACS: Introduction and Common Cryptographic Elements)": "The nodes in white correspond to keys that cannot be derived using that set of Device Keys." The nodes in white (at the mencioned figure) are precisely "the keys between its leaf and the root". Spec is far clear here. |
|
21st February 2007, 15:25 | #43 | Link | |
Registered User
Join Date: May 2003
Posts: 22
|
Quote:
Suppose that initially there is only one S-D set given, 1-8, that includes all of the device nodes except for the special leftmost one. Now suppose that the device with device node 12 is compromised. As explained in my example, it has device key 1-2. What you guys are talking about is if only this key is released, right? In this case they could do one of two things:
This is all some nice theory, but no device key was released, so let's discuss countermeasures for the Processing Key Let's consider the example tree to be a simplified representation of the first S-D set that is currently given in the MKB (this tree actually has a height of 23). What has happened now is that processing key for this set, in the example tree given by 1-8, is known. To disallow use of this key, they can do something similar to what I mentioned above, but simpler. They can just avoid using 1-8 and replace it with the sets 1-2, 2-8. This would still allow decryption by all devices except 8, but would disallow use of this particular Processing Key. For the actualy subtree of height 23, the principle is the same, the one S-D value could just be replaced by two, one excluding the left branch and another originating at the left child node and ending again in the leftmost device node. In summary, I think I can say the following:
I'm pretty much just thinking out loud here. Please point out the errors in my reasoning -- FMalibu Last edited by FMalibu; 21st February 2007 at 15:59. |
|
21st February 2007, 15:44 | #44 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Since processing keys only match S-D sets, and all S-D sets exclude at least one device below some lower node, there must be some lower "device" location that is not used (at least not yet). It made sense for them to use the smallest possible excluded set of devices, i.e., one device, and they chose the lower left one. I suppose they could revoke another lower device later and then assign the lower left location to a real device, as the device keys have not really leaked for that location. I don't know if the lower left is actually special in any sense other than that they had to start the S-D system with at least one excluded device. |
|
21st February 2007, 15:45 | #45 | Link | ||
Registered User
Join Date: May 2003
Posts: 22
|
Quote:
I think I arrived at what you were trying to say before in the previous post. What you're saying suddenly makes a lot more sense Please read my previous post and point out the things you disagree with. I'll try re-reading the thread and see if there are things you have said that aren't clear to me or just seem wrong. Quote:
Oh, and thanks for the discussion |
||
21st February 2007, 15:54 | #46 | Link | ||
Registered User
Join Date: May 2003
Posts: 22
|
Quote:
However, you say that "one processing key seems to work for all devices". You cannot know this. Maybe what you mean to say is that one processing key works for all titles. It should, because all titles can be played back by the compromised device and the S-D sets given in the MKB are the same for all titles. But it could be that another device has its device node located within another S-D set. We don't know this, because AFAIK only one device was compromised... Quote:
Also, ARGH!. I just realised I have been using both S-D and D-S inconsistently in my previous posts. I will edit them and try to correct it. -- FMalibu |
||
21st February 2007, 16:47 | #47 | Link |
Registered User
Join Date: May 2003
Posts: 22
|
xyz987:
I've re-read the thread and I think I've come up with what is the difference between the way you think it works and I think it works. It's an issue that I got wrong at first as well (wrong IMHO), but the PDF I just linked helped me understand it. Indeed the wording in the AACS specification is a bit misleading about it, particularly in the section 3.2.1 you mentioned. First I'll tell you how I think you think it works, compiled from your previous posts, and you can confirm or correct this. There is one master tree and every node in this tree has a master key. Lower master keys can always be derived from higher master keys. Device keys are master keys. Processing keys can be derived from these device keys, in case of a single revocation within a tree at the device node that has been revoked, in case of a contiguous revokation at the parent of the contiguous set. But what about non-contiguous revocations? Suppose in your example tree that 8 is still revoked and 14 is as well. If it is encrypted with the key at 8 then 14 can decrypt it, and if it is decrypted with the key at 14, then 8 can decrypt it. I'm not sure how you envisaged this. How I think it works is the following: There is one master tree and every node in this tree has a master key. Every node below a particular node has derrived keys, which are different for every root node. If we take the example key, the derived key for point 4 that has point 1 as its root node is different from the derived key for point 4 that has point 2 as its root node and again different from the master key of point 4. Device keys are always derived keys, never master keys. Each device key has two nodes associated with it, a root key and a node for which this device key is the derived key (starting at the root key). This is explained in section 3.2.4. This is why in your example a device has only 3 device keys (8,5 and 3 for node 9) and in my example it has 6 (1-2, 1-7, 1-13, 3-7, 3-13 and 6-13 for node 12). Please keep this in my when you read my examples and see if they make sense. -- FMalibu |
21st February 2007, 18:48 | #48 | Link |
Registered User
Join Date: Sep 2006
Posts: 390
|
Wow! Some solid good discussion here .
It seems our collective understanding of the Subset-difference has grown... I haven't got much time now but would like to say a few things. Different Processing Keys: Processing Keys are interesting not so much because they (usually) won't identify a Player (since they can guess anyway) but they are interesting because they can be used to decrypt every disc and are easy to get. In other words: it will be relavily easy to extract a Processing Key from a future Software Player. Its harder to get the (given) Device Key used. But its much harder to extract all 253 Device Keys from a player: thats because most of them are not used and can therefore not be found in memory (and even if found there is no way to check their validity). So what matters for us (in the near future) is whether we would need a Processing Key to decrypt all discs or need one or more (given) Device Keys. How do you know you only need a Processing Key: if all Explicit Subset-Difference Records (=ESDRs) on each (new) disc are the same. If its not you need Device Keys (or more Processing Keys depending on how many different ESDRs there are). How can they create different (but "equivalent") ESDRs? One way (but there are several things they can do) would be to put all Software players close to each other (say in a part of 256 adjacent leaves) and use the tree right next to it (also 256) as a "fake player revocation" collection. In that tree there are a little over 500 Processing Keys (keep in mind: not just the 256 leaves!) that are all reachable by the Software Players. Btw: for that to work they have to use the sub-tree covering all 512 (2x256) leaves. That way they can choose to use a different Processing Key for each movie (there are no real players in that fake-filled tree so they can "revoke" whatever they want). And they can do this every x months. This would the easiest way for them to use a different Processing Key on each disc but could cost a lot of end nodes. There are more efficient (but trickier) ways but thats just a matter of "cost". (It is noteworthy though this particular technique can be "broken" by finding just one (given) Device Key.) Now whether they will use this technique (or a variant) is going to be very interesting. Btw: I assume/suspect they will revoke each Software Player's Device Keys every so many months as a default safety procedure. Whether they will do they same for Host Private Keys I don't know (likely though). Now you got (even) more to talk about . Regards, arnezami Last edited by arnezami; 13th May 2007 at 11:01. |
21st February 2007, 19:20 | #49 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.pdf. and many other papers on the AACS system. These other papers make some aspects more clear about why it's called subset-difference, why it was chosen, and how the processing key matches up to the S-D set. |
|
21st February 2007, 19:45 | #50 | Link | ||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
Revocation works by just not using any processing key that the revoked device has. However, if you do use it anyway, it is a fake revocation that may help you trace the player. I do not know if they will do this. Now, I confess something: I am not certain if it even possible to do this. I am looking at how the crypto works more than specifically how the AACS has implemented it. Crypto says they can split the devices in half and use that for traitor tracing, but I'm not sure if this is feasible with the exact AACS implementation. I have more reading to do on this. |
||
21st February 2007, 20:17 | #51 | Link | |||||||||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
If they do not care about traitor tracing, and only want to disallow the processing key currently loose, they do not even have to use two keys. Just use the 1-9 key instead of 1-8. As long as device 9 is not assigned yet, and there should be lots of unassigned devices. Quote:
|
|||||||||
21st February 2007, 20:48 | #52 | Link | |||||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
If you would, explain these two: Found Subset-Difference: from 0x00000000 at level 22 to 0x00000000 at level 0 Found Subset-Difference: from 0x00400000 at level 22 to 0x00400000 at level 0 Level 0 is at the bottom correct? Level 22 is 22 up from the bottom? I need help with the "from" and "to" parts. there seemed to be 512 S-D records in your text file. They all seem to start at 22. Do they all start at different nodes below the true top? I think yes, since the "froms" differ, but not sure. What is the difference part of the S-D set on the 0 level? Is that the "to" part? If so, the first S-D set ends on the lower left of its tree, but it'snot clear to me about the second one. Quote:
Found Subset-Difference: from 0x00400000 at level 22 to 0x00400000 at level 0? Two devices are attacked, but neither has any device keys lost or compromised. All we know is that all devices in the S-D set for the current processing key can get that key, so presumably they will use that key. Am I correct in thinking that the current processing key matches the S-D set corresponding to the first line from your text file: Found Subset-Difference: from 0x00000000 at level 22 to 0x00000000 at level 0 Quote:
Quote:
|
|||||
21st February 2007, 20:58 | #53 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
These "master" keys are random numbers. No one except the AACS LA has any of them, and even if one was figured out, it would tell you nothing about any other master key. |
|
21st February 2007, 21:39 | #54 | Link | ||||
Registered User
Join Date: May 2003
Posts: 22
|
Quote:
Quote:
Quote:
Quote:
-- FMalibu |
||||
21st February 2007, 22:12 | #55 | Link | |||||
Registered User
Join Date: May 2003
Posts: 22
|
FoxDisc: For brevity, I wont quote everything you said, as the only comment I have for those parts that are missing is that I agree.
Quote:
Quote:
Quote:
Quote:
About the MKB text file, I probably should have explained it better. Of course I just made the script for my personal use so ik makes sense that I'm the only one that can decipher it The file just lists all the Explicit Subset-Difference entries, i.e. S-D sets, it finds sequentially, in the format "From S to D": Code:
Found Subset-Difference: from 0x00000000 at level 22 to 0x00000000 at level 0 Found Subset-Difference: from 0x00400000 at level 22 to 0x00400000 at level 0 The hexadecimal numbers represent a 32-bit integer. As the device numbers are given in 31 bits, the first (most significant) bit is always 0. The rest of the bits give the path to the node, a 0 being "left", the 1 being "right". Of course, if the level is higher than 0, the number will contain that many trailing 0's, as it won't travel further down the tree. Notice that for each S-D entry the S value is increased by 0x400000, which equals 1 << 22, and that there are a total of 512 entries. This means that all nodes at level 22 are represented as S nodes. Also notice that for each S-D entry the D value equals the S value. Since the trailing 0's for this values are revelent however, this simply means the leftmost device node that has the D node as a parent. I hope you're getting the same mental picture as I am (I like to visualise things in my head, but am to lazy to open ms paint). 512 equal height pyramids which are nearly touching (but not overlapping) at the bases, each pyramid with a red dot in the lower left corner indicating the D node and thus the revoked device. Our compromised device resides somwhere along the base of the first pyramid. Quote:
Somehow section 3.2.1 is misleading (it does say "Informative") and slightly at odds with the rest of the document. -- FMalibu |
|||||
21st February 2007, 22:12 | #56 | Link | ||
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
Quote:
In fact: there are many cats around here.. Last edited by arnezami; 21st February 2007 at 22:20. |
||
21st February 2007, 22:19 | #57 | Link | |
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
In fact it was exactly this gap I wanted to fill . And something tells me it worked... Last edited by arnezami; 21st February 2007 at 22:23. |
|
21st February 2007, 22:27 | #58 | Link | |
Registered User
Join Date: May 2003
Posts: 22
|
Quote:
I find that in particular your diagrams of the coloured tiles are a very potent metaphor. The whole business with the trucks however collides with the mental picture I had already formed, but I can imagine it being usefull to others. |
|
21st February 2007, 22:43 | #59 | Link | |
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
I don't just want to tell people how things work. I want them to "see" it themselves and then start to think for themselves about it . Last edited by arnezami; 21st February 2007 at 22:47. |
|
21st February 2007, 23:02 | #60 | Link | ||
Registered User
Join Date: Jan 2007
Posts: 274
|
Yes, as I looked closer at your file on the MKB, I suspected that.
Quote:
Quote:
So we do not know for sure about non-software players, but perhaps some lie in the second 512 height pyramid, the one just to the right of the one the software players are in, and they would normally use a processing key different from the one arnezami located? Hmmm. The processing key from arnezami confirms to them that a device from the first tree was used. (As if they didn't know where the software players reside.) I am wondering about this breakup at level 22 into 512 pyramids. I wonder if devices have device keys for above that level? I have forgotten if any specs tell how many device keys each device has. IIRC 253 are needed for one of the 512 pyramids at level 22, but only 496 or 528 for 31 or 32 levels. I'm getting a picture of this divided up base of 512 pyramids having only a few devices in each pyramid, perhaps separated by manufacturer or with software players in one and hardware in another. |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|