MKB V4 and BD+ [Archive] - Page 4

FoxDisc

14th December 2007, 18:19

Could a MKBv5 Processing Key be used on MKBv4 discs?

A PK matches a specific group of players. (That group is called a subset-difference set of players.) MKBv1 had only one huge group (only one group of all released software players, there were 511 other groups, probably for non-software players) MKBv4 had multiple groups of players. Some groups were huge and matched player IDs that would be released in the future. Some groups were tiny, of only one or two software players.

I haven't looked at MKBv5, but I've looked at earlier MKBs and I'd be willing to bet that some of the defined groups in v5 are identical to those in v4, while others were deleted or split up into smaller groups for revocation.

Bottom line is that some PKs that work on v5 would probably work on v4. Any group of players defined in v4 that had no members revoked in v5 would have a corresponding PK that worked on both.

If so, that means that a media key unlockable by the MKBv5 Processing key has been on all discs since the beginning,

No. No v5 PKs would work on a v1 MKB. PKs match a specific group. The only defined group of software players on v1 was the original 09 F9 PK found by arnezami. That PK is no longer in use. (BTW, I'm only referring to software players that do not use the KCD. There are lots of unchanged groups for hardware players on v1 that match v5 groups)

and the AACS LA is slowly depleting their fairly limited supply of Processing Keys (not sure how many copies of the media key are on each disc, but I don't think it's more than a hundred or so).

The supply of PKs is nearly inexhaustable (billions) -one for each possible S-D set of players. There were only 512 on the original MKBv1 and they've only added a dozen or so. IIRC, they have to add about 1.28 keys to an MKB for each randomly revoked player.

"Inquiring minds want to know"

ilhyfe

14th December 2007, 23:26

Did you use anydvdHD?

What I am saying is a certainty. It is from the german HD DVD since it has the HD DVD intro

http://www.amazon.de/Fantastic-Four-Rise-Silver-Surfer/dp/B000VWP2GE/ref=pd_bxgy_d_img_b/302-2734829-0012829

Of course I did :). Well the german BluRay worked fine, no BD+ here on it...

Turtleggjp

15th December 2007, 02:34

This is an odd way to write this question and it may confuse some people.

Yeah, what I guess I meant to say was a software player with device keys capable of decrypting MKBv4. When PowerDVD was given a new set of device keys, those keys will be able to calculate all needed Processing Keys so far. And it will have instructions (from the MKB it sees) for which Processing Key it will need to calculate. Now with several different MKBs, we are starting to see the higher value of these device keys over the usual Processing Keys we have been looking for already.

Now the question is: with every revocation, does PowerDVD get a completely new set of device keys? If so, it would be a lot of work to find all the device keys, only to have them all revoked in 3 months. I would assume that the AACS LA would decide that the player to be revoked has been completely compromised, so they would make it so that none of that players device keys could be used for newer MKBs.

So to answer my last question from my last post, a MKBv5 Processing Key will not decrypt MKBv4 titles. Therefore, in order to do this, we will need to still find the MKBv4 Processing Key (if there is just one like before, is there?), or else find a lot of device keys from a player capable of decrypting MKBv5.

LoRd_MuldeR

15th December 2007, 20:29

As far as I understand a player has a Device Key. From it's Device Key it can derive a number of Processing Keys. Each player has a different Device Key and thus can derive a different set of Processing Keys. The Processing Keys are used/required to decrypt the MKB found on the disc in order to get the Title Keys. To decrypt the MKB on a specific disc, you need to derive a suitable Processing Key from your Device Key. If you can't do that, you can't play the disc! In case a certain player get's revoked, they make sure it cannot decrypt the MKB's found on new discs. The MKB's on the new discs will simply require one of the Processing Keys that the revoked player cannot derive form it's Device Key. So the revoked player is left out from new discs! Players that have not been revoked will still be able to derive the required Processing Keys from their individual Device Key (for the new discs as well as for the old ones). Only the revoked player will need a fresh Device Key. Also I think a player that can derive the Processing Keys for MKBv5 discs from it's Device Key will also be able to derive the Processing Keys for older MKBv4 discs form the very same Device Key. Please correct me, if I'm wrong...

gioowe

16th December 2007, 03:57

Almost ;)

One Device Key -> Its Processing Key
MKB tells software which device key is must use. The software has many device keys.

Processing Key -> Media Key
Media Key + Volume ID -> Volume Unique Key
Volume Unique Key -> Title Keys

The MKB is not encrypted. It only contains encrypted media keys and a "map" for the software to determine which device key to use and how to use to calculate the required processing key.

LoRd_MuldeR

16th December 2007, 12:57

Okay, thanks :)

But the basic idea still is: There is a number of Processing Keys that a player can derive from its Device Keys. At the same time there is a great number of Processing Keys the player can not derive, because it is missing a suitable Device Key to derive those Processing Keys from. Since each player has different set of Device Keys, the set of Processing Keys a player can derive (or can not derive) also differs for each player.

