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.

 

Go Back   Doom9's Forum > General > Decrypting

Reply
 
Thread Tools Search this Thread Display Modes
Old 22nd February 2007, 00:02   #61  |  Link
FMalibu
Registered User
 
Join Date: May 2003
Posts: 22
Quote:
Originally Posted by FoxDisc View Post
To be sure we are on the same wavelength, an "S node" in your notation is an upper Subset node and a D is a lower Difference node? So an S=u and a D=v in the AACS uv mask notation?
Correct. I know I've confused them in the past, but I'm on the same terminology now


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.)
Yes, and I really do wonder where any other device nodes are located...

Quote:
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.
I cannot recall reading the number of device keys in any AACS document, the number of 253 was from arnezami I think. If they're never going to use any node above level 22 as S node, I suppose it wouldn't make sense to issue device keys above this level. In fact, the higher the S node, the more device keys are needed (height-1).

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
FMalibu is offline   Reply With Quote
Old 22nd February 2007, 05:21   #62  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by FoxDisc View Post
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.
Quote:
Originally Posted by FMalibu View Post
Yes, and I really do wonder where any other device nodes are located...
If they've done things correctly then stand alone players have to be in a different tree (probably the second or distributed over more than one). Why? Because of the KCD. The Media Key Precurser cannot/shoudn't be the same as the Media Key (otherwise you can use Processing Keys and Device Keys from stand alones for PC systems which is exactly what the KCD is trying to prevent). The only way to do that is to use a different Processing Key for a stand alone than for a Software Player. This is from AACS common specs:

Quote:
The use of Kmp in devices prevents the direct use of compromised Device Keys from those devices in a different type of device that does not use Kmp.
They may not have done this (which would not be very smart) as can be read in this part:

Quote:
A device that is useing KCD, generally must apply the KCD before verifying the correctness of its processing of the Media Key Block. However, it is possible that it may be processing an old Media Key Block to which the KCD data has not been incorporated in its part of the tree. Therefore, such a device shall use the Verify Media Key Record to determine if it needs to apply the KCD data or not. In other words, if the purported Media Key Precursor actually verifies as the Media Key, then it shall not apply the KCD data, even if it is a type of device that normally would use KCD data.
In fact they may have reserved the entire first tree for Software Players only. We'll see. What is important to note: stand alone players cannot me "moved" to another of these 512 trees since they only have 253 keys (Software Players can of course be moved but they may use the same policy here).

Regarding the number of Device Keys:

Quote:
Originally Posted by FMalibu View Post
I cannot recall reading the number of device keys in any AACS document, the number of 253 was from arnezami I think. If they're never going to use any node above level 22 as S node, I suppose it wouldn't make sense to issue device keys above this level. In fact, the higher the S node, the more device keys are needed (height-1).
This is from the Pre-recorded AACS docs:

Quote:
3.2 Content Decryption (General)
The AACS LA provides a set of 253 secret Device Keys, denoted Kd_0,Kd_1,…,Kd_n-1, to the licensed manufacturer for inclusion into each compliant device or application produced. Device Key sets may either be unique per licensed product, or used commonly by multiple products; the license agreement describes the details and requirements associated with these two alternatives. A licensed product shall treat its Device Keys as highly confidential, as defined in the license agreement.

