Understanding AACS (including Subset-Difference)

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

Originally Posted by FoxDisc

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]

Originally Posted by FoxDisc

@Erazor and xyz

Perhaps we can agree on some basics. Look at the graphic:


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]

Originally Posted by xyz987

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.

1. 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.
2. 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.
3. 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.
4. 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]

Originally Posted by xyz987

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]

Originally Posted by arnezami

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]

Originally Posted by FoxDisc

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]

Originally Posted by 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)

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]

Originally Posted by xyz987

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]

Originally Posted by xyz987

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]

Originally Posted by FoxDisc

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]

Originally Posted by FoxDisc

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]

Originally Posted by FoxDisc

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

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 (oct 4 2006) was released before they found and fixed the "security issues to support multi-time tracing" in the following paper (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.

1. Each participant signs up for the project (on some website or something).
2. 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.
3. 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.
4. Goto 3 (until all sequence keys are shared)
5. 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).
6. 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]

Originally Posted by arnezami

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 (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 it seems AACS really can be beaten.

[FoxDisc]

Originally Posted by arnezami

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]

Originally Posted by FoxDisc

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.