If a player gets revoked, they make sure the revoked player cannot decrypt any new discs. So on the new discs only Processing Keys will be used, which the revoked player cannot derive from it's Device Keys. The "map" found in the MKB will simply be useless for the revoked player, because it is lacking the required Device Key to start the calculation with. So it cannot derive the required Processing Key and thus won't be able to decrypt the Media Key. Without the Media Key, no Volume Unique Key and no Title Keys... But all the other players will still be able to calculate the Processing Key for the new discs as usual, because their Device Keys have not been revoked. If that wouldn't be the case, then all players in existence would need to get new Device Keys via Software/Firmware update every time one single player is revoked. That obviously isn't the case...

gioowe

16th December 2007, 18:30

LoRd_MuldeR

16th December 2007, 18:48

Correct.

But a software/player has many device keys and not all are used so you don't need to update all players if one device key is revoked. These device key sets are not random, a certain "pattern" (subset) makes it possible to only revoke a single player and let all others "alive". And that's the trick.

That's what I tried to say :)

So back to the previous question: With MKBv5 some players will be revoked. The revoked players are able to derive the Processing Keys for MKBv4 discs form their Device Keys, but they will not able to derive the Processing Keys for MKBv5 discs from their Device Keys. Hence the revoked players are left out from all new discs.

All the players that have not been revoked, will be able to derive the Processing Keys for MKBv4 discs and MKBv5 discs from their Device Keys. They neither need to get new Device Keys for MKBv5 nor do they have to keep separate Device Keys for MKBv4 backward-compatibility. They simply keep on using their current set of Device Keys as if nothing had happened.

Only the revoked players need to get new set of Device Keys via Software/Firmware update in order to be able to play the new discs...

Turtleggjp

16th December 2007, 19:49

LoRd_MuldeR

16th December 2007, 20:02