Last edited by arnezami; 22nd February 2007 at 05:37.
arnezami is offline   Reply With Quote
Old 22nd February 2007, 13:56   #63  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by arnezami View Post
If they've done things correctly ....
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?
FoxDisc is offline   Reply With Quote
Old 22nd February 2007, 14:38   #64  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by arnezami View Post
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).
Once an attacker gets the first Device Key that belongs to his player Device Key set, it is not so hard to get the rest.

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.
xyz987 is offline   Reply With Quote
Old 22nd February 2007, 14:56   #65  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
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.
It is interesting that most software "cracking" is currently done by static methods of reverse compiling or dynamic methods of debuggers. I suspect it was believed that these methods would also play a big part of any attack against software players. However, so far, it appears that neither method has been used. One attack arose from crypto methods by searching limited size memory dump for crypto keys so whole keyspace did not have to be searched, and one was based on sniffing an unencrypted communication channel.

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.
FoxDisc is offline   Reply With Quote
Old 22nd February 2007, 15:09   #66  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FMalibu View Post
First I'll tell you how I think you think it works, compiled from your previous posts, and you can confirm or correct this.
I need time to appropiately answer your post, and I have not time just now (i have to go to work). For now, just a little (and far incomplete) advance:

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).
xyz987 is offline   Reply With Quote
Old 22nd February 2007, 16:50   #67  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
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.
Some points should be clarified to keep everyone using the same terms. The MKB defines 512 S-D sets. (These are equivalent to 512 processing keys since each possible S-D set has one P-key.) If the bottom of a tree is at level 0 and you count upwards, the top of each of those 512 S-D sets is at level 22.

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:
Subtrees are subset differences.
You may want to use the term "subtree" to refer to a tree of nodes below an upper node. A group of devices in a subtree, i.e., below a single node would be a "subset of devices" or just a "subset." A big subset of devices defined by all devices below an upper node S minus a smaller subset of all devices below a lower child node D would be a "subset-difference set of devices" or just an "S-D set."

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.
FoxDisc is offline   Reply With Quote
Old 23rd February 2007, 01:11   #68  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
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.
Good clarification. Note however I am using the term "master tree" in the same sense spec uses it. Spec says that a set of Device Keys can derive any key of master tree (except a handful of them). The tree you call "master tree" doesn't comply this.

Quote:
You may want to use the term "subtree" to refer to a tree of nodes below an upper node. A group of devices in a subtree, i.e., below a single node would be a "subset of devices" or just a "subset." A big subset of devices defined by all devices below an upper node S minus a smaller subset of all devices below a lower child node D would be a "subset-difference set of devices" or just an "S-D set."
Once again I am following spec. The keys of any subtree are different than the keys of the master tree. A subtree is not "a portion of the master tree", it is another tree with another keys.

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.
Your opinion about the 512 MKB entries has a problem: the very first PK any attacker in the wide world got (arnezami's PK) is valid to decrypt the very first C-value of MKB. A great coincidence, isn it?

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.
xyz987 is offline   Reply With Quote
Old 23rd February 2007, 04:14   #69  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
Good clarification. Note however I am using the term "master tree" in the same sense spec uses it. Spec says that a set of Device Keys can derive any key of master tree (except a handful of them). The tree you call "master tree" doesn't comply this.
The "master tree" for all possible devices is different from the "master tree" for any single device with a set of device keys. I just wanted to point out that we were referring to the larger tree. Maybe we should call the larger tree the "master master tree?"

Quote:
I am following spec. The keys of any subtree are different than the keys of the master tree. A subtree is not "a portion of the master tree", it is another tree with another keys.
Again, I am just trying to get consistent terminology - nodes are parts of trees. Multiple keys are assigned to each node. There is only one large master tree with nodes below the root. In your convenient numbered tree, node 4 is node 4 for the entire tree (rooted at node 1), and for the subtree rooted at 2 and for the subtree rooted at 4 - it's always node 4. Yes, one can think of trees of keys, and the keys assigned to node 4 are different for each of those subtrees, I just think it's easier to look at nodes and subtrees of nodes that are part of the master tree.

Quote:
Your opinion about the 512 MKB entries has a problem: the very first PK any attacker in the wide world got (arnezami's PK) is valid to decrypt the very first C-value of MKB. A great coincidence, isn it?
I presume it's because they put the software players into the first subtree. They made the first S-D set as big as possible (all except one device). The first C-value is the media key encrypted with the processing key for that first S-D set. It does not seem like a coincidence to me.

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.
I was hoping that by getting clear terminology I could understand your idea. It looks like FMalibu thinks he understands you, but I do not. I think:
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).
FoxDisc is offline   Reply With Quote
Old 23rd February 2007, 13:45   #70  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
The "master tree" for all possible devices is different from the "master tree" for any single device with a set of device keys. I just wanted to point out that we were referring to the larger tree. Maybe we should call the larger tree the "master master tree?"
Your tree is not mentioned at spec, so it has no name at spec. However I also think your tree exist, and the only problem is to agree a name for it. This tree has the root keys of master tree and subtrees, so we can call it "God tree" (or any other not used name, at your choice).

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:
Again, I am just trying to get consistent terminology - nodes are parts of trees. Multiple keys are assigned to each node. There is only one large master tree with nodes below the root. In your convenient numbered tree, node 4 is node 4 for the entire tree (rooted at node 1), and for the subtree rooted at 2 and for the subtree rooted at 4 - it's always node 4. Yes, one can think of trees of keys, and the keys assigned to node 4 are different for each of those subtrees, I just think it's easier to look at nodes and subtrees of nodes that are part of the master tree.
The real problem is that "master tree" is an expresion used in AACS spec with a precise meaning. Imagine we start to talk about "master tree" in the same sense you use this expresion. Any guy who lands here simply won't understand what we are saying. He will probably think we have not read the spec. If we talk about "God tree", this guy knows at least we are talking about a different tree.

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:
I presume it's because they put the software players into the first subtree. They made the first S-D set as big as possible (all except one device). The first C-value is the media key encrypted with the processing key for that first S-D set. It does not seem like a coincidence to me.
and later you wrote:

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.
So what are you saying?. Just soft players or all players?.

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:
2)The other entries are for similar S-D sets within the larger master tree.
The other entries are just not used nowadays.

