Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Decrypting

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th March 2007, 15:13   #121  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
@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.

Last edited by arnezami; 4th March 2007 at 15:43.
arnezami is offline   Reply With Quote
Old 4th March 2007, 15:35   #122  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
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.

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

Quote:
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 is offline   Reply With Quote
Old 4th March 2007, 16:00   #123  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by arnezami View Post
@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).

Quote:
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.
xyz987 is offline   Reply With Quote
Old 4th March 2007, 16:16   #124  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by xyz987 View Post
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.

Last edited by arnezami; 4th March 2007 at 16:22.
arnezami is offline   Reply With Quote
Old 4th March 2007, 16:57   #125  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by arnezami View Post
@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.

Quote:
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.
FoxDisc is offline   Reply With Quote
Old 4th March 2007, 17:30   #126  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
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.
xyz987 is offline   Reply With Quote
Old 4th March 2007, 17:40   #127  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
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.

Quote:
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 is offline   Reply With Quote
Old 4th March 2007, 18:28   #128  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
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.
FoxDisc is offline   Reply With Quote
Old 4th March 2007, 18:45   #129  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
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.

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

Last edited by xyz987; 4th March 2007 at 20:15.
xyz987 is offline   Reply With Quote
Old 4th March 2007, 18:53   #130  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
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?
xyz987 is offline   Reply With Quote
Old 4th March 2007, 20:33   #131  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
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:

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.
FoxDisc is offline   Reply With Quote
Old 4th March 2007, 21:19   #132  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
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 is offline   Reply With Quote
Old 5th March 2007, 02:45   #133  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
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).

Last edited by xyz987; 5th March 2007 at 03:01.
xyz987 is offline   Reply With Quote
Old 5th March 2007, 04:19   #134  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
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 is offline   Reply With Quote
Old 5th March 2007, 15:15   #135  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by FoxDisc View Post
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.
FoxDisc is offline   Reply With Quote
Old 5th March 2007, 21:48   #136  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
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 is offline   Reply With Quote
Old 5th March 2007, 22:20   #137  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
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).

Last edited by xyz987; 6th March 2007 at 00:15.
xyz987 is offline   Reply With Quote
Old 5th March 2007, 22:59   #138  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
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.

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

Quote:
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.
FoxDisc is offline   Reply With Quote
Old 6th March 2007, 00:14   #139  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
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.

Quote:
If the attacker says "This SK can be used to decrypt SHREK 7"
Attacker just say "this is an uncompromised SK"

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

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

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

Last edited by xyz987; 6th March 2007 at 00:17.
xyz987 is offline   Reply With Quote
Old 6th March 2007, 02:49   #140  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
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.

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

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

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

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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

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

Forum Jump


All times are GMT +1. The time now is 13:55.


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