As far as I understand: In order to "break" a specific MKBvX, you will need to obtain the complete set of Device Keys from a player that is not revoked in MKBvX. This way you will be able to derive all the Processing Keys (from the Device Keys you have) that might be required for a MKBvX disc. Getting only a few Processing Keys doesn't help at all, because even within the same MKB version you might require Processing Keys you don't have yet. If you happen to get the Device Keys, you can derive all Processing Keys of MKBvX, so you can decrypt all the MKBvX discs (no matter which one of the Processing Key the individual discs requires). But even then you are not save, because you can be sure that they will revoke the player from which your Device Keys were leaked! So in the next MKB version after MKBvX you will suddenly require Processing Keys you can not derive from any of the leaked Device Keys! Once again you will need to obtain a complete set of Device Keys from a player that was not revoked in the latest MKB version. And in the case you manage to do this again (which I wouldn't rely on), you can be sure which player is revoked next. There will be no permanent hack...

Turtleggjp

16th December 2007, 20:04

That is why I gave Slysoft my money, so that they could wage this cat and mouse war for me. I can only hope that they keep their promise of free updates, and don't get bought out by the AACS LA.

Inventive Software

16th December 2007, 23:01

gioowe

16th December 2007, 23:21

I think everyone got caught up in the excitement of a single key that unlocks all the current discs. Most people think of the Processing Key as the main thing to find, and so far for MKBs 1 & 3, this was the case. People forget that liscensed players are not given a Processing Key, they are given several Device Keys, and from there they calculate whatever Processing Key is needed (if they can). As was said in the Understanding AACS thread, it could be that a different Processing Key is required for every disc within a MKB revision, since there are so many different ones that can be calculated from the same set of device keys. This may finally be the case with MKBv4, which explains why no one but Slysoft has broken MKBv4 yet.

MKBv4 still uses only 1 processing key. I checked all MKBv4 files that I could get and all use the same paths to calculate the processing key. There might be 2 different ones out there but I haven't found any.

It would also be a waste of space in the MKB tree and it doesn't make the system more secure. If you cracked one disc (to be more precise: if you crack the software) you can get the "current" device key or processing key. The only difference is that if you have to make the device key public, the AACS knows its origin. The processing key is "anonymous". And as long as they revoke all device keys with each MKB iteration it doesn't matter.

I currently even doubt that a device key was ever published. Our "known" device key D6767EE013AC19D42233CBF26A631B-- is actually not a device key. Its preceded by (L) 53BDABEB701A7009B15A7048CE7DDE-- and that's actually a device key that PowerVDV used to use.

(calculate all 256 possibilities to confirm)

LoRd_MuldeR

16th December 2007, 23:50

Turtleggjp

17th December 2007, 00:58

Am I gonna have to find out how this bloody chain of events works between the physical disc and actually giving you a physical image output? All this talk of keys is going over my head. It was easier with the first generation..... :D

The sticky thread about understanding AACS has a lot of information about how this whole Device/Processing Key thing works. I'd suggest you give that another read if you haven't already.

MKBv4 still uses only 1 processing key. I checked all MKBv4 files that I could get and all use the same paths to calculate the processing key. There might be 2 different ones out there but I haven't found any.

It would also be a waste of space in the MKB tree and it doesn't make the system more secure. If you cracked one disc (to be more precise: if you crack the software) you can get the "current" device key or processing key. The only difference is that if you have to make the device key public, the AACS knows its origin. The processing key is "anonymous". And as long as they revoke all device keys with each MKB iteration it doesn't matter.

I currently even doubt that a device key was ever published. Our "known" device key D6767EE013AC19D42233CBF26A631B-- is actually not a device key. Its preceded by (L) 53BDABEB701A7009B15A7048CE7DDE-- and that's actually a device key that PowerVDV used to use.

It would be more secure if all that was being published was the Processing Keys. It's true though that if a players Device Key(s) were to be discovered, then yes multiple Processing Keys would not help at all.

I thought that a Processing Key did reveal some information about which player used it. Most likely, all the software players will head towards the same Processing Key, but I would think if a Processing Key used by say the PS3 were to be published (assuming it calculates a different one than PC software players) then the AACS LA would go "OMG! Now we need to revoke the PS3 too! This is going to hurt..." However, it could be the case that not only the PS3, but all Sony Blu Ray players calculate the same Processing Key. In which case, it would not reveal specific information about the compromise player, only a general idea of who leaked it. Of course, if every player out there calculates "09 F9..." for a MKBv1 disc, then this key would be completely annonymous.

@gioowe
If you know that all MKBv4 discs show the same path to the same Processing Key, is it also possible to know how many other Processing Keys are being calculated for a particular MKB? By this I mean, how many different paths are described in MKBv4? I'm guessing by now that not all players are being directed to the same Processing Key, am I right?

LoRd_MuldeR

17th December 2007, 02:29

I thought that a Processing Key did reveal some information about which player used it. Most likely, all the software players will head towards the same Processing Key, but I would think if a Processing Key used by say the PS3 were to be published (assuming it calculates a different one than PC software players) then the AACS LA would go "OMG! Now we need to revoke the PS3 too! This is going to hurt..." However, it could be the case that not only the PS3, but all Sony Blu Ray players calculate the same Processing Key. In which case, it would not reveal specific information about the compromise player, only a general idea of who leaked it. Of course, if every player out there calculates "09 F9..." for a MKBv1 disc, then this key would be completely annonymous.

As far as I understand the theory, the function used to calculate the Processing Keys from the Device Keys is a "one-way" function. So if you got the Device Keys, you can easily calculate the Processing Keys (of course you can only derive Processing Keys that are reachable from your Device Keys). But if you got a Processing Key, you cannot revert the calculation. So calculating the Device Key from a given Processing Key is impossible! Also the same Processing Key might have been derived form different Device Keys. Nevertheless they know which Device Keys are in use (of course they do). So they don't need to invert anything! In case a certain Processing Key is leaked, they simply check all the Device Keys they have given away so far. Then they make a list of the Device Keys from which the leaked Processing Key could have been derived. Exactly those Device Keys will be revoked and at the same time all players that used them! Obviously this procedure is useless if only one single Processing Key is used for all discs and players. In case that one single Processing Keys is leaked, they would have to revoke all players in existence. To make it work, they will have to use a lot of different Processing Keys! Then the same disc can be decrypted with various Processing Keys. Different players will use different Processing Keys to decrypt the very same disc (each player will use the Processing Key it can derive from it's Device Keys). So if one of the Processing Keys is leaked, they can find out which player leaked it. Or at least they can limit it to a few players. Only those "leaky" players will be revoked. From now on they will only use Processing Keys that the revoked players cannot derive from their Device Keys. And of course they won't use any of the leaked Processing Keys on new discs...

FoxDisc

17th December 2007, 20:39

As far as I understand the theory, the function used to calculate the Processing Keys from the Device Keys is a "one-way" function. So if you got the Device Keys, you can easily calculate the Processing Keys (of course you can only derive Processing Keys that are reachable from your Device Keys). But if you got a Processing Key, you cannot revert the calculation. So calculating the Device Key from a given Processing Key is impossible!

This is correct.

Also the same Processing Key might have been derived form different Device Keys.

This is not quite correct -it's close though. A PK matches a subset difference set. An S-D set includes a group of players, and every player in that group must calculate the same PK using the same device key. They can get the device key they require by having it assigned and stored at birth, or by having a higher device key in the binary tree from which they can calculate the lower device key they need using a one way function. An original device key is called a <wait for it> "device key." A lower device key calculated from a higher originally assigned device key is called a "subsidiary device key" Player 1's device key may be Player 2's subsidiary device key. They're really the same.

Nevertheless they know which Device Keys are in use (of course they do). So they don't need to invert anything! In case a certain Processing Key is leaked, they simply check all the Device Keys they have given away so far. Then they make a list of the Device Keys from which the leaked Processing Key could have been derived. Exactly those Device Keys will be revoked and at the same time all players that used them!

