Understanding AACS (including Subset-Difference)

[arnezami]

For those that have been following the developments lately concerning HD DVD and Blu-Ray decryption it might seem difficult to get a grip on what has actually happened. There has been so much talk about so many different kinds of Keys and IDs that everything might start to look like a big blur of encryption gibberish. So far there has not really been any overview of what has actually been "broken" and what the consequences of some of the recent finds are. Basicly there is a gaping hole in our understanding of how things work which prevents us from making any definitive conclusions about the meaning of events occured. The biggest gap being the Subset-Difference technique used by AACS.

With this post/article I would like to fill this particular gap. It is meant to explain how the Subset-Difference technique works. Before that I will quickly explain how the general picture looks like so you can see how and where the Subset-Difference technique fits in.

[edit] If you're really new to AACS you might want to read this thread (http://forum.doom9.org/showthread.php?t=124505) first.

AACS in general

The following is a picture some of you might already have seen. Its a main overview of the AACS protection system. It shows the disc and the player and "all" the important keys involved in the decryption process.

http://img367.imageshack.us/img367/6008/progress6km3nf8.png

MKB = Media Key Block
Process MKB = Subset-Difference Tree system
Km = Media Key
Kvu = Volume Unique Key
Encrypted Key = Encrypted Title Key
Kt = Title Key

What it shows are all the necessary pieces of information you need in order to decrypt the content. And each piece has a role.

Subset-Difference Tree system: essentially a giant and largely secret collection of never changing Processing and Device Keys derived from one Master Device Key (or a few). Device Keys can in essense be used to derive a desired Processing Key and because only a few Device Keys are given (hidden in the Player) only a part of all Processing Keys are "reachable" by any given player. This is used for not allowing ("implicitly revoking") certain players to be able to find the right Processing Key (which is needed to get the Media Key).
Media Key: you could argue this is the "core" Key. Its derived from the Processing and a C-value (which is taken from the MKB file) and is in a way the end result of the Subset difference method. Its different for every movie. So if you find one Media Key you can only decrypt one movie (if you manage to get the Volume ID).
Volume ID: this is used to prevent bit-by-bit copying: the Volume ID can only be retrieved by asking the drive in a special way (its not stored in a file on the disc). When copying a encrypted disc this piece of information will not be on the copy thus making it impossible to decrypt/play the content: the copy won't work. The volume ID should normally only be retrievable given a Host private key (which is hidden in the player). The Volume ID is combined with the Media Key to produce the Volume Unqiue Key. And that Key can decrypt the Title Keys.
Multiple Title Keys: even if you managed to find one Title Key this will only allow you to decrypt part of the content thus making it harder because you need to retrieve all of them. This difference in Title Keys can only be accomplished by giving multiple encrypted Title Keys.
Those are the basics of AACS. While I could go into more detail concerning all these parts I will now concentrate on the Subset Difference technique since its the hardest to understand and least transparent.

The Subset Difference technique

In order to explain how this technique works its best to show how its works in its basic form. Only then we can see how more complex things like "multiple non-adjacent revocations" work. But I will not start explaining it by talking about all kind of cryptographic techniques used. I will begin with giving a real-world-like illustration/analog that everybody can understand while in the meantime being quite accurate in showing how this technique actually works. When reading the next part keep in mind: the subset-difference technique is all about reachability.

Driving a truck

The following picture shows a (tree-like) network of roads, several Parking spots and a truck with a long trailer:

http://img53.imageshack.us/img53/5931/tst5a1ji6.png

The idea is this: the truck cannot make tight turns (90 degrees is its best) and it can't go into reverse. When you look at the picture you can imagine to which places the truck can actually drive. To make it a little easier I colored the parking spots green and red to show which of them are and are not reachable from the starting position of the truck. It may not look like much but if you understand this then you're already quite a long way there of understanding the subset difference method. So look at it closely and let it sink in. :)

How it goes:

The story is like this: you are given a truck with several boxes in it and some instructions. These say you have to reach a specific Parking spot in order to get some information (carved in stone at this Parking spot). This information is important because it gives you the ablity to open one of the boxes (with a "C" on it) in your trailer. In this C-box there is a key (with an "M" on it) which in turn allows you to open other boxes (this isn't part of the subset difference anymore so the illustration ends here). Suffice to say: if all goes well you end up with opening a box with a nice present in it ;).

Revocation:

The thing is you cannot reach every Parking spot. So if you happen to have a starting position from which the Parking spot isn't reachable you will never get the present. Lets say the person that gave you the truck and boxes has also given these trucks to all kinds of people (who have different starting positions) and he does this regularly because he likes to give away presents. And lets assume he doesn't like you anymore (you were unkind to him because ... well fill in yourself). From now on he can choose a Parking spot not reachable by you. He would make sure the C-box can only be opened with the information from that (for you unreachable) Parking spot. This means you will never be able to get any presents from him anymore. You are "revoked".

You now know how the subset difference technique works :D.

Well in principle ;).

How it works in AACS

The reason why the subset-difference method may seem so hard to understand is because they had to make the above work using existing cryptographic techniques. And that could confuse you. Hopefully though since you read/looked at the above you now know the principle design of how it is supposed to work so you will get less confused by the crypto talk: in essence its all a computational way of making information "reachable" or not. Thats basicly it.

To explain how it works in AACS lets first look at the letters/examples I mentioned and clarify them:

- Parking spots: these are the Processing Keys. These are the goals to reach. Keep in mind Processing Keys don't change: the only thing that changes is the choice of the "man who gives presents" which one of all the Processing Keys has to be reached.
- The instructions: these "instructions" are in the MKB file and tell you which Processing Key (parking spot) you have to get to.
- C-box: this is a C-value in the MKB file. In fact a C-value is simply an encrypted Media Key (a "locked box" if you will). There is more than one C-value but I will get to that later (when it gets complicated ;)). In reality there is only one C-value in use at the moment.
- M-key: you guessed it. Its the Media Key. Its the result of the Processing Key and the C-value.
- You/the truck: you are basicly the Software player that tries to get to the Processing Keys.

Now what is obviously still missing are the Device Keys and an explanation of how you "drive" cryptographically. I will deal with that now :).

Device Keys:

To do that lets first look at an example of driving towards a Parking spot:

http://img95.imageshack.us/img95/7603/tst7a1os7.png

As you can see the truck has to drive north first and then goes south. This is always the case: first north (NE/NW) then south (S/SE/SW).

In reality in AACS there is no driving north: this part is skipped and you simply "jump" to the point where you start driving south (the purple arrow). But you can only jump to points that would in fact be reachable (if you would have done the actual northish driving first). As you can see in the picture I've marked the point where the truck starts going south (the purple arrow). This is the Device Key. Device Keys are the points where you normally would start driving south.

Here is a little more zoomed out picture which depicts the starting-to-drive-south points (= Device Keys) in purple:

http://img412.imageshack.us/img412/1109/tst9a2xy3.png

What you may have noticed is that these Device Keys are all right along the path north. In fact there are as many Device Keys for a tree as there are branches along the path from your position to the top of the tree. In order to drive towards a certain parking spot (Processing Key) you first need to look at the map and see which Device Key has to be your starting point (only one allows you to go to the Processing Key). From there you can "drive" southwards towards the desired Processing Key. Also notice that along the path north the are red Parking spots. These are the Processing Keys you will never be able to get to. But all the rest of them are reachable by you (green).

Driving:

In AACS "driving" always starts with a Device Key. So there is no need to drive north only south. But when going south it should also not be possible to reverse. In order for that to work they have made it impossible to go north at all (which is also why the "jumping" was needed I talked about above).

How? Well they use one-way functions: you take a Device Key and do some operation/function on it (AES-G3 to be exact) and you can get any of three things: a left sub-Device Key, a right sub-Device Key or a middle Processing Key. Whichever one you need at that point. (note: a sub-Device Key is a Device Key you generated this way. While a Device Key is given to you). Driving simply means: doing this operation on (sub) Device Keys. With each operation you move toward other sub-Device Keys (you move SE or SW in the tree) or you move towards the Processing Key (you move S in the tree and you stop). But there is no function/operation to do the reverse thus preventing you to go north.

Thats essentially how its implemented in AACS. And its equavalent to the story with the truck above.

--- Just to clear up the above pictures: the yellow arrows is the path north (in AACS driving this path isn't actually done). The purple arrow is a Device Key (this is a point where you start driving in AACS, thus skipping the northern route to it). The blue arrows indicate Keys that are somehow derived from a Device Key (sub-Device Keys and Processing Keys). The green Parking spots are Processing Keys you can reach. The red Parking spots are Processing Keys you can't reach. ---

[continued in next post]

[arnezami]

Subsets and revocation

You may have been asking yourself why its called a subset-difference method and how the revocation works (also for "multiple non-adjacent revocations" whatever that means ;)). I will explain that here.

First lets see how simple revocation works. Lets look at this picture (i've added trucks):

http://img100.imageshack.us/img100/6576/tst10a1sh3.png

Each truck represents a Software Player: they each have a "truck" and a starting position. Each one of them can only go to a certain amount of Parking spots, but no two trucks can go to the same set of Parking spots.

I've added the choice (by the "present giving man") of the Processing Key to be found (the blue circle). As you can see this revokes truck nr 1 and 2 (indicated by a red truck). This is because they both cannot get to the circled Parking spot. So by choosing the Parking spot correctly the AASC LA can revoke one or more adjacent "trucks" this way.

Good for them. But how do they revoke "trucks" that are not next to each other? Your intuitive response might be to use two (or more) Parking spots inside the tree. There are however problems with that idea. Let me give this example (this is not how its done but is just to demonstrate why they need something more than just one big tree)

http://img75.imageshack.us/img75/3937/tst10a3hl8.png

As you can see there are now two Parking spots that if reached give information to open the C-box. The intend is to revoke trucks 1, 2, 7 and 8. Well thats the idea at least. But it doesn't work. Why? Because trucks 1 and 2 can now reach the Parking spot to the right and trucks 7 and 8 can still reach the Parking spot on the left! So by doing it this way nothing is revoked (which clearly wasn't desired). The problem is caused by the fact that the positions of these trucks are not adjacent. In other words: "non-adjacent revocation" isn't possible with this method.

The solution: additional sub-trees. Basicly making it a giant "parking garage" with several floors (about 22) where each floor is twice as small as the one beneath. The top floor being very tiny. And an elevator for each truck at the starting position so they can choose the floor they want to drive on.

Here is an attempt to illustrate this:

http://img178.imageshack.us/img178/843/tst1bqq0.png

Each color is a floor. The smaller floors are on top of the larger ones (and since this is a top view you cannot see those parts of the larger lower floor). The red dots are the positions of the trucks to be revoked (these truck can move to the desired floor using an elevator).

Here are the parts relevant for these "trucks":

http://img218.imageshack.us/img218/2941/tst1ajo3.png

Ok. How does this solve the problem? Let me explain. For that we first zoom in again on our to-be-revoked trucks and see how this is done:

http://img227.imageshack.us/img227/4425/tst10a5dk8.png

I've used the same colors so you can match this with the zoomed out picture above. As you can see there are again two Parking spots used. However the trucks 1 and 2 cannot reach the circled Parking spot to the right and the trucks 7 and 8 can't reach the circled Parking spot to the left. So now these trucks (1,2,7,8) have been revoked while the other trucks (3,4,5,6) haven't been.

What is important to note is that since the information coming from the two different Parking spots (Process Keys) is different there is also a different C-value corresponding to the subtrees where the Parking spots lie in. This way it is garanteed that both trucks 3,4 and 5,6 end up with exactly the same Media Key (which is calculated by taking the Process Key and use it to decrypt the corresponding C-value).

How is all this a "subset-difference" thing? Well its not so difficult to see now: take (for example) the subtree containing trucks 1-4. These trucks are a subset of the entire collection of trucks. Another sub-set (trucks 1 and 2) are revoked. If you substract these sub-sets you end up with trucks 3 and 4 (so you take 1,2,3,4 and substract 1 and 2 from that set) which are the non-revoked trucks. Therefore its called a "subset-difference".

Some remarks

Well. That was quite a lot of information already :D. I think I've covered the bulk of the subset-difference method.

Because I know there are going to be questions I also created a separate sections for that: a special FAQ for AASC (which I will extend whenever there are more good questions and whenever I have time). I've also created a seperate post for Advanced AACS topics. Which sort of speaks for itself I hope (its still in progress :)).

I hope I did a good job in explaining this stuff. Suggestions are welcome but purely negative critical remarks that don't help our collective understanding are not sought for. Just keep in mind: I've spend an awful lot of time on this and I'm only human :).

Hope you enjoyed it...

Regards,

arnezami


------

This was posted by FoxDisc after a long discussion and probably some pondering. He says things very well :).

If anyone has followed along this thread, they will realize the complexity of this subject. I thought I might add some things that will help simplify why the AACS LA chose this system. It's not just because it's complicated.

Let's say we want to build their DRM system:

Our first crack at it:
A simple design would be to give every player/device a secret device key. Then we encrypt the media key (the media key lets us decrypt the movie) with every secret key for every device and put all those encrypted copies of the same media key on the disc. Each device would look through all the encrypted copies of the media key on a disc until it found the one it could decrypt. To "revoke" a device we just leave off the copy of the media key encrypted with his secret key!

This would work but it takes lots of space on the disc. We need room for every device present and future. We need keys that are secure (16 bytes minimum) With all those keys, there's no room for the movie!

That was their first concern. They didn't want to use up all the space on the disc.

Our second crack at it:
OK, how about this - we put the devices into lots of overlapping groups. Each device goes into many groups. We assign a secret key to each group. If a device is in a group, he gets the secret key for that group. If he's not in that group he doesn't get the key. Now, the devices have to store more than one key.

What do we do with the disc? Well, we start off by encrypting the media key only once using the key for a really big group that everyone is in. Since they all have that key, every device can decrypt it. This is looking good! We only had to use one key on the disc! We've reduced the space used on the disc by making the devices store more keys.

So how do you "revoke" devices? You stop using the key for the big group (everyone, including the bad boys have that key), and you use keys for smaller groups that the revoked devices don't belong to, but the unrevoked devices do.

This is essentially what the AACS did! A "subset difference set" is just a group of devices. A processing key is just a secret key assigned to that group. All this stuff about subset difference sets is all about ways to divide up the devices into groups so we can give a secret processing key to that group. It's fundamentally simple.

So how do we divide up the devices into groups? How do we decide how many keys to give each device? How do we make sure we can always exclude all the devices that need to be excluded while allowing all the devices we want? How do we know who leaked a key so we can exclude him? How do we make sure that knowing one key doesn't let the bad boy figure out any others? How .....

Whoa! Enough questions already ....... it's time to call in the experts - cryptologists and mathematicians. They think about this for a long while and they come up with: The Subset Difference System.


--------------

FAQ for AACS

This is a FAQ for general AACS matters. I know many of you have questions even (or should I say: especially) after reading all the above.

Here are some of the questions. There will probably be many more so I will extend this list.

Question: Why do we need the Volume ID? We already have a Processing Key!

Answer: Discs on PC based systems are protected in two ways: (1) Only non-revoked Device Keys make it possible to get a valid Media Key (see above) (2) The Volume ID is only given away by a drive if the program that is asking it has proof it has a non-revoked Host Certificate. Software players have that (hidden somewhere) so right now we can sniff the traffic between the Software Player and the drive and retrieve the Volume ID that way. But its not a perfect solution: you really want the Host Certificate/Private Key.

Question: Why don't we need Device Keys? Why do we only need a Processing Key to get a Media Key.

Answer: Well thats because they have chosen the same Processing Key on every disc. Right now there are no revokations in the subset-tree so this means all discs have the same Explicit Subset-difference Record (which are basicly the "instructions" I talked about earlier). This means for each disc we have to go to the same Parking spot/Processing Key.

Question: How does the technique of Processing Key + Volume ID differ from extracting Volume Unique Keys directly from the Software Player?

Answer: Currently the easiest way of getting hold of a VUK is by extracting it directly from the memory of WinDVD. However this is likely to be changed: they will probably "harden" this player so its not easy for anybody to write a program that can easely extract a VUK for everybody who wants to. With a known Processing/Device Keys though you wouldn't need a program to extract the VUK out of the memory of a Software player: you only need to sniff the bus for the Volume ID (or even try to guess it). If you have the VID you can calculate the VUK.

Question: Why are there 253 Device Keys for a Player? Why exactly that (strange) number?

Answer: The largest trees used are 22 nodes high. Because there is a Device Key at each branch from the top to the starting position of a Player it will have 22 Device Keys for that tree. He will also have 21 for its sub-tree. And so forth. This means a Player has 22 + 21 + 20 + ... + ... + 3 + 2 + 1 = 253 Device Keys. :)

Probably many more to follow... ;)

[arnezami]

Advanced AACS Topics

Here I would like to write about certain advanced AACS topics. So I reserved this post for that puspose (because I suspect I need a lot of space and I think its a good idea to put it right after the above explanation so we keep it organized).

The topics I'm currently thinking of are these:

Processing Keys can be different for every movie

This is about the value of the Processing now and in the future. There are ways the AACS LA can issue MKBs in such a way that each disc/movie will have to use a different Processing key thus making a Processing Key in the future much less valueable. However this is really an advanced topic which requires a thourough analysis of what can and can't be done. Its very interesting in itself.

There is also some doubt why the AACS LA hasn't used this techinque. Its possible there was too little time for them to do this properly, or they simply don't understand it themselves. Either way they screwed up by not making use of it in the first place and are not even willing to admit it (when looking at the latest "press release").

Squence Keys and tracing

This is all about sequence keys, segments etc. Currently this isn't used on any of the discs found so far but it may be in the (near) future. This is also an advanced topic so I put it here. There is a lot to be understood about this technique and therefor much to explain.

And maybe there are other advanced topics I haven't thought of. I will see when I have time to write about these subjects.

[mrazzido]

Great Work !! arnezami !!!!

[blutach]

Thanks for that arnezami. Very easy to understand. Well done!

Regards

[xyz987]

Great!

:thanks:


Advanced AACS Topics
This is about the value of the Processing now and in the future. There are ways the AACS LA can issue MKBs in such a way that each disc/movie will have to use a different Processing key thus making a Processing Key in the future much less valueable. However this is really an advanced topic which requires a thourough analysis of what can and can't be done. Its very interesting in itself.

There is also some doubt why the AACS LA hasn't used this techinque. Its possible there was too little time for them to do this properly, or they simply don't understand it themselves. Either way they screwed up by not making use of it in the first place and are not even willing to admit it (when looking at the last "press release").


I think using a different Processing Key per movie is not a good idea for them. Now they have to revoke just one Processing Key, but firts they need to close the hole. They have "lost" just one Processing Key per hole. If they use 150 keys (one per movie), they will lose 150 keys per hole. In the future tens of thousand of movies will be released, they would be losing tens of thousand of PKs per newly discovered hole.

A player has only 253 Device Keys. Sure, there are lots of posible PKs and DKs, but it is a limited resource anyway. Already-sold home players must work with any future released movie no matter how many revokations they do. If they don't achieve this goal, the whole revocation system becomes broken.

[guile]

Very impressive!! You have been a very busy boy Arnezami.

To think I feel like I am "Smart" (or something) when searching out my own keys while you are THE guy that figured out the "how" and the "why" makes me feel like a complete idiot in your presence.

Respectfully,

Clueless (g)

[snurregrekk]

thanks for your effort of making this rather hard-to-grasp information easier to understand for us all. very interesting reading! :thanks:

[h.monay]

THANK YOU SO MUCH

I understand it now :D

[Adub]

Well, done mate, well done. I look forward to added information and updates soon.

[h.monay]

here is a pic if ud like to use to show the levels
http://img53.imageshack.us/img53/7382/mkbez3.jpg

[noclip]

You mean Ted Stevens lied to me? It really is a big truck, and not just a series of tubes?

So do you have any ideas about how to get our hands on the AACS LA root key?

[xyz987]

Question: Why are there 253 Device Keys for a Player? Why exactly that (strange) number?

Answer: The largest trees used are 22 nodes high. Because there is a Device Key at each branch from the top to the starting position of a Player it will have 22 Device Keys for that tree. He will also have 21 for the sub-tree its part of. And so forth. This means a Player has 22 + 21 + 20 + ... + ... + 3 + 2 + 1 = 253 Device Keys. :)


Far good :-)

Note however that a player never gets the root Device Key (neither the root master tree key), because a root key can derive the rest of them.

So the largest tree is 23 nodes hight.

[xyz987]

EDIT: I have rewritten this message. Prior version of this message was not an accurate explanation.

Here is a little explanation with numbered nodes. This is a master tree:




1
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 3
/ \ / \
/ \ / \
/ \ / \
/ \ / \
4 5 6 7
/ \ / \ / \ / \
/ \ / \ / \ / \
8 9 10 11 12 13 14 15




A master tree is just a tree that complies this rules:

- Any lower key can be derived from higher keys through a one-way function.

- Its keys are used (directly or indirectly) to encrypt or decrypt content

- Its keys can be derived from Device Keys

First of all, what kind of keys are master tree keys?. Posibilities are Title Keys, Volume Keys, Media Keys, Processing Keys, Device Keys or "any other kind of keys" (just to be systematic). Any master tree key is used sometimes to encrypt Media Keys, so it must be a Device Key or a Processing Key. Also it can be used to derive a lower master tree key, and this derived key is used sometimes to encrypt a Media Key. Processing Keys do not comply these conditions, the only kind of key that comply this are Device Keys. So master tree keys are Device Keys.

Player 9 will receive Device Keys 8,5,3. This set of keys is chosen because they can derive any Device Key except the keys from the leaf to the root of master tree. There is no way to derive keys 1,2,4,9 from keys 3,5,8.

If you want to revoke the set of keys player 9 has, i.e. the set of Device Keys that contains key 8 (and only that set), you simply encrypt Media Key with key 9. As stated above the set of keys player 9 has received (8,5,3) can not derive key 9, so player 9 can not decrypt the content.

[HyperHacker]

Let me just make sure I get this last image...

http://img227.imageshack.us/img227/4425/tst10a5dk8.png
In this case, 7 and 8 can't reach that leftmost key, because once they get into the light-blue area they can't turn left back into the other blue area that the key is in? They can only keep going "down" to the lowest floor (the root of the tree)?

[arnezami]

Let me just make sure I get this last image...

http://img227.imageshack.us/img227/4425/tst10a5dk8.png
In this case, 7 and 8 can't reach that leftmost key, because once they get into the light-blue area they can't turn left back into the other blue area that the key is in? They can only keep going "down" to the lowest floor (the root of the tree)?

No. Keep in mind there is an elevator only at their starting point. They first have to choose their floor and then they cannot change floors. So they can't even get to the light blue area: they can only drive on one floor (which is quite small btw). Furthermore they can only move within the confines of the grey roads. So there is no way they can get to the light blue area if they started on the higher floor (the darker one).

As an aside: Also on the light blue floor no P has been chosen. So there is nothing to do there even if they started there.

Regards,

arnezami

[arnezami]

@xyz987: concerning Master Device Keys. I believe every "floor" in the garage has some kind of sub-Master Device Key and each of these keys is probably derived from a Master Device Key.

To be honest though there is not much to say or speculate about it than this. We simply don't know how they derive the Master Keys. And personally I don't think its very interesting since we can never find them out.

The only thing that matters is they have the ability to reach every Device and Processing Key.

[FoxDisc]

@arnezami - Excellent work!

At the present time, all discs use the same Processing Key
(Parking Space). Unless the same Processing Key (which is just a number) appears on different subtrees (levels of the parking garage), this means that the Processing Key in current use is on the largest master tree (the only one that all devices/trucks can access/drive on) No device (truck) can get to a Processing Key that is in its own upward chain. Yet every Processing Key in the master tree is in some (possible) device's upward chain. I'm guessing that there is a special spot in use right now at the base of the master tree that holds the current Processing Key/Parking space instead of a device/truck. All other devices in the tree can get to that spot, except the device/truck that starts there (The truck would already be there, but I thought I understood that a device could not calculate it's own single node Processing Key, as well as all the upward processing keys in its chain to the root.)

I understand the "instructions" in the MKB define the "path" to get to the Processing Key, by using ones to go right and zeros to go left when tracing from the top (perhaps I have it reversed - don't recall). Can you confirm where the current Processing Key is located on the tree/parking level and whether it's down low near the base of the master tree/trucks or up higher in the tree? Is it over on the far lower right or left of the master tree?

[arnezami]

@arnezami - Excellent work!

At the present time, all discs use the same Processing Key
(Parking Space). Unless the same Processing Key (which is just a number) appears on different subtrees (levels of the parking garage), this means that the Processing Key in current use is on the largest master tree (the only one that all devices/trucks can access/drive on) No device (truck) can get to a Processing Key that is in its own upward chain. Yet every Processing Key in the master tree is in some (possible) device's upward chain. I'm guessing that there is a special spot in use right now at the base of the master tree that holds the current Processing Key/Parking space instead of a device/truck. All other devices in the tree can get to that spot, except the device/truck that starts there (The truck would already be there, but I thought I understood that a device could not calculate it's own single node Processing Key, as well as all the upward processing keys in its chain to the root.)

I understand the "instructions" in the MKB define the "path" to get to the Processing Key, by using ones to go right and zeros to go left when tracing from the top (perhaps I have it reversed - don't recall). Can you confirm where the current Processing Key is located on the tree/parking level and whether it's down low near the base of the master tree/trucks or up higher in the tree? Is it over on the far lower right or left of the master tree?
The current Processing Key is in the far lower left of the tree used. This tree is the first tree (out of 513 I believe, I haven't analyzed yet why it isn't 512) which is why the first C-value is used. In other words: the largest tree isn't the 31 nodes high tree (which would be the truely root tree) but several floors higher. AACS simply doesn't use the trees with 31-23 nodes high. Which is why the lowest floor (for AACS) is still didived in approx 500 trees I believe.

If you open your MKBROM.AACS and take/print the docs you can see the all this in the Explicit Subset Difference Record. It takes a little effort but the number 17h (=23d) is already telling. Maybe we should make an MKB file reader or something which graphically shows you which sub-trees are used (and thus have a C-value) and what their "shape" is (the position of the C-values in the trees creating subset-differences). Would be cool and informative in the future (when they start revoking).

There could also be some slight difference in the way it works (at the very lower end) and how I pictured it. But these details will eventually be ironed out ;).

[Jay Bee]

Looks like a good effort!

But personally I didn't get any further than the first image. Maybe an explanation of what all the abbreviations in it mean would help clueless noobs (like me) getting started.

[arnezami]

Looks like a good effort!

But personally I didn't get any further than the first image. Maybe an explanation of what all the abbreviations in it mean would help clueless noobs (like me) getting started.

I've added what the abbreviations stand for in my first post. Hope that helps a (little) bit.

(keep in mind though that this article mainly focuses on the Subset-Difference method)

[Jay Bee]

thx !

[xyz987]

The current Processing Key is in the far lower left of the tree used. This tree is the first tree (out of 513 I believe, I haven't analyzed yet why it isn't 512) which is why the first C-value is used. In other words: the largest tree isn't the 31 nodes high tree (which would be the truely root tree) but several floors higher. AACS simply doesn't use the trees with 31-23 nodes high. Which is why the lowest floor (for AACS) is still didived in approx 500 trees I believe.


Where did you get number 31 from?

[arnezami]

Where did you get number 31 from?

AACS Common:

3.2.3 Storing Device Keys
Each device is given its Device Keys and a 31-bit number d called the device number.

and at a different point:

For conciseness, the path number and the “v” mask are encoded in a single 32-bit number, referred to as the uv number. The mask for v is given by the first lower-order 1-bit in the uv number.

32 - 1 = 31


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.

[xyz987]

32 - 1 = 31



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?

[xyz987]

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:



1
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 3
/ \ / \
/ \ / \
/ \ / \
/ \ / \
4 5 6 7
/ \ / \ / \ / \
/ \ / \ / \ / \
8 9 10 11 12 13 14 15



Once arnezami's Processing Key is revoked, they will start using key 9 to encrypt. Then this attacker can immediately publish key 9. Then they revoke key 9 and start encrypting with key 4, then attacker immediately publish key 4, and so on.

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.

[FoxDisc]

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.

This has been here for a while, and no one has commented, so I guess I will. As far as I can tell, and I've brought my own understanding up another notch, the above statement is not true.

Nowadays movies are (indirectly) encrypted with the Device Key that is at position 8 in below example of a master tree:



1
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 3
/ \ / \
/ \ / \
/ \ / \
/ \ / \
4 5 6 7
/ \ / \ / \ / \
/ \ / \ / \ / \
8 9 10 11 12 13 14 15




Yes, they are "sort of" using key 8. Let's make sure we are using the same terms. I'm assuming that the tree above represents the lowest level in the AACS parking garage used in the analogy of this thread. We can ignore the other levels for right now. The "key" at 8 is a processing key that corresponds to a subset difference set. It may not be clear, but every processing key (and there may be billions - haven't done the math yet) corresponds to one and only one subset difference set. What is a subset difference set? It is a set of bottom edge leaf nodes (the devices/trucks in this thread) that is defined by every device below some upper node minus every device below some lower node.

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.

Once arnezami's Processing Key is revoked, they will start using key 9 to encrypt.

Perhaps. Key 9 is the processing key for the S-D set comprising all devices below the top minus the device at 9. Device 9 cannot calculate this processing key from its own device keys. It can only calculate (or was given) keys for S-D sets that it is a member of. If Device 9 is PowerDVD, then PowerDVD will break as he will not be able to decrypt the media key when it is encrypted with the processing key for the S-D set comprising all devices below the top minus all devices at 9.

Then this attacker can immediately publish key 9.

No, he won't have it, if he *is* device 9, and if he's not, they won't use that processing key. They won't encrypt the media key and put it on the disc with any processing key that corresponds to a S-D set that has the attacker as a member. That's how it works.

Then they revoke key 9 and start encrypting with key 4, then attacker immediately publish key 4, and so on.
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.

No. No player has all the keys. A device has all the keys for every S-D set that it is a member of, but there are lots of sets the device is not a member of and that the device does not have processing keys for and cannot calculate.

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.

I'll leave this on the quote, but it makes no sense to me.

[FoxDisc]

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.

[xyz987]

This has been here for a while, and no one has commented, so I guess I will. As far as I can tell, and I've brought my own understanding up another notch, the above statement is not true.


From aacs spec:

"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."


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.


I have not checked your idea of "special key" (prior to any revocation), but anyway what is important is if an attacker with a full set of Device Keys will be able to derive the new Processing Key after revocation. He will be, in the same way any non-revoked player does.

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.


No, he won't have it, if he *is* device 9, and if he's not, they won't use that processing key. They won't encrypt the media key and put it on the disc with any processing key that corresponds to a S-D set that has the attacker as a member. That's how it works.


Of course, if he (it, the device) is device 9 game is over. But AACS LA doesn't know which device the keys of the Device Key set are from, so they can not choose to revoke a group it is a member, because they don't know its identity.

[xyz987]

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.


arnezami did it that way just because he didn't get a Device Key set. He got a Processing Key, and this Processing Key can be revoked no matter if AACS LA knows how (or from) arnezami got it.

Revoking a key is just stop releasing new movies encrypted with that key.


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.


So let's wait until they start using Sequence Keys. BTW, AFAIK Sequence Keys say nothing about where the Processing Key is from, but i have not read completely spec chapter about Sequence Keys.


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.

So attacker publish both Processing Keys, because he can derive both (as any player). Just an example: device 12 has keys 13,7, 2 so it can derive any Leaf Device Key except key 12.

[FoxDisc]

From aacs spec:
"A given set of Device Keys enables derivation of every key in the master tree except the keys between its leaf and the root"


This is correct. It doesn't conflict with what I posted. It's saying that a device can derive all Processing keys for every S-D set that the device is a member of. It's also saying it can't derive keys for S-D sets that it is not a member of. If the AACS LA knows which device is compromised, and revokes that device, all of the device keys for that device become totally useless.

I have not checked your idea of "special key" (prior to any revocation), but anyway what is important is if an attacker with a full set of Device Keys will be able to derive the new Processing Key after revocation. He will be, in the same way any non-revoked player does.

I'm not sure what you are saying here. If he's revoked, he can't calculate anything useful. The only hope he has is if the AACSLA does not know who he is. That's what Traitor Tracing is all about.

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.

The revoked attacker won't have any device keys that derive a valid processing key.

Of course, if he (it, the device) is device 9 game is over. But AACS LA doesn't know which device the keys of the Device Key set are from, so they can not choose to revoke a group it is a member, because they don't know its identity.

OK, so you are assuming they do not know the identity of the attacker? That's what Traitor Tracing is for. They have a method to find out, but they are not yet using it. They could also just assume it's one of the two PC players and revoke both sets, and force updates.

[FoxDisc]

arnezami did it that way just because he didn't got a Device Key set. He got a Processing Key, and this Processing Key can be revoked no matter if AACS LA knows how (or from) arnezami got it.

Agreed

Revoking a key is just stop releasing new movies encrypted with that key.

They don't revoke keys, they revoke devices. When they revoke a device, they automatically revoke (or more accurately, they just stop using) all the device keys that device has, because all of those keys enable calculation of a processing key that corresponds to a Subset Difference Set that the revoked device belongs to. That means that any revocation of any player (not just WinDVD or PowerDVD) will cause arnezami's processing key to stop working, since it's a processing key that all devices can calculate. Every possible revoked player could calculate it, so they can't use it any more.

So let's wait until they start using Sequence Keys. BTW, AFAIK Sequence Keys say nothing about where the Processing Key is from, but i have not read completely spec chapter about Sequence Keys.

I have not read all about sequence keys either. They may decide not to use them yet. I think they know how the keys were obtained. They don't have the scenario they planned for of leaked device keys, so they don't really need to revoke those keys (equivalent to revoking a device). They may just harden the players and use another one of many possible processing keys that all players can calculate.

So attacker publish both Processing Keys, because he can derive both (as any player). Just an example: device 12 has keys 13,7, 2 so it can derive any Leaf Device Key except key 12.

The attacker cannot derive both Processing keys. He can only derive processing keys for S-D sets that include him. He can't derive any processing key for any set that does not include him.

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.

[xyz987]

If the AACS LA knows which device is compromised, and revokes that device, all of the device keys for that device become totally useless.


I am saying there is no way to know it. All my point is this: there is no way to know it.

If you think there is a method to know which device the DK set is from, explain your method.


OK, so you are assuming they do not know the identity of the attacker? That's what Traitor Tracing is for. They have a method to find out, but they are not yet using it. They could also just assume it's one of the two PC players and revoke both sets, and force updates.


Could you explain a method of Traitor Tracing that works?

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.

[xyz987]

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.

So we are saying the same thing. AACS needs to know (or at least to figure out) which is the compromised player.

[FMalibu]

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:

1
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 3
/ \ / \
/ \ / \
/ \ / \
/ \ / \
4 5 6 7
/ \ / \ / \ / \
/ \ / \ / \ / \
8 9 10 11 12 13 14 15


Now, suppose we are a device with corresponding device node 12. The device keys given to us will be from these S-D sets: 1-2, 1-7, 1-13, 3-7, 3-13 and 6-13.

What a device has to do to find the Media Key is this:

Evaluate in which of the subset-difference trees given in the MKB its device node is located. This can be achieved by parsing all the S-D sets and seeing if the S value is a parent node of the device node, but the D node is not. If it does not find any then the device has been revoked.
Once it has found the subtree it belongs to (and it should be exactly one), the correct device key should be found.
The device key that should be used is the one that has the same S node and has either the same D node or a D node that is a parent of the D node of the subset tree from the MKB.
Note that it should have exactly one device key that fits these criterea.
In the former case, the processing key can be calculated directly with the AES-G3 function. In the latter case, the so-called subsidiary device key needs to be calculated from the device key first by iterating down the tree towards the D node of the given subtree.
Once the processing key is found, it can be combined with the C-value that corresponds to the subset-tree, also given in the MKB, to arrive at the Media Key.


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.

If you open your MKBROM.AACS and take/print the docs you can see the all this in the Explicit Subset Difference Record. It takes a little effort but the number 17h (=23d) is already telling. Maybe we should make an MKB file reader or something which graphically shows you which sub-trees are used (and thus have a C-value) and what their "shape" is (the position of the C-values in the trees creating subset-differences). Would be cool and informative in the future (when they start revoking).

I've written a small script that parses this file. I've included the output as attachment. It indicates the position and level (0=device nodes) of the S-D points found.

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

This is about the value of the Processing now and in the future. There are ways the AACS LA can issue MKBs in such a way that each disc/movie will have to use a different Processing key thus making a Processing Key in the future much less valueable. However this is really an advanced topic which requires a thourough analysis of what can and can't be done. Its very interesting in itself.

Please explain this further. How can they give S-D values that build the same tree? Or would they use some other technique?

-- FMalibu

[FoxDisc]

I am saying there is no way to know it. All my point is this: there is no way to know it.

You are right that the processing key tells only one thing - that some device in the S-D set for that processing key used their Device keys to get that processing key.

If you think there is a method to know which device the DK set is from, explain your method.

1) The main way is with sequence keys - not currently in use.
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 :-)

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.

Exactly!

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.

No- half of keyspace is not lost with key 2. You are only looking at one floor of arnezami's parking garage. Read more about subset difference sets and the AACS system. The system assumes that all device keys for any possible set of R devices are lost and the system still works.

[xyz987]

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.


Too slow. Say 1 million players are sold this year, 2 million player next year, 4 million players at 2009. Yes, I am being malicious with the numbers, but they can find that the number of players in that subtrees increases faster than the speed at they reduce posibilities.

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.


3) They read this forum and find which software player and how it was done :-)


