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. |
22nd February 2007, 00:02 | #61 | Link | |||
Registered User
Join Date: May 2003
Posts: 22
|
Quote:
Quote:
Quote:
The wise thing to do seems to be to distribute device nodes randomly. For exactly this occurence (exposure of a processing key) it helps in tracking down the culprit. -- FMalibu |
|||
22nd February 2007, 05:21 | #62 | Link | ||||||
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
Quote:
Quote:
Quote:
Regarding the number of Device Keys: Quote:
Quote:
Last edited by arnezami; 22nd February 2007 at 05:37. |
||||||
22nd February 2007, 13:56 | #63 | Link |
Registered User
Join Date: Jan 2007
Posts: 274
|
Thank you arnezami, for your usual informative post. As FMAlibu says - damn you for making me so curious - every time I start to get a handle on this, you point to another area I don't yet fully understand.
Do you know if the two software players use the same processing key? Has it been sniffed from both? This would confirm that they are in the same S-D set. Equivalently: Have the "device numbers" for these two players been identified? |
22nd February 2007, 14:38 | #64 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
MKB is signed by LA, so it can not be faked on disk. However, MKB can be faked on memory: player loads MKB, an appropiate breakpoint freezes player, attacker modify MKB at his pleasure, and player starts to run again (after breakpoint). So attacker gets a player running with a fake MKB. That way attacker can get the 253 keys. Checking validity is not strictly necessary (note attacker can not publish them: if he does so the whole set will be revoked). Attacker can check validity for the first (given) Device Key. For the rest validity will be checked if attacker needs to use them. |
|
22nd February 2007, 14:56 | #65 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
I think we still have to see how successful those other methods will be, but I'm inclined to agree with you that if one device key can be found, the others can also be found by methods such as you describe. |
|
22nd February 2007, 15:09 | #66 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
No, master tree is not a tree of master keys, it is just a tree of Device Keys. Each player receives 22 DKs for master tree (and master tree can be conceived as the subset difference for "everybody"), 21 DKs for one of the subtrees that represent "half of everybody", 20 DKs for one of the subtrees that represent "a quarter of everybody", and so on. Keys of each subtree are different that keys of any other subtree, and the same is true for master tree. Subtrees are subset differences. Master tree is nothing special (it is "the subset of everybody"), except for a sole aditional property: for each player there is a different route from leaf key to root key at master tree, and this route is used to decide which subtrees are used for each player (which subtrees the player receives DKs for). |
|
22nd February 2007, 16:50 | #67 | Link | ||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
You are using the term "master tree" here to refer to only one of those 22 level trees- the one that the software players use. We don't know which one other players use. FMalibu and I used the term "master tree" to refer to the full tree that starts 8 levels higher and includes all 512 of the trees at level 22 that you are referring to. The LA could have given device keys for those upper levels, but didn't, Thus each device, when it is given device keys, gets them from only one of those lower level 512 trees. The LA has them for the full master tree. You may want to use some term for a device tree at level 22 that is different from the term "master tree" that includes all 512 of those device trees. Quote:
Each of the 512 subtrees that starts at level 22 matches up to 2 to the 22nd power possible devices inside that subtree (all located at the bottom). The MKB has an S-D set for each of those subtrees that includes all of the possible devices in that subtree except one - the one on the lower left corner of the tree, so the subtree for the S set starts at the 22 level and the subtree for the D set starts at level 0 (on the lower left) and includes only one device. Last edited by FoxDisc; 22nd February 2007 at 20:32. |
||
23rd February 2007, 01:11 | #68 | Link | |||
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
Quote:
Quote:
They are still on master tree, just because they have not revoked yet a noncontiguous group of keys. First MKB entry belongs to master tree, the rest of entries are just not used nowadays. So any device (except one that has never been sold) can derive the appropiate DK to get later the PK. Last edited by xyz987; 23rd February 2007 at 01:21. |
|||
23rd February 2007, 04:14 | #69 | Link | ||||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
Quote:
Quote:
1) The first MKB entry is for an S-D set, not a full tree or subtree. It includes almost all devices except the lower left device, which would not be a real device. 2)The other entries are for similar S-D sets within the larger master tree. 3) We do not know if the other entries are used by current devices, but I bet they are - by non-software players. 4) Later PK keys will not be able to be derived by current devices if they are revoked by defining S-D sets in the MKB that do not include the revoked devices. The revocation will occur by adding one or more new S-D sets and media keys encrypted with the PKs for those S-D sets to the MKB (and eliminating the current S-D set which includes the current players). |
||||
23rd February 2007, 13:45 | #70 | Link | |||||||
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
Spec doesn't say where root keys come from, may be they are ramdon or nodes of a higher level tree. However, it is true that there are 8 levels above master tree. It is also true that the number of subtrees is huge (there are millions), so getting ramdonly the root keys for all those subtrees is not an efficient method. That's why I think you are right and God tree exists. Quote:
My numbered tree can be used in different ways. Note that each subtree corresponds to a node of master tree (this correspondence is to decide for which subtrees the device receives Device Keys), so you can assign numbers to subtrees. You can say "node 4 of subtree 2" for example. Again I am just trying to do things in the same way AACS does. Quote:
Quote:
I say it includes all players, of course. And the tree that includes all players (spec says "master tree of keys, where each device is uniquely associated with a leaf node of the tree") is precisely master tree (22 levels hight). Of course, God tree also includes all players (because it includes master tree), but it is 8 levels higher. Quote:
Quote:
Quote:
Note it is posible to revoke a player just storing on MKB only one valid entry (player 12 will become revoked if Media Key is encrypted with key 12). AACS LA only needs to use 2 or more entries if they want to revoke noncontiguous players. Also spec says "On average, there are 1.28 encryptions per revocation". You are saying they use 512 encryptions (512 valid entries) even if they have not revoked any player. Last edited by xyz987; 23rd February 2007 at 13:52. |
|||||||
23rd February 2007, 13:59 | #71 | Link |
Registered User
Join Date: Jan 2007
Posts: 274
|
True. The original paper by NN&L does say however. That is why I read it. The paper says they must be randomly selected for security, so I assume that's what the AACS LA did. The AACS specs says that S-D sets may also be called "NNL sets."
Perhaps I will have more time late to comment on your other points. |
23rd February 2007, 14:20 | #72 | Link |
Registered User
Join Date: Dec 2006
Posts: 142
|
Spec says that Media Key is the same no matter which player decrypts it.
So it seems that the revocation system (MKB and Device Keys) and the traitor tracing system (Sequence Keys and SKB) are highly decoupled, because the input of traitor tracing system is Media Key, and this value is not related with Processing Keys neither Device Keys. This is important because it allows an attacker to publish a Device Key safely. May be users can not decrypt all the movie (or even any portion) sans avoiding traitor tracing system, but this is not attacker's problem. The "traitors" that are traced are user players, not attacker player. |
23rd February 2007, 14:42 | #74 | Link |
Registered User
Join Date: Jan 2007
Posts: 274
|
In Common Spec, section 1.8, "Terminology" Definition of S-D tree - they say "Subset Difference Tree or NNL-Tree" I only recognized it because the original paper is sometimes called the NNL paper after its 3 authors.
|
23rd February 2007, 14:57 | #76 | Link | |||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
Quote:
Last edited by FoxDisc; 23rd February 2007 at 15:57. |
|||
23rd February 2007, 15:36 | #77 | Link | |||||||||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
The average of 1.28 encryptions per revocation is a mathematical result of how many entries they will have to put into the MKB table to revoke a randomly distributed device. If the device is contiguous with another revoked device, revocation is easy with a single entry for many devices. If revoked devices are non-contiguous, many entries may be needed, but the average is only 1.28 more entries every time they revoke another device. Last edited by FoxDisc; 23rd February 2007 at 15:51. |
|||||||||
23rd February 2007, 17:01 | #78 | Link | ||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
It couldn't include any other devices outside the first tree, even though there could be other devices in other 22-level trees. That's because (apparently) no devices received keys above the 22 level. The MKB could define other S-D sets above that level, and those sets would include devices from multiple different 22 level trees, but none of the devices could decode the associated encrypted media key. |
||
23rd February 2007, 17:32 | #79 | Link | |||
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
Quote:
Furthermore arnezami's soft player has received 22 device keys for one of the 22 level trees (the first one). However, any player also has 231 more keys (253 - 22 = 231). So the next 21 keys may be located at the second 22 level tree (at one of the two 21 level trees it has), the next 20 keys at the third 22 level tree, and so on. This order is just an example, in fact I am saying that subtrees are also using keyspace of the 30 level tree (order is not important). Quote:
BTW, it should be 31 level tree. 30 - 22 = 8 and 2^8 = 256, not 512 Edit: Also, there are up to 31 bits available for the path. Last edited by xyz987; 23rd February 2007 at 17:40. |
|||
23rd February 2007, 18:37 | #80 | Link | ||||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Quote:
Quote:
Quote:
Notice that the processing keyspace size is larger than the 31 level tree of random number master keyspace. Every node gets only one random number from the master keyspace, but it gets a processing key from every other node above it. (Well actually only from the nodes up to the 22 level.) Fortunately devices can calculate all the processing keys they need from the device keys they get. So far only one of those processing keys has been found! Last edited by FoxDisc; 23rd February 2007 at 18:54. |
||||
Thread Tools | Search this Thread |
Display Modes | |
|
|