Close, but not quite right. All they know from a released PK is the S-D set that it matches. They know every player in that S-D set could calculate that PK. They don't have any more information about who the bad boy was. In the first MKBv1 the set was so large it included all players. Obviously they didn't want to revoke all possible players. They just revoked all the players they suspected. In later MKBs, the S-D sets for actually issued player IDs are tiny - and match only one or two players.

Obviously this procedure is useless if only one single Processing Key is used for all discs and players. In case that one single Processing Keys is leaked, they would have to revoke all players in existence. To make it work, they will have to use a lot of different Processing Keys!

Yes.

Then the same disc can be decrypted with various Processing Keys. Different players will use different Processing Keys to decrypt the very same disc (each player will use the Processing Key it can derive from it's Device Keys).

This is what they are doing now. An MKB has lots of entries for different S-D sets. What they are not doing is using a different MKB on every disk.

So if one of the Processing Keys is leaked, they can find out which player leaked it. Or at least they can limit it to a few players.

Only if the S-D set is small, and has only "a few players" which in recent MKBs is true. The AACSLA has control over the size and player members of the S-D sets defined in an MKB.

Only those "leaky" players will be revoked. From now on they will only use Processing Keys that the revoked players cannot derive from their Device Keys. And of course they won't use any of the leaked Processing Keys on new discs...

Correct. When they revoke a player ID, they just omit from MKBs on future disks any S-D set that contains the revoked players.

FoxDisc

17th December 2007, 20:44

a software/player has many device keys and not all are used so you don't need to update all players if one device key is revoked.

Device keys are not actually revoked. Player IDs are revoked. Players have a set of device keys that define the revoked player ID, so you could say that the set of DKs is revoked, but I don't think of it that way.

LoRd_MuldeR

17th December 2007, 20:53

Thanks for clarification, FoxDisc. Seems like I'm on the way to understand ^^

FoxDisc

17th December 2007, 21:03

When PowerDVD was given a new set of device keys, those keys will be able to calculate all needed Processing Keys so far. And it will have instructions (from the MKB it sees) for which Processing Key it will need to calculate.

Correct

Now with several different MKBs, we are starting to see the higher value of these device keys over the usual Processing Keys we have been looking for already.

Hmmmm, I don't really agree. A set of device keys defines the player ID. A revocation of that player ID means none of the DKs can ever be used. If they could, the revoked player would not be revoked.

Now the question is: with every revocation, does PowerDVD get a completely new set of device keys?

Yes. BTW, you can think of every version of PDVD as a different player, with a different ID.

If so, it would be a lot of work to find all the device keys, only to have them all revoked in 3 months. I would assume that the AACS LA would decide that the player to be revoked has been completely compromised, so they would make it so that none of that players device keys could be used for newer MKBs.

I agree.

So to answer my last question from my last post, a MKBv5 Processing Key will not decrypt MKBv4 titles.

It might, or might not. If it matched an S-D set of players, and none of the players in that set needed to be revoked then they probably would have used it again for v5. Realistically, though, if it was a leaked PK, then it was revoked.

Therefore, in order to do this, we will need to still find the MKBv4 Processing Key (if there is just one like before, is there?), or else find a lot of device keys from a player capable of decrypting MKBv5.

You only need one valid PK used on the v4 MKB to decrypt v4 discs. You only need one DK to calculate the PK, but you need the right one, or you need the correct subsidiary DK.

FoxDisc

17th December 2007, 21:17

I think everyone got caught up in the excitement of a single key that unlocks all the current discs. Most people think of the Processing Key as the main thing to find, and so far for MKBs 1 & 3, this was the case.

It's still true (in a sense) that the PK is the thing to find. All you need is one for each MKB version, and there are lots of PKs in each version that would work. Some match large groups of players, and some match small groups, but you only need one. Of course, finding that one is not easy.

People forget that liscensed players are not given a Processing Key, they are given several Device Keys, and from there they calculate whatever Processing Key is needed (if they can).

The difference between a DK and a PK is very slight. Think of the binary tree. It's got DK's assigned to the nodes. If you are a player and are assigned a DK for a node, you can process that DK with a one-way function to get a number that is three times as long as your starting DK. The middle third is the PK. The right third is the subsidiary DK for the node to your right and below your current node. The left third is the DK (more accurately the subsidiary DK) for the node to your left and below.

You just keep on working your way left right down the tree to get the PK you need by choosing the correct subsidiary DK and processing it again through the one way function.

As was said in the Understanding AACS thread, it could be that a different Processing Key is required for every disc within a MKB revision,

If there was a different MKB for every disc, then we'd call them MKB v6, v7, v8, etc. up to v1000 if there were a thousand released discs.

gioowe

17th December 2007, 21:25

Device keys are not actually revoked. Player IDs are revoked. Players have a set of device keys that define the revoked player ID, so you could say that the set of DKs is revoked, but I don't think of it that way.

You are correct. But I'm a programmer not a crypto analyzer so I have a very simplified view of the world. :)

Of cause you cannot revoke a device key. A device key is nothing else than a calculated hash from a higher level and always fixed. All the AACS LA does is at some node kick out that value and start with a new one. And that new value is unknown. MKB defines which nodes are correct processing keys and so I have to fall down from by "stolen" device key towards any of these processing keys. If nothing is in my way I got it. If something was kicked out on my way down the path I have a problem. I need another starting point, another device key.

From a programmer's view this is all you need. So a "revoked" device key is a key that cannot find a processing key or fell out of all subsets.

FoxDisc

17th December 2007, 21:26

MKBv4 still uses only 1 processing key. I checked all MKBv4 files that I could get and all use the same paths to calculate the processing key. There might be 2 different ones out there but I haven't found any.

Thanks for this info. As you know, there's nothing secret about which devices are revoked. You can directly figure that out by reading an MKB.

It would also be a waste of space in the MKB tree and it doesn't make the system more secure. If you cracked one disc (to be more precise: if you crack the software) you can get the "current" device key or processing key. The only difference is that if you have to make the device key public, the AACS knows its origin. The processing key is "anonymous". And as long as they revoke all device keys with each MKB iteration it doesn't matter.

A single DK is just as anonymous as a PK - no more, no less. It matches an S-D set, just like the PK does. (Run the DK through the one-way fn and it gives you the PK for that set.) Everyone in that S-D set could calculate the DK or has the DK from the start. No one outside the S-D set can. Of course if the set is tiny, perhaps with only one member, it's not very anonymous :devil:

FoxDisc

17th December 2007, 21:31

@gioowe
is it also possible to know how many other Processing Keys are being calculated for a particular MKB?

Yes, it's very easy. An MKB has multiple copies of the encrypted media key, one for each PK. Just count the entries.

By this I mean, how many different paths are described in MKBv4? I'm guessing by now that not all players are being directed to the same Processing Key, am I right?

You are right. The first MKBv1 had 512 paths, and 512 PKs, but only one for the software players. There are now lots of paths for the various software players - as required to revoke some and leave the others.

gioowe

17th December 2007, 21:43

I don't think that 2 players use the same S-D at this time. Would be quite stupid. Even if the S-D as 2-3 levels I think the AACS LA still uses only 1 player in that S-D, the rest are "fillers".

Again, to be more precise: Of cause there are a number of processing keys in MKBv4. Currently 524. The "position" of the processing keys is the same on all discs.

Here's the view of the MKBv4 tree
-------------------------------------------------------------------------------------------------------------------------------------
# | UV | | U-mask (Top->Bottom) | V-mask (Bottom->Top) | Path (from Root) |
-------------------------------------------------------------------------------------------------------------------------------------
001 | 02:00000003 | -- | 11111111111111111111111111111100 | 00000000000000000000000000000001 | LLLLLLLLLLLLLLLLLLLLLLLLLLLLLL.. |
002 | 03:0000002A | -- | 11111111111111111111111111111000 | 00000000000000000000000000000011 | LLLLLLLLLLLLLLLLLLLLLLLLLLRLR..* | S
003 | 05:00000028 | -- | 11111111111111111111111111100000 | 00000000000000000000000000001111 | LLLLLLLLLLLLLLLLLLLLLLLLLLR..*** | SC
004 | 03:00000046 | -- | 11111111111111111111111111111000 | 00000000000000000000000000000011 | LLLLLLLLLLLLLLLLLLLLLLLLLRLLL..* | S
005 | 02:00000055 | -- | 11111111111111111111111111111100 | 00000000000000000000000000000001 | LLLLLLLLLLLLLLLLLLLLLLLLLRLRLR.. |
006 | 02:0000005B | -- | 11111111111111111111111111111100 | 00000000000000000000000000000001 | LLLLLLLLLLLLLLLLLLLLLLLLLRLRRL.. |
007 | 03:00000069 | -- | 11111111111111111111111111111000 | 00000000000000000000000000000001 | LLLLLLLLLLLLLLLLLLLLLLLLLRRLR... |
008 | 05:00000068 | -- | 11111111111111111111111111100000 | 00000000000000000000000000001111 | LLLLLLLLLLLLLLLLLLLLLLLLLRR..*** | SC
009 | 03:00000091 | -- | 11111111111111111111111111111000 | 00000000000000000000000000000001 | LLLLLLLLLLLLLLLLLLLLLLLLRLLRL... |
010 | 03:0000009E | -- | 11111111111111111111111111111000 | 00000000000000000000000000000011 | LLLLLLLLLLLLLLLLLLLLLLLLRLLRR..* | S
011 | 05:000000A2 | -- | 11111111111111111111111111100000 | 00000000000000000000000000000011 | LLLLLLLLLLLLLLLLLLLLLLLLRLR....* | S
012 | 07:000000A0 | -- | 11111111111111111111111110000000 | 00000000000000000000000000111111 | LLLLLLLLLLLLLLLLLLLLLLLLR..***** | SC
013 | 17:00000080 | -- | 11111111100000000000000000000000 | 00000000000000000000000011111111 | LLLLLLLLL................******* | SC
014 | 17:00800001 | -- | 11111111100000000000000000000000 | 00000000000000000000000000000001 | LLLLLLLLR....................... |
...
525 | C0:00000000 | RR | 11111111111111111111111111111111
526 | 80:00000000 | R- | 11111111111111111111111111111111
-------------------------------------------------------------------------------------------------------------------------------------
Flags: S = stops before floor (complete revocation) SC = continues again below stop node (partial revocation)

FoxDisc

17th December 2007, 21:44

As far as I understand: In order to "break" a specific MKBvX, you will need to obtain the complete set of Device Keys from a player that is not revoked in MKBvX.

No, you only need one DK, but it has to be the right one.

This way you will be able to derive all the Processing Keys (from the Device Keys you have) that might be required for a MKBvX disc.

Only one PK is needed.

Getting only a few Processing Keys doesn't help at all, because even within the same MKB version you might require Processing Keys you don't have yet.

Any valid PK will decrypt the media key in that MKB. The MKB is just lots of copies of the media key encrypted by different PKs.

If you happen to get the Device Keys, you can derive all Processing Keys of MKBvX, so you can decrypt all the MKBvX discs (no matter which one of the Processing Key the individual discs requires).

A version number for an MKB tells you what S-D sets are defined on that MKB. It tells you what PKs/DKs are needed. Any single player ID will be in only one S-D set and be able to calc only one useful PK from a single one of his DKs.

you can be sure that they will revoke the player from which your Device Keys were leaked!

Yes they will.

So in the next MKB version after MKBvX you will suddenly require Processing Keys you can not derive from any of the leaked Device Keys!

Yes.

Once again you will need to obtain a complete set of Device Keys from a player that was not revoked in the latest MKB version.

You'd only need one, but it would have to be a new one. None of the old ones would work.

There will be no permanent hack...

This is the reason I responded here (sorry if my multiple posts seem excessive, I don't get here that often, and I'm particularly interested in this area). I can see two ways to get the permanent hack, but neither seems likely. First you could break the encryption. Anyone for a quantum computer? (This is very unlikely.)

Second, someone could leak the secret AACS master keys. There could even be a single secret master key, from which all other DKs, PKs, etc. could be derived. Again, this is unlikely, but it's at least interesting to contemplate.

gioowe

17th December 2007, 21:51

The AACS master key doesn't help. Can be "revoked" too.

FoxDisc

17th December 2007, 21:53

I don't think that 2 players use the same S-D at this time. Would be quite stupid. Even if the S-D as 2-3 levels I think the AACS LA still uses only 1 player in that S-D, the rest are "fillers".

I assume you're thinking of software players (i.e., non-KCD players). The S-D sets for the hardware players are huge. There are also many multiple member S-D sets even in the software branch as you can see from your post, but they may be mostly for future player IDs, not yet issued.

gioowe

17th December 2007, 21:55

Of cause. The software players are currently the "problem". How many are actually out there?

1) PowerDVD
2) WinDVD (?, quite hard to get from Corel right now)
3) ???