;-DDDDD


No- half of keyspace is not lost with key 2. You are only looking at one floor of arnezami's parking garage. Read more about subset difference sets and the AACS system. The system assumes that all device keys for any possible set of R devices are lost and the system still works.

I wrote "half of master tree keyspace", not "half of keyspace". Master tree is first floor of arnezami's parking garage (the biggest one).

[xyz987]

Let's continue the example. Suppose that those devices that correspond to nodes 8,9 and 14 have been revoked. The D-S 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 D node and its S 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.


Good explanation, but your example is a revocation of noncontiguous keys. Things are different if they revoke contiguous keys. If keys 8,9 are revoked, they encrypt with key 4 of master tree, and any player can derive that key.


Indeed, there are 512 D-S 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 D-S 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 D-S value :)


They are just following their own specification. There is not "big coincidence" neither "they (stupidly) started". This is what you and FoxDisc miss. AACS LA is still at master tree (no subtrees, no subset differences), and they won't leave master tree until they need to revoke noncontiguous keys. That's why the very first C-value is the only one used.

[FMalibu]

Good explanation, but your example is a revocation of noncontiguous keys. Things are different if they revoke contiguous keys. If keys 8,9 are revoked, they encrypt with key 4 of master tree, and any player can derive that key.

Thanks.

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"?

They are just following their own specification. There is not "big coincidence" neither "they (stupidly) started". This is what you and FoxDisc miss. AACS LA is still at master tree (no subtrees, no subset differences), and they won't leave master tree until they need to revoke noncontiguous keys. That's why the very first C-value is the only one used.

I understand that you would think that (I assumed this at first as well), but please look at the text file I included. It's a bit cryptic, but I will attempt to describe what the Explicit Subset-Difference tree from current MKBs look like:

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:

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.

I agree with FoxDisc here. The system is designed in such a way to prevent exactly this. They will just map out all of the S-D sets in such a way that any node en route from the root node to the compromised device node is never inluded in them. Those are all the nodes you lose.

-- FMalibu

[FoxDisc]

Too slow.
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
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.

I was still talking about the master tree then. If they decide to split up the master tree and encrypt with multiple processing keys according to the divided master tree, they will know which set the traitor is in when he releases his processing key for his set. Future discs could then divide the set he is in into multiple other sets, etc. All of this could be done in the largest tree space. Of course, this is theoretic only. They are not doing it now, and I presume they would use the sequence key method, not this.

I wrote "half of master tree keyspace", not "half of keyspace". Master tree is first floor of arnezami's parking garage (the biggest one).

You are correct, I was rushing and missed this. Yes, half of largest (master) tree is available to all devices, so any one compromised device discloses that half. It's not a real limitation however - there are lots of remaining keys in subtrees and in the other half of the master tree.

[xyz987]

I'm not sure what "master keys" you are referring to. [...]

What did you mean by "encrypt with key 4 of the master tree"?


Just to clarify, I didn't say "master keys". And "encrypt with key 4 of the master tree" means that: "encrypt with key 4 of the master tree". AACS spec talks about a master tree, i drew an example numbered tree, and I said that numbered tree is an example of a master tree (not so big as the real one, of course). Master tree and subtrees are explained at chapter 3 of "AACS: Introduction and Common Cryptographic Elements" (see section 3.2.1). Note that this document is part of AACS spec.

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

[xyz987]

I was still talking about the master tree then. If they decide to split up the master tree and encrypt with multiple processing keys according to the divided master tree, they will know which set the traitor is in when he releases his processing key for his set.


This is not what spec says. Attacker can derive any key at master tree, they can not split master tree, any device can derive any key of master tree (except a little number of them). See section 3.2.1 of "AACS: Introduction and Common Cryptographic Elements)":

"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.

[FMalibu]

You are correct, I was rushing and missed this. Yes, half of largest (master) tree is available to all devices, so any one compromised device discloses that half. It's not a real limitation however - there are lots of remaining keys in subtrees and in the other half of the master tree.

Interesting. I was just writing a post stating that I disagree with this and working up an example explaining why, when it struck me that you're actually right. Let me give you the example to see if we're thinking the same thing.

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:

As only one device keys was released, the exact device that has been compromised cannot be determined. To fix the hole they would have to revoke all devices that have this device key.
Logically, this includes all devices in the rightmost half of the example tree, i.e. devices 12-15. This has the disadvantage of cripling any devices that happen to be in this range and potentially hurting a lot of users. Bad publicity.
Try to narrow down the comrpomised device node by actually releaseing a MKB with an overlapping collection of D-S sets. For example, suppose that a new MKB was included in subsequent releases that has 2-8, 3-6 and 3-7 as its sets. This still includes all device nodes (except 8), but disallows the use of the 1-2 device key. A new key has to be released to allow decryption, in case of device node 12 this would be 3-7. This halves the number of possible device node that could be the compromised node. This can be iterated until the compromised node is found. As FoxDisc already said, if the tree is big enough it would basically take a long time to find the compromised node. Actually, it depends on the distribution of the device nodes over the total device node space. If the distribution is random, and they keep track of device nodes not yet issued to manufacturers, it should be quite easy to eliminate device nodes that are known to be unused. If the distribution is sequential, it will get a lot harder.


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:

With the current Processing Key, all titles already out can be decrypted, given that the Volume-ID can be extracted (I've completely avoided discussion of it, belongs in another thread).
A new MKB can be released in future titles that will prevent use of this Processing Key, but will still allow all devices to find the Media Key.
Tracking down which device was compromised depends on device node distribution. My guess is that all software players will be revoked anyway, but that's an informed guess.
Again depending on device node distribution, finding the device key that a direct child of the S node of the first S-D set (or any S-D set) may be a more future-proof method for decrypting the media key, as countermeasures are harder, although it will probably be unwise to publish it before the first round of countermeasures are released. Of course it is important in this case that only 1 device key is released and that it be as high up the tree as possible (i.e. the direct child node of the S node).


I'm pretty much just thinking out loud here. Please point out the errors in my reasoning ;)

-- FMalibu

[FoxDisc]

Each of these D-S sets has a S node at the leftmost bottom of the tree where the D 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 S values as device nodes, they'll be revoked and won't work.

That info about lower left special key is based on comments from arnezami that the processing key he found lies in the lower left corner of the 22 high largest tree now in use. Since one processing key seems to work for all devices, all devices must be in the S-D set that corresponds to that processing key. That means the S-D set must be rooted up high to include all devices below it.

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.

[FMalibu]

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.

Language is a tricky thing. You'll have to excuse my thought patterns being different from yours. I'm still in the process of trying to understand it all, but writing things down and discussing them here helps a lot.

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.

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

Yes, you are correct. It is not referenced by the AACS specs (which I have read...at least the parts relevant to this discussion.). However, it is my understanding that the specs are based on the theory described in this document. It has helped me to understand the AACS specs, which in itself weren't clear to me. It is not a normative document, but if you read it and keep in mind what is said in the specs, you'll see that it matches up. Unfortunately they use slightly different terminology sometimes.

Oh, and thanks for the discussion ;)

[FMalibu]

That info about lower left special key is based on comments from arnezami that the processing key he found lies in the lower left corner of the 22 high largest tree now in use. Since one processing key seems to work for all devices, all devices must be in the S-D set that corresponds to that processing key. That means the S-D set must be rooted up high to include all devices below it.

(...)

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.

Well it sounded likely. I suppose they had to start somewhere.

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...

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.

It wouldn't make sense to un-revoke the lower-left device, since it wouldn't be able to play back current titles. I guess it's just lost forever, but that doesn't matter as the device node space is HUGE.

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

[FMalibu]

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

[arnezami]

Wow! Some solid good discussion here :).

It seems our collective understanding of the Subset-difference has grown... :D

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

[FoxDisc]

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.

If it helps, I have read all of section 3 and all other parts of the common crypto specification, with special attention to section 3.2.1. Part of the problem is that I have also read the original Naor, Naor, and Lotspiech paper:
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.

[FoxDisc]

This is not what spec says. Attacker can derive any key at master tree

This is what spec says and it is correct.

, they can not split master tree, any device can derive any key of master tree (except a little number of them). See section 3.2.1 of "AACS: Introduction and Common Cryptographic Elements)":
"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.

This is also all correct, except the part where you say "they cannot split the master tree." Why can't they split it? The attacker device does not have the "keys between its leaf and the root" as you quoted. The key just below the root that an attacker does not have is the processing key that half of the devices have and half do not have. Think about S-D sets. Half the devices are in the S-D set for key 2 and half are in the S-D set for key 3. The attacker does not have one of those keys. Half of the possible devices do not have it. Half do have it. No device has both. If the media key is encrypted twice, once with key at 2 and once with key at 3, all devices could decrypt, but half would have to use a different processing key, and this would tag them as being in one group or the other. This may be what arnezami refers to in later post as "fake player revocation" (perhaps not, I have read his post only briefly and not absorbed it yet)
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.

[FoxDisc]

Interesting. I was just writing a post stating that I disagree with this and working up an example explaining why, when it struck me that you're actually right.

I have done that many times :) Usually I realize my error after I post :) While writing this post to explain why I was right, I realized that perhaps you are right :) I was writing very loosely

Let me give you the example to see if we're thinking the same thing.
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.

Just for clarity For those reading along, the notation used by FMalibu for S-D set 1-8 means the set of all devices under node 1 minus all those under node 8. The S-D set 1-8 is devices 9-15

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?

You are right that release of that one key would compromise half of the keys.

In this case they could do one of two things:

As only one device keys was released, the exact device that has been compromised cannot be determined. To fix the hole they would have to revoke all devices that have this device key.
Logically, this includes all devices in the rightmost half of the example tree, i.e. devices 12-15. This has the disadvantage of cripling any devices that happen to be in this range and potentially hurting a lot of users. Bad publicity.
Try to narrow down the comrpomised device node by actually releaseing a MKB with an overlapping collection of D-S sets. For example, suppose that a new MKB was included in subsequent releases that has 2-8, 3-6 and 3-7 as its sets.

These are not "overlapping" they are still disjoint sets, but yes, that is what I was discussing - traitor tracing as a secondary use of the processing key and revocation procedure.

This still includes all device nodes (except 8), but disallows the use of the 1-2 device key. A new key has to be released to allow decryption, in case of device node 12 this would be 3-7. This halves the number of possible device node that could be the compromised node. This can be iterated until the compromised node is found. As FoxDisc already said, if the tree is big enough it would basically take a long time to find the compromised node. Actually, it depends on the distribution of the device nodes over the total device node space. If the distribution is random, and they keep track of device nodes not yet issued to manufacturers, it should be quite easy to eliminate device nodes that are known to be unused. If the distribution is sequential, it will get a lot harder.


This is all some nice theory, but no device key was released, so let's discuss countermeasures for the Processing Key :)

Although no device key was released, the processing key for set 1-8 was released. This discussion came from how they might do traitor tracing, since the processing key tells them nothing except that some member of the S-D set released it. Some have wondered why they did not start out with multiple disjoint S-D sets from the beginning.

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.

Yes.

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.

Yes. This is exactly what I was saying. Divide it into two will disallow the current procesing key, but not require revocation. Dividing in two give som limited inforamtion for future traitor tracing. They could also divide it into even more sets for more information in the future.

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.

In summary, I think I can say the following:

With the current Processing Key, all titles already out can be decrypted, given that the Volume-ID can be extracted (I've completely avoided discussion of it, belongs in another thread).
A new MKB can be released in future titles that will prevent use of this Processing Key, but will still allow all devices to find the Media Key.
Tracking down which device was compromised depends on device node distribution. My guess is that all software players will be revoked anyway, but that's an informed guess.
Again depending on device node distribution, finding the device key that a direct child of the S node of the first S-D set (or any S-D set) may be a more future-proof method for decrypting the media key, as countermeasures are harder, although it will probably be unwise to publish it before the first round of countermeasures are released. Of course it is important in this case that only 1 device key is released and that it be as high up the tree as possible (i.e. the direct child node of the S node).


I'm pretty much just thinking out loud here. Please point out the errors in my reasoning ;)

-- FMalibu

I agree with all you have posted. I really have not thought too much about releasing device keys, as no one seems to have any to release!

[FoxDisc]

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.

I wrote pporly and did mean to say that it worked for all titles, but this raises an interesting question, and begins to tread in an area you have looked at more closely than I - the organization of the MKB. The processing key matches an S-D set of devices. Are all current devices a member of that set? We know that one is not - the special lower left device, but that we can ignore as no device has been revoked yet. We also know the root of the S-D set for this processing key is at level 22, not the highest root. Are all devices below this root at level 22 or not? I gues we don't know.

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.
Can you explain this better? What S-D sets are currently defined in the MKB? I know I need to read your text file more closely to understand.

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.

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...

So the "another S-D set" you refer to might be that line:
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

It wouldn't make sense to un-revoke the lower-left device, since it wouldn't be able to play back current titles.

True. Obvious mistake by me.

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.

I wondered when you would spot that.

[FoxDisc]

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.
-- FMalibu

This is how I think it works too. FMalibu has described it somewhat differently than the AACS specs, and it took me a while to reach the same answer he has reached - by reading non AACS work. I will throw in one important additional feature here: "There is one master tree and every node in this tree has a master key."

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.

[FMalibu]

Wow! Some solid good discussion here :).

It seems out collective understanding of the Subset-difference has grown... :D

Damn you for making me so curious ;)

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

That much is true. I was merely speculating on something that would perhaps be more valuable in light of countermeasures, but obviously something that is more valuable will also be harder to obtain.

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 disc (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.)

I think I see what you're getting at. By revoking a different fake nodes for each disc you get a different tree structure and a different Explicit Subset-Difference Record in each. BTW, did you mean title or actual disc? Including a different MKB for each individual disc seems unfeasable and not economically sound when it comes to pressing discs. Maybe for different batches.

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

It will be quite interesting to see what countermeasures will be taken. For the current generation of titles the one processing key suffices. As many people have already speculated, it will be much of a cat-and-mouse game.

-- FMalibu

[FMalibu]

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

These are not "overlapping" they are still disjoint sets, but yes, that is what I was discussing - traitor tracing as a secondary use of the processing key and revocation procedure.

By overlapping I meant that they are not disjoint because they both share node 3. But indeed this is the only node they share. The device nodes are still disjoint. And yes, I was describing the traitor tracing you were discussing.

Some have wondered why they did not start out with multiple disjoint S-D sets from the beginning.

They have! See the description of the MKB later on.

Yes. This is exactly what I was saying. Divide it into two will disallow the current procesing key, but not require revocation. Dividing in two give som limited inforamtion for future traitor tracing. They could also divide it into even more sets for more information in the future.

For some reason I thought instantly dividing it into more than two wouldn't work, but I see you're right now. In the example of the compromised device node 12, instead of making it 3-6 and 3-7 they could use 6-12, 6-13, 7-14 and 7-15. If another processing key is released this would tell them instantly which device was compromised (the 6-13 device key of the device with device node 12 would be used).

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.

That's the question. Are they assigining them randomly? Also, 1-4 would make more sense, as device 8 is already revoked ;)

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":

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 specs work with masks, but I found this notation to be a little more intuitive. The level indicates how high up the tree the node is. Level 0 is a device node, the root node is at level 31 (or 30?), making a total of 32 (31?) levels. As you can see, the S node for each S-D set is located at level 22. (I'm not sure about my maths here...)

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.

This is how I think it works too. FMalibu has described it somewhat differently than the AACS specs, and it took me a while to reach the same answer he has reached - by reading non AACS work. I will throw in one important additional feature here: "There is one master tree and every node in this tree has a master key."

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.

Exactly! They are fully random and independent values.

Somehow section 3.2.1 is misleading (it does say "Informative") and slightly at odds with the rest of the document.

-- FMalibu

[arnezami]

BTW, did you mean title or actual disc? Including a different MKB for each individual disc seems unfeasable and not economically sound when it comes to pressing discs. Maybe for different batches.
Yeah. I'm sorry. I meant Title/movie.
It will be quite interesting to see what countermeasures will be taken. For the current generation of titles the one processing key suffices. As many people have already speculated, it will be much of a cat-and-mouse game.

Yeah. But don't forget: they are the mouse. We are hunting for them or better: their methods and keys ;).

In fact: there are many cats around here..

[arnezami]

Somehow section 3.2.1 is misleading (it does say "Informative") and slightly at odds with the rest of the document.
Just for the record I believe section 3.2.1 is badly written and simply isn't very informative: it doesn't fill the gap between its very (and too) general explanation and the more precise and technical sections that follow.

In fact it was exactly this gap I wanted to fill :). And something tells me it worked...

[FMalibu]

Just for the record I believe section 3.2.1 is badly written and simply isn't very informative: it doesn't fill the gap between its very (and too) general explanation and the more precise and technical sections that follow.

In fact it was exactly this gap I wanted to fill :). And something tells me it worked...

I would say it verges on being incorrect, but I can't prove it, that's why I'm sticking to misleading.

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.

[arnezami]

I would say it verges on being incorrect, but I can't prove it, that's why I'm sticking to misleading.

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.

The point of the using trucks is to make a more physical analogy instead of a mathematical one. In my experience this works better for getting the gest of an idea. More accurate (and mathematical/logical) analyses will usually follow. This choice was very deliberate.

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

[FoxDisc]

They have! See the description of the MKB later on.
Yes, as I looked closer at your file on the MKB, I suspected that.

This means that all nodes at level 22 are represented as S nodes.

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?

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 somewhere along the base of the first pyramid.

I had this picture before I opened your file or read your response. :-) I just needed to be sure that was what was in the MKB.

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.

[FMalibu]

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


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...

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

[arnezami]

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.

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:

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:

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:

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:

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.

[FoxDisc]

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?

[xyz987]

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.

[FoxDisc]

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.

[xyz987]

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

[FoxDisc]

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.

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.

[xyz987]

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.


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.


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.

[FoxDisc]

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?"

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.

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.

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

[xyz987]

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.


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.


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:


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.


2)The other entries are for similar S-D sets within the larger master tree.


The other entries are just not used nowadays.


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


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.

[FoxDisc]

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.

[xyz987]

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]

The AACS specs says that S-D sets may also be called "NNL sets."


This is far interesting. Where does spec say "NNL sets"?

[FoxDisc]

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.

[xyz987]

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.

[FoxDisc]

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)

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.

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.

[FoxDisc]

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.

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.

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.

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.

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

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.

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.

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.

[FoxDisc]

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.

[xyz987]

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".


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


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.

[FoxDisc]

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

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.]

Not so isolated, read above.

I'm not sure how the above makes them not isolated.

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. :o

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!

[FoxDisc]

If anyone has followed along this thread, they will realize the complexity of this subject. I thought I might add some things that will help simplify why the AACS LA chose this system. It's not just because it's complicated.

Let's say we want to build their DRM system:

Our first crack at it:
A simple design would be to give every player/device a secret device key. Then we encrypt the media key (the media key lets us decrypt the movie) with every secret key for every device and put all those encrypted copies of the same media key on the disc. Each device would look through all the encrypted copies of the media key on a disc until it found the one it could decrypt. To "revoke" a device we just leave off the copy of the media key encrypted with his secret key!

This would work but it takes lots of space on the disc. We need room for every device present and future. We need keys that are secure (16 bytes minimum). With all those keys, there's no room for the movie!

That was their first concern. They didn't want to use up all the space on the disc.

Our second crack at it:
OK, how about this - we put the devices into lots of overlapping groups. Each device goes into many groups. We assign a secret key to each group. If a device is in a group, he gets the secret key for that group. If he's not in that group he doesn't get the key. Now, the devices have to store more than one key.

What do we do with the disc? Well, we start off by encrypting the media key only once using the key for a really big group that everyone is in. Since they all have that key, every device can decrypt it. This is looking good! We only had to use one key on the disc! We've reduced the space used on the disc by making the devices store more keys.

So how do you "revoke" devices? You stop using the key for the big group (everyone, including the bad boys have that key), and you use keys for smaller groups that the revoked devices don't belong to, but the unrevoked devices do.

This is essentially what the AACS did! A "subset difference set" is just a group of devices. A processing key is just a secret key assigned to that group. All this stuff about subset difference sets is all about ways to divide up the devices into groups so we can give a secret processing key to that group. It's fundamentally simple.

So how do we divide up the devices into groups? How do we decide how many keys to give each device? How do we make sure we can always exclude all the devices that need to be excluded while allowing all the devices we want? How do we know who leaked a key so we can exclude him? How do we make sure that knowing one key doesn't let the bad boy figure out any others? How .....

Whoa! Enough questions already ....... it's time to call in the experts - cryptographers and mathematicians. They think about this for a long while and they come up with: The Subset Difference System.

[arnezami]

@FoxDisc very well put. I will put a link to this post (or quote it) so others/newcomers will be able to find it.

It's fundamentally simple.

Very true. :D

[FoxDisc]

I thank arnezami for his kind comments.

In my last post, I ended with some questions. The most important one was: How do you divide the devices up into groups? I'm going to try to answer that question here. More specifically, I'm going to try to explain why they chose this strange "subset difference set" to be the group of devices. We'll use the same procedure we used before - let's try to do this ourselves and see what works.

If you've read anything here, you know that we're going to use some kind of tree like this:


1
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 3
/ \ / \
/ \ / \
/ \ / \
/ \ / \
4 5 6 7
/ \ / \ / \ / \
/ \ / \ / \ / \
8 9 10 11 12 13 14 15



The experts call this a "binary tree" since it starts at a "root" node (number 1) splits in two to reach two more nodes (2 and 3) and each of those nodes splits in two, etc. 'til you get to the bottom level where the nodes are sometimes called "leaves."

The leaves (8-15) are our devices. Remember that every group is going to be assigned a secret key and every device gets all the secret keys for all the groups he belongs to and none for groups he does not belong to.

OK, here's our first shot at dividing up the 8 devices/leaves on the bottom row into groups. We'll start off simple: A device is a member of a group if he's below a node. He's not a member if he's not below a node. (We'll later call the node above him an "S-node".)

Example time! Group 4 includes devices 8 and 9. Group 2 includes devices 8-11. Device 8 is a member of groups 1, 2 and 4. He's also a member of group 8 (himself). He's not a member of any other groups.

What secret key do we assign to each group? We'll use a random number generator and assign one to every number in the tree. That number is the secret key. (Keep this master tree with random numbers assigned to every node in mind - we'll use it later. The AACS really did this, and they really have such a tree of random numbers. It is the holy grail of their system, and no one except the LA has any of those numbers.)

This looks pretty good so far. Device 8 only has to store four secret numbers for groups 1, 2, 4 and 8. Device 13 also only has to store four secret numbers for groups 1, 3, 6 and 13. Every device stores only 4 numbers. Not too bad! Our disc only has one copy of the media key encrypted with the processing key/secret number for group 1. Everyone can decrypt it since they are all members of that group and all have the processing key for group 1.

Hey this is great! ..... So far...... But along comes a bad boy and he's stolen our secret keys in device 8. We have to punish him! No more decrypting for 8! He is "REVOKED!"

So this is simple. We just stop using processing key 1 to encrypt our media key. Hmmmmm. I guess we can't use 2, 4 or 8 either! Bad boy number 8 has those too. We just have to use groups that he is not a member of. But, we have to make sure we let everyone else decrypt. They are not bad boys.

So here's what we do: We encrypt the media key with the secret numbers for 9, 5 and 3! Now everyone can decrypt it except bad boy 8! We showed him! Except, notice that we started with only one encryption on the disc, but now we've got 3, and we only revoked one bad boy. We had to use all the keys on the branches that lead away from him (His path to the root is 8-4-2-1 and the branches off that path are at 9, 5 and 3. We'll call this the path from a device to root the "device path" and the nodes off that path the "branch nodes"). Even worse, what if this tree was 32 levels high like the real master tree? We would have had to add 32 new entries just to revoke one bad boy!

That's why the AACS used a different system than the simple system described above. They were still worried about running out of space on the disc!

Our simple system in our first crack at this did not make enough groups! We need more groups with more secret processing keys. When we made the group include everyone below a node, they only had one group for every level of the tree. If we can make more groups, a device will have to store more keys, but it will be easier to exclude them, because there will be more groups that he doesn't belong to.

Let's take our second crack at making groups of devices:
Here's what we need: We need more big groups that do not include bad boys. It's really simple. (Can you believe this guy! "Simple" Hah!) We'll take our old group (everyone below an S-node) and we'll kick out of that group everyone below some other node that's below the first node.

That is exactly what the AACSLA did! (I think I read that in the last post!) They called this group of devices a "Subset Difference Set." The upper node is the S-node, the lower node is the D-node. Everyone below the upper S-node is in the subset difference set UNLESS they are also below the lower D-node. We'd have to call on those mathematicians to prove it, but with S-D sets, on average, we only need to add between 1 and 2 encrypted copies of the media key to the disc to revoke our bad boy.

Hang on - we're making progress. All we've got to do now is give all of our devices all the processing keys for all the S-D sets that they belong to! There's only one small problem. There are an awful lot of S-D sets! We tried to make a lot of them, and we succeeded. There are so many different S-D sets that no device has enough memory to store all his keys! Great system! We traded not enough room on the disc for not enough room in the player device!

Here's how they solved that. Remember that master tree with all the assigned random numbers from our first crack at this? (I told you to remember that - why didn't you?) They figured out a way to calculate all the processing keys for all the S-D sets that start at any S-node from that one secret random number in the holy grail tree! Using a "one way function" they start with the secret number for the S-node and they calculate another secret number (a processing key) for each D-node below it. The processing key for an S-D set that starts at S and ends at D is the number assigned to D that was calculated from the original secret random number assigned to S. Because they used a one way function, if they give device 8 the processing key for S-D set 1-7. he can't figure out the secret random number for node 1 and he can't figure out the processing key for set 1-8. (The set 1-7 starts at node S=1 and excludes everyone below node D=7. Device 8 is a member of that set since he is not excluded. Set 1-8 starts at 1, and excludes node 8. Device 8 is not a member of that set.) The AACSLA never gives out the S-node secret random numbers.

Now suppose they gave a device all the secret S-node numbers in the holy grail tree that lie on his device path. That would be exactly equivalent to our first system. A device could calculate all the S-D sets below every node on his device path to the root! That's no good. He's not a member of some of those sets. We have to prevent him from calculating the processing key for an S-D set when D is on his device path.

Here's how they solved that: Remember those "branch nodes" off the device path? (Now what did I tell you about this remembering thing? Try to keep up here - we're moments from the end!) If they keep the S-node secret random number secret, but give every device all the processing keys on the branch D-nodes that are calculated from the S-node secret number, then the device can calculate all the other processing keys it's entitled to, but not the ones it isn't! The branch node processing keys are called "Device Keys." That's it. The end. (Well almost.)

Sequel:
The AACSLA master tree of S-node secret random numbers is 32 levels high. (We refer to the bottom level as level 0 and the root as level 31). For some reason, the AACS LA started off with 512 S-D sets at level 22, not one big one rooted at level 31. Each device is a member of only one of those 512 sets, so it only gets device keys for the 0-22 branch nodes.

[FMalibu]

Hi, keeping up with this thread is a dayjob in itself, so I won't reply to everything :)

@arnezami:
This KCD intrigues me. I hadn't read up on it and just skipped over it before, assuming it was something to do with BD+ or something. Do you know if it's even used in standalones? Is that mandatory? Indeed, the first S-D tree leads to a plain media key, so if KCD is even used then it would have to be in any of the other 511 trees.

@xyz987:
A lot of confusion in this thread is caused by difference in terminology. It doesn't help that section 3.2.1 seems to be...well weird. I'm can see what you mean now though, and if I apply slightly different terminology it seems to be correct ;)

@FoxDisc:
Good explanation, nicely analogous to NNL paper. Again about terminology, I think you should have used "subsidiary device keys" in place of "processing keys" sometimes. Also, more examples == better!

-- FMalibu

[xyz987]

@xyz987:
A lot of confusion in this thread is caused by difference in terminology. It doesn't help that section 3.2.1 seems to be...well weird. I'm can see what you mean now though, and if I apply slightly different terminology it seems to be correct ;)


Yeah, terminology is being a real problem. AFAIK i am using AACS terminology. Afortunately, it seems that the worst terminology problems have been sidestepped.

Section 3.2.1 looks so weird for the reason arnezami pointed: there is a gap between the (far general) section 3.2.1 and the (far precise) rest of the spec. My opinion about that section is that it is describing things in a right way (it was written by spec authors), and problems to understand it are just caused by the infamous gap.

[xyz987]

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


From NNL paper:

"In both the Complete Subtree and Subset Difference methods, a unique label is associated with each node in the tree. Storing these labels explicitly at the Center can become a serious constraint. However, these labels can be generated at the center by applying a pseudo-random function on the name of the node without affecting the security of the scheme. This reduces the storage required by at the Center to the single key of the pseudo-random function."

NNL says that using pseudo-random keys (labels) is safe. Just to clarify: "random" and "pseudo-random" are not the same thing.

Anyway, AACS is *not* using random keys in master tree (22 level tree) neither subtrees (21 level and lower). Device Keys are not random. Players 9 and 15 will compute the same arnezami's PK. Player 9 will compute it directly from its DK 8. Player 15 will compute Subsidiary Device Key 4 from its DK 2, and later it will compute 8 from 4. Subsidiary DK 8 (computed by player 15) is the same key that Device Key 8 from player 9 DK set.

Root keys at the mentioned trees (22 level and lower) may be random, but the rest of the keys at that trees are not.

Of course, the rest of the keys at 31 level tree may be random, spec says nothing about it.

[arnezami]

@arnezami:
This KCD intrigues me. I hadn't read up on it and just skipped over it before, assuming it was something to do with BD+ or something. Do you know if it's even used in standalones? Is that mandatory? Indeed, the first S-D tree leads to a plain media key, so if KCD is even used then it would have to be in any of the other 511 trees.

Right now there is no real way to be sure if the KCD is used for standalones yet. If they don't use it yet they can do it for later discs.

The point of the KCD is to prevent using (many different hacked) standalone players to get Device or Processing Keys. These keys (from standalones) are useless now. Keep in mind: many software players all have the same Device Keys, but standalones have different for each (well they should ;) **). The reason these keys are useless is because a KCD based system reveals the Media Key Precursor which together with the KCD in turn produces (in a one-way fashion) the Media Key. In fact (if they implemented the KCD) our Media Key is the result of a one-way operation on the Media Key Precursor and the KCD on that disc (in other words: they couldn't simply choose any Media Key they wanted. They produced the Media Keys by choosing a Media Key precursor and/or KCD first).

So we might find a Device or Processing Key from a standalone but we can only decrypt a C-value which produces a Media Key Precursor. But without a KCD (not readable by PC drive) these Keys are useless for non-KCD systems.

What could theoretically be done? Hack the firmware of a standalone (of a well sold one). Try to figure out how the KCD is put on the disc. Then "teach" the most common PC based drives (by firmware patch) to read the KCD. And of course include some command to retrieve the KCD. And voila :). We could use the device/processing keys of every standalone in the world (and there will be many...). They cannot "harden" already sold standalone players so this would be pretty much game over (=known method of retrieving Device/Processing Keys from a standalone and just a PC drive patch needed for people to decrypt discs). Although the sequence keys come in to play here. But at worst this would "only" cost one standalone every so many months... (which is already hacked so it can be reprogrammed anyway, so no real loss)

The question is: can PC drives (physically that is) read the KCD at all?

I can't answer that question but my gut says yes: why make its method of storage "confidential" in the first place?

Ooh. I'm really devious here :devil:

Regards,

arnezami

** if they didn't give standalones unique Device Key sets then they are sooooo screwed...

[xyz987]

They cannot "harden" already sold standalone players so this would be pretty much game over (=known method of retrieving Device/Processing Keys from a standalone and just a PC drive patch needed for people to decrypt discs).


Great!

This kind of thing can break AACS completely if someone figures out how to sidestep Sequence Key set revocation.


