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. |
4th March 2007, 15:13 | #121 | Link |
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. |
4th March 2007, 15:35 | #122 | Link | |||
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
Quote:
Quote:
|
|||
4th March 2007, 16:00 | #123 | Link | ||
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
Quote:
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. |
||
4th March 2007, 16:16 | #124 | Link | |
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
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. |
|
4th March 2007, 16:57 | #125 | Link | ||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
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:
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. |
||
4th March 2007, 17:30 | #126 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
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. |
|
4th March 2007, 17:40 | #127 | Link | ||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
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:
|
||
4th March 2007, 18:28 | #128 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
Without additional SKs, you can't get the decryption of the Segment Keys done, and without those, the Title can't be fully decrypted. |
|
4th March 2007, 18:45 | #129 | Link | ||
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
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:
Last edited by xyz987; 4th March 2007 at 20:15. |
||
4th March 2007, 18:53 | #130 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
|
|
4th March 2007, 20:33 | #131 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
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. |
|
4th March 2007, 21:19 | #132 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
"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. |
|
5th March 2007, 02:45 | #133 | Link |
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. |
5th March 2007, 04:19 | #134 | Link |
Registered User
Join Date: Jan 2007
Posts: 274
|
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.
|
5th March 2007, 15:15 | #135 | Link | |
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
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. |
|
5th March 2007, 21:48 | #136 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
To avoid duplication, i will answer the rest on another post. |
|
5th March 2007, 22:20 | #137 | Link | |
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
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. |
|
5th March 2007, 22:59 | #138 | Link | |||
Registered User
Join Date: Jan 2007
Posts: 274
|
Quote:
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:
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. |
|||
6th March 2007, 00:14 | #139 | Link | |||||
Registered User
Join Date: Dec 2006
Posts: 142
|
Quote:
Quote:
Quote:
Quote:
Quote:
Last edited by xyz987; 6th March 2007 at 00:17. |
|||||
6th March 2007, 02:49 | #140 | Link | |||
Registered User
Join Date: Jan 2007
Posts: 274
|
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:
Quote:
Quote:
|
|||
Thread Tools | Search this Thread |
Display Modes | |
|
|