Quote:
3) We do not know if the other entries are used by current devices, but I bet they are - by non-software players.
Here is the "big coincidence". Soft players are at the very first entry. Of course, it is not a coincidence if all players are there (master tree).

Quote:
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).

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.
xyz987 is offline   Reply With Quote
Old 23rd February 2007, 13:59   #71  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
Spec doesn't say where root keys come from
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.
FoxDisc is offline   Reply With Quote
Old 23rd February 2007, 14:20   #72  |  Link
xyz987
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.
xyz987 is offline   Reply With Quote
Old 23rd February 2007, 14:23   #73  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
The AACS specs says that S-D sets may also be called "NNL sets."
This is far interesting. Where does spec say "NNL sets"?
xyz987 is offline   Reply With Quote
Old 23rd February 2007, 14:42   #74  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
This is far interesting. Where does spec say "NNL sets"?
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.
FoxDisc is offline   Reply With Quote
Old 23rd February 2007, 14:53   #75  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
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.
Thank for the info. I will read NNL paper.
xyz987 is offline   Reply With Quote
Old 23rd February 2007, 14:57   #76  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
Spec says that Media Key is the same no matter which player decrypts it.
Yes. There is only one, encrypted multiple different ways with different processing keys matching different S-D sets and put in the MKB. (Sometimes the MKB may lead to Media Key Precursor which must be processed with KCD to get actual media key)

Quote:
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.
I haven't looked at Sequence keys closely yet, but since they aren't using them yet, the only traitor tracing information they have is from the processing key released. The processing key matches one and only one set of devices (everyone below level 22 in the first of the 512 sets minus the one lonely non-device in the lower left corner), and they know that it came from one of those devices.

Quote:
This is important because it allows an attacker to publish a Device Key safely.
A Device Key defines an S-D set of devices. Publishing that key tells the LA that the device releasing it knew that key and was in that set. Right now that set is very very large, but it might be smaller later.

Last edited by FoxDisc; 23rd February 2007 at 15:57.
FoxDisc is offline   Reply With Quote
Old 23rd February 2007, 15:36   #77  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
The real problem is that "master tree" is an expresion used in AACS spec with a precise meaning. Imagine we start to talk about "master tree" in the same sense you use this expresion. Any guy who lands here simply won't understand what we are saying. He will probably think we have not read the spec. If we talk about "God tree", this guy knows at least we are talking about a different tree.
Actually, I think he will be confused both ways! It is complex. I just think calling a subtree that is 8 levels down from the root a "master tree" is more confusing.

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.
So what are you saying?. Just soft players or all players?.
I am saying we don't know, but I suspect it is only soft players.

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).
I say a single player was only given keys for its 22 level tree, so for that player, the 22 level tree might as well be the master tree, but for the AACS LA they have keys for 30 level high master tree. This means that the AACS LA will never define a S-D set above the 22 level, since no devices have keys for that tree, but they can assign keys for any one of the 512 S-D sets rooted at the 22 level.

Quote:
Of course, God tree also includes all players (because it includes master tree), but it is 8 levels higher.

