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. |
18th February 2007, 17:36 | #21 | Link | |
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
(keep in mind though that this article mainly focuses on the Subset-Difference method) Last edited by arnezami; 18th February 2007 at 17:39. |
|
18th February 2007, 22:51 | #23 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
|
|
19th February 2007, 07:02 | #24 | Link | ||
Registered User
Join Date: Sep 2006
Posts: 390
|
AACS Common:
Quote:
Quote:
General remark: for programmers I advice them to read chapter 3 of the Common AACS specs. Its shows how things are implemented and stored and is quite thourough and precise. Last edited by arnezami; 19th February 2007 at 07:09. |
||
19th February 2007, 10:48 | #25 | Link |
Registered User
Join Date: Dec 2006
Posts: 142
|
Okay. Could you publish the uv number and u mask that are stored at first entry of Explicit Subset-Difference Record on MKB?
Edit: I think you already have published u mask entry (23d), right? Last edited by xyz987; 19th February 2007 at 11:02. |
19th February 2007, 11:22 | #26 | Link |
Registered User
Join Date: Dec 2006
Posts: 142
|
If is noteworthy to say that an attacker that gets the full set of Device Keys (253 keys) from any soft player can do some interesting things because he can derive any key of master tree and sub-trees, except a handful of them.
Nowadays movies are (indirectly) encrypted with the Device Key that is at position 8 in below example of a master tree: Code:
1 / \ / \ / \ / \ / \ / \ / \ / \ / \ 2 3 / \ / \ / \ / \ / \ / \ / \ / \ 4 5 6 7 / \ / \ / \ / \ / \ / \ / \ / \ 8 9 10 11 12 13 14 15 Any attacker with a full set of Device Keys can simply sit and wait next revocation, publishing always just the necessary Device Key to decrypt, sans revealing the identity of his player, so his set of Device Keys can not be revoked. The only necesary caution is to check first that the next Device Key attacker is going to publish is not his Leaf Device Key (far improbable). If it is any other, and they are already using it to encrypt, the attacker can safely publish it. Last edited by xyz987; 19th February 2007 at 16:03. |
20th February 2007, 21:37 | #27 | Link | ||||||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
There are lots and lots and lots of possible such S-D sets. The S-D method allows most of the processing keys to be calculated from some other processing key. Anyway, every device gets a set of device keys and can calculate all the other processing keys for any S-D set that it is a member of. So what processing key is now in use, and what S-D set does that key correspond to? As best I can tell, for the numbered tree above and the AACS tree, the S-D set in question is the set starting at the top node (number 1 above) minus the set starting at the lower left (number 8 above). To make that clear: there is no device at the lower left (it's special), and every device is below the top. Thus, when you subtract off the set comprising the lower left from all devicees below the top, you still leave all devices. That is the S-D set now in use. That S-D set has one and only one unchanging processing key. Every device out there is a member of that S-D set. Every device can calculate that processing key, and use that processing key to get the media key, etc. to decrypt. Quote:
Quote:
Quote:
Quote:
|
||||||
20th February 2007, 22:05 | #28 | Link |
Registered User
Join Date: Jan 2007
Posts: 274
|
Traitor Tracing
I might as well go on a bit further from my last post. The processing key that arnezami found is a key that corresponds to a S-D set that all devices are members of and all devices can therefore calculate. If arnezami or muslix64 had just popped up and said here's the processing key, no one at AACS would have been sure where that key came from. Any device could have found it in theory. Lots of people are wondering why they did it this way.
Of course, they might well have suspected it came from a licensed PC software player, a la WinDVD or PowerDVD. I think they are probably pretty sure of how it's leaked out by now They could have done some things to help them figure out where it came from and that process is called "traitor tracing." It turns out they have some sophisticated procedures using what are called "sequence keys" to help with traitor tracing, but as far as anyone can tell, they are not using that method. Purely to help understand S-D sets, here is another way they could have done this - they could have divided all the devices up into two S-D sets. Using the convenient number tree quoted in my last post, one set would be the S-D set including: the set of all devices below node 1 minus the set of all devices below node 3. That S-D set would be devices 8, 9, 10 and 11. That S-D set would have only one processing key and only those devices could have figured it out. The other S-D set would be: the set of all devices below node 1 minus the set of all devices below node 2. That S-D set would be devices 12, 13, 14 and 15. That S-D set would also have only one processing key, different from the first and only devices 12-15 could have figured it out. Those two S-D sets do not overlap. Using the AACS system, they would have encrypted the media key twice, once with the processing key for the first set above and once for the second set above. Then when the processing key leaked, they would have known which of the two groups it came from. All devices could have decrypted the media key, but only with the processing key they knew how to get. |
21st February 2007, 00:42 | #29 | 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: "For each sub-tree corresponding to a node in the master tree between a given device’s leaf and the root, that set of Device Keys enables derivation of every key in that sub-tree except the keys between its leaf and the root within that sub-tree." Quote:
Furthermore, attacker can safely publish the Device Key who derives the new Processing Key. If several Processing Keys are used to encrypt different movies, attacker can publish the Device Key that derives all of them. Any player can derive that Device Key, attacker is not revealing identity of the player he got Device Key set from. Quote:
|
|||
21st February 2007, 01:19 | #30 | Link | |||
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
Revoking a key is just stop releasing new movies encrypted with that key. Quote:
Quote:
Last edited by xyz987; 21st February 2007 at 02:20. |
|||
21st February 2007, 01:58 | #31 | Link | ||||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
Quote:
Quote:
|
||||
21st February 2007, 02:30 | #32 | Link | ||||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
Quote:
Quote:
I think you've misunderstood what it means for device 12 to have keys 13, 7 and 2 for the S-D set that starts at node 1. Since the set starts at node 1, all devices 8-15 are in that set. However, key 2 corresponds to that set (below node 1) minus the set that starts at node 2. Thus the key at 2 in the example is a processing key that works for device 12-15. Since 12 is in that set, he has that key or can calc it. The key at 7 is for the S-D set that includes every device elow node 1 minus every device below 7. That includes devices 8-13. Since 12 is in that set, he's got that key too, etc. What device 12 does *not* have is the key at 6 or 3 or 12. He's not in those S-D sets, and he can't get those keys. As soon as the AACS LA figures out he's #12, they'll use one of those keys and he's out of luck. To emphasize, the key at 3 is good for everyone below 1 minus everyone below 3. Since 12 is below 3 he's not in that S-D set and wasn't given that key. |
||||
21st February 2007, 02:41 | #33 | Link | ||
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
If you think there is a method to know which device the DK set is from, explain your method. Quote:
And yes, they can revoke all the soft players. However, if they don't close first the hole that allowed attacker to get the old DK set, attacker will get the new set again. Even worse, once the old DK set is revoked, attacker can publish it, and this would cause AACS LA loses a big chunk of key space for future revocations. Just publishing Device Key 2 causes LA loses half of master tree keyspace. |
||
21st February 2007, 03:02 | #34 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
|
|
21st February 2007, 03:48 | #35 | Link | ||
Registered User
Join Date: May 2003
Posts: 22
|
First of all, thanks for the explenation and all other hard work. The thread about the processing key peaked my intested and prompted me to figure out how this part of AACS actually works and what actually was uncovered. From what I understand of it, this explanation is correct, but I still wanted to add some points that I have gathered. Note that a lot of information came from http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.pdf.
FoxDisc seems to be spot on with his description of the S-D sets. What I think is happening is that node in the tree has its own random master key, which are never released by the AACS-LA. When the S point equals a node, the master key for this node is used. The full set of S-D points included in the MKB creates a tree that reaches only those device nodes (i.e. the nodes at the bottom) which have not been revoked. Note that these sets never overlap (as the specifications state they area collection of "disjoint subsets"). Each device key also has a S-D set associated with it. This is because a device key is simply a key that is derived from the master key of node S, downwards until it has reached node D, using the AES-G3 function. The device keys are handed out in such a way that a device can derive the processing key for any given S-D set, except for those where the D is a node that is on the path from the root node to the device node. As an example, lets look at that nice tree again: Code:
1 / \ / \ / \ / \ / \ / \ / \ / \ / \ 2 3 / \ / \ / \ / \ / \ / \ / \ / \ 4 5 6 7 / \ / \ / \ / \ / \ / \ / \ / \ 8 9 10 11 12 13 14 15 What a device has to do to find the Media Key is this:
Let's continue the example. Suppose that those devices that correspond to nodes 8,9 and 14 have been revoked. The S-D values given in the MKB should then be 2-4 and 3-14, as this is the set that reaches all device nodes except those that have been excluded. The device with device node 12 selects the 3-14 substree, as it is included in that, and uses its 3-7 key, as this key has also has 3 as its S node and its D node is on the route to node 14. It uses this key to derive the subsidiary device key at node 14 and subsequently the processing key. It will look up the C-value belonging to subset-tree 3-14 and decode the media key. This has repeated a lot of things that have been said before in this thread, but I hope that by reiterating it, it will be better understood. Also, of course I do not know if what I said is correct at all, I just inferred it from what I've read so far. Please comment on those issues you have found to be different. Quote:
Indeed, there are 512 S-D sets. As already indicated, the device node for the device for which the processing key was found is located within the very first set. If I'm correct in what I've said above, this means that the compromised device can actually located within 1/512th of the total device space. If devices are spread randomly and equally among all the device node values, it shouldn't be too hard too track down. However, it seems like a big coincidence that the device is located within the first S-D tree. If they (stupidly) started handing out device nodes at value 0 and work their way upwards (in the tree this would be starting at the left bottom node and going right one step each time), then there is no way to determine which device was compromised. In fact, a total of 2^22 - 1 = 4194303 devices should get a hit on the first S-D value Quote:
-- FMalibu Last edited by FMalibu; 21st February 2007 at 15:57. Reason: S-D/D-S mixup |
||
21st February 2007, 04:59 | #36 | Link | ||||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
2) Second way is with processing keys as explained above. This is slow, but basically, they know for every processing key released that some device in the corresponding S-D set released it. 3) They read this forum and find which software player and how it was done :-) Quote:
Quote:
|
||||
21st February 2007, 05:43 | #37 | Link | |||
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
On the other hand I must say that I didn't understand you first time you mencioned this method. I was talking about master tree and you started to talk about subtrees. Note however that encrypting with keys at subtrees is supposedly reserved to revocation of noncontiguous leaf keys: "This scheme enables efficient revocation of any combination of Leaf Keys. To revoke only a single Leaf Key (i.e., to enable calculation of the Media Key by any set of Device Keys except the set containing that Leaf Key), the Media Key Block will include the Media Key encrypted only by the master tree’s Leaf Key that is being revoked. If the Media Key is encrypted using a key located higher in the tree, the effect will be revocation of a contiguous range of Leaf Keys which are commonly rooted at that node. Efficient revocation of noncontiguous Leaf Keys can be accomplished through use of the sub-tree key systems" If they follow their own spec, they won't leave the master tree until a revocation of noncontiguous leaf keys is needed. Device Key revocation is not a Traitor Tracing method, it is just revocation. Quote:
Quote:
Last edited by xyz987; 21st February 2007 at 06:12. |
|||
21st February 2007, 06:09 | #38 | Link | ||
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
Quote:
|
||
21st February 2007, 13:25 | #39 | Link | |||
Registered User
Join Date: May 2003
Posts: 22
|
Quote:
I'm not sure what "master keys" you are referring to. When I'm talking about master keys, I mean keys of a specific node, that are to be used when this node is the starting node (S node), and are thus used to derive device keys, subsidiary device keys and eventually processing keys. So in this case of contiguous device revocation (devices 8 and 9), as subset tree will be given for 2-4, as I said. By definition this includes every device node (at the bottom) that has node 2 as a parent, except for those that have node 4 as a parent, which are device nodes 8 and 9. So I maintain that my example was correct. What did you mean by "encrypt with key 4 of the master tree"? Quote:
Suppose the device nodes at the bottom are called level 0. Since the tree is 31 tiers high, the root node would be at level 30. All S entries for the S-D sets are at level 22 now. Each of these S-D sets has a D node at the leftmost bottom of the tree where the S node is root. According to FoxDisc this is a special value and indicates no device revocation (thanks for that info, must have missed that somewhere). No device should exist with those D values as device nodes, they'll be revoked and won't work. It follows that there must be a total of 512 of these trees (2^(31-22) = 512) to make a complete tree that reaches all device nodes, except the leftmost ones in each subtree. The device node of the compromised device resides in the very first D-S set, not in any of the other 511 D-S sets, which means that its "location" can be determined within 1/512th of the total device node space. It remains to be seen if this is a coincidence or not. Also: Quote:
-- FMalibu Last edited by FMalibu; 21st February 2007 at 15:58. Reason: S-D/D-S mixup |
|||
21st February 2007, 13:58 | #40 | Link | ||
Registered User
Join Date: Jan 2007
Posts: 274
|
Yes, it is a slower method, and it is not the principal method. At this point it does not look like they are using any method except 3
Quote:
Quote:
|
||
|
|