New Processing Key found!! (MKB v3 is now open)

[aKzenT]

Originally Posted by Peer van Heuen

The MKB version number is mainly used for synchronizing revocation lists. This applies to HRLs/DRLs.
From my understanding, the version number wouldn't have to change at all if the only news is some revoked device keys (effectively revoking a processing key if you like).

So they may just have forgotten some Host IDs on v2 (after all, the list of revoked host certificates in v3 is fairly long).

Good point. However even if it was because of some new revoked device keys, it would make sense for the AACS LA to give it a new version number to distinguish the two versions internally.

[Elias]

What the hell is the point with cracking and releasing AACS keys if it can be updated with new keys?

[KenD00]

Originally Posted by FoxDisc

Was it my comment that they'd "be used for only a moment on small areas of the data" that you thought was wrong?

Yes.

Originally Posted by FoxDisc

I think the reason they might start using SKs is to break the current software and database schema here and to make it harder to find the multiple VVUKs needed for decryption. If their purpose is to hide those keys, I'd expect them to make short brief usage.

I think that too. But if these sections are only small, lets say 1 second, people might get the idea "hey, why not just skip that part, the movie is still watchable". I just wanted to show that this might not work.

However i'm not sure if they will use SKs very soon, its quite some work to encode multiple angles, especially for BluRay the authoring effort seems quite high. Even today DVDs use multi angles very rarely.

[FoxDisc]

Originally Posted by KenD00

if these sections are only small, lets say 1 second, people might get the idea "hey, why not just skip that part, the movie is still watchable". I just wanted to show that this might not work.

However i'm not sure if they will use SKs very soon, its quite some work to encode multiple angles, especially for BluRay the authoring effort seems quite high. Even today DVDs use multi angles very rarely.

I basically agree with your comments. The SKB system was designed as a type of watermark, not for encryption. There are up to 32 segments per title, so it could be pretty annoying to "just skip that part," particularly if they tried to do that at the critical emotional highlights of a movie, but I can see your point. All of that takes more authoring effort. I think we just have to wait and see.

[mlansell]

Originally Posted by Elias

What the hell is the point with cracking and releasing AACS keys if it can be updated with new keys?

Er, so that they have to release new keys? Since they have to give 90 days notice, that means no more tha 4 updates per year.

If your real question is "why release the keys" then I guess that depends on how the system works. If it is possible to find and use a key without the AACS being able to find out which key it is, then it would be better for the "Masters of Keyfinding" to keeep their discoveries to themselves (or at least only circulated among the people writing the decrypting apps).

If simply using a key means the AACS-LA can find out which one it must be, then not releasing it serves no purpose.

Mal

[greath]

One thing I was wondering was, the AACS LA will need to either reverse engineer AnyDVD to find out the key it is using, or to construct a MKB with some particiular values so that they can find out which C-value the programme uses. However, if I were writing AnyDVD, I would CRC each MKB and if it's not matching an officially released MKB then do nothing. This way there would be no way for the AACS to "probe" my software. True, there would be a need to update the decrypting programme when a new MKB is released, but then there would be a need anyway as the processing key will likely have been revoked.

[arnezami]

Originally Posted by greath

One thing I was wondering was, the AACS LA will need to either reverse engineer AnyDVD to find out the key it is using, or to construct a MKB with some particiular values so that they can find out which C-value the programme uses. However, if I were writing AnyDVD, I would CRC each MKB and if it's not matching an officially released MKB then do nothing. This way there would be no way for the AACS to "probe" my software. True, there would be a need to update the decrypting programme when a new MKB is released, but then there would be a need anyway as the processing key will likely have been revoked.

This is subtle and hard to explain. But a different MKB version means that the subset difference record is different. But two MKB files with the same version (but of two different movies) are not the same: the C-values (encrypted Media Keys) are never the same (something I also mistakenly assumed back in feb, evdberg corrected me).

The point: they can create special discs on which they use the same/latest MKB version but just alter the C-values. The only thing they would have to do is to look at the decypted content (which is different according to the keys used by AnyDVD). There is no hiding here.

Regards,

arnezami

[shevegen]

I think they hate us all

[psme]

If AnyDVD uses a VID database ONLY, then there would be nothing to trace, right? When it encounter a new disc, it can upload the encrypt table and later update the database.

regards,

Li On

[bourke]

Sounds like a plan :-)

Next processing key someone finds just sit back and make an automatic VUK uploading online database :-)

If someone wants a disc that aint in there, simply have them snail mail you the disc :-)

[awhitehead]

Originally Posted by bourke

Sounds like a plan :-)

Next processing key someone finds just sit back and make an automatic VUK uploading online database :-)

If someone wants a disc that aint in there, simply have them snail mail you the disc :-)

SKBs are designed to specifically figure out which keys were comporomised in event of a black box attack. An example of such a black box would be a website, that allows a user to select and upload the MKBROM.AACS file from an HD-DVD disc, and produce a VUK.