Although the sequence keys come in to play here. But at worst this would "only" cost one standalone every so many months... (which is already hacked so it can be reprogrammed anyway, so no real loss)


Note that SKs and SKBs are highly decoupled of DKs and MKBs. Standalone player owner can publish the end sub DK (or the PK), and SKs can be from a soft player. Traitor tracing (SKs and SKBs) will detect the soft player, not the standalone. Furthermore, traitor tracing is useful only if attacker publish Media Key Variants (from a soft player, for example). Attacker can not be traced if he doesn't publish Media Key Variants. The problem is that a Sequence Key set can be revoked, so it can not be published. Soft player user is let alone to solve the problem of getting the SKs.


I can't answer that question but my gut says yes: why make its method of storage "confidential" otherwise?


If they are relying on "security through obscurity" they are dead. This is always a Bad Idea.

[FoxDisc]

@FoxDisc:
Good explanation, nicely analogous to NNL paper. Again about terminology, I think you should have used "subsidiary device keys" in place of "processing keys" sometimes. Also, more examples == better!
-- FMalibu
Yes, I suppose I should have gone into the fact that a starting number (device key) processed through the one way function leads to a number that is three times as big, with the middle section being a processing key and the right and left sections being the subsidiary device keys for the right and left branches. I'd already spent so much time on it, however, I just left it as was.

[HyperHacker]

Thanks, that explanation was a huge help. :)

Is revocation not a weakness then? Right now the media key is encrypted only once on the disc, with the device key for node 1, but if they wanted to revoke a device they'd have to include a few different copies of the media key encrypted with different device keys; is this right? So then we have a few blocks that we know will all decrypt to the same plaintext. I'm no cryptographist but this seems like a potential weakness...

[xyz987]

Although the sequence keys come in to play here.


A hacked firmware for standalone player can also give Sequence Keys to attacker. Attacker can buy a standalone player, flash it with a hacked firmware, get the keys, flash it again with original firmware and return player to shop (in some countries there is a time of several days to lawfully return a product to shop).

AACS LA would be tracing someone else player.

However real problem remains: if a Sequence Key set is published, that set can be revoked. It is valid for all previously released movies, but not for future ones.

[xyz987]

There is a way to sidestep Sequence Key set revocation. A Sequence Key set can be revoked, but spec clearly says it is impossible to revoke a single SK, because many players share it. So an attacker that gets several SK sets from different players can wait until AACS LA "activates" SKB (i.e. Media Key Variant is used to encrypt part of the movie), and then attacker can publish one SK from one of his SK sets. Then AACS LA will release new movies with an "updated" SKB (where this published key is considered "compromised"), then attacker will publish another SK from another SK set, and so on. Sequence Key sets are never revoked this way.

[arnezami]

Regarding the KCD idea (stealth firmware):

What would be really cool is to let the "updated" firmware of a PC drive give the KCD and the Volume ID as the first response the drive gives back during the AACS-auth process (Dn|Dcert). It would only do this when we give him the Media Key Precursor first as Hn (so it can calculate the Media Key and check if its correct and only then return the KCD+VID as Dn|Dcert). Since our independent software decrypter/player would have a Processing/Device key from a standalone it can calculate the Media Key Precursor and make the drive give the KCD and Volume ID. However there is no way they can let a official Software Player check if the drive firmware is hacked (by checking whether it gives the KCD or VID) because it cannot make the drive give back the the KCD and Volume ID! It would need the Processing/Device Key of a standalone for that! And thats exactly what they do not want to give to software players :devil:

http://img246.imageshack.us/img246/8592/evilgi9.png

We would be beating them at their own game. :D

Of course this all depends on whether PC drives can actually read the KCD in the first place.

This could be the 3rd-generation way of decrypting discs (using standalones for device key retrieval and using them in PC based systems) The first-gen being direct VUK retrieval (WinDVD memory picking). The second-gen would be the Software Player key snoops/debugs: getting Device/Processing Key + Host Private Key (+Cert). Thats what we are still working on now. Maybe in a year or so will we be needing this new (3rd gen) technique (eg. when no software players are allowed anymore or are very hard to break or are only allowed to run on vista etc) and we'll probably need that time to properly develop this new technique.

Right now I believe we should concentrate on getting a Host Private Key (+Cert) from a software player. That would be really nice. :)

[FoxDisc]

My two long explanatory posts were an effort to follow in arnezami's footsteps and simplify, simplify.

The first post was an attempt to explain the simple concept of overlapping groups of device with an associated secret number assigned to each group. I was focusing on the "why" overlapping groups were chosen. By giving the secret number to everyone in a group, and not giving it to anyone else, the AACSLA could shift initial key storage away from the disc and into the player devices.

The second post was an attempt to explain why they chose the specific type of overlapping groups (S-D sets). S-D sets do seem like an odd choice, but they were chosen out of the necessity to have lots and lots of such groups. I was focusing on "why" they needed so many groups - again to minimize the space used on the discs, but this time it was for minimizing space used up for each revocation.

On the issue of terminology:
I started off trying not to use any words from the spec for the secret number assigned to a group. I should have tried harder. The terms "secret number," "secret key" "random number," pseudorandom number," "device key," "processing key" and "subsidiary device key" are all words that refer to the original simple concept of a secret number assigned to a group of devices. They are all either the secret number assigned to a group or they are some other number that can be used to calculate the secret number. The true name for that secret number when it's assigned to an S-D set is "processing key," but I started with ordinary sets, not S-D sets, so I didn't want to call the secret number a processing key and I didn't want to go into details of how processing keys were derived from device keys.

[FoxDisc]

The question is: can PC drives (physically that is) read the KCD at all?

The HD DVD and DVD Pre-recorded Book says that the KCD is stored in the Copyright Data Section of the lead in area.
It's right after the lsb_64 of the volume id. If the volume id can be read, doesn't that mean the PC drive should be able to read the KCD?

[arnezami]

The HD DVD and DVD Pre-recorded Book says that the KCD is stored in the Copyright Data Section of the lead in area.
It's right after the lsb_64 of the volume id. If the volume id can be read, doesn't that mean the PC drive should be able to read the KCD?

Very possible.

[FoxDisc]

They cannot "harden" already sold standalone players so this would be pretty much game over (=known method of retrieving Device/Processing Keys from a standalone and just a PC drive patch needed for people to decrypt discs).
Great! This kind of thing can break AACS completely if someone figures out how to sidestep Sequence Key set revocation.

When I first read arnezami's quote, I didn't understand it. They can always revoke a device. I thought perhaps he meant that they wouldn't dare revoke a widely sold player device. Of course, it's possible that every standalone device out there uses a different set of keys. Then they could revoke player serial #1 from mnfr A without revoking serial #2 of the same model and same mnfr A.

Then I thought perhaps he meant that if there was a method to get device keys out of standalones (plus KCDs), and if that method was quick, then attackers could stay ahead of disc releases and the whole system would collapse. Of course, something like that is already in place with software players, so the whole KCD thing would be a non-issue.

Your comment about sequence keys made it even more confusing to me.

Note that SKs and SKBs are highly decoupled of DKs and MKBs. Standalone player owner can publish the end sub DK (or the PK), and SKs can be from a soft player. Traitor tracing (SKs and SKBs) will detect the soft player, not the standalone. Furthermore, traitor tracing is useful only if attacker publish Media Key Variants (from a soft player, for example). Attacker can not be traced if he doesn't publish Media Key Variants. The problem is that a Sequence Key set can be revoked, so it can not be published. Soft player user is let alone to solve the problem of getting the SKs.

Since SKs are not being used now, there has been little discussion of them. My understanding was that they lead to a different decrypted movie. For example, device #1 decrypts the movie and you see a car with license plate #1 go by. Device #2 decrypts movie and you see a car with license plate #2 go by. The AACSLA can tell from the movie released which device decrypted it. I would not expect that the DKs from one player would work with the SKs from another, but perhaps you have reviewed this? Do you want to discuss your analysis of SKs?

[xyz987]

Then I thought perhaps he meant that if there was a method to get device keys out of standalones (plus KCDs), and if that method was quick, then attackers could stay ahead of disc releases and the whole system would collapse. Of course, something like that is already in place with software players, so the whole KCD thing would be a non-issue.


Just think about what i have previously written about an attacker that gets a DK set but he only publishes the (sub) DK that is directly used to compute PK. It is impossible to trace attacker with just one revocation, and several revocations need time. Furthermore, an attacker can simply stop publishing new keys as soon as AACS LA is getting closer, so in fact attacker is never located neither his player is revoked. Using MKB to do traitor tracing is far slow and unefficient (also note MKB was never intended to do so).

The advantage of getting DKs from an standalone player is that already sold home theater players can not be hardened. If they have a hole, they will have that hole forever. Soft players can be upgraded, and users can be forced to upgrade (just revoking previous versions). Standalones can not be upgraded.


Since SKs are not being used now, there has been little discussion of them. My understanding was that they lead to a different decrypted movie. For example, device #1 decrypts the movie and you see a car with license plate #1 go by. Device #2 decrypts movie and you see a car with license plate #2 go by. The AACSLA can tell from the movie released which device decrypted it. I would not expect that the DKs from one player would work with the SKs from another, but perhaps you have reviewed this? Do you want to discuss your analysis of SKs?

Yes, the DKs from one player will work with the SKs from another player. MKB and SKB are almost entirely decoupled, the only linkage is Media Key, and Media Key is the same for each movie, no matter which PK the player have used to decrypt Media Key.

The output of "MKB system" is Media Key and only Media Key, the input of "SKB system" is Media Key and only Media Key. Both systems are decoupled.

SKs and SKB can trace the player SK set is from, not the player DK set is from.

[dirio49]

I don't know much about in cryptology or whatever.
But I saw a video on youtube, a person opened up a standalone Hddvd player and the drive was just a standard computer drive ;)

here is the link.

http://tinyurl.com/27hvrk

[arnezami]

I don't know much about in cryptology or whatever.
But I saw a video on youtube, a person opened up a standalone Hddvd player and the drive was just a standard computer drive ;)

here is the link.

http://tinyurl.com/27hvrk

Cool :)

This opens possiblities...

As an aside: if they just happen to so stupid not to give each standalone their own unqiue set of Device Keys and it is possible for PC drives to read KCDs then one set of DKs will open up AACS completely (requiring only a firmware patch). The only thing they could do then is to revoke all these standalones of that particular company.

Now surely they haven't been that careless... ;)

[HyperHacker]

A hacked firmware for standalone player can also give Sequence Keys to attacker. Attacker can buy a standalone player, flash it with a hacked firmware, get the keys, flash it again with original firmware and return player to shop (in some countries there is a time of several days to lawfully return a product to shop).

AACS LA would be tracing someone else player.
This seems like the way to go. We get the keys for basically nothing from a variety of devices. If they revoke those devices, or try to trace them, they'll be hassling innocent consumers, which is a bonus as people will soon get sick of the whole thing.

I don't know much about in cryptology or whatever.
But I saw a video on youtube, a person opened up a standalone Hddvd player and the drive was just a standard computer drive ;)

here is the link.

http://tinyurl.com/27hvrk
Oh dear God. XD Yeah, that's content protection alright! PC IDE drive, easily removeable RAM and flash ROM, x86 CPU... It'd be pretty hard to crack that! ;-)

Standalones can not be upgraded.
They could have rewriteable firmware, and use revocation to force the user to upgrade the firmware via a disc they get from the manufacturer. It'd be a pain, and not especially effective, but possible.

[xyz987]

They could have rewriteable firmware, and use revocation to force the user to upgrade the firmware via a disc they get from the manufacturer. It'd be a pain, and not especially effective, but possible.

HyperHacker, some standalone player users have problems with the remote control, they can use just the most basic buttons of it. I find highly improbable this kind of users can flash an upgraded firmware.

For this kind of users a disk that doesn't play is a broken disk. They will return it to shop. If the player doesn't play several disks, they will return the player.

For us, tech guys, it is hard to imagine the extremely low knowledge of these users, but they are far numerous.

[Mug Funky]

revoking standalones would be a last resort for AACS-LA.

mainly because the format (HD or BR) with the least revoked players will win, and that'd cause a legal nightmare for all concerned - the "losing" format's member companies will be quite annoyed at AACS-LA no doubt, and i can't see it playing out well for anybody. even the winning format will have tons of revokations and disillusioned customers who've realised that 5% more sharpness with 20% more artefacts plus buying a new player every week isn't a good deal compared to DVD.

[HyperHacker]

HyperHacker, some standalone player users have problems with the remote control, they can use just the most basic buttons of it. I find highly improbable this kind of users can flash an upgraded firmware.

For this kind of users a disk that doesn't play is a broken disk. They will return it to shop. If the player doesn't play several disks, they will return the player.

For us, tech guys, it is hard to imagine the extremely low knowledge of these users, but they are far numerous.
I'm aware of how dumb people can be when it comes to technology ("can you put the internet on this floppy disk"), but if properly designed, the procedure could be as simple as calling tech support, giving them your address, receiving a disc in the mail, and putting it in the player.

[Jay Bee]

I'm aware of how dumb people can be when it comes to technology ("can you put the internet on this floppy disk"), but if properly designed, the procedure could be as simple as calling tech support, giving them your address, receiving a disc in the mail, and putting it in the player.

That's the simplest way, yes. But I'd say it's already far too much hassle for most people to accept: They paid for a player and some disks and now they have to go to tech support because pirates cracked the protection? (not saying the guys who did this are pirates of course)

[Punqtured]

That's the simplest way, yes. But I'd say it's already far too much hassle for most people to accept: They paid for a player and some disks and now they have to go to tech support because pirates cracked the protection? (not saying the guys who did this are pirates of course)

As Xyz987 wrote at some point earlier, most consumers wouldn't know why their player suddenly won't work, and instead of calling some tech-support, they'd simply return their player because "it's broke - please fix it".

Apllying this scenario too often would cause consumers to simply disregard given products, which in time would cause manufacturers to stop producing such players wich again would be the end of either format.

[xyz987]

I'm aware of how dumb people can be when it comes to technology ("can you put the internet on this floppy disk"), but if properly designed, the procedure could be as simple as calling tech support, giving them your address, receiving a disc in the mail, and putting it in the player.

It is hard to believe, but below are real life cases (I have worked on tech support for years):

Calling tech support: they don't know the number. It is on box and also on instructions, but they don't see it is on box neither on instructions.

Giving them your address: some people don't know which is their own address.

Receiving a disc in the mail: for various reasons, some people say that they haven't received it.

Putting it in the player: i have no experience about such kind of real life cases. However I can imagine that some people are hurry when player is flashing and put it off (so player will become useless in some cases) or they let the firmware disk inside and player is always flashing when they put it on, and this causes panic to them ("player is not working"). Nonetheless, to flash it is frecuently necessary to press simultaneously 2 buttons on the remote, and this is too complex for a lot of people.

A lot of people simply would return player to shop.

[sillKotscha]

I'm aware of how dumb people can be when it comes to technology ("can you put the internet on this floppy disk")...



or another nice example from a shop selling different telephone mainlines with internet access...

Q: "do you have that internet everyone is talking about?" ...

snappy answer: "no, sorry... the last one was sold yesterday but we'll receive new ones tomorrow..."

:D

[jkenzie]

Here is the original blog:
http://geekswithblogs.net/lorint/archive/2006/04/21/75795.aspx

[FoxDisc]

Using MKB to do traitor tracing is far slow and unefficient (also note MKB was never intended to do so).

Yes, I completely agree. The MKB was designed for revocation. The SKB for tracing.

The advantage of getting DKs from an standalone player is that already sold home theater players can not be hardened. If they have a hole, they will have that hole forever.

If they were smart, every standalone player could be individually revoked if it could be traced. They wouldn't have to revoke large groups of players. If they make a mistake, they could try to recall the revoked player or send out a firmware upgrade on a disc (I wonder if they left that as an option - to change device keys with an externally applicable firmware upgrade). I don't think they' would mind risking pissing off a single owner to close a hole.

They will never want to revoke multiple standalones if they can avoid it. Within a single one of the 512 trees, however, there are over 8 million different possible players that could be individually revoked if they've been given individualized device keys.

Soft players can be upgraded, and users can be forced to upgrade (just revoking previous versions). Standalones can not be upgraded.

Do we know this? I know they would not do a mass upgrade required for a mass revocation, but perhaps a single device revocation could be "fixed" with a firmware upgrade process.

Yes, the DKs from one player will work with the SKs from another player. MKB and SKB are almost entirely decoupled, the only linkage is Media Key, and Media Key is the same for each movie, no matter which PK the player have used to decrypt Media Key.
The output of "MKB system" is Media Key and only Media Key, the input of "SKB system" is Media Key and only Media Key. Both systems are decoupled.
SKs and SKB can trace the player SK set is from, not the player DK set is from.

I really need to look at the Sequence Key and Sequence Key Block system and how it interacts with the Device Key/MediaKey and MKB system. (Unless you can explain it.) Something doesn't seem right here. Surely, if they used the SKB system to track down a player, they must be able to revoke it to prevent it from decrypting a movie by preventing either the device keys or the sequence keys from working.

I know they can revoke the device keys. You seem to be saying that does no good if they came from another player than the sequence keys, but surely they would have foreseen that? What good does it do to know where the SK keys came from if they aren't linked to DKs and they can only revoke DKs, not SKs?

I would expect the sequence keys to be required and the revocation to work on the sequence keys, or for the sets of DKs and SKs to be inextricably linked so that they know which DKs to revoke from the SK tracing. I must be missing something fundamental here.

[FoxDisc]

From NNL paper:
"In both the Complete Subtree and Subset Difference methods, a unique label is associated with each node in the tree. Storing these labels explicitly at the Center can become a serious constraint. However, these labels can be generated at the center by applying a pseudo-random function on the name of the node without affecting the security of the scheme. This reduces the storage required by at the Center to the single key of the pseudo-random function."

On the issue of whether the AACSLA assigned independent random numbers to label each of the nodes in the tree or a "single key of the pseudo-random function": If I was the AACSLA, I would be scared to death if I used a single key number at the root of the tree from which all other numbers assigned to all other nodes could be calculated. If that one number leaked, all would be lost! The alternative to that one number was to assign every node a random number. To break the entire system would require knowing the entire database comprising the entire random number tree.

Even though the storage requirements are in gigabytes, I would see that as an advantage. It would be much harder to accidentally leak (or intentionally leak) an entire database of random numbers than it would be to leak just one 16 byte master key. I don't think we know what they did, but I'd put my money on the large database of true random numbers over the single key for a pseudo random function, even if the large database is technically less efficient.

[HyperHacker]

That's the simplest way, yes. But I'd say it's already far too much hassle for most people to accept: They paid for a player and some disks and now they have to go to tech support because pirates cracked the protection? (not saying the guys who did this are pirates of course)
No, it's certainly not a good method. I'm just saying it is possible. (And really, if you can't call someone, give them your address, insert a disc, press a few buttons, and remove it again, just why do you have an HD-DVD player? ;-))

[FoxDisc]

Well, I said these two systems are highly decoupled. Output of DKs and MKB is Media Key, and input of SKs and SKB is Media Key. We agree that Media Key is the same, no matter which PK has been used to decrypt it.

So they can use SKB system to trace which player SK is from, not which player PK is from.

Unfortunately, they are not highly decoupled. They are very closely coupled. The purpose of Sequence Keys is to track devices and allow them to be revoked. Both the SKs and the aassociated DKs are revoked when the AACS LA issues a new MKB and SKB for a new disc.

A Media Key MK is produced from a Processing Key PK and the Volume ID. A PK is calculated from a Device Key. A PK corresponds to an S-D set that includes a specific group of devices that have that DK or can calculate it. All devices in that group produce that MK. All devices that are not in that group cannot calculate that MK. They calculate another MK if they are not revoked. If they are revoked, they cannot calculate any MK. Clearly, all devices do not start with the same MK and different PKs do not lead to the same MK.

In the same way that devices are revoked by revoking sets of DKs when an MKB is issued, the SK sets are revoked when a coupled SKB is issued.
The spec says:
"If a set of Sequence Keys is compromised in a way that threatens the integrity of the system, an updated SKB can be released that causes a device with one or more compromised sets of Sequence Keys to calculate invalid Variant Data. In this way, the compromised Sequence Keys are “revoked” by the new
SKB."

The MKB and SKB are linked as the following discussion in the spec describes:

"The device may use the Verify Media Key Record to make sure that it has the correct Media Key for processing the SKB. The Media Key comes from calculation based on the separate Media Key Block. Since MKBs and SKBs are associated, the device can, in effect, verify it has the correct MKB/SKB pair. The device action in the case of a mismatched MKB/SKB pair is manufacturer-specific. In any event, the device will not be able to process the content correctly."

I think that's enough for now. It is interesting to note what the AACS specs calls the SKB: "Forensic Data" and the MKB: "Device Revocation Data." By linking the SKB to the MKB they ensure forensic tracing and correct revocation.

[frogman]

Quote:
Soft players can be upgraded, and users can be forced to upgrade (just revoking previous versions). Standalones can not be upgraded.

Do we know this? I know they would not do a mass upgrade required for a mass revocation, but perhaps a single device revocation could be "fixed" with a firmware upgrade process.

Ok,,,This morning I bought The toshiba HD-A2 model for $599 CDN Funds...Upon opening the box there was a notice in a bold Statement: quote: Please note that if you send in the Firmware Update Request Card included with your player, you will recieve an updated disc by mail from Toshiba as soon as it becomes availible.

Here is my rant: Sorry Admins: You would think that anyone purchasing a DVD player these day for $600 plus tax you would get a HDMI cable to watch your purchaced HD DVD's in HD mode! And I got 25 HD DVD in my collection already. Thank-you very much.
Wrong they only supplied Standard RCA connectors.
Question:
Can you watch a HD DVD movie played on a HD DVD Drive into a Toshiba HD TV with RCA cable? I don't know as I will now return it as I find this to be false advertizing! Go smoke that in your pipe Toshiba.
This is not fair use in my book!

[frogman]

Sorry but I just got into a few pages into the manual here and The toshiba HD A2 has a RJ45 Ethernet connector in back ...Manual say If connected to Internet the unit will phone home and automatically get the updates?

How sad....Next I will snail mail them a key to my front door.

[arnezami]

A Media Key MK is produced from a Processing Key PK and the Volume ID. A PK is calculated from a Device Key. A PK corresponds to an S-D set that includes a specific group of devices that have that DK or can calculate it. All devices in that group produce that MK. All devices that are not in that group cannot calculate that MK. They calculate another MK if they are not revoked. If they are revoked, they cannot calculate any MK. Clearly, all devices do not start with the same MK and different PKs do not lead to the same MK.

I'm not sure if you implied this but just to clear up: each device (no matter in what group) will produce the same MK (given the same disc/movie of course). The C-values make sure of this (they have been produced by encrypting the same Media Key but with different Processing Keys). So the Media Key does not contain any device-identifyable information.

Of course all KCD based systems first produce the same Media Precursor (which then results in the same Media Key again).

[xyz987]

A Media Key MK is produced from a Processing Key PK and the Volume ID. A PK is calculated from a Device Key. A PK corresponds to an S-D set that includes a specific group of devices that have that DK or can calculate it. All devices in that group produce that MK. All devices that are not in that group cannot calculate that MK. They calculate another MK if they are not revoked. If they are revoked, they cannot calculate any MK. Clearly, all devices do not start with the same MK and different PKs do not lead to the same MK.


This seems to be wrong. MK is always the same for each movie (or edition/printing of a movie). Disk replicator receives just one MK (section 3.1 of Prerecorded spec) per edition. Also section 1.8 (Terminology) of Common spec defines MKB, and clearly states that any non-revoked device will compute the same "common key (Media Key)" from MKB. Even more important: Media Key is always a single expression (not plural). There are DKs, PKs, SKs and others in plural, but VUK, MK and others are always named as single (not plural).

I looked for any other possible link between MKB a SKB, and MK is the only one. Provided MK is always the same per disk, no matter which PK has been used to get it, MKB system and SKB system are decoupled.

If you agree with the above, we can go further about how to use this decoupling to break AACS. The attacker that gets a DK set can not be traced with SKB system if he doesn't publish a SK, and he can not be revoked because he can not be identified. Also, another attacker can safely publish a single SK from his player, and this single SK can not be traced neither revoked (section 4.1 of Prerecorded spec, a SK set can be revoked, but not a single SK). This single SK can be considered as "compromised" in future movie releases, but then another attacker can publish another single SK and so on.

[FoxDisc]

I'm not sure if you implied this but just to clear up: each device (no matter in what group) will produce the same MK (given the same disc/movie of course). The C-values make sure of this (they have been produced by encrypting the same Media Key but with different Processing Keys). So the Media Key does not contain any device-identifyable information.

I agree, all devices produce the same Media Key. The Media Key contains no device identifying information. The Processing Key used to get that MK, and the DK used to get the PK, and the particular one of the C-values decrypted all carry some information, but none of these have to be released.......

In the future, however, the MK will not be enough.

Right now, the Media Key is the same as a Title Key (now that the Host Private Key is loose, and the Drive will give up the Volume ID). Right now, the Title Key is encrypted with the MK and the Volume ID (via the Volume Unique Key). However, when Sequence Keys are used, the SKs will be used to calculate Media Key Variants. It is these MKVs (I should write Kmvs) that will be used, and the variants will differ. As the AACS specs say:

ENCRYPT:
"For each protected Title, the licensed replicator calculates a cryptographic hash of the Media Key and/or the Media Key Variants and the Volume ID, and uses the result to encrypt the Title’s Title Key."
This glosses over the calculation of a Volume Variant Unique Key which is:
Kvvu = AES-G(Kmv, IDv).

DECRYPT:
"The AACS LA also provides a set of 256 Sequence Keys to the licensed manufacturer for inclusion in each compliant device or application produced. Like Device Keys, Sequence Keys may be either unique per licensed product, or used in common by multiple products. If a product’s Device Keys are unique, then its Sequence Keys will also be unique; if a product’s Device Keys are in common, then its Sequence Keys will also be in common. In either event, the licensed product reads the SKB from the prerecorded medium and uses its Sequence Keys and its previously calculated Media Key to calculate its Media Key Variant.
For each protected Title the licensed product then calculates a cryptographic hash of the calculated Media Key and/or the Media Key Variants and the Volume ID, and uses the result to decrypt the Title’s Encrypted Title Key. The result is then used to decrypt the Title, as specified for each supported format elsewhere in this specification."

Media Key Variants will be eventually be needed, and they do carry device identifying information. As the spec puts it:
"the SKB merely allows different variants of the Media Key to be calculated by different devices."

[FoxDisc]

I looked for any other possible link between MKB a SKB, and MK is the only one. Provided MK is always the same per disk, no matter which PK has been used to get it, MKB system and SKB system are decoupled.

Read my comments to arnezami first.

If you agree with the above, we can go further about how to use this decoupling to break AACS.

If you have read my comments to arnezami, you will see that I agree that the Media Key is the same (that's why it's singular everywhere), but the Media Key Variants are not, and they are required (when SKBs begin to be used)

The attacker that gets a DK set can not be traced with SKB system if he doesn't publish a SK, and he can not be revoked because he can not be identified.

This I strongly disagree with. The entire purpose of the Sequence Key system is "forensic" and "tracing." The specs have many references to this purpose and how the SKs are designed to resist the "anonymous" or "oracle" attack.

Also, another attacker can safely publish a single SK from his player, and this single SK can not be traced neither revoked (section 4.1 of Prerecorded spec, a SK set can be revoked, but not a single SK). This single SK can be considered as "compromised" in future movie releases, but then another attacker can publish another single SK and so on.

Technically, they can and do revoke a single SK (they call it "compromised"), but when they do, they make sure that all good boys have at least one other unrevoked SK and all bad boys have all their SKs revoked. Some good boys will share bad boys revoked/compromised SKs, but not all or them - sets are unique. It takes an unrevoked set to work through the 256 Column by 64K row Sequence Key matrix to get the result needed for decryption. Every device gets an SK for every column. You start in the first column and decrypt. A single SK takes you to the next column if it is revoked. After each column, the device either has the answer, or it has to move to the next column and try again. A revoked device has its SKs revoked by the new SKB when its DKs are revoked with the matching new MKB.

It is the matrix that makes the tracing powerful. Different groups of devices (these groups are not the same as the S-D set that the device is in) will work through the matrix to get different answers. There is no one right answer. These different answers/groups are used to identify the specific device that worked through the matrix so its SK set and its DK set can be revoked.

[xyz987]

Media Key Variants will be eventually be needed, and they do carry device identifying information. As the spec puts it:
"the SKB merely allows different variants of the Media Key to be calculated by different devices."

You are right. However, this information refers to the device the SK is from, not the device the DK/PK is from. Also, a single published SK don't identify completely a device (spec says any SK is shared by many thousands of devices).

It is noteworthy to say that any device computes and uses just one Media Key Variant. There are several MKVs per disk (i.e. per movie edition), but any device will use just one of them. There is no enought information to trace traitor on a single published SK.

[arnezami]

@FoxDisc: I think what xyz987 is trying to say is that if the Device Keys from Player A are used (eg. to generate a Processing Key) to decrypt the bulk of the content and the Sequence Keys of Player B are used for the other parts then the AACS LA will only be able to trace Player B. Not Player A. And only the DKs (and SKs) of Player B will be revoked.

In that sense the DKs and SKs are "decoupled".

It may also be possible to get SKs out of many standalone players making it harder or impossible to track them. Effectively disabling (or slowing down) the tracing system. As far as I know SKs do not require any KCD-like something so they can be used on PC systems aswell. Meaning: get a Device/Processing Key from a software player (or alternatively: a Proc/Dev key from a standalone and using KCD enabled patched PC-drives) and keep using the SKs taken out of many standalones.

A more practical example: lets say there is a way to get SKs out of a certain type of standalone. And lets say there are 30 people willing to help. If each of them releases a few of their SKs it may be hard or impossible for the AACS LA to track these standalones down.

How difficult this actually is for the AACS LA and how to organize this ourselves is something we have to figure out. I do however believe the tracking system has its limits. It may be possible to permanently disable the tracking system this way :). We'll have to do the math for this.

[xyz987]

This I strongly disagree with. The entire purpose of the Sequence Key system is "forensic" and "tracing." The specs have many references to this purpose and how the SKs are designed to resist the "anonymous" or "oracle" attack.


The oracle attack is different. It is publishing keys on a movie-by-movie basis. SKB system is good for that, but this a different kind of attack. Janvitos and others are doing an oracle attack on his sticky threads (BluRay and HDDVD), arnezami and Atari Vampire have not done an oracle attack.


Technically, they can and do revoke a single SK (they call it "compromised")


No, compromised and revoked are different things. The attacker that publishes just one SK of his SK set is never identified neither revoked. He can view and decrypt newly released movies, his player is never revoked neither his SK set. That's why AACS call these two things differently.


It is the matrix that makes the tracing powerful. Different groups of devices (these groups are not the same as the S-D set that the device is in) will work through the matrix to get different answers. There is no one right answer. These different answers/groups are used to identify the specific device that worked through the matrix so its SK set and its DK set can be revoked.

If attacker is publishing a MKV per movie (oracle attack), he will be soon identified and revoked (he is publishing after the matrix). If attacker publish just one SK (that may be or may be not valid for all the movies), he won't be identified neither revoked (he is publishing before the matrix).

[xyz987]

@FoxDisc: I think what xyz987 is trying to say is that if the Device Keys from Player A are used (eg. to generate a Processing Key) to decrypt the bulk of the content and the Sequence Keys of Player B are used for the other parts then the AACS LA will only be able to trace Player B. Not Player A. And only the DKs (and SKs) of Player B will be revoked.


Just a clarification. Player A won't be identified even if AACS LA uses MKV to encrypt all the movie. In fact it is not important which is the percentage of movie that is encrypted with MKV. The important thing is that attacker A gives everybody the capability to compute MK, and attacker B gives everybody the capability to decrypt all the movie from MK (computing MKV if needed), and none of the attackers can be traced (but attacker B can publish just one SK).


How difficult this actually is for the AACS LA and how to organize this ourselves is something we have to figure out. I do however believe the tracking system has its limits. It may be possible to permanently disable the tracking system this way :). We'll have to do the math for this.

I have tried to do that math for days (and probably weeks) :-)

The problem is we don't know how LA assigns SKs to players, so it is difficult to know which number of SKs from different players is needed to permanently break the tracing system.

[arnezami]

I have tried to do that math for days (and probably weeks) :-)

The problem is we don't know how LA assigns SKs to players, so it is difficult to know which number of SKs from different players is needed to permanently break the tracing system.
I think a good approach would be to only publish keys from which you know say 5-10 others also have it. Given enough people we will have enough SKs to decrypt everything. Then we can all stop releasing SKs. Game over tracing.

Of course this also depends on the way the AACS LA gives out SKs and on how many players have been sold.

[FoxDisc]

@FoxDisc: I think what xyz987 is trying to say is that if the Device Keys from Player A are used (eg. to generate a Processing Key) to decrypt the bulk of the content and the Sequence Keys of Player B are used for the other parts then the AACS LA will only be able to trace Player B. Not Player A. And only the DKs (and SKs) of Player B will be revoked.
In that sense the DKs and SKs are "decoupled".

Preliminary comments: This is a complex system, and I do not pretend to fully understand it. I expect to make errors as I delve further. I truly thank you and xyz for your comments - they lead me to better understanding. At this point I'm trying to understand better, not to explain to others. Where I disagree, I will say so and say why. Where I think I am wrong, I will try to say that too.

I don't disagree with your characterization of "decoupled." It's just that once the SKs for a device B have been revoked by revoking the DKs and the SKs for device B, then the movie can no longer be decrypted by device B. Device A can still decrypt the movie for his own use, but so what? The AACS LA does not care if he is compromised, as long as he does not release 1) the decrypted title or 2) keys necessary to decrypt the whole title.

If he released either 1 or 2, then he releases enough information to identify his device for revocation.

It may also be possible to get SKs out of many standalone players making it harder or impossible to track them. Effectively disabling (or slowing down) the tracing system. As far as I know SKs do not require any KCD-like something so they can be used on PC systems aswell. Meaning: get a Device/Processing Key from a software player (or alternatively: a Proc/Dev key from a standalone and using KCD enabled patched PC-drives) and keep using the SKs taken out of many standalones.

A more practical example: lets say there is a way to get SKs out of a certain type of standalone. And lets say there are 30 people willing to help. If each of them releases a few of their SKs it may be hard or impossible for the AACS LA to track these standalones down.

How difficult this actually is for the AACS LA and how to organize this ourselves is something we have to figure out. I do however believe the tracking system has its limits. It may be possible to permanently disable the tracking system this way :). We'll have to do the math for this.