FoxDisc

17th December 2007, 22:01

The AACS master key doesn't help. Can be "revoked" too.

No, if there is single master key, it can calculate all issued DKs and all DKs that could be issued. If there isn't a single master key (and I think there isn't) then there are master keys for every node, and from these keys you can calculate all possible DKs present and future for every possible device.

An AACSLA "master key" (a key that is never issued and is only used to create keys that are issued) is the DK for the S-D set comprising all players below a node minus all players below that same node. As you can see that's the null set, so it has no members, so no real players ever get those keys. Nonetheless, the keys do exist. If you process those keys using the one way fn, you get the DKs for the two nodes below it and those keys are issued.

Another way to think of these keys is just the secrets used by AACSLA to create keys they issue. They must have some way to make them. They can't revoke their own secrets without revoking the whole system. If they ever leaked, the system would collapse.

FoxDisc

17th December 2007, 22:08

Of cause. The software players are currently the "problem". How many are actually out there?

1) PowerDVD
2) WinDVD (?, quite hard to get from Corel right now)
3) ???

I heard there was another one from Japan a month or so ago, but I haven't heard much about it. From the point of view of the MKB/AACS system, each version of PDVD/WDVD is a different player, but each copy of that version is the same player. The hardware players are different. Each player has a unique ID, even if it's the same model number from the same manufacturer, it gets a unique ID.