[lightshadow]

In regards to when AACS LA will revoke the second Processing Key...

Perhaps AACS LA have a deal like Apple, that they are forced to fix any attack within a fixed number of weeks?

I think Apple's period is 3 weeks. If Apple haven't fixed the attack, then Apple have to pay huge amount of cash to the record companys.

If such deal exist, then it is not enough for AACS LA to just issue now Processing Keys. They will then be forced fix the attack.

That being said, it could be, that AACS LA have been working on SK since the first attack, and this second Processing Key was just to buy some time...

[aKzenT]

Originally Posted by awhitehead

SKBs are designed to specifically figure out which keys were comporomised in event of a black box attack. An example of such a black box would be a website, that allows a user to select and upload the MKBROM.AACS file from an HD-DVD disc, and produce a VUK.

I don't think that is true. While SKBs are designed to prevent black box attacks, a webservice that gives you a VUK if you upload a MKBROM.AACS will never use SKBs (they are not in this file). However if they start using SKs, your webservice simply can't give you all information needed to decrypt the WHOLE movie by just looking at the MKB.

Also, if this service would accept any MKB, they could simply trace the player by trying different subset difference records.
And even if you create a hash of the Subset Difference record and only allow specific versions, they could still create a fake MKB where they use a different media key for each subset difference and see which one is used to get the VUK.

Correction: The last sentence is incorrect. While the AACS LA could do that, your webservice could easily detect that by verifying the media key with the verify media key record in the mkb. They could do the same however with multiple attacks, where some C values have the correct encrypted media key and some have not.

[greath]

Originally Posted by arnezami

This is subtle and hard to explain. But a different MKB version means that the subset difference record is different. But two MKB files with the same version (but of two different movies) are not the same: the C-values (encrypted Media Keys) are never the same (something I also mistakenly assumed back in feb, evdberg corrected me).i

Yes, that would make sense. I'm new to all this clandestine activity:-) If each MKB version produced the same media key because the C-values and the processing key were identical then only a media key would be needed to unlock all discs with that MKB version and the AACS would have no clue of the processing key used and hence the device key.

BTW, I guess this means that the replicators must either get a MKB "template" from AACS and they must work out the C-values. Or, the AACS issues for each disc a MKB and gives the replicator a media key. They must have to do something for their $1,500 a disc licence fee...........

[Johhn]

Originally Posted by lightshadow

In regards to when AACS LA will revoke the second Processing Key...

Perhaps AACS LA have a deal like Apple, that they are forced to fix any attack within a fixed number of weeks?

I think Apple's period is 3 weeks. If Apple haven't fixed the attack, then Apple have to pay huge amount of cash to the record companys.

If such deal exist, then it is not enough for AACS LA to just issue now Processing Keys. They will then be forced fix the attack.

That being said, it could be, that AACS LA have been working on SK since the first attack, and this second Processing Key was just to buy some time...

It isn't like Apple. Apple offer a drm cloaked download service and they can deliver updates through that service at no notice. With aacs, revocation and blacklisting is by means of data carried on new disks. They therefore need players and drives to be updated before new disks are released, and so there is a notice provision in the licensing arrangement which currently entitles drive and player makers 90 days notice before new disks should appear.

That involves serving notice on the player and drive manufacturers who then have 90 days before the new disks will appear. They will need to develop the upgrades/updates etc. and have them out before the disks are released. Also, replicators should also have the information before the 90 days to allow for manufacturing and distribution lead times. In theory, disks released within the 90 day limit should not have the latest data on them, and those released afterwards should. So a situation like Matrix where a set of disks has different versions should not really have arisen. Maybe there was a blunder at the replicators, or the timetabling of the procedures does not easily handle a situation where several different disks are made over a period of time, but they are released as a set.

Also, the aacsla is not an independent enterprise selling services to the studios. It is a consortium of the studios, and I doubt if the same sort of commercial pressure exists that would apply to Apple.

In addition to changing the keys, those players were supposedly changed to make it more difficult to glean keys, and thus "fix the attack" - but it is difficult to draw inferences.

As regards the SK regime, that is primarily for tracing the source of gleaned keys and is not a layer of extra security to make key extraction significantly more difficult. It remains to be seen whether it also has that effect.

One problem the LA have is that although they can determine where the keys came from, they will not necessarily know how they were extracted. That can make decision making tricky as there is little value in blacklisting a key leaked via a software player compromise, if you don't also try and plug the compromise by which it came.

[wilmac]

Originally Posted by Johhn

It isn't like Apple. Apple offer a drm cloaked download service and they can deliver updates through that service at no notice. With aacs, revocation and blacklisting is by means of data carried on new disks. They therefore need players and drives to be updated before new disks are released, and so there is a notice provision in the licensing arrangement which currently entitles drive and player makers 90 days notice before new disks should appear.