Here is how I see the future: I know my crystal ball is still cloudy, however :)

A decrypted title or a program that can decrypt a title will define a set of compromised sequence keys. That set and the matching DKs for that set can be revoked. As far as I can tell, no innocent devices will be revoked. The SKs involved will become "compromised" and only traitor devices will be involved in revocation.

I am not saying that this is the end of the matter - that the AACS LA will succeed in revoking and fixing the broken system. I actually think they will fail, but I think they will fail because of what you describe - multiple devices will be broken to get their SKs and DKs faster than they can be identified and revoked. Not all information will be revealed at once from all compromised devices.

[xyz987]

I don't disagree with your characterization of "decoupled." It's just that once the SKs for a device B have been revoked by revoking the DKs and the SKs for device B, then the movie can no longer be decrypted by device B. Device A can still decrypt the movie for his own use, but so what? The AACS LA does not care if he is compromised, as long as he does not release 1) the decrypted title or 2) keys necessary to decrypt the whole title.


Of course, if an attacker publishes all the SKs from player B, this player will be revoked. However, if an attacker publishes just one SK from player B this player can not be identified neither revoked, and a lot of already released movies (probably all) can be decrypted by everybody. If not all the movies can be decrypted with the published SK, another attacker can publish another single SK from another player.

Once the published SK is considered "compromised" in newly released movies, another attacker can publish another SK from another player, and so on.

All the point is this: publishing just one SK from each player is always safe for attackers.

[FoxDisc]

The oracle attack is different. It is publishing keys on a movie-by-movie basis. SKB system is good for that, but this a different kind of attack. Janvitos and others are doing an oracle attack on his sticky threads (BluRay and HDDVD), arnezami and Atari Vampire have not done an oracle attack.

I was not clear. There are two basic types of attacks. In one, the decrypted title/movie is released. In the other, keys are released sufficient to decrypt the movie. The keys may be released as keys or as part of a program that does the decryption. Right now it only takes title keys, or PKs/DKs/Vid etc. to get the Title Key. However, when the Sequence Keys are used, it will take more than just a single Title Key - Segment Keys will be needed. (Oh no, not another kind of key!)

Take a look at Section 7.2 of the HD DVD and DVD Pre-recorded Book As the movie is being decrypted from the disc, it decrypts each cell in turn with the Title Key. A cell is a time portion of the title. As it decrypts, it checks to see if this cell is part of a group of cells called a "Sequence Key Section." Right now there are none. When the SKs are used, and the first Sequence Key Section is reached, it will need to decrypt and use only one cell from that group of cells. Maybe that cell has a man wearing red shirt. Another cell he wears a blue shirt. (In reality, it is probably some hidden difference.) However, to decrypt it cannot use the Title Key. It must use the Segment Key. Where does it get the Segment Key? From the SKB processing and SKs. The end result - Title is labeled with the particular cell from the Sequence Key Section.

No, compromised and revoked are different things. The attacker that publishes just one SK of his SK set is never identified neither revoked. He can view and decrypt newly released movies, his player is never revoked neither his SK set. That's why AACS call these two things differently.

But one SK is not enough if it is compromised. It must be used to work to next column in the matrix.

[FoxDisc]

All the point is this: publishing just one SK from each player is always safe for attackers.

It may be safe, but I don't think it is enough to decrypt a Title. Every time the Title/EVOB decryption arrives at a Sequence Key Section it will need to use a Segment Key (instead of the Title Key). It will need to consult the disc and use its SKs to decrypt one of the Segment Keys stored there. There can be 32 Sequence Key Sections. There can be eight different cells on the disc, one of which has to be decrypted. This alone gives 8 cells selected 32 times as 8^32 different versions of the Title that could result. To add complexity, there are actually 6 different lookup tables for the 32 possible Sequence Key Sections.

Without additional SKs, you can't get the decryption of the Segment Keys done, and without those, the Title can't be fully decrypted.

[xyz987]

Take a look at Section 7.2 of the HD DVD and DVD Pre-recorded Book As the movie is being decrypted from the disc, it decrypts each cell in turn with the Title Key. A cell is a time portion of the title. As it decrypts, it checks to see if this cell is part of a group of cells called a "Sequence Key Section." Right now there are none. When the SKs are used, and the first Sequence Key Section is reached, it will need to decrypt and use only one cell from that group of cells. Maybe that cell has a man wearing red shirt. Another cell he wears a blue shirt. (In reality, it is probably some hidden difference.) However, to decrypt it cannot use the Title Key. It must use the Segment Key. Where does it get the Segment Key? From the SKB processing and SKs. The end result - Title is labeled with the particular cell from the Sequence Key Section.


So attacker publishes just one SK, and this published SK allows everybody to decrypt a red shirt. This is not new information for LA because the published SK is also previously known by LA (i.e. LA knows this SK has been published because everybody knows it).

However there is a new thing here (new for me, at least). There are 6 SKBs on each HDDVD disk and may be 6 different SKs are needed (i have not checked this). Anyway, may be an attacker can safely publish just 6 SKs, or may be we need 6 attackers publish 6 SKs from 6 different players. This doesn't change things a lot.


But one SK is not enough if it is compromised. It must be used to work to next column in the matrix.

Yes, as soon as the published SK is compromised attacker can decrypt newly released movies because he has the rest of his SKs (he never published them so his player is not revoked), and the rest of the world needs that another attacker publish another SK from another player.

[xyz987]

It may be safe, but I don't think it is enough to decrypt a Title. Every time the Title/EVOB decryption arrives at a Sequence Key Section it will need to use a Segment Key (instead of the Title Key). It will need to consult the disc and use its SKs to decrypt one of the Segment Keys stored there. There can be 32 Sequence Key Sections. There can be eight different cells on the disc, one of which has to be decrypted. This alone gives 8 cells selected 32 times as 8^32 different versions of the Title that could result. To add complexity, there are actually 6 different lookup tables for the 32 possible Sequence Key Sections.

Without additional SKs, you can't get the decryption of the Segment Keys done, and without those, the Title can't be fully decrypted.

I will read HDDVD spec. Until i do, how many SKs do you say are needed?

[FoxDisc]

I will read HDDVD spec. Until i do, how many SKs do you say are needed?

Good question. I do not know. Please do not think I always disagree with you or that I think I know all answers. I am working hard to understand this. We should work together.

Let's try to see the whole picture. I am just beginnning to grasp the elephant - sometimes I touch the tail and think "snake-like" sometimes I touch the leg and think "tree-like."

Remember arnezami's picture here:
http://img367.imageshack.us/img367/6008/progress6km3nf8.png
This picture is too simple for the SKB situation. Look at Fig. 3-1 of the PreRecorded spec. The Km goes to the SKB processing to get the Kmv. Kmv then goes through AES-G and IDv to get Kvvu. Here is the first place SKs are used - to get the Kmv required for this device.

How many are needed here? I think this depends upon how the groups of devices (grouped by SKs, not DKs) are set up the first time the SKB is used. I don't yet know if we have enough information to answer this.

Let's continue on. The Title decryption process will stop at as many as 32 points where a Segment Key will be needed. Each device will only be able to decrypt one Segment Key (with its Sequence Keys) for one of the 8 cells at each stopping point.

If I understand it correctly, there are 6 tables of 32 entries each. Each time it must go to the right entry and use its Sequence Keys to get and decrypt the correct Segment Key. How many are needed for this? I don't know. Again, I think it depends on how it is set up by AACS LA.

We have skipped some stuff that I am not yet clear on, and I am not sure about the independence of the SK usage, but here is what I suspect will be required: Out of the 256 SKs given each device, almost all or all will be needed to decrypt a single Title. Each time the matrix of 256 columns is entered, multiple columns will be used, requiring multiple SKs.

[xyz987]

We have skipped some stuff that I am not yet clear on, and I am not sure about the independence of the SK usage, but here is what I suspect will be required: Out of the 256 SKs given each device, almost all or all will be needed to decrypt a single Title. Each time the matrix of 256 columns is entered, multiple columns will be used, requiring multiple SKs.

No, as far as i can see a maximum of 6 SKs will be needed. Spec says:

"The first column will have an encryption of the output key (denoted ‘K’ in the figure) in every uncompromised Sequence Key’s cell. Devices that do not have compromised keys in that column immediately decrypt the output key."

and also:

"The subsequent additional conditional columns are produced the same way as the first column: They will have an encryption of the output key in every uncompromised Sequence Key’s cell."

Just one uncompromised SK is needed per SKB, and there are 6 SKBs on a HDDVD disk. AFAIK the only question is to know if the same SK is valid for the 6 SKBs or each SKB requires a different SK to get a valid output. Supposedly the same uncompromised SK should be valid for any SKB, but there are 6 SKBs for some reason, so to give a safe answer i need first to know why there are 6 SKBs instead of just one.

[xyz987]

Well, i have read the whole thing about HDDVD Segment Keys, and it is just a system to determine which Sequence Key was used to decrypt a movie, so it doesn't affect to an attacker who publishes just one Sequence Key.

Segment Keys are just to face the problem of an attacker publishing a decrypted movie (not the key, but the movie). AACS needs to know which is the Sequence Key that has been used to decrypt it, so some frames of the movie vary slightly from a Sequence Key to another, so AACS LA can know which SK was used to decrypt a pirated movie available on Internet.

Nothing of this affects our attacker. He is publishing his SK (just one), so AACS LA knows which is the compromised SK anyway.

BTW AACS LA guys have designed a far good system. Segment Keys give them 62-63 bits of information about the Sequence Key (hence they use 6 SKBs), and a Sequence Key is 64 bit long.

Edit: BluRay is also using 6 SKBs (section 6.2.1 of BluRay Prerecorded spec).

[FoxDisc]

No, as far as i can see a maximum of 6 SKs will be needed.

How much information do you think this discloses about the attacker? An SKB defines one of 256 columns in the SK matrix to be used. There are up to 64K rows in that matrix. The decryption by a specific device uses as an input not only the specific Sequence Key in the SKB defined column, but also the specific row out of 64K rows that the Key was located in. How many devices have that key in that row? I think that information has to be disclosed to successsfully use the SK. If this process is done 6 times, with 6 keys, there is a potential for quite a bit of information about the attacker. A related question is how much information the Segment Key system discloses. Again, I think it discloses more than just what SK was used, I think it has the potential to disclose what position in the matrix each key was in.

[FoxDisc]

How much information do you think this discloses about the attacker?

Just a quick comment here: A Sequence Key is 64 bits. The row that any specific SK is on is identified by 16 bits. That's 80 bits of potential information about the attacker, and there are only 32 bits of different numbered revocable attackers in the whole Device Key/MKB AACS system.

Both the SK and its associated Row go into the decryption calculations and both are labeled as "confidential" in the specs.

I had been thinking that an attacker was associated with a specific set of shared SKs as discussed in the specs. Similar to the way that a set of DKs could specifically identify a device, I thought the SK system relied on identifying the device with a shared SK by knowing the "set of SKs" that the specs talk about. I now realize that's not necessary. The row that a specific SK is in also carries 16 bits of information (64K rows in the matrix) that are in addition to the 64 bits carried by the SK itself. If this process is repeated 6 or more times, there seems to be lots of potential information about the specific device used for a successful decryption.

[xyz987]

If this process is done 6 times, with 6 keys, there is a potential for quite a bit of information about the attacker.

Just one Sequence Key is used in the 6 SKBs. Any uncompromised SK is valid for any SKB.

To avoid duplication, i will answer the rest on another post.

[xyz987]

Just a quick comment here: A Sequence Key is 64 bits. The row that any specific SK is on is identified by 16 bits. That's 80 bits of potential information about the attacker, and there are only 32 bits of different numbered revocable attackers in the whole Device Key/MKB AACS system.

Both the SK and its associated Row go into the decryption calculations and both are labeled as "confidential" in the specs.


I think you are focusing it wrongly. If attacker only publishes just one SK, that's exactly what AACS LA gets. They can not get more information from this. Any problem with the row is a problem for the guy that decrypts the movie. If he is a fair use guy, no problem (he is not publishing the decrypted movie). If he is a pirate that puts the movie on Internet, may be he can be located or may be not (i think it is obvious pirate can not be located, but this is out of our debate, and a bit off-topic on this forum).

If additional row information is needed to decrypt, fair use guy can always try all the possible rows (aprox. 65,000).

[FoxDisc]

I think you are focusing it wrongly. If attacker only publishes just one SK, that's exactly what AACS LA gets.

One SK is not enough to decrypt. Decryption of a title with an SKB requires that the device read the SKB from a disc, find the defined column (one of 256) in the SKB on the disc, look up the SK (64 bits) that he has in that column and determine the row (16 bits) Then he can start for this one title.

If the attacker says "This SK can be used to decrypt SHREK 7" he has just disclosed a minimum of the column and SK that his compromised device had. How many devices are there that have that one specific 64 bit unrevoked key in that specific column? If it's revoked/compromised, then he'll need to give the second SK he has and it's column number when the SKB decryption process gives up a link instead of the key K and sends him to another column of the Sequence Key matrix.

They can not get more information from this. Any problem with the row is a problem for the guy that decrypts the movie.

As you say, the attacker can just search the 64K possible rows, but it's a search that the AACSLA can do also, so I think the row is disclosed too as soon as the attacker says that key works for a specific Title.

If he is a fair use guy, no problem (he is not publishing the decrypted movie). If he is a pirate that puts the movie on Internet, may be he can be located or may be not (i think it is obvious pirate can not be located, but this is out of our debate, and a bit off-topic on this forum).

I additional row information is needed to decrypt, fair use guy can always try all the possible rows (aprox. 65,000).

I think we are trying to determine:

What is the minimum information that must be disclosed to decrypt a title past the new SKB, and how much does that information disclose about the source of the disclosed information. The minimum needed to get through the SKB is an unrevoked 64 bit SK in the correct 8 bit column for that title. (Perhaps more is needed, but this is certainly needed.) This seems to me to be a lot of information since they are only trying to identify a 32 bit numbered device.

[xyz987]

One SK is not enough to decrypt. Decryption of a title with an SKB requires that the device read the SKB from a disc, find the defined column (one of 256) in the SKB on the disc, look up the SK (64 bits) that he has in that column and determine the row (16 bits) Then he can start for this one title.


Spec says one uncompromised SK is enought. Most times just the first column is used, for the rest of columns see below.


If the attacker says "This SK can be used to decrypt SHREK 7"


Attacker just say "this is an uncompromised SK"


If it's revoked/compromised, then he'll need to give the second SK he has and it's column number when the SKB decryption process gives up a link instead of the key K and sends him to another column of the Sequence Key matrix.


Column number is not needed. He is publishing an uncompromised SK. Other previously published SKs (so they are now "compromised") are also known by the fair use guy. Anyway a time-ordered list of "already published SKs" solves any lack of knowledge by fair use guy.


As you say, the attacker can just search the 64K possible rows, but it's a search that the AACSLA can do also, so I think the row is disclosed too as soon as the attacker says that key works for a specific Title.


You need to explain here why spec says a single SK can not revoked. In fact i think many possible rows can be used with the same SK (outputting slightly different movies), but this is just a conjeture. The very true fact is that a single SK can not be revoked, player identity is not revealed.


What is the minimum information that must be disclosed to decrypt a title past the new SKB, and how much does that information disclose about the source of the disclosed information. The minimum needed to get through the SKB is an unrevoked 64 bit SK in the correct 8 bit column for that title. (Perhaps more is needed, but this is certainly needed.) This seems to me to be a lot of information since they are only trying to identify a 32 bit numbered device.

The minimum information is just one uncompromised SK, and that information discloses virtually nothing about the source because spec says a SK is shared by many thousands of players.

[FoxDisc]

Attacker just say "this is an uncompromised SK"

The SKB for a specific title/disc has an SKB. The third record in that SKB is the "Calculate Variant Data Record." That record specifies the one column out of the 256 columns in the SK matrix to be used by a device to decrypt this title. All devices start in that column c. The device looks down the column c in its matrix of SK keys to find the one row r that holds an SK. Every device has only one key in this column, but the keys are likely to be different and the row it is in will usually be different. The SK, row r and column c form a set that the device uses to calculate the Variant Data Dv as follows:

Dv = [AES-G(Kms_i, X ⊕ f(c,r))]msb_80 ⊕ Dke_r
where Kms_i is the device’s i-th Media Sequence Key’s value and Dke_r is the 80-bit value starting at
byte offset r × 10 within the Record’s Encrypted Key Data. f(c,r) represents the 128-bit value:
f(c,r) = 000016 || c || 000016 || r || 000000000000000016
where c and r are left-padded to lengths 16 bits, by prepending zero-valued bits to each as needed. The
resulting Dv becomes the current Variant Data value.

X is the Nonce from the second record in the SKB. As you can see, this record has a table of encrypted values. The row number r times 10 is used as an ofsset to find the correct value for the calculation of the first Dv above.

Without the correct SK for the column c defined on the disc, and the correct row r, the correct Dv won't be found and decryption will fail. If the first SK it uses in the first column is revoked, the first Dv found is not the correct final Dv. The first "Calculate Variant Data Record." will send it to the next record labeled the "Conditionally Calculate Variant Data Record."

This record has a second column defined. Again, the device must look up in its matrix in the second defined column c2 to find a second SK2 on a specific row r2. It then processes through the Conditionally Calculate Variant Data Record to get a second Variant Data Dv. This continues until it has done this with an unrevoked SK or hit the end of the SKB. Ultimately, it arrives at a final Dv which it uses to calculate the Media Key Variant Kmv.

Column number is not needed. He is publishing an uncompromised SK.

See above. Without the matching SK for the column number specified in the SKB, and the matching row r the Kmv can't be obtained.

You need to explain here why spec says a single SK can not revoked. In fact i think many possible rows can be used with the same SK (outputting slightly different movies), but this is just a conjeture. The very true fact is that a single SK can not be revoked, player identity is not revealed.

I suppose you can say that technically, the SK is not "revoked." What happens is described above. The compromised SK in the first column leads to the Conditionally Calculate Variant Data Record which specifies a second column in the SK matrix (256 columns by up to 64K rows). The device must have a non-compromised SK in that column, and again it will use its row and column and SK to calculate the Variant Data Dv.

The minimum information is just one uncompromised SK, and that information discloses virtually nothing about the source because spec says a SK is shared by many thousands of players.

It could be shared, but it will likely not be in the same row.

[xyz987]

I suppose you can say that technically, the SK is not "revoked." What happens is described above. The compromised SK in the first column leads to the Conditionally Calculate Variant Data Record which specifies a second column in the SK matrix (256 columns by up to 64K rows). The device must have a non-compromised SK in that column, and again it will use its row and column and SK to calculate the Variant Data Dv.


So what?. Nowadays there is no compromised SK. Then LA starts including SKBs on disks (no compromised SK yet), then attacker A publishes just one SK from player A and everybody decrypts newly released movies, then LA starts releasing SKBs where SK A is considered compromised, then attacker B publishes just one SK from player B and everybody decrypts newly released movies again, and so on.

AACS LA can not revoke player A neither player B. LA never has enought information to revoke any player. May be SK B is at the second column or may be it is at the first. If it is at the second, everybody can decrypt the movie anyway because everybody has both SK A and SK B. AACS LA is not getting new information about player A because SK B is not from player A.


It could be shared, but it will likely not be in the same row.

So a lot of row numbers can be used to decrypt a movie (probably outputting an slightly different movie each one).

This is a win-win game for me. If the published SK is at same row on any player, fair use guy can decrypt because he can try all the possible row numbers. If the published SK is at different rows for each player, fair use guy simply will pick a valid row number and he can decrypt anyway.

You are trying to get water from desert sand. Attacker just publishes one uncompromised SK. This is all the information AACS LA knows about attacker player.

[FoxDisc]

Nowadays there is no compromised SK. Then LA starts including SKBs on disks (no compromised SK yet), then attacker A publishes just one SK from player A and everybody decrypts newly released movies,

But one SK will not decrypt "newly released movies" unless that one SK is in the specified SK matrix column of every newly released movie. It won't be. Every movie will specify a different column in its SKB, and the one released SK won't be in every column.

then LA starts releasing SKBs where SK A is considered compromised, then attacker B publishes just one SK from player B and everybody decrypts newly released movies again, and so on.

Why do you think one SK will work? How will they decrypt the correct Dv from the SKB?

AACS LA can not revoke player A neither player B. LA never has enought information to revoke any player. May be SK B is at the second column or may be it is at the first. If it is at the second, everybody can decrypt the movie anyway because everybody has both SK A and SK B. AACS LA is not getting new information about player A because SK B is not from player A.

Work through the SKB decoding process. Pay particular attention to how Dv is calculated. You can't get to the Kmv you need without one unrevoked SK in the correct column for each movie. An SK is of no value unless it is in the column required for that movie. Every movie will require a 64 bit SK that is in the column specified by the movie. Different players will have different SKs in that column. They will also have different row numbers. The combination will identify the player that the SK came from. Even if the movie is decrypted and released, the differences in the movie from the Segment Keys will identify the keys used for decryption. That is the whole purpose of the system.


This is a win-win game for me. If the published SK is at same row on any player, fair use guy can decrypt because he can try all the possible row numbers. If the published SK is at different rows for each player, fair use guy simply will pick a valid row number and he can decrypt anyway.

There is no reason to suspect that a single SK will be in more than one row of the required column in different players. There is no reason to believe it will be used in other columns for different movies.

You are trying to get water from desert sand. Attacker just publishes one uncompromised SK. This is all the information AACS LA knows about attacker player.

If that is all that is published, it will probably decrypt only one movie - the one that has that key in the column specified in the movie, and it will probably identify the player it came from - the player that has that specific key in the specified column for that movie. Other players will have different SKs in the specified column and their SK will be in a different row.

[xyz987]

But one SK will not decrypt "newly released movies" unless that one SK is in the specified SK matrix column of every newly released movie. It won't be. Every movie will specify a different column in its SKB, and the one released SK won't be in every column.


Note I already pointed (a lot of messages ago) the possibility that the published SK is not useful to decrypt all the movies. Anyway an attacker can publish just one SK, and this SK will decrypt some movies (probably all, see below), and another attacker will publish another SK from another player, and his SK will decrypt some other movies and so on.


Work through the SKB decoding process. Pay particular attention to how Dv is calculated. You can't get to the Kmv you need without one unrevoked SK in the correct column for each movie. An SK is of no value unless it is in the column required for that movie. Every movie will require a 64 bit SK that is in the column specified by the movie. Different players will have different SKs in that column. They will also have different row numbers. The combination will identify the player that the SK came from. Even if the movie is decrypted and released, the differences in the movie from the Segment Keys will identify the keys used for decryption. That is the whole purpose of the system.


Again you are trying to get more bits of information from row and column. Note that any SK has 64 bits, and the maximum number of possible devices is 32 bit long. Clearly the purpose of SKs is not to identify a player from just one SK, because a SK is shared by many players and any SK doubles the number of bits necessary to identify a player (provided it is not shared by many players, but it is).

It is paradoxical you are trying to get information from row (16 bits) and column (8 bits), because 16 + 8 = 24 and the number of possible players has 32 bits. Any SK has a lot more bits that column and row numbers altogether. Clearly it has no sense trying to identify a SK (that is published, so the SK is identified) that is 64 bit long from row (16 bit) and column (8 bit) numbers.


If that is all that is published, it will probably decrypt only one movie - the one that has that key in the column specified in the movie, and it will probably identify the player it came from - the player that has that specific key in the specified column for that movie. Other players will have different SKs in the specified column and their SK will be in a different row.

No, not only one movie. Note they can not specify a different SK for each movie because there are 256 columns. 256 is the maximum number of different first columns they can use "simultaneously".

The question is: what does LA prefer?. Forcing the publishing of a lot of SKs (up to 256), or forcing the publishing of just one SK per "compromising iteration"?. The purpose of SKB system is to avoid the oracle attack, where the necessary keys to decrypt a movie are published on a movie-by-movie basis. So it has no sense they use a different SK per movie (up to 256). If they do so, they are just accelerating the publishing of lots of SKs (good news for us) and ultimately the SKB system will become broken. Anyway it has no sense to do so because they know the published SK and they also have the column number (they did put this number on SBK!).

May be you should ask yourself why they are using the same SK for a lot of players. It is complex to answer this, and the answer is not on spec, so i prefer you answer yourself this question.

Spec says a SK is shared by many thousands of devices, it also says a single key can not be revoked. Playing with rows and columns and many movies doesn't change this fact. A SK is 64 bit long, if it is possible to identify the player from a single SK, they have enought bits to do so, and spec would say a single SK can be revoked, but it says just the contrary.

[FoxDisc]

Note I already pointed (a lot of messages ago) the possibility that the published SK is not useful to decrypt all the movies. Anyway an attacker can publish just one SK, and this SK will decrypt some movies (probably all, see below), and another attacker will publish another SK from another player, and his SK will decrypt some other movies and so on.

I think we will have to wait and see, but we both know the purpose of the SKB system. It is to identify the device number. I suggest we focus on understanding the system, and try to stay away from discussing how that system could be attacked. That will let us stick to things we can agree or disagree on, from the spec.

The first disc released using Sequence Keys will have an SKB.AACS and an SKF.AACS file. We don't know if all the discs will use the same files, the way they all use the same MKB files now. However, let's assume that they all use the same files. This seems to be simplest scenario. In that case, there are six SKBs in the SKB.AACS file. Each of those SKBs specifies a a column in the SK matrix. A device must locate and use one SK in each of the six columns. Those six SKs with their associated row and column numbers and the Nonce in the SKB produce six Dv values according to the formula quoted earlier. According to the spec:

""The SKB process for one SKB yields one Volume Variant Unique Key (Kvvu) and Variant Data (Dv). The lower 10 bits of the Variant Data are, in this book, called Segment Key Unit Number (SKUN). Thus, the six times of the SKB processes for the SKBF yields in order six Volume Variant Unique Keys and six SKUNs: Kvvu[ 1 ], Kvvu[ 2 ], ..., Kvvu[ 6 ], SKUN[ 1 ], SKUN[ 2 ], ..., SKUN[ 6 ]"

The Volume Variant Unique Keys (Kvvu) are the equivalent of the Volume Unique Key currently being used. The SKUN values are used with the SKF file to decrypt the Segment Keys. Those are the things that act as watermarks for a decrypted title to identify the device that did the decryption.

I can't yet tell you the details of how much information this process carries about the device that did the decryption, as I'm still working through the complex process, but I can tell that there is lots of information here. I can also tell that the system is well designed cryptographically and I know what its purpose is. Until it is fully understood by us, I don't think we can see its weaknesses yet.

Again you are trying to get more bits of information from row and column. Note that any SK has 64 bits, and the maximum number of possible devices is 32 bit long. Clearly the purpose of SKs is not to identify a player from just one SK, because a SK is shared by many players and any SK doubles the number of bits necessary to identify a player (provided it is not shared by many players, but it is).

Yes, it is strange that a single SK carries more than enough information to identify a device, but I suspect that this goes back to the issue of space on the disc. They can't just put one SKB for every SK out there. It would take too much space. They can group users however.

It is paradoxical you are trying to get information from row (16 bits) and column (8 bits), because 16 + 8 = 24 and the number of possible players has 32 bits. Any SK has a lot more bits that column and row numbers altogether. Clearly it has no sense trying to identify a SK (that is published, so the SK is identified) that is 64 bit long from row (16 bit) and column (8 bit) numbers.

The attack must disclose the row and column that a specific SK is in. It looks like that must be done six times (although the six SKBs might define the same column, with the same SK but produce different Dvs - we'll have to see) You have to ask yourself how many devices have that SK in that location.

Moreover, for each of the 6 SKBs, they can require two or more SKs to be disclosed. Again, we will have to wait and see. From the broad perspective, we know what they intend for this system to do. I will be surprised if it does not work, but to know for sure, we wil have to understand the details of 1) how it works and 2) how they actually implement it, whey they start using it.

No, not only one movie. Note they can not specify a different SK for each movie because there are 256 columns. 256 is the maximum number of different first columns they can use "simultaneously".

Yes, that is the maximum number of different first columns, but remember, they can require second columns if they want and there are 6 different SKBs with 6 different first columns.

The question is: what does LA prefer?. Forcing the publishing of a lot of SKs (up to 256), or forcing the publishing of just one SK per "compromising iteration"?. The purpose of SKB system is to avoid the oracle attack, where the necessary keys to decrypt a movie are published on a movie-by-movie basis. So it has no sense they use a different SK per movie (up to 256). If they do so, they are just accelerating the publishing of lots of SKs (good news for us) and ultimately the SKB system will become broken. Anyway it has no sense to do so because they know the published SK and they also have the column number (they did put this number on SBK!).

May be you should ask yourself why they are using the same SK for a lot of players. It is complex to answer this, and the answer is not on spec, so i prefer you answer yourself this question.

I think they use the same SK for multiple devices to limit the space used on the disc for their SKB tracing system. As to the purpose of the SKB system, clearly it is to track the compromised device. I think the system is set up so that if you give the keys necessary to decrypt, you have disclosed the compromised device. If you give the decrypted movie, it has been watermarked in a way that labels it with the keys used and again it identifies the keys and device used.

Spec says a SK is shared by many thousands of devices, it also says a single key can not be revoked.

It says a single SK can be shared. It doesn't say if the same key is found in the same row and column. It also says that devices that share a key can be required to find a second or third key in different columns, and that set can be used to identify the device. It also requires six SKBs

Playing with rows and columns and many movies doesn't change this fact. A SK is 64 bit long, if it is possible to identify the player from a single SK, they have enought bits to do so, and spec would say a single SK can be revoked, but it says just the contrary.

Agreed, but I don't think they had enough space on the disc to do it this way. They could have used the device keys to identify the device too. Then they could have skipped the whole SKB thing. There are plenty of bits in the device keys too, but instead, they gave out a small set of lengthy device keys and used MKBs, just like the set/columns of Sequence Keys with the associated SKBs.

[FoxDisc]

If anyone is following along, I'll try to summarize what I currently understand about how the Sequence Key system will work.

First, the majority of the movie is encrypted by a single title key, just as it is now. If that Title Key (Kt) is released, the majority of the movie could be decrypted and backed up. The majority of the movie resides in cells that are sequentially recorded on the disc. The Kt is used to sequentially decrypt them, just as happens now.

What about the rest of the movie? The "rest" of the movie resides in up to 32 spots in each EVOB. At these locations, there are eight different alternative cells, instead of the normal one cell. Only one from the eight is used by each device, but different devices can decrypt different ones. Any one of the eight (at each of the 32 spots) would produce a complete movie. These 8 cells are not encrypted with the Title Key. They are encrypted with something called a Segment Key. The Sequence Keys are used to get the Segment Keys and to find out which of the eight cells at each spot to use for each device.

Different SKs result in different cells being decrypted at these different locations. A single device can only get one cell out of 8 at each location. It needs to use the six different SKBs to select the correct cell and get the correct Segment Key. It is the combination of cells actually decrypted that identifies which device did the decryption. That can be determined by looking at either the decrypted movie, or at the keys provided that allowed a successful decryption.

[xyz987]

Yes, it is strange that a single SK carries more than enough information to identify a device, but I suspect that this goes back to the issue of space on the disc. They can't just put one SKB for every SK out there. It would take too much space. They can group users however.


Yes, I also think space is the reason. Note that grouping users has an disadvantage for AACS LA. They can easily identify groups, but they can not identify individuals at first shot. There is no solution for this problem. If they have created groups to save space, they don't have enought information to identify individuals. That's why an attacker that publishes just one SK can do it safely (sans being located).


The attack must disclose the row and column that a specific SK is in. [...] You have to ask yourself how many devices have that SK in that location.


Attacker discloses nothing except one SK. There are two posibilities:

1- All the players that have this SK have it at same column. So LA knows that attacker player is a player that has this SK (great discovery!)

2- The players that have this SK have it at different columns. However all these players (including attacker player) can try their SK at the column LA chose. LA doesn't know if SK column number at attacker player is "first" column (i.e. the chosen column) or any other column.

The same for rows. As I explained on another post, this is a win-win game.


Moreover, for each of the 6 SKBs, they can require two or more SKs to be disclosed.


Far unlikely they do so. Segment Keys are just a watermark system to face the case a pirate keeps secret his SK but publishes the decrypted movie. It is a system to identify the SK that has been used to decrypt. That's why there are 6 SKBs (and no more). If they require a different SK per SKB then pirates can keep secret their SKs and publish the decrypted movie. If LA does so it won't know which SKs have been compromised (they are getting just 10-11 bits per SK).

Forget the watermark system, it is just for pirates. Any watermark system requires a thing to work: a published movie.


Yes, that is the maximum number of different first columns, but remember, they can require second columns if they want


Of course they can break their own spec, but it is unlikely they do so. Second column will be used by some players just in case they have a compromised key at first column.

[FoxDisc]

an attacker that publishes just one SK can do it safely (sans being located).....
Attacker discloses nothing except one SK. There are two posibilities:

1- All the players that have this SK have it at same column. So LA knows that attacker player is a player that has this SK (great discovery!)

2- The players that have this SK have it at different columns. However all these players (including attacker player) can try their SK at the column LA chose. LA doesn't know if SK column number at attacker player is "first" column (i.e. the chosen column) or any other column.

The AACSLA has a master matrix of 2^16 rows and 2^8 columns. Each element in the matrix is a Sequence Key.
Each device gets one SK from each column. It also gets the associated row number. There are 6 SKBs on each disk. Each one defines a column in the matrix. Every device has to look up its SK and matching row number for that column. They do this six times to calculate the six variant media keys and six Dvs. A single SK does no good. You need the matching row and it has to be in the right column. Here is the formula:
Dv = [AES-G(Kms_i, X ⊕ f(c,r))]msb_80 ⊕ Dke_

If the attack gives only a single SK, there is not enough information to decrypt. It needs to give this information six times for the 6 SKBs. The first SK tells the AACSLA that the device was one of 2^16 different groups. Disclosing 2 tells it that the device was one of 2^32 possible groups. Disclosing all 6 identifies the device as one of 2^92 groups. There are only 2^32 differnt devices, so on average, the 2d or third required key out of the 6 identifies the source.
c and r are the column and row

Far unlikely they do so. Segment Keys are just a watermark system to face the case a pirate keeps secret his SK but publishes the decrypted movie. It is a system to identify the SK that has been used to decrypt. That's why there are 6 SKBs (and no more).

The SK system does watermark the movie, and if an attacker discloses the keys that will successfully decrypt a movie, the movie will be watermarked, and the 6 Sk/row combinations disclosed will identify the source as well as the watermark did.

If they require a different SK per SKB then pirates can keep secret their SKs and publish the decrypted movie. If LA does so it won't know which SKs have been compromised (they are getting just 10-11 bits per SK).

It's not how much information they get per SK, it's how much they get per set of 6 SKs required to decrypt the movie.