gioowe

17th December 2007, 22:16

I have some kind of thinking problem with this. I assumed that each S-D set starts with a new (randomly generated) key.

Our 9F-Key is M of level 32. We got the sub device keys of level 32 (AA 85 ...), 31 (CC BF ...), 30 (6A 5A ...), 29 (BD 2B ...), 28 (D6 76 ...) and the device key (53 BD ...) at level 27. From there we can calculate all 3^5 keys = 243. MKBv3 redefines subset of level 28 (05:0000001C) and that key changed! I could recalculate it from level 27 and actually both L und R sub-device keys are rewritten. So the tree changes with every MKB iteration beginning with each new S-D start.

Or am I missing something?

gioowe

17th December 2007, 22:36

got visual aid...

http://img248.imageshack.us/img248/4163/visualaidic0.png

FoxDisc

17th December 2007, 23:00

I have some kind of thinking problem with this. I assumed that each S-D set starts with a new (randomly generated) key.

They can't start all possible S-D sets with a randomly generated key (it would be a randomly generated DK). First, there are too many possible S-D sets. Second, you need the upper level DK, which matches an upper level S-D to produce the lower level subsidiary DKs (which match lower level S-D sets= same u-node number, but lower v-node) through the one way function.

You might be thinking that they could only generate the two highest level pair of uv defined S-D sets randomly for each u-defined node (and two v-nodes just below u-node).