That involves serving notice on the player and drive manufacturers who then have 90 days before the new disks will appear. They will need to develop the upgrades/updates etc. and have them out before the disks are released. Also, replicators should also have the information before the 90 days to allow for manufacturing and distribution lead times. In theory, disks released within the 90 day limit should not have the latest data on them, and those released afterwards should. So a situation like Matrix where a set of disks has different versions should not really have arisen. Maybe there was a blunder at the replicators, or the timetabling of the procedures does not easily handle a situation where several different disks are made over a period of time, but they are released as a set.

Also, the aacsla is not an independent enterprise selling services to the studios. It is a consortium of the studios, and I doubt if the same sort of commercial pressure exists that would apply to Apple.

In addition to changing the keys, those players were supposedly changed to make it more difficult to glean keys, and thus "fix the attack" - but it is difficult to draw inferences.

As regards the SK regime, that is primarily for tracing the source of gleaned keys and is not a layer of extra security to make key extraction significantly more difficult. It remains to be seen whether it also has that effect.

One problem the LA have is that although they can determine where the keys came from, they will not necessarily know how they were extracted. That can make decision making tricky as there is little value in blacklisting a key leaked via a software player compromise, if you don't also try and plug the compromise by which it came.

Nice, good food for thought...

[xyz987]

Originally Posted by Johhn

As regards the SK regime, that is primarily for tracing the source of gleaned keys and is not a layer of extra security to make key extraction significantly more difficult. It remains to be seen whether it also has that effect.

Yes, that's right, it is *not* an extra layer. So it is possible LA never uses SKs. There is no need for traitor tracing because all the leaked keys are published.

One problem the LA have is that although they can determine where the keys came from, they will not necessarily know how they were extracted. That can make decision making tricky as there is little value in blacklisting a key leaked via a software player compromise, if you don't also try and plug the compromise by which it came.

Far interesting. They have a traitor tracing system, but they don't have a hole tracing system.

The 90 days notice and the above, altogether, make things far difficult to LA.

[awhitehead]

@aKzenT
You are correct that in order to decrypt SKBs I also need SKB.AACS and SKF.AACS. My point is that if my hypothetical Black Box server v2.0 accepts MKBROM.AACS, SKB.AACS and SKF.AACS (Last two if available/applicable), and generates a VUK, and there are more then a handful of AACS licensees, then yes, in order to fingerpoint, AACS LA will probably have to start using SKBs.

Currently the menthod of trying a bunch of MKBs works because there are only a handfull of keys out there. I can think of only Cyberlink, Nero and Intervideo as having the device keys that can use the MKB to generate a valid VUK, and Toshiba (on HD-DVD side) and 3 or 4 Blu-Ray vendors on the Blu-Ray side, that have the KCD style device keys.

If AACS takes off, and there are 30 or 50 licensees, just brute-forcing will no-longer works, esp if my hypothetical Black Box Server does something to rate-limit the number of VUKs it will generate per "customer" per day. If you need to do 30 tries to figure out which device key I use, and I tell you that you can run the test once every 3 days.... By the time you know, I will probably be on a new key.

@greath AACS MKB costs 1.5K USD, and another two hundred dollars for electronic delivery. Additionally,there is a one time cost between 3K and 10K USD upon setting up the contract. source.
You'd think that the studios are paying because they feel that they will lose more then at least 1700 USD per movie due to casual copying, etc. Guarantee to the studios about fixing something in X # of days is silly - if the disc encryption is broken, it is broken, and short of re-releasing the disc, you can't change that fact. If you are a studio that made 20K discs of "Inside Weyland-Yutani", and sold 2K copies world wide, you think that being told that "Yeah, we will give you your next MKB for the re-issuing of this title for free" would help?

("Inside Weyland-Yutani" is a made up name, I have no idea if a movie by that name exists)

[Johhn]

I imagine that the sales of some movies are so low that they would have been better to master them without aacs and give them away. Well maybe it isn't that bad, but it isn't very good either.

Take a look at the following article about sales:

http://www.tvpredictions.com/whip060207.htm

[Galileo2000]

Originally Posted by Johhn

I imagine that the sales of some movies are so low that they would have been better to master them without aacs and give them away. Well maybe it isn't that bad, but it isn't very good either.

Take a look at the following article about sales:

http://www.tvpredictions.com/whip060207.htm

Interestingly enough, Circuit City had Matrix Trilogy HD DVDs for $19.99.

For 3 days.

All the orders in quantity of 1 were completed.

Don't believe it was a price mistake.

Looks like more like the guerilla attack from the HD DVD camp.

People who didn't have the HD DVD players were buying and THEN getting HD DVD players.

Things are going to be interesting, but my bet BD will lose.

Anyway, we have about a hundred releases to enjoy soon.

Thanks to all.