The other entries are just not used nowadays.
We don't know this, and I suspect it is not true. We don't have any device keys or processing keys used by hardware players. If they were given device keys in the second set of the 512 sets, they would calculate a different processing key, and they would use that key to decrypt C-Value number 2 not number 1, and they would get the same media key that arnezami's processing key gets.

Quote:
Here is the "big coincidence". Soft players are at the very first entry. Of course, it is not a coincidence if all players are there (master tree).
As I said, they had to put soft players somewhere, I asssume they just put them in the first group. You are right, they may have put all players in that first group, but maybe not. If they didn't, then they are in another 22 level high tree (that you call master tree for that player).

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).
Yes. In fact, they must use *some* key from the tree, and any device below that key could not use it to decrypt. That is why the lower left key in the tree is special - no device gets assigned that key.

Quote:
AACS LA only needs to use 2 or more entries if they want to revoke noncontiguous players.
True. Right now they are "revoking" 512 noncontiguous "devices," the devices are on the lower left of the 512 different S-D sets defined by nodes at the 22 level of the master 30 level tree.

Quote:
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.
Yes. These 512 entries allow grouping the devices into isolated groups (that you call master trees, but which are really 22 level subtrees of the 30 level AACS LA tree).

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.
FoxDisc is offline   Reply With Quote
Old 23rd February 2007, 17:01   #78  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
Quote:
They made the first S-D set as big as possible (all except one device).
So what are you saying?. Just soft players or all players?.
You quoted two things from me. When I first read your question, I did not realize that my two quotes were somewhat inconsistent. When I wrote "They made the first S-D set as big as possible (all except one device)." I meant that they made the first S-D set as big as they could and it included all devices in that 22 level tree except one. It did not include any devices in any of the 511 other 22 level trees. The biggest they could make it was 1/512 of all possible devices.

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.
FoxDisc is offline   Reply With Quote
Old 23rd February 2007, 17:32   #79  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
Actually, I think he will be confused both ways! It is complex. I just think calling a subtree that is 8 levels down from the root a "master tree" is more confusing.
So we can talk about 22 level tree and 30 level tree, as you have started to do. So we can avoid using the expression "master tree".

Quote:
I say a single player was only given keys for its 22 level tree, so for that player, the 22 level tree might as well be the master tree, but for the AACS LA they have keys for 30 level high master tree. This means that the AACS LA will never define a S-D set above the 22 level, since no devices have keys for that tree, but they can assign keys for any one of the 512 S-D sets rooted at the 22 level.
Okay, but they still have a problem. There are millions of subtrees, picking a ramdon root key for each of them is not and efficient method. Also, I have not read yet NNL paper but you are always talking about a unique tree for everything, so subtrees should be part of this unique tree (the 30 level tree)

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:
Yes. These 512 entries allow grouping the devices into isolated groups (that you call master trees, but which are really 22 level subtrees of the 30 level AACS LA tree).
Not so isolated, read above.

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.
xyz987 is offline   Reply With Quote
Old 23rd February 2007, 18:37   #80  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
Okay, but they still have a problem. There are millions of subtrees, picking a ramdon root key for each of them is not and efficient method. Also, I have not read yet NNL paper but you are always talking about a unique tree for everything, so subtrees should be part of this unique tree (the 30 level tree)
Yes, subtrees are part of the 31 level tree (edited from references to 30 level - see below). The paper says to choose a different random key for every node in the tree. I agree, it is a large number. I came up with 64 Gb of data in random numbers. (32 levels counting from 0 level at bottom to level 31 at top times 16 bytes for each 128 bit key).

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).
Yes, I agree. [edit: I think I read your intent here incorrectly. The 22 device keys for one subtree tell you nothing about the 22 keys for another adjacent one of the 512 subtrees, nor anything about either of the two sets of 21 device keys for the same one of the 512 subtrees. Device keys come from the random number assigned to the root node of a subtree. That's why all nodes get a random number assigned in a master 31 level tree - so knowing some device keys from one subtree tells you nothing about other subtrees.]

Quote:
Not so isolated, read above.
I'm not sure how the above makes them not isolated.

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.
Yes, that makes sense, I'm always messing up at the boundaries. I edited this post to change my references to a 31 level tree for the large tree. I edited the random number data size too, but I still may be off by a factor of two.

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.
FoxDisc is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 15:21.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.