The first thing the device does with the six SKBs is to prepare a lookup table with 192 entries. Why 192? because it has 32 spots it will need them times 6 sets of decryption keys from the 6 SKBs. Each of the 32 watermarking spots will look up one value from the table.

Forget the watermark system, it is just for pirates. Any watermark system requires a thing to work: a published movie.
Any decryption that succeeds produces a watermarked movie. The purpose of the watermark is to identify the device that the keys came from. Any set of keys that works will define the device and the keys to be revoked as well as the movie did.

[xyz987]

If the attack gives only a single SK, there is not enough information to decrypt.


Again?. Column number is at SKB, and fair use guy can try all the rows of that column.

You can not change the fact that many thousands of players have this SK. May be this SK is at different columns for each player or not. May be this SK is at different rows for each player or not. Attacker only publishes just one SK. He is not revealing at which row of which column is this SK in his player.

Please pick any distribution of this SK in four players (choose column and row numbers for each player), say me which is the Unconditional Column you pick for your SKB and i will show you that attacker player may be any of the four players.


It needs to give this information six times for the 6 SKBs.


Again?. Attacker publishes just one SK. If more that one SK is required for the 6 SKBs on same disk (far improbable), other attackers will publish additional SKs, each of them from different players (just one SK per player).

The same if more than one SK is required to decrypt different movies. Attacker always publishes just one SK. Read my lips: just one SK per player.

[FoxDisc]

Again?. Column number is at SKB, and fair use guy can try all the rows of that column.

The 64 bit SK in the specified column is in only one row of the AACS LA master matrix, so whoever disclosed the SK for this column might as well disclose the associated confidential row. It's not of any value without that.

You can not change the fact that many thousands of players have this SK.

We agree on this. There are only 2^16 different rows for each column. There are up to 2^32 different possible players, so up to 2^16 may have this exact SK in this row. Every player gets one SK from this column and gets told the secret row #.

May be this SK is at different columns for each player or not. May be this SK is at different rows for each player or not. Attacker only publishes just one SK. He is not revealing at which row of which column is this SK in his player.

It's unlikely the same SK will be used in different places in the matrix (there are 64 bits to the key and only 24 bits of places to put them in the master matrix). If an attacker doesn't reveal the associated row, then others can't use it to decrypt. He needs to disclose a valid set of six SKs from the master matrix with their associated row numbers for others to succeed.

Please pick any distribution of this SK in four players (choose column and row numbers for each player), say me which is the Unconditional Column you pick for your SKB and i will show you that attacker player may be any of the four players.

If you give me a 64 bit SK, it will only be useful with its associated confidential row number. I've given you the decryption formula twice that requires the key and its row and column. The key has to match the position (row and column) in the master matrix used by the LA to make the SKBs. There will only be one place in that matrix where it apppears. It will only be useful if it's a valid SK in the Unconditional Column defined by the SKB.

Even if you give me a valid SK and a valid row, that is not enough to decrypt the 32 regions of the Title where SKs are used. You must give me 5 more sets for the other 5 SKBs.

Again?. Attacker publishes just one SK. If more that one SK is required for the 6 SKBs on same disk (far improbable),

I think it is not "improbable." I think it is certain. However, we do not know. We won't know until they use an SKB. We do know this:
1) The purpose of the SKB system is to identify the attacker
2) You are right that thousands share the same SK in the first column, so if that is all that is needed, the LA cannot tell who published it.
3) There are 6 SKBs, not one and each requires an SK from a column.

I deduce from that - they will not use the same column for each SKB as that will not let them identify the attacker.

Read my lips: just one SK per player.

I read them. I don't agree. Why would they specify 6 SKBs on each disc? Why do they set up a lookup table with 192 entries (32 decryptions times 6)? Why do they have 6 different Volume Unique Keys for decryption at the 32 locations? Why would they use the same SK for all 6 SKBs when we know they would not be able to identify the attacker if they did that? You are assuming they would do the one thing that would prevent the SK system from accomplishing its stated purpose.

Perhaps we should agree to disagree. If your position is that they will use the same SK for all 6 SKBs, then I agree with your comments - they would not be able to identify the attacker beyond the single column (one out of 65,000 different possible groups of devices). I can't prove that they will not do such a stupid thing.

[FoxDisc]

Here are some interesting questions for the future about Sequence Keys:

1) A set of 6 Sequence Keys and their row numbers from the AACS LA master matrix (256 columns up to 2^16 rows) will be required to decrypt a Title. All devices will have a valid set. The question is how many sets will be valid for a specific set of SKBs. Will the first 3 SKs from player A and the last 3 from player B form a valid decryption set? I think the answer is no, but I'm not sure.

2) A Title has up to 32 spots where one of 8 different cells must be decrypted. It appears that each of the 8 cells can potentially be decrypted, so that all that is required is to give one decryption key for one of the 8 cells at each of the 32 locations. These keys are the equivalent of the title key that is used for the rest of the movie. I'm still not sure how much information a single decryption key for a cell gives out about the source of that key. The 32 keys needed could come from many different players.

3) Software players are likely to remain the most attacked players. Will they give out the same set of Device Keys and Sequence Keys to each player version or will they start individualizing each copy of the player to be able to identify and revoke specific copies? This seems unlikely, but who knows.

[ralferoo]

2) A Title has up to 32 spots where one of 8 different cells must be decrypted. It appears that each of the 8 cells can potentially be decrypted, so that all that is required is to give one decryption key for one of the 8 cells at each of the 32 locations. These keys are the equivalent of the title key that is used for the rest of the movie. I'm still not sure how much information a single decryption key for a cell gives out about the source of that key. The 32 keys needed could come from many different players.
Before I start, I should note that in this post I'll be using the term "oracle server" as mentioned in previous posts as a term for an internet service that is given a request containing enough information to identify a disc and returns a response containing the keys required to decrypt the the title. If sequence keys are used, you'd get back a general media key and 32 cell keys to decrypt a particular title. Hopefully, this is also the meaning others were using for that term.

Now, if each of these 32 keys (cells) can each take on 1 of 8 possible values, we have 3 bits of information, meaning overall there is 96 bits of information given out about the device's SK set. 96 bits is large enough that every individual device can be uniquely, and this seems the likely way of identifying a set of keys to be revoked. I would strongly imagine that the device class is encoded into this so they can work out which nodes in the regular tree need to be revoked if it became apparent that an entire class of device had become easy to compromise and an easy source of keys.

If an oracle service had access to two sets of keys, in the best case scenario (from its perspective) it could come up with a different key for each cell and choose randomly which one to publish, effectively making 32 bits of that 96 bits random. From a sample of one, the tracing technique would identify the wrong device completely (assuming the cell keys weren't all from the same player). However, as the oracle server offered keys to decrypt different titles, it would become apparent which 32 bits were being chosen randomly, and so which 64 bits were correct.

Now, this is probably where the 256 columns comes in, because if one set of keys was "temporarily revoked" when questioning the oracle server, it would have to choose a different set of keys for each of the columns. If these were chosen carefully by the LA then the identifying bits would be distributed differently and so a different set of 64 bits could be determined. Now, if the column was chosen particularly so that those 64 bits included the 32 unknown bits, then the oracle server would be giving up the identity of both of its sources of device keys.

Now, the oracle server stands a better chance of avoiding detection if it doesn't randomly choose a key from each cell, but instead having that choice as a function of the input. Thus, for the same request it will always impersonate the same device rather than carelessly giving away information about which bits are entropic.

On the other hand, if the oracle server is prepared to attempt to decrypt any request that comes in, it will be forced to give up that information as it will have to decrypt MSKs from arbitrary columns. The only way the oracle server can be relatively safe is if it gives keys out from known good requests, e.g. when it has itself previously seen that physical media. Even then, given enough titles using keys from different columns it will give up its own identity.

Obviously, the more SKs the oracle server has the more entropy it can provide in the output, but all this does is increase the number of columns needed to identify its sources.

So, the other obvious approach is finding a way of discovering a large source of these key sets. This is most likely to come from a class of device being compromised (e.g. a particular model of hardware player or version of software player where the keys can be easily discovered). So, in all likelihood the LA will assign a large common set of keys to a manufacturer and a smaller set of keys that particularly identify the individual device. e.g. cells 1-16 might be decoded using exactly the same key for all devices of the same model and 17-32 providing a serial number for an individual device. This would improve security the available bits of entropy from an oracle server would be greatly diminished unless it had key sets from several different types.

[FoxDisc]

Before I start, I should note that in this post I'll be using the term "oracle server" as mentioned in previous posts as a term for an internet service that is given a request containing enough information to identify a disc and returns a response containing the keys required to decrypt the the title. If sequence keys are used, you'd get back a general media key and 32 cell keys to decrypt a particular title. Hopefully, this is also the meaning others were using for that term.

Yes, this is an "anonymous" oracle because it gives out the final key for each encrypted section, without disclosing the smaller set of Sequence Keys it used to get the answers . A non-anonymous oracle would give out the 6 Sequence Key/row# sets and let the recipient calculate the keys for each of the 32 sections.

The terminology makes more sense in the Device Key scenario. In that scenario, the media key/title key is encrypted multiple times by multiple processing keys. Every device ultimately arrives at the same Title Key, but could have used any one of many different processing keys. The anonymous oracle would only give out the final title key (or the final decrypted movie) which could have come from any device - disclosing nothing. In contrast, a program capable of playing a disc must calculate the title key and that discloses the exact device keys/processing keys used for the calculation, so it is not anonymous.

The terminology as applied to the Sequence Key scenario is a bit confusing since the purpose of the SKs is to identify the device even with an "anonymous oracle" attack, although it is more difficult than when the non-anonymous SKs are given out.

Now, if each of these 32 keys (cells) can each take on 1 of 8 possible values, we have 3 bits of information, meaning overall there is 96 bits of information given out about the device's SK set. 96 bits is large enough that every individual device can be uniquely, and this seems the likely way of identifying a set of keys to be revoked. I would strongly imagine that the device class is encoded into this so they can work out which nodes in the regular tree need to be revoked if it became apparent that an entire class of device had become easy to compromise and an easy source of keys.

I suspect you are right.

If an oracle service had access to two sets of keys, .....

Interesting analysis. Clearly the more final decryption keys for the 32 times 8 cells that the oracle has, the harder it is to identify it. If it had all of them, it would be truly anonymous, but I doubt that anything short of all keys from all devices would give that level of information.

[FoxDisc]

2) A Title has up to 32 spots where one of 8 different cells must be decrypted. It appears that each of the 8 cells can potentially be decrypted, so that all that is required is to give one decryption key for one of the 8 cells at each of the 32 locations. These keys are the equivalent of the title key that is used for the rest of the movie. I'm still not sure how much information a single decryption key for a cell gives out about the source of that key. The 32 keys needed could come from many different players.

A related issue to the above: The result of decrypting one of the 8 cells is a time portion of the movie/title. That section has to be marked. Each of the other cells from the 8 has to have a different mark. We're talking about true watermarking here. The video data needs to be fundamentally the same or everyone will see a different movie.

Instead of issuing decryption keys, the oracle could theoretically issue the decrypted section of the movie. The oracle could serve up all of the decrypted sections with the watermarking removed so it couldn't be traced back to the keys used to decrypt it. This anonymizes the oracle. I've seen some interesting analyses of watermarking removal techniques. Unfortunately, now we're talking about needing a pirate server (for 32 short sections of the movie) to protect the fair use right to make backups. It would be ironic if the whole AACS system pushed legitimate users towards piracy merely to exercise their fair use rights.

I suppose the encrypted sections could be uploaded, decrypted, then processed to remove the watermarking before being returned. I haven't checked to see how big these sections are.

[xyz987]

We agree on this. There are only 2^16 different rows for each column. There are up to 2^32 different possible players, so up to 2^16 may have this exact SK in this row.


I want to be sure we really agree on this. If an attacker publishes just one SK (just the SK) from his player, do you agree LA doesn't know the identity of attacker player?

May be an step-by-step approach is more fruitful.

[FoxDisc]

I want to be sure we really agree on this. If an attacker publishes just one SK (just the SK) from his player, do you agree LA doesn't know the identity of attacker player?

May be an step-by-step approach is more fruitful.

There are up to 2^16 rows in a single column. Let's assume that all rows were used in the master matrix (this give the AACS LA the maximum information). If the attacker publishes a single SK they know he had that SK. They know where that SK is in the master matrix. Someone has a record of all the players ever issued with that SK. We don't know how many players have been issued SKs. However, if all 2^32 possible players were randomly issued SKs, 2^16 players would have that same key.

Yes, I think we agree about this.

[arnezami]

There are up to 2^16 rows in a single column. Let's assume that all rows were used in the master matrix (this give the AACS LA the maximum information). If the attacker publishes a single SK they know he had that SK. They know where that SK is in the master matrix. Someone has a record of all the players ever issued with that SK. We don't know how many players have been issued SKs. However, if all 2^32 possible players were randomly issued SKs, 2^16 players would have that same key.

Yes, I think we agree about this.

So if there are 256 people who each release 1 sequence key (each out of a different column) we will have a complete set of 256 Sequence keys. And the 256 people will not be identified if (1) there are more than enough players sold (2) sequence keys are distributed randomly.

The problem is of course: they can revoke unique sets of 256 keys. Since we would have exactly that it may be possible (1) none of the 256 sequence keys actually works in the first place or (2) they will make sure none of the 256 keys work (by not using any of these 256 keys on future discs).

Alternative: make sure you find say 256 people each releasing 2 keys. Assuming we now have two sequence keys in each column I have the feeling they (the AACS LA) would then have a real problem. Why? Because there are upto 2^256 possible combinations of unique sets of 256 keys. And (given pure random distribution) how do they know which sets to revoke?

All depends on the amount of players sold (that is: those with unique sets of keys**) and the randomness/smartness of the distribution. Eg. we might not be able to find two different Sequence keys in each column (but that has both advantages and disadvantages: revoking-wise).

Maybe we should do some concrete examples:

- Only 1000 players released. Random distribution.
- Only 1000 players released. "Smarter" distribution.
- 100000 players released. Random distribution.
- 100000 players released. "Smarter" distribution.
- 10000000 players released. Random distribution.
- 10000000 players released. "Smarter" distribution.

In any way I believe (from a comsumers point of view) the general rule of thumb is this: if you have found a Key and several other people have it too you can probably release it without risk.

Regards,

arnezami

** Needless to say that if they would use the same set of sequence keys in many standalones they are screwed since they would have to revoke them all. In fact: even if many Keys of the sets of a single type of player are shared between those players we could release these (maybe 200?) and they wouldn't be able to revoke them. So non-randomness may not be "Smarter" at all: we would have reduced the problem from finding 256 keys to say 50 (in for example a software player or from standalones by less savvy people).

[xyz987]

Yes, I think we agree about this.

Okay. Next step:

A guy called Peter has downloaded the published SK. Peter wants to get a valid Volume Variant Unique Key (he wants just one of the VVUKs), he can check if a VVUK is valid looking at Segment Key File. He knows which is the column number for each SKB (there are 6 SKBs on disk) because it is stored on it, but there are 2 things he doesn´t know:

1- Row number

2- Which SBK he must use (there are 6)

So Peter try all the possibilities. First he tries row number 0 with SKB 1 and he checks if he has got a valid VVUK, if not then he tries row 1 with SKB 1 and so on. If SKB 1 doesn't output a valid VVUK, he repeat the process with SKB 2 and so on.

Do you agree that Peter will find a valid VVUK?

[xyz987]

Alternative: make sure you find say 256 people each releasing 2 keys. Assuming we now have two sequence keys in each column I have the feeling they (the AACS LA) would then have a real problem. Why? Because there are upto 2^256 possible combinations of unique sets of 256 keys. And (given pure random distribution) how do they know which sets to revoke?


They can not revoke any player if the 512 SKs are from 512 different players, but all the published 512 SKs will become "compromised", i.e. they will not be useful to decrypt newly released movies.

[arnezami]

They can not revoke any player if the 512 SKs are from 512 different players, but all the published 512 SKs will become "compromised", i.e. they will not be useful to decrypt newly released movies.

Sure. But we would then have the Sequence Keys for a large amount of discs. Without giving up any identities.

Problem is: you would have to give away more and more information (or let more people be involved) for the next batch of discs. Unless they are distributing Sequence Keys in a non-random (and not so smart) way.

Naturally extracting all 256 Keys from a Software Player is far more effective. Revocation is probably default (for Software players) so it doesn't really matter.

[FoxDisc]

So if there are 256 people who each release 1 sequence key (each out of a different column) we will have a complete set of 256 Sequence keys. And the 256 people will not be identified if (1) there are more than enough players sold (2) sequence keys are distributed randomly.

I will just quickly comment on this. There are 2^4096 different possible sets of sequence keys. There are only 2^32 possible players, so there are many sets that are never assigned. This goes back to my question #1 - is a set of SKs - some from A and some from B a valid set? I haven't decided yet, but I suspect, based on the process and math that the answer is no. I think they can build SKB files with the 6 SKBs so that random collections of SKs will not be valid - they won't work to decrypt anything. Worse - the SKs will become compromised. They can be revoked individually, requiring the players who have them to go to the second column containing an uncompromised SK when processing that SKB.

Of course, I am still not certain - it's an area I'm planning to look at. Comments are welcome.

Another general comment - I'm pretty sure everyone understands that this is highly theoretical. The AACSLA knows that software players are being attacked. There's not a lot of "tracing" that needs to be done when they know the attack is from software players. Nonetheless, I think they will implement SKBs because it does increase the number of keys to be handled, stored, uploaded and processed. It makes backing up harder.

[arnezami]

This goes back to my question #1 - is a set of SKs - some from A and some from B a valid set? I haven't decided yet, but I suspect, based on the process and math that the answer is no. I think they can build SKB files with the 6 SKBs so that random collections of SKs will not be valid - they won't work to decrypt anything.
I suspect a (randomly) collected set of 256 Sequence Keys will be able to decrypt at least some movie or movie fragments. Especially if Sequence Keys are released (by customers) that are actually used for decrypting already released movies/discs. If we could choose 256+ Keys that work on several discs they will probably be able to decrypt most (if not all) discs released so far. This is because I think the SKs used in the SKBs might always be the same for one SKB version.

I agree this is quite theoretical stuff right now. We don't need any of this right now but its interesing stuff. And I also believe extracting 256 keys is much harder than extracting just a (few) Processing/Device Keys and a Pirvate Key. So it would be wise for them to implement it even if they don't use it for tracing.

[FoxDisc]

Okay. Next step:

You have my respect - this is a very good way to find out where we disagree. Together we look for the truth of how it works.

A guy called Peter has downloaded the published SK. Peter wants to get a valid Volume Variant Unique Key (he wants just one of the VVUKs), he can check if a VVUK is valid looking at Segment Key File. He knows which is the column number for each SKB (there are 6 SKBs on disk) because it is stored on it, but there are 2 things he doesn´t know:

1- Row number

2- Which SBK he must use (there are 6)

So Peter try all the possibilities. First he tries row number 0 with SKB 1 and he checks if he has got a valid VVUK, if not then he tries row 1 with SKB 1 and so on. If SKB 1 doesn't output a valid VVUK, he repeat the process with SKB 2 and so on.

Do you agree that Peter will find a valid VVUK?

This SK is going to be found in only one row and column of the master AACS matrix of SKs. Whoever disclosed it knew that information, and the AACS LA knows it, so there is no reason to keep secret either number 1 (row) or 2 (column = which of 6 SKBs it matches.)

There is no reason for the recipient to have to search for row or column number. If it is not in the correct column for any of the 6 SKBs for the movie he is trying to decrypt, it is of no use.

Now, let me break the question down further. First, let's assume the SK is an unrevoked SK in the correct column for the first of the six SKBs. Then the answer is clearly yes. The recipient will be able to calculate a valid Volume Variant Unique Key (Kvvu) and valid Variant Data Dv. The lower 10 bits of the Variant Data are the Segment Key Unit Number (SKUN). This process would be the same as any other valid device would follow.

Now the process gets more tricky. You want to know if a valid Volume Variant Unique Key (Kvvu) and valid Variant Data (Dv) will be calculated for this key if it is not in the column of the first SKB. I think the answer is again technically yes. I think at this level the SKs are still independent (not totally sure, but I think so) IOW, any device having this SK in this column will calculate the same Kvvu and Dv.

It would produce valid Volume Variant Unique Key (Kvvu) and valid Variant Data (Dv). However, that's not the end of the story. You don't use the Kvvu's and Dv's independently. You use them to build a table with the other 5 SKs you have. My reading of the process is that you will build the wrong table and/or use/decrypt the wrong entries in that table with the wrong keys if your set of 6 SKs is not a valid set.

This goes directly back to my question #1 of whether a set of SKs made up of the SKs from different players forms a valid set.

The above is intended to lead you to the next question - about how the Kvvu's and Dv/SKUN's are used with the Segment Key File (SKF) in the “AACS” directory. The SKF contains six Segment Key Group (SKG) fields. Each SKG field contains 1024 Segment Key Unit (SKU) fields. An SKU field contains 32 encrypted pairs of a Segment Key Number (SEG_NO) and a Segment Key of 16 bytes. From the 1024 SKU fields in the correct one of the six SKG fields, one SKU field is chosen according to the SKUN number above. The chosen SKU field,can be decrypted by the matching Volume Variant Unique Key Kvvu.

So to answer your question - yes, I think six individually valid Kvvu's and 6 matching valid Variant Data Dv's would be calculated by Peter (if 6 unrevoked SKs are disclosed for the specified 6 columns). I say "independently valid" because I think that one by one, each Kvvu matches what a valid device would have calculated at that position. The set of 6, however, depends on what 6 SKs were used. If they all came from a single valid device, we are on the right track for a successful decryption. If not .... we are about to reach the crux of the matter.

[FoxDisc]

I suspect a (randomly) collected set of 256 Sequence Keys will be able to decrypt at least some movie or movie fragments.

Arnezami and xyz drive me to understand more deeply. After the last post, I looked more closely at my first question - will SKs from different devices succeed in decryption. Although I cannot be certain, I now lean towards the belief that they will allow decryption, provided that only one column and one key is required for each SKB.

I have not found any definitive connection between the six SKBs. I now believe that the SK system works as follows: Each time SKs are released capable of decrypting a title (or a decrypted title is released), it will identify six compromised SKs. They may come from one device or they may come from multiple devices.

Since innocent devices share SKs, they could not revoke the device that has those 6 keys. They might define an innocent device. However, they can also obtain information from other titles, which would reveal another 6. This will narrow it down as to whether one device or multiple devices are compromised, but perhaps it is not enough information still.

So what they do is revoke all of the known compromised Sequence Keys with a new SKB file. They don't revoke any player yet. This requires the attacker to disclose a pair of SKs for each of the six SKBs. This narrows down the suspect list substantially. With multiple titles, they should quickly be able to identify whether the keys come from one compromised device or multiple devices. Just knowing one pair of SKs in two columns tells the LA that the device is in one of 2^32 different groups (first column is one of 2^16 groups and second is one of 2^16 different subgroups within the first group). There are only 2^32 different players. This should tell them what they want to know.

I believe I was incorrect in thinking that the keys used for the six SKBs are linked. It is more likely that the linking is done on an SKB by SKB basis as described above by requiring more than one SK to be used to get the correct Kvvu and Dv. To emphasize: if the first SK in the defined column is compromised, you must still use that compromised SK to get a first Dv. You then must use an SK from another column and the DV previously calculated to get the final Kvvu and Dv. You can't get the final without the first, and you don't get the right answer for the final if the first wasn't calculated from the same SK set used for the final. This is the linkage the AACS LA needs.

In fact, I suppose they could do this on the first SKB set released. They could assume that every single SK released is compromised and force every device to use two keys from its set of SKs for every SKB. It is those keys that are clearly linked.

This will be much easier to understand when (if?) the first SKB files are released.

[xyz987]

Sure. But we would then have the Sequence Keys for a large amount of discs. Without giving up any identities.


Yeah, that's true.


Problem is: you would have to give away more and more information (or let more people be involved) for the next batch of discs.


The only way to avoid this is to break completely the SKB system. It is theoretically possible to do so because the maximum number of players is a 32 bit number, and the number of positions at the matrix is a 24 bit number. However I simply don't know how many SKs from different players must be published to achieve this goal. If a group of attackers get 16 millions SKs no doubt they have broken it, but 16 million is not a practical number. The problem is to find a far lower number (may be there is no that lower number!).


Naturally extracting all 256 Keys from a Software Player is far more effective. Revocation is probably default (for Software players) so it doesn't really matter.

Yeah, nowadays soft players are almost completely broken but they can be hardened. In my opinion, we should go further. We should go to "things" that can not be hardened (i.e. standalones). This is the only way to escape from revocations.

[xyz987]

I now lean towards the belief that they will allow decryption


Okay. Next step:

Now Peter has decrypted the movie using 6 SKs from different players. But these SKs will become "compromised" soon, so the new movie that Peter will buy later can not be decrypted using them.

Afortunately, other 6 attackers publish other 6 SKs from different players. Let's say 3 of these SKs are at the "first" column of the corresponding SKB and the other 3 are at the "second" column. To get 6 valid VVUKs for the new movie Peter needs the 6 SKs work right.

For the first 3 SKs Peter finds they are at the "first" column of the first 3 SKBs and he repeats the process we have explained on former messages. No news here.

For the other 3 SKs (they are not at "first" column) Peter does as follow:

He tries the first of the compromised SKs (the old SKs) to process the first column of the fourth SKB. This allows him to go to second column (rightly or wrongly), then he uses the fourth of the uncompromised SKs (the new SKs) at second column and he checks if the resulting VVUK is valid. If not, he repeats the process with another old SK or another SKB or another new SK.

Do you agree that Peter will get 6 valid VVUKs for the new movie?

[FoxDisc]

Okay. Next step: Now Peter has decrypted the movie using 6 SKs from different players.

You have assumed that each of the SKB's required only one SK. I am fine with this assumption, but I suspect the LA will start off requiring at least two SKs from the same device for at least one of the six SKB decryptions. This will identify that device for revocation.

But these SKs will become "compromised" soon, so the new movie that Peter will buy later can not be decrypted using them.

Agreed. Also, when you say SKs are compromised and Peter can't decrypt, you are saying that the LA has changed the disc. They can revoke devices (and their SK set) when they did this. Did they find out the device/devices the SKs came from previously? If they did, they have revoked devices and all their device and sequence keys. If they are smart, they can identify all 6 devices that provided the original SKs for the 6 SKBs. All their DKs and SKs become useless.

Afortunately, other 6 attackers publish other 6 SKs from different players. Let's say 3 of these SKs are at the "first" column of the corresponding SKB and the other 3 are at the "second" column. To get 6 valid VVUKs for the new movie Peter needs the 6 SKs work right.

For the first 3 SKs Peter finds they are at the "first" column of the first 3 SKBs and he repeats the process we have explained on former messages. No news here.

Agreed so far.

For the other 3 SKs (they are not at "first" column) Peter does as follow:

He tries the first of the compromised SKs (the old SKs) to process the first column of the fourth SKB. This allows him to go to second column (rightly or wrongly), then he uses the fourth of the uncompromised SKs (the new SKs) at second column and he checks if the resulting VVUK is valid. If not, he repeats the process with another old SK or another SKB or another new SK.

Do you agree that Peter will get 6 valid VVUKs for the new movie?

This deserves a long answer, but all I have time for is the short answer: No.

In general, when a first and second column are required for an SKB, the SKs must be from the same set. The first column produces a specific Dv and that Dv gets modified correctly by the second column SK processing only when the first answer was right and the second column was processed by a member of the same set as the first SK. When the set is revoked, they never get the right answer.

[xyz987]

If they are smart, they can identify all 6 devices that provided the original SKs for the 6 SKBs.

I don't understand this. First you agree that attacker player (one SK per player) can not be identified, now you say it can be identified. Could you clarify this?.

Just to clarify: a SK is "compromised" when SKB column sends the player to another column. A SK set is revoked when final output is zero. I have not said that first 6 players have been revoked, I have just said that the published SKs become "compromised" (i.e. these keys send to another column).


This deserves a long answer, but all I have time for is the short answer: No.

In general, when a first and second column are required for an SKB, the SKs must be from the same set. The first column produces a specific Dv and that Dv gets modified correctly by the second column SK processing only when the first answer was right and the second column was processed by a member of the same set as the first SK. When the set is revoked, they never get the right answer.


To answer this i prefer to wait until you clarify the above.

Hint: the Variant Data from the first column is always the same value for every player that must use the second column. Any player that lands on second column decrypts DEADBEEFh before processing second column. Further details as soon as you have clarified the above.

[FoxDisc]

I don't understand this. First you agree that attacker player (one SK per player) can not be identified, now you say it can be identified. Could you clarify this?.

If only one column (and only one SK) is required for an SKB, then attacker can be narrowed to one in 2^16. That is not enough to identify him. If two are required, he can be narrowed to one in 2^32. There are only 2^32 players. We started off assuming the LA would only use one column, since that was the simplest to analyze. If they use two, he can be identified.

Just to clarify: a SK is "compromised" when SKB column sends the player to another column. A SK set is revoked when final output is zero. I have not said that first 6 players have been revoked, I have just said that the published SKs become "compromised" (i.e. these keys send to another column).

I agree with this terminology and understand that the 6 devices were not revoked. Individual devices and sets of SKs are revoked. When a set is revoked, all of its SKs are presumably compromised.

To answer this i prefer to wait until you clarify the above.

Was I clear? One column per SKB is not enough to identify source (original simpler assumption by both of us). Two or more is enough (later assumption by me - you are still talking about one in some spots, so I try to answer based on that assumption).

Hint: the Variant Data from the first column is always the same value for every player that must use the second column.

Yes. After the first column the LA has found the one group out of 65,000 possible groups that the bad boy is in. All we need to know is which member of this group is the bad boy,and which are innocent. The second column divides the first group up again into 65,000 more subgroups.

Any player that lands on second column decrypts DEADBEEFh before processing second column.

Yes. We agree everyone in this smaller group can get the DEADBEEF. But now the bad boy uses his second SK and row number for the second column. Now the LA says AHA! Bad Boy Found! He is the only one in the first group (with SK1) who had this SK2.

The first SK1 was 64 bits long. The second was 64 bits long. The two form a 128 bit number that only the Bad Boy has. Good Boys share the first half of the 128 bit number, but not the second half.

Further details as soon as you have clarified the above.

OK

[ErazorTT]

i've been reading that whole thread with much of interest lately.

now, i feel i have to interfere. i'm not quite sure why you two (Fox, xyz) talk at cross-purposes, at least this is what i think you are just doing.

i'll try to sum up what each of you has written, perhaps that helps you to get back in line.

each of you must agree with every point. if one of you doesn't agree with one point further dicussion is senseless.
so than this would be where you have to come to an agreement, before goning on.

1. only one SK is enough to decrypt one SBK. there may be 6 SK from 6 different players to decrypt an whole film.

2. there are 2^32 players and one SK reveals that the player is one out of 2^16.
so with one published SK he cannot be revoken.

-- 6 SKs from 6 different players are distributed

3. peter takes these published SKs. he will be able to decode the film SHREK1 if the 6 SKs are all from the 1st row.
It actually doesn't matter if he knows the row and/or the column of these SKs or not.
he could try them out if he didn't new the row and/or column.

4. after the SKs are published they are labeld compromised and will be revoked on futere disks
(the SKs are revoked not the players, because LA doesn't know which player to revoke).

--6 new SKs are distributed from 6 different players. these player are not the first 6 player, these are other 6 different players.

5. if these SKs were again entirely from the first row Peter would be able to decrypt the new film SHREK2.

--but, to complecate the situation, the 6 SKs are now not entirely from the first row.

6. will peter be able to decrypt the film SHREK2?

[FoxDisc]

Hint: the Variant Data from the first column is always the same value for every player that must use the second column. Any player that lands on second column decrypts DEADBEEFh before processing second column.

A brief additional comment: The result for the first column is always the same for every player that must use the second column. However, the LA can send some players from the first column to the third column and others to the second column. After the first column is processed, players who need to go farther get a "link" to another column. The link could go to the second column or the third, etc. Different devices with different SK1s can get different links to different columns requiring different SK2s. This gives the Licensing Authority additional options to identify the attacker or revoke key sets.

[FoxDisc]

i've been reading that whole thread with much of interest lately. now, i feel i have to interfere. i'm not quite sure why you two (Fox, xyz) talk at cross-purposes, at least this is what i think you are just doing.

Perhaps you don't see how basic assumptions change as we study it more deeply. This causes early posts to be outdated and later posts to be inconsistent with early assumptions. It takes time to agree on each point.

i'll try to sum up what each of you has written

each of you must agree with every point. if one of you doesn't agree with one point further dicussion is senseless.
so than this would be where you have to come to an agreement, before goning on.

1. only one SK is enough to decrypt one SBK. there may be 6 SK from 6 different players to decrypt an whole film.

This calls for a prediction of what the LA will do. It can't be answered. I think xyz and I agree that one SK is needed per column used in each SKB. If the SKB defines only one column, only one SK is needed. If it defines two, then two are needed. We will know the answer as soon as they release an SKB. I suspect at least one will need two columns. Neither of us can answer what they will do, only what the effect of the two possibilites will be.

2. there are 2^32 players and one SK reveals that the player is one out of 2^16.

Agreed

so with one published SK he cannot be revoken.

I technically disagree, but agree in practice. Technically, all devices with an SK can be revoked. Practically, that might require revoking innocents (we don't know how many players have that key or what the LA knows about the members of the group.) Most likely, the published SK would just be considered to be "compromised" and the LA would look for more info if that was all the info they had. We don't know if a single published SK would be of any value (I suspect not), so the situation may not arise.

-- 6 SKs from 6 different players are distributed

We don't know if this is of any value - do you want to talk about it or not? It is sometimes useful to talk about it to agree what would happen if .... even when we don't think it will happen or we don't think it will be useful.

3. peter takes these published SKs. he will be able to decode the film SHREK1 if the 6 SKs are all from the 1st row.
It actually doesn't matter if he knows the row and/or the column of these SKs or not.
he could try them out if he didn't new the row and/or column.

You are doing pretty good, but I don't think you meant "all from the 1st row." Rows and columns are in the master matrix. Each SKB defines a column from the master matrix. Every device has one SK in that column, but they are usually on different rows. I don't see how you would get the SKs from the first row. If they were from the first row, you would know the row. I think you should be asking for agreement on whether a specific SK for a specific column defined in an SKB uniquely identifies the row. The answer to that is yes. (It probably uniquely identifies the column too.) The LA knows the row, the device disclosing it knows the row, so it's not a secret. If you don't understand why that is the question you should ask - ask.

4. after the SKs are published they are labeld compromised and will be revoked on futere disks
(the SKs are revoked not the players, because LA doesn't know which player to revoke).

You are deep into an assumption I think is probably not valid (one SK per SKB), and you are asking for a prediction about what the LA will do. I agree that published SKs will be considered compromised. We don't know how many devices actually share SKs. If PDVD has SK1 and WDVD has SK2, but not SK1, and SK1 and SK2 have not been assigned to any other device, then the release of SK1 means it came from PDVD.

--6 new SKs are distributed from 6 different players. these player are not the first 6 player, these are other 6 different players.

5. if these SKs were again entirely from the first row Peter would be able to decrypt the new film SHREK2.

--but, to complecate the situation, the 6 SKs are now not entirely from the first row.

Again with the "first row." You will have to clarify. If you want to be very clear, make sure you distinguish between the column of the LA's SK master matrix and the column of the SKB that specifies the column in the master matrix. Sometimes in this thread the column specified by the SKB is called the "first column" It is officially the "Unconditional Column." All other columns in the SKB are "Conditional" columns (sometimes called the "second column" here) and they also point to a column in the master matrix. A device checks the unconditional column in the SKB, reads the specified column for the master matrix, and get his single SK and row number for that column. Every device gets one and only one SK from each column of the master matrix. The device will need the SK, the row and the column to work through the first column of the SKB. If the SKB sends him to another column, he'll need that info again for the next specified column of the master matrix, etc.

6. will peter be able to decrypt the film SHREK2?

Not if he's a bad boy and the LA has his number. :)

[FoxDisc]

This thread is deep into details of the SKB traitor tracing system. I'm going to step away from the details a bit to remind us of what is under discussion in this thread.

1) The beginning of this thread covers the Subset Difference System, Device Keys, Subsidiary Device Keys, MKBs, Processing Keys, etc. It describes how the main keys are distributed, controlled and revoked for the majority of the movie. It is based on a binary tree of 32 levels, with 2^32 players at the bottom. The AACS LA has one secret random number at every node of that tree (or a way to calculate a pseudorandom number). This system alone was relied on to encrypt all discs and it has been shown to be insufficient.

2) Sequence Keys are under discussion now. They are used to get the keys needed to decrypt 32 short segments of the movie. They are used to find the device at the bottom of the tree above that is the "traitor." Once found, he can be revoked from both parts of the system (Sequence Keys and Device Keys) SKs come from a master matrix possessed by the LA that has 256 columns and 2^16 rows. Each cell in the matrix has a 64 bit SK. It is to the SK system like the Master Tree referred to above is to the DK system. Sequence Keys are not yet in use. There are actually two parts of this SK system under simultaneous discussion - Anonymous attack and Non-anonymous:

2A) Non-anonymous is getting the most discussion here. This may be confusing, as a lot of the discussion is about trying to remain anonymous in the non-anonymous attack. Non-anonymous means that someone releases Sequence Keys allowing one to decrypt the segment keys needed to decrypt the 32 missing segments of the movie. Sequence Keys are like Device Keys, they are shared, but they tell something about where they came from.