Yes, they could do that, but why bother holding twice as many random numbers, when they can generate a single random number just above those two and use the one-way function to produce those two.

They could even have single random number for the root, use the one way for all u-nodes below that, but If I was the AACSLA, that would be too scary. If one number leaked the entire system would crash. By assigning a random number to each node, gigabytes of random numbers would have to leak to bring the whole system down.

the tree changes with every MKB iteration beginning with each new S-D start.

Or am I missing something?

I'm almost out of time, but I'll try a quick response, see if it helps. If not, we can try again. S-D set is a Subset Difference set. I think of the S-node as defining a subset of devices below the S-node and the D-node as being always below the S-node and defining a set of players below the D-node.

For clarity, the S-node is the u-node. The D-node is the v-node in AACS specs. The uv number defines the two nodes. The S-D set is all devices below S that are not below D.

A DK matches a single S-D set. If I give you S-node, I must also give you the D-node for the DK. Every possible S-node has a different AACS master key, that is never released. If you have it you could calc the two DKs for the two S-D sets that have that S node and the two D nodes one below it. No single device ever gets those two DKs. Every starting S-node produces a different set of related S-D sets though the one way fn, but different starting S-nodes produce DKs that have no relation to one another. Each S-node is on one of arnezami's "parking garage floors."

More later ......

Peer van Heuen

17th December 2007, 23:59

They could even have single random number for the root, use the one way for all u-nodes below that, but If I was the AACSLA, that would be too scary. If one number leaked the entire system would crash. By assigning a random number to each node, gigabytes of random numbers would have to leak to bring the whole system down.

They might be generating random roots - and if so, they will do that "on-demand", whenever a new root is required.
But I do think they would probably derive the keys by some one-way function (maybe AES-G3, maybe some other function).
After all: if both the one master key and the ("secret") one-way function leak, they can still change the strategy for the next round. So the whole system is not really down that way.
After all it does have some elegance if you can describe all possible root keys with one key and a well defined function - as opposed to storing them all in a huge DB.
But then again - we don't really care, how they do that, right?

The AACS master key doesn't help. Can be "revoked" too.

Could actually - but this would require an update of all players. This includes standalones, PS3, Xbox, .... I say again: all players.

Also, unless my imagination doesn't get the whole picture, all players would have to implement algorithms to cope with old and new device key sets (e.g. require 2 sets of device keys from then on).

That would result in quite a stir :-)

gioowe

18th December 2007, 00:02

Turtleggjp

18th December 2007, 03:40

gioowe

18th December 2007, 04:43

No.

static byte[] CalculateSubDeviceProcessingKey(byte[] DeviceKey, byte LeftMiddleRight)
{
byte[] Seed = { 0x7B, 0x10, 0x3C, 0x5D, 0xCB, 0x08, 0xC4, 0xE5, 0x1A, 0x27, 0xB0, 0x17, 0x99, 0x05, 0x3B, (byte) (0xD9 + LeftMiddleRight) };

byte[] SubDeviceProcessingKey = Utility.AACS_AES128(DeviceKey, Seed);

for (int I = 0 ; I < 16 ; ++I)
{
SubDeviceProcessingKey[I] ^= Seed[I];
}

return SubDeviceProcessingKey;
}

byte[] AACS_AES128(byte[] Key, byte[] Data);

Turtleggjp

18th December 2007, 07:13

Ok, I think I get that now. It's always fun trying to re-learn how to read C++ again. :rolleyes:

So then how does the whole "Parking Garage Floor Number" part come into play?

FoxDisc

18th December 2007, 15:31

They might be generating random roots - and if so, they will do that "on-demand", whenever a new root is required.

I got no sleep last night, so it's probably a mistake to disagree with Peer, but (at least for the hardware players) they've already issued full sets of Device Keys that would have to be generated from secret random roots. I don't see how they could generate them after they've issued the DKs. For software players, maybe they could revoke all existing players, then make any changes they want to the software branch.