2B) Anonymous. This refers to releasing the segment keys after decryption by the Sequence Keys (or the actual decrypted segments of the movie). There are 192 segment keys per movie (6 SKBs times 32 segments). Only 32 are needed, but having a specific 32 tells the LA something about where they came from. Again this may be confusing, because the purpose of the SK system is to identify an attacker making an anonymous attack. There has been very little discussion of this type of attack here, but after the non-anonymous scenario is fully understood, focus may shift again to the anonymous scenario.

[ErazorTT]

We don't know if this is of any value - do you want to talk about it or not? It is sometimes useful to talk about it to agree what would happen if .... even when we don't think it will happen or we don't think it will be useful.

Ok let's say they want two SK for an SKB. Wouldn't it be possible to feed the SKB with two SK's from different players?

You are doing pretty good, but I don't think you meant "all from the 1st row." Rows and columns are in the master matrix. Each SKB defines a column from the master matrix. Every device has one SK in that column, but they are usually on different rows. I don't see how you would get the SKs from the first row. If they were from the first row, you would know the row. I think you should be asking for agreement on whether a specific SK for a specific column defined in an SKB uniquely identifies the row. The answer to that is yes. (It probably uniquely identifies the column too.) The LA knows the row, the device disclosing it knows the row, so it's not a secret. If you don't understand why that is the question you should ask - ask.

I meant columns in the SKB.

You are deep into an assumption I think is probably not valid (one SK per SKB), and you are asking for a prediction about what the LA will do. I agree that published SKs will be considered compromised. We don't know how many devices actually share SKs. If PDVD has SK1 and WDVD has SK2, but not SK1, and SK1 and SK2 have not been assigned to any other device, then the release of SK1 means it came from PDVD.

there are 2^8*2^16=16mio different SK. there can be 2^32 players. it could be actually possible to give the first 16mio player an idividual SK, that's true. this would mean that a single SK is enough to revoke a player. as long they don't sell many players they can have very few player to share SK's. but for later there are clearly too few SK's.

Again with the "first row." You will have to clarify. If you want to be very clear, make sure you distinguish between the column of the LA's SK master matrix and the column of the SKB that specifies the column in the master matrix. Sometimes in this thread the column specified by the SKB is called the "first column" It is officially the "Unconditional Column." All other columns in the SKB are "Conditional" columns (sometimes called the "second column" here) and they also point to a column in the master matrix. A device checks the unconditional column in the SKB, reads the specified column for the master matrix, and get his single SK and row number for that column. Every device gets one and only one SK from each column of the master matrix. The device will need the SK, the row and the column to work through the first column of the SKB. If the SKB sends him to another column, he'll need that info again for the next specified column of the master matrix, etc.

Just for beeing sure i understood the SK-system the right way:
There is this master matrix of SK's. it has 256 columns and 64K rows. each player gets one SK from each column.
The SKB asks for (Ok let's say) two SK's. it can define from which colums (one of those 256) these SK'S have to come from, so it defines the unconditional column. if it gets a revoked SK it will ask for an other SK (with the deadbeef thing), now we're in the conditional column(s). If it the SKs are all revoken than the player is revoken. Is this right? am i useing terminology right?

[xyz987]

i'll try to sum up what each of you has written, perhaps that helps you to get back in line.

each of you must agree with every point. if one of you doesn't agree with one point further dicussion is senseless.
so than this would be where you have to come to an agreement, before goning on.

1. only one SK is enough to decrypt one SBK. there may be 6 SK from 6 different players to decrypt an whole film.

2. there are 2^32 players and one SK reveals that the player is one out of 2^16.
so with one published SK he cannot be revoken.

-- 6 SKs from 6 different players are distributed

3. peter takes these published SKs. he will be able to decode the film SHREK1 if the 6 SKs are all from the 1st row.
It actually doesn't matter if he knows the row and/or the column of these SKs or not.
he could try them out if he didn't new the row and/or column.

4. after the SKs are published they are labeld compromised and will be revoked on futere disks
(the SKs are revoked not the players, because LA doesn't know which player to revoke).

--6 new SKs are distributed from 6 different players. these player are not the first 6 player, these are other 6 different players.

5. if these SKs were again entirely from the first row Peter would be able to decrypt the new film SHREK2.

--but, to complecate the situation, the 6 SKs are now not entirely from the first row.


Agreed. You have summarized it far well.

Just a clarification: Peter doesn't need to try all columns, because the column number that must be used is at SKB.


6. will peter be able to decrypt the film SHREK2?


My answer is yes. 3 SKBs are using the second column. On this SKBs the first column outputs a link to the second column when one of the previously compromised SKs is used. Peter has these SKs (and decrypted Shrek 1 with them), so Peter can go to the second column, and the newly published SKs will give him the decrypted movie.

[FoxDisc]

Ok let's say they want two SK for an SKB. Wouldn't it be possible to feed the SKB with two SK's from different players?

Short answer: No. The first SK1 sends you to one of the Conditional Columns. The second SK2 only works in that column. Only one out 2^32 players has both SK1 and SK2. There are only 2^32 players.

there are 2^8*2^16=16mio different SK. there can be 2^32 players. it could be actually possible to give the first 16mio player an idividual SK, that's true.

Each player gets one and only only one from each column of the master matrix.

this would mean that a single SK is enough to revoke a player. as long they don't sell many players they can have very few player to share SK's. but for later there are clearly too few SK's.

Yes. They can start with unique SKs and then use them as they get more players. Who knows how they did it.

Just for beeing sure i understood the SK-system the right way:
There is this master matrix of SK's. it has 256 columns and 64K rows. each player gets one SK from each column.
The SKB asks for (Ok let's say) two SK's. it can define from which colums (one of those 256) these SK'S have to come from, so it defines the unconditional column. if it gets an revoked SK it will ask for an other SK, conditional column. Is this right? am i useing terminology right?

Yes. You are using terminology right. The unconditional column of the SKB specifies one column of the master matrix. The device will have an SK and a row number for that column of the master matrix. If that SK is "compromised", the calculation produces a link to another column in the SKB (a conditional column) The link can be to any one of the conditional columns. The new column in the SKB specifies another column in the master matrix. Again, the device looks up the SK and matching row number for the specified column of the master matrix.

[ErazorTT]

Short answer: No. The first SK1 sends you to one of the Conditional Columns. The second SK2 only works in that column. Only one out 2^32 players has both SK1 and SK2. There are only 2^32 players.

My answer is yes. 3 SKBs are using the second column. On this SKBs the first column outputs a link to the second column when one of the previously compromised SKs is used. Peter has these SKs (and decrypted Shrek 1 with them), so Peter can go to the second column, and the newly published SKs will give him the decrypted movie.

i know you haven't answered to the same question but it is almost the same.
at least if oue is right the other must be wrong and the other way round.

so here is the point where you two have to find an agreement. don't feel that i have read enough of the specs that i can say anything of who could be right.

[xyz987]

If only one column (and only one SK) is required for an SKB, then attacker can be narrowed to one in 2^16. That is not enough to identify him. If two are required, he can be narrowed to one in 2^32. There are only 2^32 players. We started off assuming the LA would only use one column, since that was the simplest to analyze. If they use two, he can be identified.


Well, we are just now talking about using 2 columns, right?


Yes. After the first column the LA has found the one group out of 65,000 possible groups that the bad boy is in. All we need to know is which member of this group is the bad boy,and which are innocent. The second column divides the first group up again into 65,000 more subgroups.

[...]

Yes. We agree everyone in this smaller group can get the DEADBEEF. But now the bad boy uses his second SK and row number for the second column. Now the LA says AHA! Bad Boy Found! He is the only one in the first group (with SK1) who had this SK2.


Who is "bad boy"?. The guy that published SK1 or the guy that published SK2?. It is perfectly possible the guy that publishes SK2 has not SK1 in his player.

Take a view at figure 4-1 of prerecorded spec (page 22). At column 2, players with different SKs (rows 3 and 5) go to column 3.

SK1 and SK2 are not related at all because they are from different players. For SK1 there are just 2 possibilities:

1- SK1 is not "compromised" at that SKB. So SK1 is enought to decrypt the movie.

2- SK1 is "compromised" at that SKB. So SK1 (and may be other SKs) outputs a link to the second column.

SK2 is from other player, so there are 2 possibilities:

A - SK2 is at first column (a lot of players have an uncompromised SK for first column) so SK2 decrypts the movie.

B - SK2 is at second column. So Peter uses SK1 to go to second column, and uses SK2 to decrypt the movie.

Edit:

If just one row of first column has the link to second column the probabilities for second attacker are:

Almost 100% his player just uses first column (this is the probability of A).

Near 0% (1/65536) his player goes to second column (this is the probability of B).

Also, if just one row of first column has NOT the link to second column the probabilities for second attacker are:

Near 0% (1/65536) his player just uses first column (this is the probability of A).

Almost 100% his player goes to second column (this is the probability of B). In this case almost 100% of the players go to second column. LA can not get information from here.

When i wrote about decrypting Shrek2 i have been using a probability of 50% (half the rows have a link). Of course LA can choose any other probability, but this is a win-win game for second attacker. No matter which probability LA chooses, the player of second attacker can not be identified.

If you disagree, just say me how many rows at first column have a link.

@FoxDisc: I have edited this post several times.

[xyz987]

A brief additional comment: The result for the first column is always the same for every player that must use the second column. However, the LA can send some players from the first column to the third column and others to the second column. After the first column is processed, players who need to go farther get a "link" to another column. The link could go to the second column or the third, etc. Different devices with different SK1s can get different links to different columns requiring different SK2s. This gives the Licensing Authority additional options to identify the attacker or revoke key sets.

Another terminology problem. I am using "SK1" to refer the SK that has been published by first attacker, but you are using it with a different meaning (any SK that is at first column).

[FoxDisc]

so here is the point where you two have to find an agreement.

Yes. This is what we have been discussing. I'm not sure why you think we are not discussing it.

[arnezami]

there are 2^8*2^16=16mio different SK. there can be 2^32 players. it could be actually possible to give the first 16mio player an idividual SK, that's true. this would mean that a single SK is enough to revoke a player. as long they don't sell many players they can have very few player to share SK's. but for later there are clearly too few SK's.
Haven't got much time to discuss (busy programming ;)). But just a few things:

1) Giving the first 16 million devices a unique SK (and using only those in the SKBs) is not going to work (for them): the size of the SKBs would become too large. This limitation has not really been discussed yet. In fact they may choose to try to keep SKBs as small as possible. In any way its likely many/all players will have at least some keys in common with any other player. It is therefore unlikely that releasing only one (or just a few) Sequence Key(s) per device will reveal its identity (asuming many devices have been sold).

2) Since a Link Key can be verified (by the deadbeef check) it has to be the same for every device that uses that column in the SKB. In other words: a Sequence Key (first column) from device A that will result in a Link Key (for say column 5) can be used in combination with a Sequence Key (for column 5) from device B that also uses this column 5 in the SKB. This directly affects the possibility of using Sequence Keys from different devices. Given this example though: it might be true that the identity of device B is revealed this way. So the owner of B should only reveal this Sequence Key if it knows that this exact Key is also used by different devices. Whether this is always the case highly depends on what I mentioned in my first point above.

3) When looking at the following picture it shows the paths followed by different devices while processing a SKB. I have a gut feeling these paths will be exactly the same for every disc/movie that have the same SKB "version":

http://img138.imageshack.us/img138/3659/seqop7.png

This would be very similar to their use of the same MKB version: they use the same Explicit Subset-Difference Record (and thus Processing Key) for every disc/movie but their C-values are different. This I think will also be the case with SKBs: the values of the keys will be different but the arrows/paths taken by devices might very well be the same on every disc (using this same SKB "version"). This is just a feeling though. It would mean that only if things are revoked (new "version") will the structure/paths of this picture change (working with the above example: arrows will change or be added and more K's will become 0's). If this is true though (and combine this idea with my second point here) that could lead to some interesting things... :)

What is also interesting is the question: will all, some or none of these K's in this picture be the same? In other words: will a resulting Dv be different for every device? How many different Dv's can (at most) come out of one SKB (assuming you have all Sequence Keys from all devices) considering that all these devices should still be able to decrypt all movies (all segments)? What is the limitation of different Dv's here? 1024?

Just something to discuss.

Regards,

arnezami

[xyz987]

Since a Link Key can be verified (by the deadbeef check) it has to be the same for every device that uses that column in the SKB. In other words: a Sequence Key (first column) from device A that will result in a Link Key (for say column 5) can be used in combination with a Sequence Key (for column 5) from device B that also uses this column 5 in the SKB. This directly affects the possibility of using Sequence Keys from different devices. Given this example though: it might be true that the identity of device B is revealed this way. So the owner of B should only reveal this Sequence Key if it knows that this exact Key is also used by different devices. Whether this is always the case highly depends on what I mentioned in my first point above.


No, identity of B is not revealed. All the players have a SK at column 5. To understand this, read the below example:

Let's say LA is using a matrix that has 2 columns and 2 rows, so there are 4 SKs. SK1 is at first row of first column, SK2 is at second row of first column, and so on.

Key distribution is as follows:

25% of the players (group 1) have SK1 and SK3
25% of the players (group 2) have SK1 and SK4
25% of the players (group 3) have SK2 and SK3
25% of the players (group 4) have SK2 and SK4

Traitors tracing works as follows:

Let's say LA release a new SKB. SK1 ouputs a link to the second column. SK2 decrypts the movie. Also SK3 and SK4 decrypt the movie, but at second column.

When a player decrypts the movie:

50% of the players will use SK2 to decrypt it
25% of the players will use SK3 to decrypt it and all these players have SK1
25% of the players will use SK4 to decrypt it and all these players have SK1

Using more columns LA can determine the identity of any player, because each additional column reduces the probabilities if the SKs used to decrypt are from the same player.

However if attackers publish just one SK from different players (one SK per player), LA can not reduce the probabilities from column to column.

If attacker A publishes SK1 the movie is decrypted and his identity is not revealed because 50% of all players has this key. Nothing new here but this is just a reference case (just one column have been used to decrypt). I put this case here just for illustrative purposes (LA can force all the players to go to other columns).

If attacker A publishes SK2 (yes, SK2), and attacker B publishes SK4 the movie is decrypted too. Of course LA knows that the player of attacker A is a member of groups 3 or 4 (50% of all players, no news here). Now the funny thing: LA just knows that the player of attacker B is a member of groups 2 or 4 (50% of all players). LA is not getting new information from attacker B, it is not getting aditional information from the fact that 2 columns are used to decrypt if SKs are from different players.

If 2 columns are used to decrypt then a link to the second column is needed, but this link is the same for everybody, it always decrypt DEADBEEF. Peter just needs SK2 (to get the link) and SK4 (to decrypt).

[ErazorTT]

Short answer: No. The first SK1 sends you to one of the Conditional Columns. The second SK2 only works in that column. Only one out 2^32 players has both SK1 and SK2. There are only 2^32 players.

Ok i don't get that.
let's say the unconditional SK (SK1) was rejected.
then SKB wants to have one conditional SK (SK2) form a specific column.
why can't this SK (SK2) be from another player than SK1. SK2 beeing from the right colum obviously.

i mean SKB just wants one SK from the right conditional column.
how could SKB know these SK are from different columns?

[FoxDisc]

@FoxDisc: I have edited this post several times.

I am not ignoring you. I started a long reply post, was busy, did some more work on it, got busy again. Now I see you've changed some things. I haven't even had time to read the edits yet, so that will take some time, and I think arnezami has some good points too. At least we are all on the same path - working through what hapens when the SKB is processed column by column.

Think about this question, previously mentioned in this thread, as you think about arnezami's comments.

Suppose the LA began to assign their "sets of SKs" by giving the first device the first SK in every row, and the second device the first SK in every row except the last column (#256) where they assigned the SK from row 2. The third gets the same, except the SK in the third row for the last column. The first 2^16 devices get the same SK (from first row) in the first 155 columns and a different one in the last column only. Then the 2^16 plus one device gets the first SK in every row except the 255th column. He gets the SK from row one in column 256, the 2^16 plus 2 device increments the SK in the last column jsut like the second device did. He gets the second row SK in column 256.

If you proceed this way, every device will get a "unique set of SKs" and yet we are done assigning Devices SKs when we fill the last two cloumns. Everyone got the same SK in the first 254 rows!

The point is that there are only 2^32 devices, yet there are 2^4096 different "unique set of SKs" from the master matrix.

The method described above made the sets of SKs as similar as possible. I don't think they assigned device multiple identical SKs, even though they could. I think they assigned them set of SKs that are as different as possible, not as similar as possible or something in between those limits. I think they made the sets as differnt as possible so that they could identify the device as easily as possible knowing as few as possible of their SKs.

The question is: What happens if a device having a set of SKs that was not actually assigned by the LA tries to process an SKB by following the table (I see that arnezami has posted it for our convenience)? This is key to understanding your idea of mixing SKs from two different devices to hide where the SKs came from. A mixed set of SKs is likely to be one of the 2^4096 possible sets that was never actually assigned to any device.

A related question is: How did the LA assign SKs to devices? More specifically, If device A has an SK and device B has the same SK, do they share any other SKs?

Sorry - even my short post is long, and all I did was point out some key questions.

(BTW, do you agree that every 64 bit SK in every one of the 2^24 cells is probably a unique number so that knowing the SK's 64 bit value uniquely identifies its row and column.)

[xyz987]

The question is: What happens if a device having a set of SKs that was not actually assigned by the LA tries to process an SKB by following the table (I see that arnezami has posted it for our convenience)? This is key to understanding your idea of mixing SKs from two different devices to hide where the SKs came from. A mixed set of SKs is likely to be one of the 2^4096 possible sets that was never actually assigned to any device.


No matter how they do it, the worst case is that Peter just needs a link to go to second column and a SK at second column to decrypt. This link is always the same value for second column of that SKB. If 3 columns are required, Peter will need a link to go to second column and a link to go from second column to third (this is the worst case again because may be some players decrypt at first or second columns and may be the first or second published SKs are from one of these players). Of course if 3 columns are required a third attacker will publish a third SK (just one SK per player).

Any SK from an unrevoked player will output either a link to next column or the final Variant Data. There are no more posibilities.


A related question is: How did the LA assign SKs to devices? More specifically, If device A has an SK and device B has the same SK, do they share any other SKs?


Randomly. It would be a Bad Idea to assign SKs other way.


(BTW, do you agree that every 64 bit SK in every one of the 2^24 cells is probably a unique number so that knowing the SK's 64 bit value uniquely identifies its row and column.)

Yes, I agree. In fact, SKB system wouldn't work if different SKs are asigned to same cell.

[FoxDisc]

No, identity of B is not revealed. All the players have a SK at column 5.

I've been looking for a good place to pick up this thread again, to explain why mixing SKs from different players is not going to work and how the tracing works. I chose here. I think arnezami's post is the most interesting, but I'll try to stick to this discussion first and emphasize why he's right on the point you are disagreeing with here. For reference, we need his image:

http://img138.imageshack.us/img138/3659/seqop7.png

You say: "All the players have a SK at column 5." That's true. Let's be clear on why you are saying that. A first player A has looked at column 1 in the SKB. He has a compromised SK for that column, so instead of getting a key K, he decrypts a link to column 5. OK, now we know that if this device is revoked, when he goes to column 5, he'll decrypt a zero in that column.

If he's not revoked, he'll decrypt the key K from column 5. He could disclose his second uncompromised SK for column 5, but that requires disclosing two SKs from the same set of SKs. The more keys he discloses the more the LA knows about him. Every device has a unique set of SKs and as the specs say: "The fundamental principle is that no two devices have many [sequence] keys in common."

The attacker wants to keep secret his SKs. Of course, the LA knows that is exactly what he wants to do. As they put it:

"Attackers would prefer to use already-compromised Sequence Keys if they could, so that no new forensic information could be deduced by the licensing agency. Therefore, it is important that compromised keys are no longer usable by the attackers. The problem is that many thousands of devices might share a single compromised key."

Anyway, back to your comment which is: "All the players have a SK at column 5." I believe you are saying this because you are not going to use player A's sequence key for column 5 (which will work to decrypt a valid key K) but instead, you are going to use someone else's SK from column 5. The problem is that when you look at column 5, you get a list of keys encrypted with SKs. You need one of the SKs that the LA actually used to encrypt the answer K in that column so you can decrypt it. However, they didn't use everyone's SK from column 5. They only used SK's from people who had the same SK in column 1 that player A had. If you have an SK in column 5 that can decrypt a key K in column 5, then you also had the same key that player A had in column 1.

Perhaps you are lucky, and player B disclosed a key for column 5 that works. Then player B and player A both had the same key in column 1. It's true that player A remains anonymous, but so what? He didn't give out enough information to decrypt anything. Player B gave out enough info to decrypt, but he's no longer anonymous and will be revoked.

Now, you can say this: There are only 2^16 keys in column 5. Everyone of 2^32 players gets a key in column 5, so 2^16 players (or more) share a key in this column. I'll just get one from someone who did not have player A's key in column 1. But is there any such player? The answer is no. More specifically, if their key in column 5 was used to encrypt the answer K, then they had the same key in column 1. Everyone has a key in column 5, but not everyone needs to go to column 5, and not every SK from column 5 will decrypt an answer K. Although we don't know exactly what they did with SK key assignment, we know what they wanted to do. Unless they made a serious stupidity mistake, they only encrypted with SKs from column 5 if that SK in column 5 was assigned to a player that had the SK in column 1 that sent them to column 5 via the link in column 1.

To understand this, read the below example:

Let's say LA is using a matrix that has 2 columns and 2 rows, so there are 4 SKs. SK1 is at first row of first column, SK2 is at second row of first column, and so on.

Key distribution is as follows:

25% of the players (group 1) have SK1 and SK3
25% of the players (group 2) have SK1 and SK4
25% of the players (group 3) have SK2 and SK3
25% of the players (group 4) have SK2 and SK4
Traitors tracing works as follows:
Let's say LA release a new SKB. SK1 ouputs a link to the second column. SK2 decrypts the movie. Also SK3 and SK4 decrypt the movie, but at second column.


Your error is here. They will not assign SK4 to group 4 if SK1 is needed to get to the second column and SK2 is not. You have assigned every possible combination of SKs to a player. You have too many shared keys in common. As you can see from the spec portion quoted above, the LA knows not to do that. In the real world, there are 2^4096 unique sets of SKs and only 2^32 players who get a set. Those who have the second key will also have the first one. That set is needed to decrypt, and it identifies the player.

Sorry about the delay in responding.

[FoxDisc]

let's say the unconditional SK (SK1) was rejected.
then SKB wants to have one conditional SK (SK2) form a specific column.
why can't this SK (SK2) be from another player than SK1.

SK2 can be from another player (call him "X"), but for it to be of any value, the LA must have encrypted the answer key K in the conditional column with the SK2 from player X. The only reason a player would be decrypting something in the conditional column is if it was sent there by the unconditional column. Why would the LA put the answer K there for an unauthorized player to decrypt?

[FoxDisc]

Haven't got much time to discuss (busy programming ;)). But just a few things:

1) Giving the first 16 million devices a unique SK (and using only those in the SKBs) is not going to work (for them): the size of the SKBs would become too large. This limitation has not really been discussed yet. In fact they may choose to try to keep SKBs as small as possible. In any way its likely many/all players will have at least some keys in common with any other player. It is therefore unlikely that releasing only one (or just a few) Sequence Key(s) per device will reveal its identity (asuming many devices have been sold).

I haven't got enough time to discuss all of these now, so I'll tackle the interesting bits as time permits. The specs make it clear that it is advantageous for the LA to minimize the overlap of assigned SKs. The fewer in common, the easier it is to identify a player. We don't have any information yet about how they have actually assigned SKs, but it wouldn't surprise me if the 16 million unique keys in the entire master matrix are assigned very early. That minimizes overlap of commonly assigned keys which is exactly what they want to do.

In contrast, attackers want to disclose only commonly assigned SKs to prevent identification. I think we'll have to wait to see the first SKBs to understand how they intend to implement the tracing system. I agree that there are limits imposed by the size of the SKB.

As we know, they did a poor job with the initial implementation of the MKB system. Only one Processing Key was used. I doubt we'd have guessed that just by reading the specs.

[arnezami]

On a sidenote: I think I have devised a (cryptographically sound) way for several people who have found sequence keys to see if they have any sequence keys in common without releasing the sequence keys themselves :). Its pretty complicated and mainly uses some XOR techniques (and some private/public key pairs for each participant). But it could in principle be done on a forum or a specially designed website.

Anyway. Its not very practical yet and not very efficient. So I'm still trying to make it better. But since this is not needed yet I can take my time. But I think its a good idea to think about this stuff sooner than later. The more people we can get involved the better when it comes to finding and releasing common SKs (if/when we can't use Software Players for retrieving SKs anymore that is). If we can create a system that does it safely for people more will consider and do it.

Regards,

arnezami

PS. It has some similarities with the techniques used for herbivore (http://www.cs.cornell.edu/People/egs/herbivore/how_it_works.html) (but its different because herbivore focuses on privacy while we want to compare notes without actually releasing the notes). Which is hard btw ;).

[FoxDisc]

On a sidenote: I think I have devised a (cryptographically sound) way for several people who have found sequence keys to see if they have any sequence keys in common without releasing the sequence keys themselves :).

I don't think I'd call it a "sidenote." As I was writing one of those posts about how the attacker wants to use only shared keys and the LA wants to reduce the number of shared keys I was thinking how hard it would be to find out how many keys were "shared" without disclosing/compromising them. As usual, it looks like you are thinking way ahead.

[arnezami]

I don't think I'd call it a "sidenote." As I was writing one of those posts about how the attacker wants to use only shared keys and the LA wants to reduce the number of shared keys I was thinking how hard it would be to find out how many keys were "shared" without disclosing/compromising them. As usual, it looks like you are thinking way ahead.

:D :D :D :D

[xyz987]

Anyway, back to your comment which is: "All the players have a SK at column 5." I believe you are saying this because you are not going to use player A's sequence key for column 5 (which will work to decrypt a valid key K) but instead, you are going to use someone else's SK from column 5. The problem is that when you look at column 5, you get a list of keys encrypted with SKs. You need one of the SKs that the LA actually used to encrypt the answer K in that column so you can decrypt it. However, they didn't use everyone's SK from column 5. They only used SK's from people who had the same SK in column 1 that player A had. If you have an SK in column 5 that can decrypt a key K in column 5, then you also had the same key that player A had in column 1.


You simply don't understand how SKB works. However there is an easy solution:

Let's say attacker A has published a SK that is at 12,543th row of 123th column (let's say 123th column was "first" column at Shrek1 SKB).

Now you are LA, and you are designing the SKB of Shrek2. Please say me how is your SKB, and i will say you how it sinks when second attacker publishes his SK. Of course, you must specify all the data of a real SKB. For short you can start saying just some basic data, but if i ask you, you must say me any data that anybody can read on a SKB.

Of course, you know nothing about attacker B. He has not published any SK yet.

Of course, your SKB must allow any player to decrypt. You can choose any SK distribution on players, but there are more that 32 millions of them. There is just one SK per matrix cell (we agreed on it before) i.e. all the players that have a SK at row r of column c will have the same SK.

Let's start the game...

[FoxDisc]

You simply don't understand how SKB works.

It would help if you would explain more.

attacker A has published a SK that is at 12,543th row of 123th column (let's say 123th column was "first" column at Shrek1 SKB).

Odd choice.

Now you are LA, and you are designing the SKB of Shrek2. Please say me how is your SKB, and i will say you how it sinks when second attacker publishes his SK. Of course, you must specify all the data of a real SKB. For short you can start saying just some basic data, but if i ask you, you must say me any data that anybody can read on a SKB.
Of course, you know nothing about attacker B. He has not published any SK yet.
Of course, your SKB must allow any player to decrypt. You can choose any SK distribution on players, but there are more that 32 millions of them. There is just one SK per matrix cell (we agreed on it before) i.e. all the players that have a SK at row r of column c will have the same SK.

Let's start the game...

SK 12,543th row of 123th column is compromised. This one SK was not sufficient to decrypt Shrek1. Attacker A can decrypt with his other secret SKs, but no one else can. Recommend no change for 6 SKBs on Shrek2. Wait for more info on attacker A.

[xyz987]

SK 12,543th row of 123th column is compromised. This one SK was not sufficient to decrypt Shrek1. Attacker A can decrypt with his other secret SKs, but no one else can. Recommend no change for 6 SKBs on Shrek2. Wait for more info on attacker A.

You are changing the case. Shrek1 was decrypted because there was just one column at Shrek1 SKB. Well, no problem. Let's play with Shrek1 SKB.

How many columns are at Shrek1 SKB?. How many rows at each column?.

You say that SK of attacker A is not enought to decrypt. This implies that all the players get at first column a link to another column. Do you agree?.

Everybody knows the published SK, so everybody can know which column this SK outputs a link to. Which is this column at Shrek1 SKB? (second, third...). Which is its column number? (a link to this column can decrypt the column number that is stored on SKB). Note i am asking two different things.

[ErazorTT]

SK2 can be from another player (call him "X"), but for it to be of any value, the LA must have encrypted the answer key K in the conditional column with the SK2 from player X. The only reason a player would be decrypting something in the conditional column is if it was sent there by the unconditional column. Why would the LA put the answer K there for an unauthorized player to decrypt?

1. they don't know which player is unauthorized! if they had known the player would have been revoken by MKB!

2. so you say the link key can be used only with one specific SK form the column? could you please say why you think that, and where it is written in specs?
by the way, i don't see how LA could do this, technically.

3. for safty reasons i think i'd better explain how i interprete the picture of page 22 of prerecorded (the picture we have in this threat):
"The first column will have an encryption of the output key (denoted ‘K’ in the figure) in every uncompromised Sequence Key’s cell"
AND
"The subsequent additional conditional columns are produced the same way as the first column: They will have an encryption of the output key in every uncompromised Sequence Key’s cell."
what i understand by that: In each column (of the SKB) there is an "answer" for every SK of one column (from the master matrix). the answer can be either the output key (K) or the link key (link).

So how does it work:
"Devices that do not have compromised keys in that [unconditional] column immediately decrypt the output key."
This answeres one question from xyz's last post!

"Devices with a compromised key will get a further link key to another column instead of the output key."
AND
"If the header decrypts correctly, the device knows it has a link key and processes the column. If it does not decrypt correctly, the device knows it has either the output key or a link key for a different column."
they don't say anything about SK's in right columns which are however wrong!

so i think every (not compromised) SK from the right column can decrypt the output key.
if you don't agree please explain by refering to specs.

[FoxDisc]

You are changing the case. Shrek1 was decrypted because there was just one column at Shrek1 SKB.
You didn't say that and I thought I had made it clear that I think every device will have to use at least two SKs.

Well, no problem. Let's play with Shrek1 SKB.
How many columns are at Shrek1 SKB?. How many rows at each column?.

Ten columns in each of six SKBs and up to 2^16 rows.

You say that SK of attacker A is not enought to decrypt. This implies that all the players get at first column a link to another column. Do you agree?.

You are attacker A. You know only what attacker A knows. Attacker A knows that his compromised SK leads through five columns of first SKB. He does not know what other players ("all players") will get at first column of first SKB (perhaps link to same column, perhaps link to another column, perhaps key K). Attacker A also knows about other 5 SKBs. What information will you release?

Everybody knows the published SK, so everybody can know which column this SK outputs a link to.
Agreed
Which is this column at Shrek1 SKB? (second, third...).
second
Which is its column number?
124 (adjacent to right of your choice of 123)

[FoxDisc]

1. they don't know which player is unauthorized! if they had known the player would have been revoken by MKB!

I didn't say they knew the player. I said they assigned keys to minimize common shared keys.

2. so you say the link key can be used only with one specific SK form the column?

No, I did not say that. I said that when the LA gave devices an SK for the first column that decrypted the link to the second column, they made sure that they gave keys for the second column too that were not given to any (very few) other devices.

they don't say anything about SK's in right columns which are however wrong!
so i think every (not compromised) SK from the right column can decrypt the output key.
if you don't agree please explain by refering to specs.

Look at the table. Some devices will decrypt zero in the second column. When the system started, the LA assigned some devices an SK for the first column that leads via a link to a second column. What did they assign in the second column to those devices? They were not obligated to use every possible one of the 65,536 SKs in the second column. They did not. Perhaps they assigned only a handful of those 65,536 possible rows/SKs. Many possible rows/SKs were never assigned to any of these devices. What would you decrypt in the second column with an SK from the second column that was never assigned to a device that has the correct SK in the first column?

Remember, there are 2^4096 unique sets of SKs and only 2^32-512 devices. The LA knows which of the 2^4096 sets are valid and which are not valid. Broadly speaking, the question above is all about what happens when you try to decrypt with an invalid set of SKs. If they had used only 2 columns instead of 256, they could have issued 2^32 unique sets of SKs. Why do you think they used 256 columns? It's because the 2 column scenario uses too many shared keys. Every combination is valid for someone, so even though it's unique, you can't be sure if the keys were from the same attacker or from two attackers who shared their keys to look like an innocent user. You and xyz keep looking at the shared key situation and are not focusing on the fact that most combinations are not valid, were never issued, are known by the LA to be invalid and won't decrypt the title.

[FoxDisc]

@Erazor and xyz

Perhaps we can agree on some basics. Look at the graphic:
http://img138.imageshack.us/img138/3659/seqop7.png

Can we agree on what is required to decrypt column 4 and get a valid answer key K in that column? Tell me what minimum information you think is needed for just that one column.

[FoxDisc]

It is amazing what you find on the web. We have been wandering in the dark on sequence keys as we don't know how they are assigned and we've never seen an actual SKB.

Try this link:
http://domino.watson.ibm.com/library/CyberDig.nsf/papers/7158161AA398C8CE8525722200570F64/$File/rj10394.pdf

It describes limitations of the SKB tracing system, anonymous colluding attacks and non-anonymous attacks (the literature calls them "clone decoder attacks"). It's apparently written by those who designed the AACS SK system. Part of it is word for word identical to the AACS spec description of the SK system. Fascinating reading.

[arnezami]

It is amazing what you find on the web. We have been wandering in the dark on sequence keys as we don't know how they are assigned and we've never seen an actual SKB.

Try this link:
http://domino.watson.ibm.com/library/CyberDig.nsf/papers/7158161AA398C8CE8525722200570F64/$File/rj10394.pdf

It describes limitations of the SKB tracing system, anonymous colluding attacks and non-anonymous attacks (the literature calls them "clone decoder attacks). It's apparently written by those who designed the AACS SK system. Part of it is word for word identical to the AACS spec description of the SK system. Fascinating reading.

Cool stuff :). Thanks.

[FoxDisc]

Cool stuff :). Thanks.

I had planned to discuss some of your really interesting comments/questions from one of your earlier posts - like how many different Dvs there are and how many different answer keys K are in a single column of an SKB and how different players and different disks would move through the SKBs. There are some hints to the answers to those questions in that paper.

As I read it, the system is probabilistic, not deterministic (they run some probability of revoking an innocent player when they revoke traitors.) They can set that probability as low as they want (they used one in a million in the paper).

Another interesting thing was that attackers that are randomly distributed among devices were easier to defend against than attackers who all had the same manufacturer or model of player. You would think that one model would be weaker and that most attacks would be by that one compromised model, yet they designed it so that likely scenario puts the most strain on the system. At some point, given enough attacks by a single mnfr/model, they say the AACS system would fail.

[kendo019]

After searching that same website I found this doc on "Efficient Traitor Tracing". It made for some good reading.

http://domino.watson.ibm.com/library/cyberdig.nsf/papers/AF8C220CB33D5A98852571FF00570458/$File/rj10390.pdf

Regards

[xyz987]

You are attacker A. You know only what attacker A knows. Attacker A knows that his compromised SK leads through five columns of first SKB. He does not know what other players ("all players") will get at first column of first SKB (perhaps link to same column, perhaps link to another column, perhaps key K). Attacker A also knows about other 5 SKBs. What information will you release?


No, I am not attacker A.

Timeline (of your new case):

1- LA releases the first movie with SKB (Shrek1)

2- Attacker A publishes his SK at first column (123), but this is not enought to decrypt because your SKB requires at least 2 SKs to decrypt.

3- Attacker B downloads the first published SK (SK from attacker A player). He founds that this SK outputs a link to second column (124).

Attacker B has his SK at column 123, but this is not enought to decrypt because your SK requires at least 2 SKs to decrypt. He also has his SK at column 124.

Attacker B can go to column 124 because he has the SK from attacker A. He tries at column 124 his SK 124. If it outputs a link or final Variant Data, this means that there are a lot of players whose SK 124 will output a link or final Variant Data. He knows this because player A and player B are different players. It is extremely improbable that just these 2 players are the only ones that have a valid output (a link or final Variant Data) when mixing keys from player A and another player. So he publishes his SK 124 safely (his player can not be identified).

If not, he publishes his SK 123.

There are 2 possibilities:

1- Attacker B publishes his SK 124: now everybody has 2 links, or one link and final Variant Data.

2- Attacker B publishes his SK 123: now everybody has 2 links.

There are 10 columns on your SKB, and each published SK gives everybody one link more or final Variant Data. After 10 attackers have published 10 SKs (just one SK per player) your SKB will become broken (probably before 10 SKs).

[xyz987]

@Erazor and xyz

Perhaps we can agree on some basics. Look at the graphic:
http://img138.imageshack.us/img138/3659/seqop7.png

Can we agree on what is required to decrypt column 4 and get a valid answer key K in that column? Tell me what minimum information you think is needed for just that one column.

Tell me what is required to decrypt column 1.

*Most* players decrypt at column one. Virtually no player decrypts at column 4. Of course this is not your SKB, but it is the SKB spec authors chose as a good example.

You are simply blind about this matter. If they send *most* players to column 4, *most* players will have the keys to reach it. If they send just a few players to column 4, *most* players will have the keys to decrypt at other columns.

Your requirement is far away of reality.

[arnezami]

Tell me what is required to decrypt column 1.

*Most* players decrypt at column one. Virtually no player decrypts at column 4. Of course this is not your SKB, but it is the SKB spec authors chose as a good example.

You are simply blind about this matter. If they send *most* players to column 4, *most* players will have the keys to reach it. If they send just a few players to column 4, *most* players will have the keys to decrypt at other columns.

Your requirement is far away of reality.

I'm not deep into this discussion now (still trying to help the PS3 guys :)) but just this.

I believe they will fill the first column with link keys only. It might be a good idea to assume that and reason from there.
A (released) Key identifies a player only if that key is not being used by another player (maybe better to say: "not given to another player" here). Keys in conditional columns are probably used by less players than the ones from the first column. They are therefore more identifying.
The path a player takes to get to a Key (in a certain column) might be different for different players (not shown in example picture btw). But by only releasing one Key per player the path taken by each individual player is not revealed.
Even if players have a sequence key in common this does not mean they will both use it on the same disc (if at least one uses it). However: since they share this key either one of them can release this key while having the same result.

Not sure if that helps. But maybe.

Regards,

arnezami

PS. Should I do a study and write an article on Sequence Keys (instead of programming that is?)

[radone]

Please, I am right in these assertions:

Content player has DeviceId that might not be unique for all players (it could be shared between them)
For each DeviceId exists many Device keys
Player-device (with DeviceID defined) contains sub-set of device Device keys for particular deviceID only


Thanks, for any reply. I just need to ensure I understand well.

[FoxDisc]

No, I am not attacker A.

I may get a chance to respond later. Our discussion was an attempt to guess 1) how they assigned SKs and 2) how they traced traitors with released keys or movies. Guessing was useful to help us understsand what they could have done. However, it's far more useful to read the papers at the website I listed and actually have them tell us what they did. We need to understand:

inner codes
outer codes
slot assignments.

Have you read the papers? Let's talk about the limits they say are on the system.

[xyz987]

I believe they will fill the first column with link keys only. It might be a good idea to assume that and reason from there.


This is not the case of the figure that FoxDisc showed (spec figure). However it is the case of his SKB, and we are talking about it. It is not a good idea to take this figure as an example of his SKB.


A (released) Key identifies a player only if that key is not being used by another player (maybe better to say: "not given to another player" here). Keys in conditional columns are probably used by less players than the ones from the first column. They are therefore more identifying.


If they have distributed SKs randomly, the above is not true. Of course they can choose other key distribution, but they can not change key distribution for already sold standalones.

Note that a not random distribution is a Bad Idea for them. However I don't know which is FoxDisc's key distribution, i don't even know is he has decided a key distribution, and i am not assuming random distribution when i talk about his SKB.

I think this is fair because we don't know which is key distribution LA have chosen for already sold standalones. However it is not fair he changes the case again and again. He has done it several times, and it is far frustrating for me he does so.

I suggest we (FoxDisc and me) keep focused on his SKB until we decide if attackers have broken it or not.


The path a player takes to get to a Key (in a certain column) might be different for different players (not shown in example picture btw). But by only releasing one Key per player the path taken by each individual player is not revealed.


I agree.


Even if players have a sequence key in common this does not mean they will both use it on the same disc (if at least one uses it). However: since they share this key either one of them can release this key while having the same result.[/list]


I agree.


PS. Should I do a study and write an article on Sequence Keys (instead of programming that is?)

At your choice. You are good for both things :-)

[xyz987]

I may get a chance to respond later. Our discussion was an attempt to guess 1) how they assigned SKs and 2) how they traced traitors with released keys or movies. Guessing was useful to help us understsand what they could have done.


Not for me. I proposed a method of attack (publishing just one SK per player). For me our discussion is about this method of attack, if it works or not.


However, it's far more useful to read the papers at the website I listed and actually have them tell us what they did.


In my opinion you will never understand how SKB system works if you don't understand before what happens with your SKB. In my opinion your SKB is broken after 10 attackers publish 10 SKs from different player (or before 10).


Have you read the papers? Let's talk about the limits they say are on the system.

I really appreciate your contribution here. I have not read them yet, but i will do. Note that my method of attack doesn't depend of SK distribution they have chosen.

I really think the skeptic role is far important on any good discussion, but please keep focused on your SKB until you see it is broken or until you get the identity of a player.

[FoxDisc]

Please, I am right in these assertions:
Content player has DeviceId that might not be unique for all players (it could be shared between them)
This is basically correct. A "device" has a 32 bit device number associated with it. Two identical players could share the same device number.

For each DeviceId exists many Device keys
Each unique device number has a specific unique set of 253 device keys.

Player-device (with DeviceID defined) contains sub-set of device Device keys for particular deviceID only


This looks wrong. If you specify the device number, everyone knows the location (nodes) of the device keys for that device. The LA knows the value of all of those device keys. An adjacent device would know almost all of the values of those device keys.

[FoxDisc]

This is not the case of the figure that FoxDisc showed (spec figure). However it is the case of his SKB, and we are talking about it. It is not a good idea to take this figure as an example of his SKB.

I must emphsize that this discussion of SKs has taken (should take) a major turn as a result of the new information about actual implementation of AACS traitor tracing.

The first thing I get from the papers is that they are not trying to identify a player from a single movie/SKB. The "outer code" specifies one of a group of 255 movies. The inner code specifies one of 256 variations of the movie. I don't see much point in taklking about my hypothetical 10 column SKB until we understand the process.

Another thing I get from the papers is that they aren't looking for the most likely individual traitor for a single movie. They are looking for the most likely group of traitors releasing a large group of movies.

Specifically, yesterday, I would have agreed with arnezami that the first column would mostly have links. Now I'm less sure. The first column may have many answer key K's (these are Variant Data). They are assigning a group of Dvs within a column so that they know which columns from a specific SKB were used. They may be using the six SKBs and rotating the SKBs for each movie release to collect the bulk data on groups of compromised devices.

I don't know which is FoxDisc's key istribution,

Exactly! And I don't know yours, and we both didn't know the AACS key distribution until recently. At least now we have some good information on the truth of this subject. Inner code, outer code and slot assignment tell us a lot about their key distribution system.

I think this is fair because we don't know which is key distribution LA have chosen for already sold standalones. However it is not fair he changes the case again and again. He has done it several times, and it is far frustrating for me he does so.

Whoa! When we learn new information, what is the point of discussing a false premise? I have never changed the case. Not once. I switched from discussing the linkage of SKs in six SKBs to the linkage of SKs within a single SKB, because the latter is more clear, but you never bothered to address the first case anyway. The linkage between the six SKBs seems to b epart of their group tracing procedure via multiple movies. We were trying to simplify to look at a single movie, and you have been trying to simplify farther to look at a single SKB.
With the new information, it is clear that we can't simplify that much and still understand the tracing system.

You repeatedly misunderstood or made assumptions that were not true or inconsistent. Do you want me to go on with explaining how a single device can be identified from a single SKB using an assignment system that they are not using? Just assume the first 16 million devices got one of the 16 million unique keys, and that they've assigned less than 16 million devices a key set so far. Of course, then we'd have to discuss size limitations on discs, and whether those are reasonable limitations. I had a more complex assignment scheme in mind, but there's no point to discussing it, it's not the one the AACS selected.

You've never given any hint of how you think their SKB system works to trace traitors. Do you really think it does not work? I think the burden is on you to show why. I think it works, but has limits. It is the limits that I am interested in.

You never discuss the six SKBs, just one. You never say how a movie can be decrypted with released keys. You don't give enough information about your example, then complain when I make an assumption that differs from what you expected.

OK, enough rant. Let's try to stay on point and focus on our common interest - how does it actually work.

I suggest we (FoxDisc and me) keep focused on his SKB until we decide if attackers have broken it or not.

We were never trying to decide if it was broken. Of course it would be "broken" - every player has the required keys! We were trying to decide how much a broken SKB discloses about the attackers when it is broken, and to do that we were making assumptions about SK key assignment. Now we have some actual information about that matter. Let's focus on that.

To do that, we're going to have to talk about how many movies are released, how many traitors T have released keys, how the keys were assigned, etc. We're going to have to talk in their language of slot assignment, and inner and outer codes. I don't yet fully understand that. Do you?

If not, let's work on that, not on old hypotheticals based on assumptions about key assignments that are not correct.

[FoxDisc]

Not for me. I proposed a method of attack (publishing just one SK per player). For me our discussion is about this method of attack, if it works or not.

Perhaps I was not clear - this method always "works" if a player will give up enough keys or there are enough attackers. That has never been the question. The question has always been how much information key disclosure gives out, and that has always revolved around key assignment and use of the keys in the SKB. Until recently, we had no information on those two items.

In my opinion you will never understand how SKB system works if you don't understand before what happens with your SKB. In my opinion your SKB is broken after 10 attackers publish 10 SKs from different player (or before 10).

Assume you are right. ( I am not disagreeing, one may be enough, but that single one tells something about the "slot" and inner/outer" code). If you are right, you have broken one SKB. To decrypt, you must break six SKBs, so you may need 60 keys. I chose ten columns for my scheme, but perhaps the first SKB will require 20 or 30. Then you need perhaps 120 or 180? Are there that many different attackers? Now you have one movie. The SKB system is set up to track groups of attackers over multiple movies. On the next movie how many from the first group will disclose again?

There is no doubt that enough attackers in the right assignment slots will completely break the system.

I really appreciate your contribution here. I have not read them yet, but i will do.

I somewhat regret my last post, but I do resent the implication that I have changed the case to avoid your arguments. Your responses are as frustrating to me as mine seem to be to you.

Note that my method of attack doesn't depend of SK distribution they have chosen.

Could you explain your method a bit more? Is it to have each attacker release a single key for a single column? This will clearly work. There are only 2^24 keys and there are 2^32-512 players, each with 256 keys. Eventually, given enough attackers, even with only one key per attacker, all the keys get released and the system is broken.

I don't think there is any doubt that the system can be broken if you assume that all attackers can access their SKs and are willing to disclose one or more

I really think the skeptic role is far important on any good discussion, but please keep focused on your SKB until you see it is broken or until you get the identity of a player.

You still miss the point here. Identification depends on key assignment. The AACS LA has set up a system where one SKB for one movie is not intended to identify a single device. Multiple SKBs for multiple movies are intended to identify a group of devices.

To understand the SK system, we are going to have to make some assumptions about how many attackers there are, and what slot/slots their devices are assigned to. "Slots" correspond to manufacturers or models.

When you read the papers, look at some of the charts on how many movies it will take to identify attackers to a one in a million probability of error under various assumptions. Some SK assignment options require hundreds of movies before a large group of attackers is identified.

[xyz987]

The first thing I get from the papers is that they are not trying to identify a player from a single movie/SKB. The "outer code" specifies one of a group of 255 movies. The inner code specifies one of 256 variations of the movie. I don't see much point in taklking about my hypothetical 10 column SKB until we understand the process.

Another thing I get from the papers is that they aren't looking for the most likely individual traitor for a single movie. They are looking for the most likely group of traitors releasing a large group of movies.

Specifically, yesterday, I would have agreed with arnezami that the first column would mostly have links. Now I'm less sure. The first column may have many answer key K's (these are Variant Data). They are assigning a group of Dvs within a column so that they know which columns from a specific SKB were used. They may be using the six SKBs and rotating the SKBs for each movie release to collect the bulk data on groups of compromised devices.


I have not read the document yet, but now you are saying things that have sense for me. I will read it as soon as posible.


OK, enough rant. Let's try to stay on point and focus on our common interest - how does it actually work.


Well, your memory is not very good in my opinion. However I agree that's enought rant. So let's try to go further, as you say.

I have not read it yet, but it seems that the document says they are not giving keys to players in a full random way. So it is possible attackers can publish safely more than one SK per player. Again, i will read it as soon as posible.

[xyz987]

I somewhat regret my last post, but I do resent the implication that I have changed the case to avoid your arguments. Your responses are as frustrating to me as mine seem to be to you.


I said you have changed the case, but i didn´t say you did it to avoid my arguments :-)


Could you explain your method a bit more? Is it to have each attacker release a single key for a single column? This will clearly work. There are only 2^24 keys and there are 2^32-512 players, each with 256 keys. Eventually, given enough attackers, even with only one key per attacker, all the keys get released and the system is broken.


Exactly. No matter if 180 SKs are needed to decrypt just one movie (far improbable), if attackers can publish safely at least one SK per player, attackers will do it. If enought attackers do so the system is broken.

If attackers can avoid "sacrificing" their players (revocation), they will publish the keys, and the only question is to know if there are enought attackers.


You still miss the point here. Identification depends on key assignment. The AACS LA has set up a system where one SKB for one movie is not intended to identify a single device. Multiple SKBs for multiple movies are intended to identify a group of devices.


No, identification does not depend on key assignment if each attacker publishes just one SK per player. Now we have more information about key assignment, and this is good. So may be we can go further.


To understand the SK system, we are going to have to make some assumptions about how many attackers there are, and what slot/slots their devices are assigned to. "Slots" correspond to manufacturers or models.


I think two or three widely sold standalone models will be hacked for HDDVD and the same for BluRay. Are they using the same matrix for both formats?. For Device Keys they are using the same master tree, so why not?

[blutach]

Gentlemen,

The discussion here is getting just a little heated for my liking. The road is long and we all know it is not an easy one to travel. Let's respect each other's views at all times please.

Regards

[arnezami]

I had planned to discuss some of your really interesting comments/questions from one of your earlier posts - like how many different Dvs there are and how many different answer keys K are in a single column of an SKB and how different players and different disks would move through the SKBs. There are some hints to the answers to those questions in that paper.

As I read it, the system is probabilistic, not deterministic (they run some probability of revoking an innocent player when they revoke traitors.) They can set that probability as low as they want (they used one in a million in the paper).

Another interesting thing was that attackers that are randomly distributed among devices were easier to defend against than attackers who all had the same manufacturer or model of player. You would think that one model would be weaker and that most attacks would be by that one compromised model, yet they designed it so that likely scenario puts the most strain on the system. At some point, given enough attacks by a single mnfr/model, they say the AACS system would fail.

I've been reading this document now and I must say its very very interesting :). Its from the designers of AACS themselves so we can see how they have been thinking and reasoning.

What surprises me most is the fact that they are clustering devices from the same model/manufacturer. At some point they talk about only 64 keys (per column) used for one model (wth total of 4096 rows). With up to 250,000 devices (64^3) using that 64 keys cluster. To me that means that if you only release one Sequence Key (which is in a small cluster of 64 keys used by the other devices of the same model) there will always be another (innocent) device having this same Sequence Key. So given enough people willing to do this we would have enough keys to decrypt all movies released by then. The releasers of Sequence Keys do not even have to check whether their sequence key is shared (before releasing it) because if they use the same cluster they already know this is the case. And when they have the same model they are in the same cluster.

Sure they can revoke these keys but this can be done with many people many times.

It seems like they are so much concentrating on anonymous attacks (one attacker that has only one or a very few devices "opened" and releasing only content keys) that they are not capable of coping with many people releasing just one Sequence Key anymore.

-- I can already imagine whats going to happen: some hacker is going to find some kind of buffer overflow exploit for a specific model. He gives out an iso which when burned and inserted as a dvd produces this overflow and runs some designed code: revealing the Sequence Keys on your screen/tv :). Maybe even with a menu so we could choose which sequence key we want to see using our remote control :D --

In fact: the document talks about only 32 fully compromised devices (thus one person/group having all these sequence keys) being a major problem for the system. Thats not a lot of devices if we would find a hack for one model... (although this part deals with the anonymous attack so we have to see what this really does)

Anyway. Good stuff. We should pick it apart and try to learn as much as possible from it. But we've got time so no hurry. :)

Regards,

arnezami

PS. Just to put things into perspective concerning the amount of rows: 6 SKBs with 4K/16K/64K rows would take:

4096 rows * 256 columns * 10 bytes * 6 SKBs =~ 63MB.
16383 rows =~ 250MB.
64K rows =~ 1GB...