But I do think they would probably derive the keys by some one-way function (maybe AES-G3, maybe some other function).

This is certainly possible. It just struck me as more secure to use a large database of random numbers.

After all: if both the one master key and the ("secret") one-way function leak, they can still change the strategy for the next round.

I don't follow this (actually, I'm just politely saying I don't agree). I see several possible ways they could have done this.

The most elegant way is to use a single secret master key at the root of the binary tree. Using the one way function nine times (2^9) gives you the secret key at the top of each one of the original 512 subtrees in the original MKBv1. Only one of those subtrees is the software branch.

Second option is to choose 512 secret random unrelated keys, one for the top of each of those branches. Last option is to choose a secret random number for every possible S-node.

I don't see any way to change the secret key at the root of any subtree without changing previously assigned DKs for devices in that subtree. And if you change DKs, you've got problems for previouisly issued discs and MKBs. .

[re revoking secret master key at root of entire system] this would require an update of all players. This includes standalones, PS3, Xbox, .... I say again: all players.

Also, unless my imagination doesn't get the whole picture, all players would have to implement algorithms to cope with old and new device key sets (e.g. require 2 sets of device keys from then on).

That would result in quite a stir :-)

Yes, I agree. This would basically require restarting the whole system from scratch, with some mechanism for dealing with the discs issued with MKBs under the old system.

FoxDisc

18th December 2007, 16:06

S-D set (defined by MKB) is clear. How a device key is "revoked" (better removed from all S-D sets) too.

What I not quite understand is why they define new S-D sets below another S-D set. For instance in MKBv3.

They don't. Each different S-node is on a whole separate plane (or parking garage floor per arnezami). The S-node defines the root for a subtree containing DKs and PKs for that S-node. All the DKs and PKs for any given S-node are related, but are unrelated to the keys for any different S-node.
Any other S-node defines an entirely different and independent subtree. In arnezami's analogy, an S-node (u-node in AACS terminology) defines a separate parking garage floor.

DKs (and subsidiary DKs that you can calculate) are assigned to the D-node on the parking garage floor (subtree) defined by the S-node. Each node has multiple DKs (every time it's a D-node), but defines only one subtree/parking garage floor.

I think of it this way - The AACSLA has a secret key (either secretly generated or randomly selected) for each S-node. Take an S-node S1. From the secret key for S1, they can generate all DKs for all possible S1-D sets, i.e., all sets rooted at S1 having a difference set D below S1. If you are a device below S1, you will get some of these DKs (you get one DK for every branch off the upward path from you to S1). If you are not below S1, you get none of those DKs.

(From the above comments, you can derive the number of DKs that each player starts with.)

To revoke a device in a new MKB, you make sure he's not below any S-nodes in the S-D sets of your new MKB or if he is, you make sure he's also below the D-node.

FoxDisc

18th December 2007, 16:24

Wow, this thread exploded...

Quick clarification on how the whole "driving" proceedure works. If I understand it correctly, each player starts with its 128-bit device key (one of many it has), and does the magic AES algorithm (publicly known, no mystery here) and what comes out is a 384-bit result (3x as large). From here, you either:

A. Select the first 128-bits and repeat.
B. Select the last 128-bits and repeat.
C. Select the middle 128-bits as your processing key and you are done.

Did I get that right? Is that all it takes to start the process? It sounded like something else was needed to start (like a "floor number" in the "parking garage").

Well gioowe said no, but I'd say yes -that's basically right, with lots of details and add'l complexity. You later asked about the "parking garage floor." That's the same thing as the S-node (u node in AACS-speak) That comes in when you choose the correct starting DK.

The MKB defines lots of S-D sets (and has one encrypted copy of the media key for each set.) You have to find the set you are in. It's the one where you are below the S-node, but not below the D-node (v-node in AACS-speak).

The S-node defines the parking garage floor. The higher the S-node, the larger the floor. Each device has one DK for each level on every floor that it has access to. (It has access to a floor if it is below the S-node) So for the largest floor (like in MKBv1) there are 22 DKs (out of the 253 it started with) to consider. (A DK is assigned to a D-node on an S-floor.)

The device just looks at each S1-D1 set defined in the MKB. It asks if it is below S1, if yes, it asks if it is below D1. If no, then it knows it has the required DK, either originally assigned (it's located at D1 on the S1-floor) or it can calculate it from a DK on floor S1 that is above D1.

If it has to calc the DK, it uses the basic ABC procedure you gave above to come up with the DK for S1-D1, then uses the ABC procedure again to get the PK it needs.

edit: I hope the terms "level" and "higher" when referring to a the nodes of a single binary subtree on a single floor aren't too confusing in the context of the parking garage floor analogy where floors (and therefore different subtrees) can also be thought of as being higher or lower. You should be able to figure them out from the context. Usually the floor you are dealing with is defined early on by the S-node.