[edit]It appears that this paper (http://domino.watson.ibm.com/library/cyberdig.nsf/papers/AF8C220CB33D5A98852571FF00570458/$File/rj10390.pdf) (oct 4 2006) was released before they found and fixed the "security issues to support multi-time tracing" in the following paper (http://domino.watson.ibm.com/library/cyberdig.nsf/papers/AF8C220CB33D5A98852571FF00570458/$File/rj10394.pdf) (nov 1 2006). So it seems their "fix" introduced these clusters...
And btw: when were the first HD players released/manufactured? When did they have the time to assign Sequence keys according to the new cluster style? Did they assign them at all? This really smells like a last minute fix...

[arnezami]

I'm still thinking about this out but... (btw: this is completely different from what I mentioned earlier about "sharing notes")

Here is a possible (and simple) scheme to release all Sequence Keys (that say 50-200 people have in common) at once. Thus not making it possible for the AACS LA to see which sequence keys came from whom and therefore not possible to revoke specific players.

Each participant signs up for the project (on some website or something).
Each participant shares one random Sequence Key with each other participant (privately encrypted but through the website that is). So almost doubling his amount of sequence keys. Any other participant (possibly a mole) will know no more than 1 key from each participant and is therefore not capable of identifying any player.
Each participant then shares one random Sequence Key out of his new (doubled) set of sequence keys with each other participant. This recieving participant doesn't know from whom this key originally came (for certain) and therfore cannot identify the player.
Goto 3 (until all sequence keys are shared)
Everybody now has the total set of sequence keys between all participants (and therefore likely more than 50% of the keys of all the clusters they are in).
The AACS LA has a problem. Or don't they?

[edited]The question here is: what happens exactly if all these keys get revoked. Will many, some or no innocent players be revoked? Can they even do this? (edit: Hmmm. I'm now guessing they can... unless almost all sequence keys are released within these clusters. Probably the only way this would work is if everybody would give their keys to one person/group and they would release the segment keys for every movie while keeping the sequence keys hidden)


arnezami

[xyz987]

It seems like they are so much concentrating on anonymous attacks (one attacker that has only one or a very few devices "opened" and releasing only content keys) that they are not capable of coping with many people releasing just one Sequence Key anymore.


Yes, and this is really good news for us. It is noteworthy to say they have no other option: there are just 2^24 cells in matrix (16 millions) and at the next years one billion players (10^9) will be sold.

BTW i would like to give this method (publishing just one SK per player) a name. We can call it "lone SK attack".


And btw: when were the first HD players released/manufactured? When did they have the time to assign Sequence keys according to the new cluster style? Did they assign them at all? This really smells like a last minute fix...


Yes, it is not a good idea to assume this SK assignment as certain yet. However may be they started to assign clusters to manufacturers/models for laziness (it is easier to do that way), and later they took this fact for their purposes.

[arnezami]

Been thinking about it a little more:

This is a combination of "releasing them all" and "releasing just one key". And its very powerful I think :).

The "one column at a time" approach:

A better approach would be to let each participant give its Sequence key for 1 agreed upon column (eg all beginning at the first column). If the website/webmaster/organizer doesn't show where each Key is coming from it/he can safely release these keys since the AACS LA wouldn't know which devices nor which persons these are from. This goes on until all 64 keys (or very close to it) of that column are released. This can be done for each column at a time until all columns (and thus rows) from these clusters are released (with 4096 columns that would be 4096/64 = 64 keys per cluster. So that would be a total of 256 columns * 64 keys = 16256 keys to be retrieved by people having this player model). The AACS LA could consequently revoke these released keys (64 keys for each column) but this will eventually end in either (1) revoking all devices of that model (they won't do this) or (2) when the last columns are fully released they have to stop: so none of the devices are revoked. Voila! Sequence Keys: Game Over. The beauty is: everyone releases only 1 key at a time (privately to the website/webhost) so none of the participants nor any observer will ever know which keys came from whom and none of the devices will be identified since only 1 key is released at a time (and none of the previous released keys from each column does identify anyone of course).

I think this will actually work very well :D (if keys are roughly evenly distributed within the model's clusters)

Given 4096 rows my guestimate would be we need approximately 100-150 participants/devices to make this work (of the same model/manufacturer).

This technique won't work that well if 16K or 65K rows are used (since you need so many participants). But its still possible. And if they release some DVDs/BDs with only 4096 rows in their SKBs then this will certainly work (assuming they would then also be using this clustering for SK device assigment using 4096 rows).

In other words: one exploit in a well sold player model will very likely kill the traitor system permanently.

arnezami

[edit] If you would combine the above approach with this idea (http://forum.doom9.org/showthread.php?p=959884&highlight=stealth#post959884) it seems AACS really can be beaten. ;)

[FoxDisc]

Been thinking about it a little more:
Given 4096 rows my guestimate would be we need approximately 100-150 participants/devices to make this work (of the same model/manufacturer).

I was very surprised that the charts of number of movies required to detect a group of traitors versus size of traitor group always maxed out at a traitor group of 16! You are talking about traitor groups nearly ten times larger than they were thinking about as they designed the system.

In other words: one exploit in a well sold player model will very likely kill the traitor system.

Yes, the system is particularly vulnerable to large numbers of exploits within a single model. You would think that would be the most likely scenario, not random exploits distributed over many different players.

[arnezami]

I was very surprised that the charts of number of movies required to detect a group of traitors versus size of traitor group always maxed out at a traitor group of 16! You are talking about traitor groups nearly ten times larger than they were thinking about as they designed the system.



Yes, the system is particularly vulnerable to large numbers of exploits within a single model. You would think that would be the most likely scenario, not random exploits distributed over many different players.

Yes. Just imagine (this is just one example) the PS3 gets hacked and a (linux) program is released giving all sequence keys of your PS3. There are thousands and thousands of these things sold. I don't think it would be that hard to get around 100 volunteers to kill the Sequence Key system for good. Especially since there is no risk involved of being revoked. And it only has to be done once.

In the old system (with no clustering) this wouldn't work very well since you would need something like 7000-10000 volunteers (assuming only 4096 rows). Although any model could be used so it might have been a little easier to get more volunteers but still. However because they used clustering (did they really btw or was Lotspiech too late with his "fix"?) they reduced the keys per column (for one model) from 4096 to 64. Thats quite significant!

Even with 16K keys it will still be possible to use this technique. In that case there will be 256 keys per cluster. So I guess we would need around 400-700 volunteers. Thats still doable I think (especially since its fun and disables an important part of a major DRM system :))

Keep in mind: if the sequence key system is disabled then revocation (MKB) becomes quite useless (for standalones) since they will not know which standalones the device/processing keys come from. And somehow I suspect some standalones out there don't even use the KCD protection which would mean we could use their processing/device keys on a PC (without a drive firmware hack for retrieving the KCD).

Need I go on?

Regards,

arnezami

PS. I'm still trying to understand certain things in the paper about some hazy things he said. Eg he is talking about 4 or 6 columns (sometimes 18) and seems to completely ignore the fact that there are 256 columns. There is also the picture of 1 movie per column which is weird because 256 movies using 256 columns won't work because if one key is revoked innocent devices will be revoked to. So interpretation of the text is still a bit of an issue for me atm. Some parts seem to be written hastely (especially the multi-time "fixing" parts) indicated by the many typos, short sentences and lack of precision.

[awhitehead]

Since everyone is linking to paper co-authored by Jeffrey Lotspiech, I just want to point out that he has a website, http://www.lotspiech.com/ and that archive.org has an archive of http://www.lotspiech.com/AACS/ from before he started asking to register to view it: http://web.archive.org/web/20060604054302/http://www.lotspiech.com/AACS/

Since he talks about NNL trees, original paper on NNL by Naor, Naor and Lotspiech is at http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.pdf

HTH

[FoxDisc]

PS. I'm still trying to understand certain things in the paper about some hazy things he said. Eg he is talking about 4 or 6 columns (sometimes 18) and seems to completely ignore the fact that there are 256 columns. There is also the picture of 1 movie per column which is weird because 256 movies using 256 columns won't work because if one key is revoked innocent devices will be revoked to. So interpretation of the text is still a bit of an issue for me atm. Some parts seem to be written hastely (especially the multi-time "fixing" parts) indicated by the many typos, short sentences and lack of precision.

I am glad you say this - I am also puzzled by some of the same things in the papers. He talks about 16 variations at 15 points producing 256 versions of the movie. The AACS specs refer to eight versions at 32 points.

[xyz987]

In the old system (with no clustering) this wouldn't work very well since you would need something like 7000-10000 volunteers (assuming only 4096 rows). Although any model could be used so it might have been a little easier to get more volunteers but still. However because they used clustering (did they really btw or was Lotspiech too late with his "fix"?) they reduced the keys per column (for one model) from 4096 to 64. Thats quite significant!


This key assignment is far surprising for me. Of course any key assignment that is not entirely random is a Bad Idea, but this one seems to be a Very Bad Idea if i understood it. This seems to be equivalent to assign a SK matrix to each model, a matrix whose number of rows is far lower that the number of rows of master matrix.

The weak point of any SK matrix is the number of rows (it is noteworthy to say that NNL paper says "the CPRM method is not r-flexible: the probability that a non-revoked device is uncovered grows with r, hence in order to keep it small enough the number of revocations must be bounded by A"). But it seems Lotspiech is proposing here to reduce a lot the number of rows for each manufacturer/model.

Have i understood it?. It is hard to believe they did a so big mistake.

[arnezami]

Ok. I did some simulations. It appears my estimates are somewhat off. But still practical.

For finding 58 of the 64 keys (per cluster) we need approx 146 volunteers.

For finding 60 of the 64 keys (per cluster) we need approx 169 volunteers.

For finding 63 of the 64 keys (per cluster) we need approx 239 volunteers.

For finding 64 of the 64 keys (per cluster) we need approx 308 volunteers.

(this is based on random distribution of the keys)

Thats quite a bit more than I guessed earlier but still very doable.

The question is: do we even need so many of the keys per cluster to be safe? In other words: assume they revoke all released keys (say 60 of all 64 keys for each column). How big a chance is there that some/many innocent devices get revoked in the process? My bet is (although we could do the math on this properly) that there will be quite a lot of innocents revoked if they would do that. Especially since different movies would require keys from different columns. And there are bound to be innocents that do not have the keys in those columns (for at least some movies) if they revoke all these keys.

Personally I think its better to be safe than sorry: 64 out of 64 will always be safe (with maybe a few columns with 63 or 62)

There is also the possibility they aren't even using all 64 keys (within clusters) but are only using a subset of those (maybe some sequential non-random distribution). This could have both advantages (less keys per cluster is easier) aswell as disadvantages (how do you know you have all keys that are in use?) But when you have enough voluntiers there won't be any risk of missing keys.

arnezami

PS. For 256 keys per cluster (16K rows) it would take around 1000-1500 voluntiers to get around 250-256 keys for each column. Thats starting to get somewhat impractical. But maybe not. Since we can take all the time in the world for more people to join the effort.

[arnezami]

I did some searching and figuring out concerning the timing of the specifications of AACS. I now believe the paper from Lotspiech and Hongxia (the "Renweable traitor tracing: ..." paper (http://domino.watson.ibm.com/library/CyberDig.nsf/papers/7158161AA398C8CE8525722200570F64/$File/rj10394.pdf) we are getting all this info from) was not written in late 2006 but in 2004 (or maybe 2005). I think it was lately edited to add new references (I now believe it originally had something like 12 or 13 references all of which are from 2004 and before).

Why is this important? Because I also believe the problems Lotspiech and Hongxia found might have been fixed in a different/better way than they proposed in their paper.

Things that are better/different when looking at the (most recent) AACS specs:

Amount of points in the movie for variations was 15: aacs specs now says 32 (and thats per title/EVOB). The number of variations was 16 per variation point: in aacs specs it seems like to be 8 now.
Only speaks of one SKB per disc: aacs specs say 6 SKBs (and SKGs).

The above might have solved some of the problems they described. There are now max 1024 Variation Data and combined with the (six) Segment/Sequence key blocks the problem with Multi-time might might have been solved wihtout having to make sure each column gets different variations which caused the q / c to go too low thus requiring the slot/clustering method.

I'm not sure though...

Some more dates:
July 14 2004: AACS common specs technical overview draft (http://www.aacsla.com/marketplace/overview/aacs_technical_overview_040721.pdf) (this is quite interesting because it shows whats changed since then, also look at their design regarding Bus encryption ;)) No talk about Sequence Keys.
2004/2005??: Renweable traitor tracing etc (http://domino.watson.ibm.com/library/CyberDig.nsf/papers/7158161AA398C8CE8525722200570F64/$File/rj10394.pdf) written (but not released) by Lotspiech and Hongxia.
April 2005: the AACS (common) specs released (http://yro.slashdot.org/article.pl?sid=05/04/15/0448205). No talk about Sequence Keys though (and can't find the 0.90 specs released then, does anybody still have them?) Does anybody know if and when the Prerecorded specs came out?
March 13 2006: version 0.911 of the BD and HD DVD pre-recorded books released (these were hardly different from the 0.912 specs released Agust 15 2006, see "red line (http://www.aacsla.com/specifications/specification_support)" documents for this)
March 31 2006: Toshiba released their first HD DVD player in Japan (wikipedia (http://en.wikipedia.org/wiki/HD_DVD))
November 2006: After being edited IBM releases the paper from Lotspiech and Hongxia along with what appears to be an even older one about Efficient traitor tracing (http://domino.watson.ibm.com/library/cyberdig.nsf/papers/AF8C220CB33D5A98852571FF00570458/$File/rj10390.pdf).

The reason why I think the paper was written earlier? Because it wouldn't make sense that they release the AACS specs and start selling players and then write a paper on how to fix a major problem. It just looks like this was written before 2006 also because a few things appears to have changed (like the 15 / 32 discrepancy) after that. Also the last reference in the document is not referred to (and is a very recent late 2006 piece) and is therefore probably added just before release (but the paper isn't based on it).

In other words: I don't think we can be sure whether or not the clustering "fix" has been implemented or not.

Regards,

arnezami

[xyz987]

In other words: I don't think we can be sure whether or not the clustering "fix" has been implemented or not.


Of course. It is not on spec, so may be they have done it this way or not. That's why we must rely just on spec.

So the old questions arise again. But i am simply tired and bored these old questions are never finished just because the focus is always changing again and again.

If someone really wants to debate what happens if each attacker publish just one key per player, i will do it to the very end of the question.

Changing the focus and keeping old questions unresolved is just a waste of time.

And yes, i am angry.

Edit: of course i am not angry with you, arnezami.

[FoxDisc]

If someone really wants to debate what happens if each attacker publish just one key per player, i will do it to the very end of the question.

We know what will happen if an unlimited number of compromised devices each publish one unique SK per player. There are more players than SKs and each player has multiple SKs. Ultimately all keys get published and AACS is broken. The question has always been how many players less than "an unlimited number" have to get together and the answer to that question depends on key assignment. If you think you have some answers to questions that have not been considered or some insight that has not been revealed, why don't you post your analysis? This is an explanation thread, not some kind of debate contest.

[gaurav1780]

hi,

how about having a small practical example showing how NON-CONTIGUOUS devices are revoked. Say in an 8-device environment (d0-d7), d1 and d6 need to be revoked. which are the keys used to encrypt media key. If the answer is device key of d1 and d6, it is not accurate since d1 and d6 can collude and share information. maybe we can deploy a shared nomenclature....
root ..............................................A
level 1 ............................B..........................C
level 2 .....................E...........F.............G............H
level 3 (devices) ....d0..d1....d2..d3......d4..d5.....d6..d7


what would be really clarifying is answer to the question "which keys do the subset difference trees rooted at A-H store?"

[arnezami]

hi,

how about having a small practical example showing how NON-CONTIGUOUS devices are revoked. Say in an 8-device environment (d0-d7), d1 and d6 need to be revoked. which are the keys used to encrypt media key. If the answer is device key of d1 and d6, it is not accurate since d1 and d6 can collude and share information. maybe we can deploy a shared nomenclature....
root ..............................................A
level 1 ............................B..........................C
level 2 .....................E...........F.............G............H
level 3 (devices) ....d0..d1....d2..d3......d4..d5.....d6..d7


what would be really clarifying is answer to the question "which keys do the subset difference trees rooted at A-H store?"

No. They cannot collude. They both have the same disc (so they exactly the same information) and none of their Device Keys allows them to go to any Processing Keys (that would reveal the Media Key). So having the collection of the Device Keys of both participants won't help at all since none of those lead to anything useful.

You need a non-revoked third participant.

[gaurav1780]

No. They cannot collude. They both have the same disc (so they exactly the same information) and none of their Device Keys allows them to go to any Processing Keys (that would reveal the Media Key). So having the collection of the Device Keys of both participants won't help at all since none of those lead to anything useful.

You need a non-revoked third participant.

continuing along the same notation -
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

d1 has device keys k_d0, k_F, k_C
d6 has device keys k_d7, k_G, k_B

isn't it right that k_C and k_B can effectively derive all device keys (k_d0...........k_d7).

am i missing something here? (i am pretty sure i am, but can't figure out what)

do the key subsystems originating at the nodes of the master key tree contain key K to decrypt media key, such that K can't be reached by a combination of revoked keys?

[arnezami]

continuing along the same notation -
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

d1 has device keys k_d0, k_F, k_C
d6 has device keys k_d7, k_G, k_B

isn't it right that k_C and k_B can effectively derive all device keys (k_d0...........k_d7).

am i missing something here? (i am pretty sure i am, but can't figure out what)

do the key subsystems originating at the nodes of the master key tree contain key K to decrypt media key, such that K can't be reached by a combination of revoked keys?

Yes you're missing something here :).

When both devices are revoked this whole tree won't be used again. The tree (or floor if you will) above it is used.

Here is your example (using my truck/garage picture style) to explain this:

http://img264.imageshack.us/img264/872/examplevo2.jpg

As you can see the trucks (d1 and d6) cannot reach the tree the other one is driving on because there simply isn't any road to it. And they cannot get to the circled Parking spot in their own tree. Note that the floor below (the very light blue one) is simply not used anymore (on new discs).

Hope that helps. ;)

arnezami

[FoxDisc]

continuing along the same notation -
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

d1 has device keys k_d0, k_F, k_C
d6 has device keys k_d7, k_G, k_B

Your notation is part of what is confusing you. You are looking at a subtree that starts at the node A. When you write:
d1 has device keys k_d0, k_F, k_C
d6 has device keys k_d7, k_G, k_B


You should write:
d1 has device keys A-d0, A-F, A-C
d6 has device keys A-d7, A-G, A-B
These are device keys that signify a Subset Difference set rooted at A and subtracting out the devices below another node. Thus, the device key for A-F matches the S-D set of d0, d1, d4-d7. (d2 and d3 are below F so they are not part of the A-F S-D set. The other devices are below A, but not below F so they are members). The device key for A-F allows calculation of the processing key for that S-D set and the S-D sets of A-d2 and A-d3.

isn't it right that k_C and k_B can effectively derive all device keys (k_d0...........k_d7).

Yes, but only for the S-D sets rooted at node A. The AACS LA won't use those S-D sets for the MKB and they won't use the device keys for those sets. There is another set of device keys for S-D sets rooted at B (and every other node). d1 does not have the key on the subtree rooted at B for the S-D set B-d1, but d0, d2 and d3 all do have that device key or one that will calculate it (d2 and d3 have B-E and can calculate B-d1 from B-E).
d6 is not below B and has no B-rooted device keys so he can't help d1.

am i missing something here? (i am pretty sure i am, but can't figure out what)

Did that help?

Edit:
For reference and to clarify - the full set of device keys for the two revoked devices are:

d1 has device keys A-d0, A-F, A-C, B-F, B-d0, E-d0 (3 keys on A-level, 2 keys on B level, 1 key on E)

d6 has device keys A-d7, A-G, A-B, C-G, C-d7, H-d7 (3 keys on A-level, 2 keys on C level, 1 key on H)

The simplest MKB encryption of the media key that excludes d1 and d6 is to encrypt the media key twice, once with the B-d1 key and once with the C-d6 key. These are the largest S-D sets (first node is as high as possible, second node as low as possible) that exclude both d1 and d6.

[gaurav1780]

Hey Arnezami and FoxDisc, both the replies were EXTREMELY helpful. Thanks a lot for the help. I am writing a program to provide a comprehensive example of which subsets are used when different pairs (of size 2, 3, ...n) collude. I will shortly have an example for others with a 16 device structure. thanks again, mates.

[ffguy]

While I claim no significant knowledge of the AACS system, I may still be able to help with the cause.

Given a large number of nodes, is it even feasible to consider brute forcing parts of the protection with a distrubuted approach? I'm sure many people on the forums and projects such as distributed.net could help, especially considering the importance of the task.

Also, I can potentially get runtime on a large 1024-node cluster, if that would help. I'm a simple techie who takes care of minor problems, but for the most part I can run whatever I want while nobody is using it. I enjoy brute forcing sudoku solutions during my lunch break :)

[arnezami]

While I claim no significant knowledge of the AACS system, I may still be able to help with the cause.

Given a large number of nodes, is it even feasible to consider brute forcing parts of the protection with a distrubuted approach? I'm sure many people on the forums and projects such as distributed.net could help, especially considering the importance of the task.

Also, I can potentially get runtime on a large 1024-node cluster, if that would help. I'm a simple techie who takes care of minor problems, but for the most part I can run whatever I want while nobody is using it. I enjoy brute forcing sudoku solutions during my lunch break :)
Brute forcing AACS keys is not an option. In short: you won't be able to crack AES (which is the encryption cypher used for most keys) or ECDSA for that matter. In this area they have done well.

There may be a role for the community concerning Sequence Keys in the future. But this is based on speculation combined with logic so far. We'll have to wait until they really start using Sequence Keys and see if its practical.

But if we need people to help you can be assured we will tell everyone we can reach ;).

arnezami

[awhitehead]

Ok, this is a question for folks who understand AACS and AES a bit better then I do, primarily FoxDisc and xyz987 (anyone else, pipe in, of course).

We know that in process of decryption, volume ID is hashed together with the media key to obtain VUK. Media key, in turn is generated by using the processing key to decrypt the c-value on the disc.

How strong is the system if the volume ID is known to be all zeros, and we do not know the processing key? Does a mastering house forgetting to set a volume ID on a title gives us anything in terms of finding a valid processing key? My gut feeling tells me that "not much if anything", but I'd like a confirmation.

Thank you.

[xyz987]

How strong is the system if the volume ID is known to be all zeros, and we do not know the processing key? Does a mastering house forgetting to set a volume ID on a title gives us anything in terms of finding a valid processing key? My gut feeling tells me that "not much if anything", but I'd like a confirmation.

You are right, we get nothing. In fact VoID is not a key, but a dirty trick to avoid bit-per-bit home copying. Althought it is not a key, burning software doesn't know this value because it is stored at a reserved data area (2 reserved areas in fact), so it is not possible to do a verbatim copy of the disk.

Of course, there are "unofficial ways" to get VoID, so this dirty trick will become "broken" as soon as anybody develops the appropiate burning soft. However it is far more useful to decrypt the movie, and store it decrypted. That's the reason nobody is developing such kind of burning soft.

[FoxDisc]

How strong is the system if the volume ID is known to be all zeros, and we do not know the processing key? Does a mastering house forgetting to set a volume ID on a title gives us anything in terms of finding a valid processing key? My gut feeling tells me that "not much if anything", but I'd like a confirmation.

I agree with xyz and your gut - knowing the VID is zero is no better than knowing it's value when it's not zero, and it's easy to get the value, whatever it is.

[awhitehead]

You are right, we get nothing. In fact VoID is not a key, but a dirty trick to avoid bit-per-bit home copying. Althought it is not a key, burning software doesn't know this value because it is stored at a reserved data area (2 reserved areas in fact), so it is not possible to do a verbatim copy of the disk.

So basically, once HD-DVD recorders start showing up, mastering house not setting VID (leaving it all zeros) would mean that home bit by bit copy of that particular disc in an encrypted state is possible (assuming that the protectred areas on the HD-DVD-R or equivalent media would have the BCA and friends all zeros, of course). And given how easy it is for consumer to create a fully decrypted backup, plus lack of long term problems with decrypted backups (inplying that consumers that would make backups of their media would chose to make decrypted backups), it's not as major an oversight at it might seem.

Hrm.

Thank you for clarifying.

BTW, this question came up when I was looking at "Relentless Enemies" - it has an all zeros VID but is AACS protected.

[FoxDisc]

So basically, once HD-DVD recorders start showing up, mastering house not setting VID (leaving it all zeros) would mean that home bit by bit copy of that particular disc in an encrypted state is possible (assuming that the protectred areas on the HD-DVD-R or equivalent media would have the BCA and friends all zeros, of course).

I'm reasonably sure that a pre-recorded disc that has VID set to zero would be handled differently from a recordable disc copy. The pre-recorded disc should be recognized as an AACS disc by the drive and the drive should enter into an AACS authenticated session with the host. The VID, even if it's zero, will be used with the media key to calculate a volume unique key.

For the case of a recordable disc copy, however, I suspect that whole process won't happen. I don't think it will get a zero for the VID, I think it will get an error when it tries to read the portion of the VID in the Burst Cutting Area of a recordable disc.

It would be an interesting thing to test, however.

[radone]

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?

[FoxDisc]

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

This part is right.


I probably missed something because I thought that non-revoked device d0 has device keys: B-d1, C-d6. Am I right?

No, you are not right. d0 has device key B-d1, but not C-d6. The first node must be above the device, and the second one not above. C is not above d0 (not on path from d0 to top), so he does not have C-d6.
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?

I'd like to help, but I don't follow your question here. "to encrypt a message M for user d0 only" Why do you want only d0 to read it, and what does that have to do with AACS? The simple answer is use only E-d1 key and no others, but why would you/LA do that?

[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?

[FoxDisc]

root ..............................................A
level 1 ............................B..........................C
level 2 .....................E...........F.............G............H
level 3 (devices) ....d0..d1....d2..d3......d4..d5.....d6..d7

d1 has device keys A-d0, A-F, A-C, B-d0, B-F, E-d0
d6 has device keys A-d7, A-G, A-B, C-d7, C-G, H-d7
(I've added all the keys they would be assigned on this part of the tree)

d0 has device key B-d1, but not C-d6. The first node must be above the device, and the second one not above. C is not above d0 (not on path from d0 to top), so he does not have C-d6.


For those interested:

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. :devil: 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.

[paranoid87]

hm...

so what if AA and BB's dont get matched? i dont know how to say it..the AACS LA..?

[blutach]

@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

[bcrabl]

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?

[Shinigami-Sama]

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?
device keys

[bcrabl]

device keys

The device key is a component of the player(powerdvd for example) not of the HD DVD drive.

[Shinigami-Sama]

The device key is a component of the player(powerdvd for example) not of the HD DVD drive.

I thought those were sub-device keys?

[bcrabl]

I thought those were sub-device keys?

Maybe. But still I do not think that the drive itself has any keys. The idea here is to be able to bypass the whole protection like daemon tools does.

[KenD00]

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.

:rolleyes:

[FoxDisc]

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.
:rolleyes:

This post raises 3 issues:

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.

[bcrabl]

This post raises 3 issues:

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)



Even if it cannot read everything now, I bet it can be made to read everything.

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.

But do we know enough to make a virtual drive?:confused:

[KenD00]

@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.

:rolleyes:

[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.

Aaah, now I see why you wrote as you did. I had forgotten that the raw sector read did not work on these sectors yet I knew that the data from these sectors (KCD and half of VID) could be obtained.

[FoxDisc]

Even if it cannot read everything now, I bet it can be made to read everything.

Everything on the disc that is needed can be read now. As KenD00 points out, actual bits in some areas can't be read, but that data can still be obtained after it's been read by the XBox drive.

But do we know enough to make a virtual drive?:confused:

That depends on what you mean by "virtual drive." There are two ways that a disc gets decrypted and played - in standalone players and in PCs using 1) host software (like PowerDVD) and 2) a PC disc drive.

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.

[jesperl]

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.

In the future, we may get audio watermarking (Verance) on HD-DVD such that authorized players will refuse to play unencrypted discs. Perhaps, this could generate some interest in making backup copies with encryption?

[FoxDisc]

In the future, we may get audio watermarking (Verance) on HD-DVD such that authorized players will refuse to play unencrypted discs. Perhaps, this could generate some interest in making backup copies with encryption?

I'm sure it would generate interest in tools to remove watermarking. It would also generate interest in various other non-AACS authorized players that would ignore the watermarking.

[bcrabl]

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.

OMG. That means that Xbox drive has device keys :devil::devil::devil:

[FoxDisc]

OMG. That means that Xbox drive has device keys :devil::devil::devil:

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.

[Geremia]

wel.....all these informations about xbox360 hd-dvd were not meant to be public because they are not already usefull.

[MartyMcNuts]

Hi all, I know this is an old thread and I have read it a few times over, which does provide some general information on how Subset-Differences work, however there doesn't seem to be anything with more detail. What I am trying to do is test a bunch of "possible device keys" against a MKB_RO.inf file to calculate a "processing key" for that MKB. I already understand the rest of the procedure to calculate the "media key" and the "VUK" but need assistance with the device key to processing key step.

So,according to the AACS specs (3.2.3 - 3.2.5), each subset-difference is encoded with 5 bytes. The first byte is the U mask and the last 4 bytes are the UV number (most significant byte first). So for example, I have a subset-difference 0B 00 00 0A 00, (0B) is the U Mask and (00 00 0A 00) is the UV Number. Now, that (first byte) is treated as a number, the number of low-order 0-bits in the mask. For example, the value 01 denotes a mask of FFFFFFFE; value 0A denotes a mask of FFFFFC00.

Question 1. How is this u_mask calculated?



From the AACS Specs, "For conciseness, the path number and the “v” mask are encoded in a single 32-bit number, referred to as the uv number. The mask for v is given by the first lower-order 1-bit in the uv number. That bit, and all lower-order 0-bits, are zero bits in the “v” mask."

The first sentence there I understand. The rest doesn't make sense to me, however, by using the code:

long v_mask = 0xFFFFFFFF;
while ((uv & ~v_mask) == 0) v_mask <<= 1;

to calculate the v_mask, for the example subset-difference "0B 00 00 0A 00", use the UV number, "00 00 0A 00" the v_mask equals "FF FF FC 00"

Parts I don't understand are:

"As a result, the u mask always has more 0 bits than the v mask. The subset-difference is the subtree rooted at node u minus the sub-tree rooted at node v."

Question 2: Can someone please show me this using the example subset-difference above?



From the AACS specs "A subset-difference applies to a device if the u node is on a path from the device’s node to the root of the tree, but the v node is not. This is simple to calculate using the uv number, the appropriate mask, and the device node number (D_node). By definition, a device “D_node” is on a path to a “uv” number with mask “m” if and only if:

(D_node & m) == (uv & m)

Thus, a subset-difference applies if and only if:

((D_node & u_mask ) == (uv & u_mask)) and ((D_node & v_mask) != (uv & v_mask))

Question 3: Where does this D_node come from?


AACS specs CONTINUED: The device searches through the Explicit Subset-Difference Record fields, looking at the identified subset-differences, until it finds the one that applies to it. At that point the device either has the Device Key, or is able to derive the subsidiary Device Key, associated with that subset-difference. It finds the appropriate stored Device Key as follows: assuming the Explicit Subset-Difference Record value is uv, u_mask, and v_mask, and the stored Device Key has uv’, m’u, and m’v, the appropriate Device Key is the one that meets the following condition:

(u_mask == m’u) and ((uv & m’v) == (uv’ & m’v))

If m’v equals v_mask, the starting Device Key is the final Device Key, and is used directly to derive the Processing Key, as described above. Usually, however, the starting Device Key’s node is further up in the tree, and the actual Device Key will have to be derived. The device does that as follows:

1. Initialization. m = the stored v mask m’v. Dk = the starting Device Key.
2. Use AES-G3 on Dk, as described above, to determine a left subsidiary Device Key, a Processing Key, and a right subsidiary Device Key.
3. Look at the most significant zero bit in m. If the corresponding bit in the incoming uv number is 0, Dk = left subsidiary Device Key from step 2. Otherwise, Dk = right subsidiary Device Key from step 2.
4. Iteration. Arithmetic shift m right one bit. If it does not equal the incoming v mask mv, repeat starting at step 2.

I understand steps 2 and 4. I do not understand steps 1 and 3.

Question 4: Since we are not an authentic device, how can we know / calculate / obtain the UV, u-mask and v_mask from a device key?
Question 5: If we cannot know these, how do we work around that?


Some answers including calculations (or possibly some code?) using the above example subset-difference would be greatly appreciated.

Thanks,
Marty

[mick0]

Question 1. How is this u_mask calculated?
Question 2: Can someone please show me this using the example subset-difference above?
Question 3: Where does this D_node come from?
Question 4: Since we are not an authentic device, how can we know / calculate / obtain the UV, u-mask and v_mask from a device key?
Question 5: If we cannot know these, how do we work around that?

Some answers including calculations (or possibly some code?) using the above example subset-difference would be greatly appreciated.

Thanks,
Marty

Hi Marty

For questions 1,2,4 and 5 maybe you should see how aacskeys does it?

Also, I'm curious, why do you want to calculate these using your own custom implementation instead of just using aacskeys (http://s000.tinyupload.com/index.php?file_id=31122209976861014118) (available since 2007, open source and runs on Windows/Linux/Mac)?

Aacskeys can calculate and print these for you - all you need to do is to copy-paste device/processing keys you want to test in to ProcessingDeviceKeysSimple.txt and run it in verbose mode (-v). It can try large number of keys in a relatively short time and it doesn't require device_node, UV or u_mask_shift values like libaacs does.

If you are writing a BD player/ripper then why not just use libaacs instead of writing your own AACS implementation?

For reference here is a list of currently known device keys you can use with aacskeys (libaacs/KEYDB.cfg compatible format).
| DK | DEVICE_KEY 0xAA856A1BA814AB99FFDEBA6AEFBE1C04 | DEVICE_NODE 0x0018 | KEY_UV 0x00000001 | KEY_U_MASK_SHIFT 0x17 ; MKBv01
| DK | DEVICE_KEY 0x810827A76E5B2CC1685E3217A23E2186 | DEVICE_NODE 0x0100 | KEY_UV 0x00000100 | KEY_U_MASK_SHIFT 0x17 ; MKBv01-MKBv12
| DK | DEVICE_KEY 0x44145A846F19D096F2C84A2E50C5C4F5 | DEVICE_NODE 0x0200 | KEY_UV 0x00000280 | KEY_U_MASK_SHIFT 0x09 ; MKBv14-MKBv16
| DK | DEVICE_KEY 0xEB55A475080FBCF18534EFA0839A7373 | DEVICE_NODE 0x0340 | KEY_UV 0x00000340 | KEY_U_MASK_SHIFT 0x08 ; MKBv17-MKBv19
| DK | DEVICE_KEY 0xFB4AC39009E82113D45ECF4B7EAEA467 | DEVICE_NODE 0x0388 | KEY_UV 0x00000384 | KEY_U_MASK_SHIFT 0x07 ; MKBv20-MKBv21
| DK | DEVICE_KEY 0x8BF4FBD91A7FB7DB8576D1E5A15A8544 | DEVICE_NODE 0x0388 | KEY_UV 0x00000384 | KEY_U_MASK_SHIFT 0x05 ; MKBv22-MKBv30
| DK | DEVICE_KEY 0xA088BC72424478EACAF237A9E258351E | DEVICE_NODE 0x0400 | KEY_UV 0x00000200 | KEY_U_MASK_SHIFT 0x17 ; MKBv01-MKBv23
| DK | DEVICE_KEY 0x5FB86EF127C19C171E799F61C27BDC2A | DEVICE_NODE 0x0800 | KEY_UV 0x00000400 | KEY_U_MASK_SHIFT 0x17 ; MKBv01-MKBv48
| DK | DEVICE_KEY 0x6C02A9C4DF6DE9314F6F4BB44677BD67 | DEVICE_NODE 0x0600 | KEY_UV 0x00000500 | KEY_U_MASK_SHIFT 0x0A ; MKBv24-MKBv35
| DK | DEVICE_KEY 0x4D84E4D6D434A08D6EF0B523B6D891B2 | DEVICE_NODE 0x0700 | KEY_UV 0x00000680 | KEY_U_MASK_SHIFT 0x09 ; MKBv36-MKBv43
| DK | DEVICE_KEY 0xF2F56575C0C5448042298FA9B316AB9A | DEVICE_NODE 0x0710 | KEY_UV 0x00000714 | KEY_U_MASK_SHIFT 0x04 ; MKBv44-MKBv51
| DK | DEVICE_KEY 0x31A194B61D3119D2B09DC0D8B9A73A00 | DEVICE_NODE 0x0880 | KEY_UV 0x00000840 | KEY_U_MASK_SHIFT 0x0B ; MKBv49-MKBv52
| DK | DEVICE_KEY 0x25F9782764D026413C3D4868F891E81E | DEVICE_NODE 0x0884 | KEY_UV 0x000008A0 | KEY_U_MASK_SHIFT 0x07 ; MKBv53-MKBv54
| DK | DEVICE_KEY 0xFDAD855E9A89E5335288AF2805DC0497 | DEVICE_NODE 0x08F0 | KEY_UV 0x000008FC | KEY_U_MASK_SHIFT 0x04 ; MKBv55-MKBv57
| DK | DEVICE_KEY 0x7FD1F7966AD2B0E4F4901205E32A69BA | DEVICE_NODE 0x0A00 | KEY_UV 0x00000900 | KEY_U_MASK_SHIFT 0x0B ; MKBv49-MKBv62

And all currently known processing keys (libaacs/KEYDB.cfg format)
| PK | 0x09F911029D74E35BD84156C5635688C0 ; MKBv01
| PK | 0x455FE10422CA29C4933F95052B792AB2 ; MKBv03
| PK | 0x973940BB180E83266231EE596CEF65B2 ; MKBv03-MKBv12
| PK | 0xF190A1E8178D80643494394F8031D9C8 ; MKBv04
| PK | 0x7A5F8A09F833F7221BD41FA64C9C7933 ; MKBv06-MKBv08
| PK | 0xC87294CE84F9CCEB5984B547EEC18D66 ; MKBv09
| PK | 0x452F6E403CDF10714E41DFAA257D313F ; MKBv10
| PK | 0x58EBDADF88DCC93304CBBEDB9EE095F6 ; MKBv14-MKBv16
| PK | 0xCC72242D4CC8156B960502805987DED0 ; MKBv14-MKBv23
| PK | 0x465FA8BE828509014D05D2FCCEFF35D2 ; MKBv17
| PK | 0xAD5E546C46D72DC083AEB5686924E1B3 ; MKBv18-MKBv19
| PK | 0x53FCE78ECD352DA50D526B5EE3D3D96B ; MKBv20-MKBv21
| PK | 0xC32238976FF44A51E2D33553CFE85772 ; MKBv22-MKBv30
| PK | 0x3ADE0AB7C9E4270055506C449E8EE6CF ; MKBv24-MKBv48
| PK | 0xD11E3DBA323D37DE3DE0D6A0DC5EC807 ; MKBv24-MKBv25
| PK | 0xAAAF8A16F829DA16A124D837F64EE2D8 ; MKBv26-MKBv28
| PK | 0xC0F535929D59CD071BEE9CB53F0C21C2 ; MKBv30-MKBv35
| PK | 0x99AB6AE0A7E13504CE284B7CA401B26A ; MKBv31-MKBv36
| PK | 0x19DF7DA3A1FB75AC4DC34CCB6AF6A5C7 ; MKBv36-MKBv38
| PK | 0x3FB9D3314AAC7F76581190A624A5C578 ; MKBv39-MKBv43
| PK | 0x186D1BBA19487F6450C1FD5ADA9407E6 ; MKBv44-MKBv51
| PK | 0xF2C416A45D806D964F567B5D7FED209D ; MKBv49-MKBv52
| PK | 0x7A8BAB1B0C66C39D1A2EEE6883E4DD3C ; MKBv53-MKBv54
| PK | 0x1F70D403A6D39B20A3F7131750ACAA22 ; MKBv53-MKBv54
| PK | 0x8FBDD8452146552EF76136B0A348590B ; MKBv55-MKBv57
| PK | 0x0EB5F81CF17405CAFDB97832F5EA11B4 ; MKBv55-MKBv62

[MartyMcNuts]

@mick0,

I thought I'd design my own VUK finder program with GUI, which I have mostly done using a list of processing keys, however, this method only works up to MKBv62.

I would like to better understand the Device Key to Processing Key method as I want to test possible device keys from PS3 firmware to see if they can calculate the correct processing key for a given MKB (v63 - v66). I had thought about using libaacs but I don't really understand some of the code (especially the part regarding device keys, uv's, v_masks etc) or how to use it. (I am a c# programmer and would like to understand the method so I can then either convert some c++ code to c# or write my own)

[mick0]

@mick0,

I thought I'd design my own VUK finder program with GUI, which I have mostly done using a list of processing keys, however, this method only works up to MKBv62.

I would like to better understand the Device Key to Processing Key method as I want to test possible device keys from PS3 firmware to see if they can calculate the correct processing key for a given MKB (v63 - v66). I had thought about using libaacs but I don't really understand some of the code (especially the part regarding device keys, uv's, v_masks etc) or how to use it. (I am a c# programmer and would like to understand the method so I can then either convert some c++ code to c# or write my own)

I see.

Unfortunately I can't help you with the calculations.

Also, I'm not sure if there still are people around who actually understands all this, so basically I think your best bet is be to study how libaacs and aacskeys are doing it.

[MartyMcNuts]

mick0,

Yeah, I may have to read up on c++ so I can better understand some of the libaacs code.

Thanks,
Marty

[maetel99]

Here is some code I wrote to use a device key to determine a processing key via the subset-difference process. This code essentially consolidates the libaacs functions _find_dk(), _calc_mk_dks(), and _calc_v_mask(), along with some macros. The input to the function is a candidate device key and an index into the record arrays for the encrypted media key and subset-differences. The function returns a processing key if the device key is valid, otherwise it returns an error code. I'm not including all the lower-level functions here.

There is some ambiguity in the AACS spec as far as what record array index to start from when testing a candidate device key in the subset-difference tree. My code follows the model used in libaacs in which we simply test every index for a given device key and look for the first one that delivers a valid processing key. Unfortunately, this can be slow since there may be 500+ records to test and each one requires iterating over a subset-difference tree.


// attempts to derive a processing key from a given device key and subset difference record index
// follows logic from AACS Common Spec section 3.2.4
// sdIdx = index of subset difference record to use
// deviceKey = 16 byte device key to use
// processingKey = 16 byte processing key if sucessful
// mediaKey = 16 byte media key if successful
// returns 0 if found processing key, -1 if no valid key, -2 if device key is revoked
int DeriveProcessingKeyForDeviceKeySubsetRecord(BDAACSMKBStatus *mkbStat, int sdIdx,
unsigned char *deviceKey, unsigned char *processingKey, unsigned char *mediaKey)
{
int result;
int32_t tmvIter;
uint32_t m, n, mu, mv, uv, mvIter;
unsigned char uvNumber[4], devKey[16], verifyData[16], encDataKey[16], procKey[16], medKey[16];

// get the verification data (MKB record type 0x81)
BDAACSMKBGetVerificationData(mkbStat, verifyData);
// get encrypted data key for this subset difference index (MKB record type 0x05)
BDAACSMKBGetMediaKeyData(mkbStat, sdIdx, encDataKey);
// get subset diffence data for this index (MKB record type 0x04)
BDAACSMKBGetSubsetDiffData(mkbStat, sdIdx, &mu, uvNumber);

// check u mask value from record
// AACS common spec section 3.2.3:
// if the u mask value is not of the bit form 00xxxxxx, this marks the end of the list
if ((mu & 0xC0) != 0) {
// end of the list, device at this record location is revoked
return -2;
}

// compute uv from uvNumber in endian independent way
uv = uvNumber[0];
uv = (uv << 8) | uvNumber[1];
uv = (uv << 8) | uvNumber[2];
uv = (uv << 8) | uvNumber[3];
if (uv == 0)
return -1;

// following AACS common spec section 3.2.3, derive v mask mv from the uv number
// the v mask is given by the first lower-order 1-bit in the uv number
// that bit, and all lower-order 0-bits, are zero bits in the v mask
mv = 0xFFFFFFFF;
while ((uv & ~mv) == 0)
mv <<= 1;
// following AACS common spec section 3.2.5.1.5, encoded u-mask value is actually
// the number of low-order 0-bits in the mask
mu = 0xFFFFFFFF << mu;

// section 3.2.3: the mu mask always has more trailing 0 bits than the mv mask
// the deeper the position of a node in the tree, the shorter the sequence of 0-bits
// in the mask associated to that node, and u is an ancestor of v
if (mv < mu)
return -1;

// initialize iterator and starting device key
mvIter = mv;
result = -1;

while (mvIter != mu) {

// start with initial device key
memcpy(devKey, deviceKey, 16);

// repeat subset-difference iteration as needed
tmvIter = mvIter;
while (tmvIter != mv) {
// determine the bit position of the most significant 0 bit in iterator
// use algorithm from Hacker's Delight, number of trailing zeros
m = ~tmvIter & (tmvIter - 1);
n = 1;
while (m != 0) {
n <<= 1;
m >>= 1;
}
n >>= 1;
// determine whether to take a right or a left subsidiary Device Key
if ((uv & n) == 0) {
// use left subsidiary Device key
AACSEncryptAESG3(devKey, devKey, 0, 0);
}
else {
// use right subsidiary Device key
AACSEncryptAESG3(devKey, 0, 0, devKey);
}

// arithmetic shift right using signed integer
tmvIter >>= 1;
}

// get processing key at this position
AACSEncryptAESG3(devKey, 0, procKey, 0);
// attempt to derive media key using this processing key to check if it is valid
result = AACSDeriveMediaKeyFromProcessKey(procKey, encDataKey, uvNumber, verifyData, medKey);
if (result == 0) {
// valid processing key
if (processingKey)
memcpy(processingKey, procKey, 16);
if (mediaKey)
memcpy(mediaKey, medKey, 16);
mvIter = mu;
}
else
mvIter <<= 1;
}

return result;
}

[MartyMcNuts]

thanks @maetel99.

I'll take a look at your code.

[MartyMcNuts]

@maetel99,

I have a question regarding your code. The first section where you check the u mask value from record (spec 3.2.3)

if ((mu & 0xC0) != 0) {
// end of the list, device at this record location is revoked
return -2;
}

according to your code, mu is currently unassigned.

uint32_t m, n, mu, mv, uv, mvIter;


Can you please advise what the value of mu is and how you obtain it.

Thanks

[videoh]

Looks like mu gets set by this call:

// get subset diffence data for this index (MKB record type 0x04)
BDAACSMKBGetSubsetDiffData(mkbStat, sdIdx, &mu, uvNumber);

[MartyMcNuts]

Thanks @videoh,

haha Not sure how I missed that!!

[maetel99]

Looks like mu gets set by this call:

// get subset diffence data for this index (MKB record type 0x04)
BDAACSMKBGetSubsetDiffData(mkbStat, sdIdx, &mu, uvNumber);


Correct, the initial value of the u-mask is read in from the subset difference record in the MKB file at the specified index.

[videoh]

haha Not sure how I missed that!! Those naughty & characters like to hide in plain sight. ;)