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

[arnezami]

I guess its official now. :D

The new Processing Key was posted by BtCB on freedom to tinker (http://www.freedom-to-tinker.com/?p=1155#comment-367359) about a week ago (release day +1).

its:

45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

Save it. Store it. :)

This opens up all newly released (and many to be released) HD DVD and Blu-ray discs. Wanna understand: go here (http://forum.doom9.org/showthread.php?t=124505).

Regards,

arnezami

PS. I strongly advise everybody who knows how it was retrieved not to talk about it publicly.

-- Btw: To get a VUK you first need to get the Volume ID of the disc (there are several ways). If you have that you can use aacskeys with this Volume ID as input. --

[zeroprobe]

damn I need a new jacket.

Who dares to post it on digg lol. Would surely start another riot.

[Zotty]

Nice one, thank you!

Oooh these are the moments I hate going to work. I'd rather stay home and play around with this new 'toy' :D

[bob0r]

BtCB Says:

May 23rd, 2007 at 4:02 am
Here’s mine:

45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

What are the odds that this is the new processing key?

...


Priceless :D

[FoxDisc]

PS. I strongly advise everybody who knows how it was retrieved not to talk about it publicly.
BtCB made it clear where it came from. He used Ed Felten's automatic key assignment proggie on that web page. Wow! It's amazing that he happened to be assigned a valid PK! I wonder what the chances are that it will happen again..... say shortly after the next revocation.:)

[mixanobios]

i wonder if i can get next week's lotto numbers using the same tool :D

[zeroprobe]

aacs la must be really unlucky, whats are the odds of that happening lol.

[FoxDisc]

I strongly advise everybody who knows how it was retrieved not to talk about it publicly.

On a more serious note, let's look at what the disclosure of this PK tells the AACS LA about where it came from:

The AACS LA knows the content of the last MKB (can anyone tell me where the "V3" number comes from? Is it built into the MKB?) The last MKB had only 15 S-D sets that matched 15 DKs and 15 PKs (these 15 are in the software branch - there are another 511 non-software branches). Presumably, this PK is one of the 15. Some of the 15 are as small as a single device. One of them is huge (about 2^22), but I strongly suspect that this is not that big set. I'll guess that this PK is one of the other 14, all of which fall within 128 devices. By matching this PK to the MKB released, they narrow the device down, and may have pinpointed it.

Even if the group that matches this PK is not a single device, they may be able to narrow it further. A processing key corresponds to a device key. A device key corresponds to a specific subset difference set, i.e., a specific node on a specific "floor" of the entire tree. The LA knows the matching floor and node numbers. They also know that the matching DK can only be calculated from DKs on this floor that are on the binary tree above this node. Finally they know which DKs have been given out. They may be able to narrow the device down if not all DKs that can calculate this PK have been assigned.

I'd like to know which of these groups match the PK just disclosed. It's something the LA already knows, and it's something that could be calculated with a moderate bit of effort.


umask:uv number
05:0000001C
03:0000002A
05:00000028
03:00000046
02:00000049
02:0000004F
02:00000055
02:0000005B
03:00000069
05:00000068
02:00000085
02:0000008B
04:00000091
07:00000090
17:00000080

[mrazzido]

wow very great! i hope i get some days new european bluray disc with new keys. then i check this.

[Bystander]

Attempting to decrypt my Pirates of the Caribbean: Dead Man's Chest with new info.

New Proessing key works. However, it is required to copy the Certificate folder as well as BDMV folder.

Used fetchvidbr to get vid, then inserted the new processing key into the simple.txt file for aacskeys. Then used aacskeys to calculate the hash and vuk while using the vid in the command line args. Then inserted into DumpHD database and presto.

[Sirber]

already on digg :)

http://digg.com/security/455FE10422CA29C4933F95052B792AB2_AACS_Processing_Key

[FoxDisc]

The new Processing Key was posted by BtCB on freedom to tinker about a week ago (release day +1).

This is a side note to Slysoft, who I expect monitors this forum. It's in the interest of Slysoft to disclose the Processing Key they have uncovered as soon as they release their software.

If Slysoft does not release the PK they are using, someone here will sooner or later uncover and release a PK. Notice how quickly BtCB had this PK. He published it on release day +1, and may have had it before then. If BtCBs PK is the same one that Slysoft is using in AnyDVD, there's no harm, but what if they are different? If there are two holes, both will get plugged in the next round of cat vs. mouse (IMHO, the LA looks like the poor mouse right now.) It would be better for Slysoft not to have both holes plugged. They may even have found the same PK released here, but used another one and by not publicly disclosing the one they use in their software, they lose this PK as a backup for the next round.

I'd also like to point out that it's in the best interest of fair use lovers here for Slysoft to copy and use any PK released here, if it's released before Slysoft releases their own software, and for any PK released by Slysoft to be used in software released here. No one should complain about such behaviour from Slysoft or open source software authors - for the same reason - there's just no benefit to having two or more PKs released and two or more exploits closed on every round.

My .02

[evdberg]

@FoxDisc,

According to my (updated) MKB tool the media key is found at entry 4 (zero-based, so the 5th entry).

can anyone tell me where the "V3" number comes from?
It is stored in a long word at offset 8 in the beginning of the file (in the 'Type and Version' section to be precise).

[FoxDisc]

According to my (updated) MKB tool the media key is found at entry 4 (zero-based, so the 5th entry).

Thanks.
Would that be: 02:00000049? ( I think the order is correct)

00000049 points to a revoked node on the lowest level (the device level) in the V3 MKB (PK/DKs are located at the difference part of the S-D sets - i.e., at revoked device nodes or above groups of revoked devices - devices don't have the PK/DK associated with their own device number.) The only device that has that PK/DK is the adjacent (to the right) 0000004B device (the 02: part tells us this floor has only 2 devices and one is revoked). That means the LA knows exactly where this PK came from. I suspect some software player company got another nasty phone call from an irate LA exec.

I've been trying to figure out BtCBs "hint" of uv:00000047. That points to one of a pair of revoked devices, but the associated PK/DK is not used in the MKB V3. My guess as to the "hint" is that it is the device number of one of the revoked software players, but maybe I'm missing something.

[Fahzuu]

I've been trying to figure out BtCBs "hint" of uv:00000047. That points to one of a pair of revoked devices, but the associated PK/DK is not used in the MKB V3. My guess as to the "hint" is that it is the device number of one of the revoked software players, but maybe I'm missing something.

...or maybe it's just a typo and should read 00000049...

[Galileo2000]

I've been trying to figure out BtCBs "hint" of uv:00000047. That points to one of a pair of revoked devices, but the associated PK/DK is not used in the MKB V3. My guess as to the "hint" is that it is the device number of one of the revoked software players, but maybe I'm missing something.

Is it possible he is pointing to the player tampering with which gave him a key?

[arnezami]

Its another one of those good days :D.

Here is a screenshot of aacskeys working with the new Processing Key:

http://img262.imageshack.us/img262/3666/matrix2dr9.png

KenD00 and I are working on a combined program of DumpHD and aacskeys (basicly having the latter being accessed as a backup in case a VUK is not found in the local database and as a source of newly found vuks). Prototype is working :). Still quite a bit to do. But I will now have more time for programming again...

Ooh. And for those (other) "key finders" out there: we still need a Host Private Key for (really) easy Volume ID retrieval. ;) That would be great. For aacskeys users: keep in mind the current version of aacskeys does not give a proper error when trying and failing to retrieve a Volume ID: but if the VID is all 00's then you know you first have to get the Volume ID yourself and then input it into aacskeys (like I did above).

Btw: the uv 47 is a typo : it should be 49 (as can be seen in the above screenshot).

Regards,

arnezami

[FoxDisc]

Is it possible he is pointing to the player tampering with which gave him a key?
No, only the 4B player has that key. Arnezami says it was a typo, which makes sense.

[FoxDisc]

Btw: the uv 47 is a typo : it should be 49 (as can be seen in the above screenshot).

I notice that the aacskeys screenshot is giving the uv number, which includes the path and the v-mask encoded together, but I don't see the u-mask. The u-mask gives the "floor" that this node is on and is necessary to figure out how many other devices are in the set that has access to this PK. Unless I'm missing something, you might want to add it - it's only one byte value. I'm used to the 02:00000049 format where the u-mask precedes the uv number and is separated by a colon.

[jetsetter]

Priceless :D

Yes. Nice way to post that. I suppose future keys will require ever-more-subtle leaks onto the webs.

[Revgen]

KenD00 and I are working on a combined program of DumpHD and aacskeys (basicly having the latter being accessed as a backup in case a VUK is not found in the local database and as a source of newly found vuks). Prototype is working :)

Gimme! Gimme! Gimme! :D

Thanks a lot to both of you for the work you do.

[abcx]

Awesome! The fight against AACS continues. I'm proud of you guys!

[atzplzw]

Hehe! That took quite a while until someone noticed...

[Galileo2000]

OK, what am I doing wrong?

- put a new key into txt file ProcessingDeviceKeysSimple.txt as the only entry w/o spaces;
- started vid.exe and got the correct VID from Matrix 3;
- started aacskeys with the drive letter and VID from vid.exe in the command line.

No matter what I am getting "Error opening Media Key file f:\AACS\MKBROM.AACS".

I am using aacskeys.exe 2.6. And yes, I enter the correct VID in the command line, I am pretty sure.


Totally drives me nuts.

Suggestions are welcome, thanks.

[arnezami]

OK, what am I doing wrong?

- put a new key into txt file ProcessingDeviceKeysSimple as the only entry w/o spaces;
- started vid.exe and got the correct VID from Matrix 3;
- started aacskeys with the drive letter and VID from vid.exe in the command line.

No matter what I am getting "Error opening Media Key file f:\AACS\MKBROM.AACS".

Totally drives me nuts.

Suggestions are welcome, thanks.

Looks like some file access problem (maybe opened by anothe program? anydvd running?). aacskeys version? What happens if you copy the AACS directory into the root of one of your HDDs. So something like C:\AACS\MKBROM.AACS. And then use c as drive letter (don't forget the v for verbose and the vid of course).

arnezami

[Galileo2000]

Looks like some file access problem (maybe opened by anothe program? anydvd running?). aacskeys version? What happens if you copy the AACS directory into the root of one of your HDDs. So something like C:\AACS\MKBROM.AACS. And then use c as drive letter (don't forget the v for verbose and the vid of course).

arnezami

Thanks a lot arnezami.

I did it on the new, pretty fresh system I've assembled not too long ago and Toshiba UDF 2.5 drivers weren't installed.

Installed drivers, rebooted, everything works like a charm now :D

[mlansell]

Am I missing something? My version of aacskeys spits out the VUK without me needing to find the VID myself.

Does the new version not do this anymore?

[mlansell]

there's just no benefit to having two or more PKs released and two or more exploits closed on every round.

Or they could just not release their key and the danger of two being "out there" and revoked together doesn't even come up.

I really don't see how them releasing their key helps them in any way, and seeing as theirs is a comercial operation, it's not reasonable to expect them to release keys just to be nice to us.

Mal

[Galileo2000]

Am I missing something? My version of aacskeys spits out the VUK without me needing to find the VID myself.



Does the new version not do this anymore?


You need to use verbose mode, and then you don't need VID (on my machine).

With normal mode or w/o parameter on my machine (XP SP2) I am getting exception trying to run it with "n" parameter or without any parameters, with or without VID in the command line.

Arnezami, let me know if you want more details, but IMHO this exception error does not matter at the moment.

[FoxDisc]

Or they could just not release their key and the danger of two being "out there" and revoked together doesn't even come up.
They can't "just not release their key." When they release their software, the LA immediately knows what key Slysoft has found. and they'll revoke it on the next round. The LA already knows the key - all they have to do is see which of the C-records AnyDVD accesses. It takes them ten minutes of work. Nothing Slysoft does can hide it.

I really don't see how them releasing their key helps them in any way,

Then you didn't read/understand my post.

and seeing as theirs is a comercial operation, it's not reasonable to expect them to release keys just to be nice to us.
Mal

It's not "just to be nice to us" - it's in their own best interest. They lose two possible exploits instead of a single one if they don't. They may lose one of their own backup keys if they don't.

[zacox]

Not to beat a dead horse or anything, but how many cycles of revoking and releasing new keys will we go through before AACS is deemed as insecure and not worth fixing as CSS?

My guess the upper limit is 340,282,366,920,938,463,463,374,607,431,768,211,456 cycles, but hopefully one or two more before the AACS LS decides it's not really effective protection.

[arnezami]

Am I missing something? My version of aacskeys spits out the VUK without me needing to find the VID myself.

Does the new version not do this anymore?

aacskeys works fine on older discs. No need for volume id inputting. My instructions about inputting the volume id is only if aacskeys itself cannot get the volume id using its Host Private Key (people who have inserted a new disc in their drive at some point have this key being revoked by their drive: the drive won't talk to aacskeys anymore when it comes to the volume id). As I said only if the VID is all 00's do you have to find the VID yourself first and then input it.

Verbose mode itself is not important: but you need to choose a mode: n, v or s when inputting the VID.

arnezami

[arnezami]

This is a side note to Slysoft, who I expect monitors this forum. It's in the interest of Slysoft to disclose the Processing Key they have uncovered as soon as they release their software.

If Slysoft does not release the PK they are using, someone here will sooner or later uncover and release a PK. Notice how quickly BtCB had this PK. He published it on release day +1, and may have had it before then. If BtCBs PK is the same one that Slysoft is using in AnyDVD, there's no harm, but what if they are different? If there are two holes, both will get plugged in the next round of cat vs. mouse (IMHO, the LA looks like the poor mouse right now.) It would be better for Slysoft not to have both holes plugged. They may even have found the same PK released here, but used another one and by not publicly disclosing the one they use in their software, they lose this PK as a backup for the next round.

I'd also like to point out that it's in the best interest of fair use lovers here for Slysoft to copy and use any PK released here, if it's released before Slysoft releases their own software, and for any PK released by Slysoft to be used in software released here. No one should complain about such behaviour from Slysoft or open source software authors - for the same reason - there's just no benefit to having two or more PKs released and two or more exploits closed on every round.

My .02

You are right that it would be in the best interest of us and Slysoft if they (in the future) would use an already Processing Key if that key has been released before their own product (with their new key) has not yet been released.

The same is true for us: if they release their key (ehm program) we should use that one. We shoud find one on our own but use theirs. But since it is not known which key they are using its simlply a guess: its possible we find a different Processing Key then they have which (if posting that one) would be a waste: two players instead of one player would be instructed to harden their product.

In order to make sure we release the same key either Slysoft has to tell someone (privately) over here from where they got their key (they wouldn't have to give it away) or we have to ask SlySoft privately whether our to be released key is the same as theirs or we have to figure it out ourselves. Which would take extra time. This would indeed benefit both us and them. To prevent multiple keys from being out there.

On the other hand: the ACCS LA pretty much revoked all players this time so they may do this the next time aswell. But not all players will be ordered to harden themselves so I think this is an important issue. Maybe we should talk with SlySoft about this :).

Of course if next time we find the key(s) first this won't be an issue at all ;).

Regards,

arnezami

PS. A program cannot hide which Device/Processing Key(s) its using. Not from the AACS LA anyway.

[mlansell]

They can't "just not release their key." When they release their software, the LA immediately knows what key Slysoft has found. and they'll revoke it on the next round. The LA already knows the key - all they have to do is see which of the C-records AnyDVD accesses. It takes them ten minutes of work. Nothing Slysoft does can hide it.
I don't yet understand how the key stuff works, but couldn't they just access all the C-records, or at least a lot of them, to hide the one they are really using?

It's not "just to be nice to us" - it's in their own best interest. They lose two possible exploits instead of a single one if they don't. They may lose one of their own backup keys if they don't.
But that relies on a random bunch of people unconnected with their operation to not release any other keys they find - do you think that likely? Will people here really not bother to go after other keys, if Slysoft released theirs? We've seen with the latest key that it doesn't stay quiet long when a new one is found...

Mal

[mlansell]

people who have inserted a new disc in their drive at some point have this key being revoked by their drive: the drive won't talk to aacskeys anymore when it comes to the volume id

Thanks for the tip. I think that day is getting closer for me... :-(

[arnezami]

Not to beat a dead horse or anything, but how many cycles of revoking and releasing new keys will we go through before AACS is deemed as insecure and not worth fixing as CSS?
There is still quite a bit for them to throw at us: sequence keys, using multiple processing keys, bd+, forced firmware patches. You name it.

It will be interesting what they have to say. What could they say? New version: instantly opened. How do wrap that in a few PR sentences? ;)

arnezami

[oblioman]

There is still quite a bit for them to throw at us: sequence keys, using multiple processing keys, bd+, forced firmware patches. You name it.

It will be interesting what they have to say. What could they say? New version: instantly opened. How do wrap that in a few PR sentences? ;)

arnezami

You don't wrap it in a few sentences. Me been reading your posts for some time and find them most interesting. What me understands is Alice Cooper ( trying to understand frank zappa, but he confuses me),, but to follow yer post's keep's me most intrigued. Learning and listening - Thank you!

[FoxDisc]

I don't yet understand how the key stuff works, but couldn't they just access all the C-records, or at least a lot of them, to hide the one they are really using?

That wouldn't slow them down much. AnyDVD can only decrypt the title with one valid C-record. AACS LA can just keep munging different C-records until AnyDVD fails.


But that relies on a random bunch of people unconnected with their operation to not release any other keys they find - do you think that likely? Will people here really not bother to go after other keys, if Slysoft released theirs? We've seen with the latest key that it doesn't stay quiet long when a new one is found...

You are right that there's some temptation to disclose a new PK once it's found, but as long as there's at least one public PK that works, the temptation can be resisted more easily. If it's not released, and not revoked the next round, whoever found it can release it on 0-day of the next MKB revocation and look like a hero.

[bourke]

I think they're factored in a fair few revokations into the costs of maintaining AACS, however it is not this issue that is affecting the effectiveness of AACS. It seems to be the players not being hardened enough (with Bus encryption) etc. I can't see any Windows software player being hardened enough unless the OS blocks access to the program's memory! Maybe Microsoft want WinDVD and PowerDVD to be revoked entirely so that they can sell their own future player as the only one available for Windows LOL!

However hardware players will probably see hypervisor-style hardening soon if players keep being compromised at this rate!

[Johhn]

According to the Freedom to Tinker article entitled "AACS Updated, Broken Again", the main problem currently faced by the LA is the length of time that it takes to blacklist or revoke. Licence terms require player manufacturers are given at least 90 days notice before new disks can be released, and even if that was reduced, manufacturing and distribution times mean a delay cannot be totaly eliminated. Slysoft and others are not constrained by delays like that, and can put their updates out as soon as they are ready.

As regards hardware solutions, it would appear that they are not currently looking at that. If you look at the Movielabs site, where the studios have a joint enterprise making grants for technological developments, they are looking for ways to hide cryptographic keys in software players without needing harware assist, as they put it. See http://www.movielabs.com/Challenge/hidingofcryptographickeys.html

Also, they have other problems looming. There are allegations that aacs itself violates cryptographic patents held by Certicom. And although not directly in point, there are also allegations that technology used in Blu-Ray disks violates patents held by Target Technology.

[FoxDisc]

hardware players will probably see hypervisor-style hardening soon if players keep being compromised at this rate!

I'm sure people are working on the hardware players, but so far there's not much sign they've been seriously compromised. I suspect the software players will stay in the forefront for quite awhile before the LA begins to worry too much about the hardware players.

[FTX]

There is still quite a bit for them to throw at us: sequence keys, using multiple processing keys, bd+, forced firmware patches. You name it.

It will be interesting what they have to say. What could they say? New version: instantly opened. How do wrap that in a few PR sentences? ;)

arnezami

It is clear that the HD-DVD camp has virtually no protection since it only has AACS and that is solved quickly by you guys and by the Slysoft crew.

What will be interesting to follow, is how good (or how long) BD+ will be able to resist circumvention. I guess we will find out once the "BD+ enabled" disks will arrive.

and congrats on the great work done allready

Cheers

F

[FoxDisc]

It is clear that the HD-DVD camp has virtually no protection since it only has AACS and that is solved quickly by you guys and by the Slysoft crew.

The AACS system still has features that have not been implemented, and those features could pose a problem in the future. I wouldn't agree that AACS has no teeth left. Right now the entire movie gets decrypted with a single VUK. If Sequence Key Blocks are implemented, decryption will require multiple keys in addition to the VUK used now, and each of those keys will be used for only a moment on small areas of the data. It could be significantly more difficult to solve SBK protection.

It will be interesting to see the LA's next move.

There were lots of people here who could barely contain their eagerness to get hold of new discs with new MKBs. If I was the LA, I might do nothing for a while - at least it would frustrate their "enemy" and they wouldn't get another of those headlines saying AACS was cracked in 30 seconds. :)

[greath]

If I was the LA, I might do nothing for a while - at least it would frustrate their "enemy" and they wouldn't get another of those headlines saying AACS was cracked in 30 seconds. :)

It was mentioned on AVS that the AACS Licence says that MKBs can only be changed once every 90 days. It takes time for the replicators to switch from one MKB to another, and if they had to do this more often they would be a bit frustrated! So 90 days from the 23rd April ( was that the last date ) will be the earliest release of the next MKB.

[KenD00]

If Sequence Key Blocks are implemented, decryption will require multiple keys in addition to the VUK used now, and each of those keys will be used for only a moment on small areas of the data.

I've read this many times now and i think this is not true. The aacs spec (at least the HD-DVD one) talks about a minimum length of a sequence key section, but no maximum length. So it is possible that the whole movie is a sequence key section, however this is unlikely because that would blow the space requirement by factor 8 (for HD-DVD, not sure about BD, this looks more complicated there). But thats not so important anyway, because you exactly know when a sequence key section is played back (you need to decode the corresponding map file) so you know when to look for the keys ;).

:rolleyes:

[awhitehead]

So 90 days from the 23rd April ( was that the last date ) will be the earliest release of the next MKB.

For starters, this is not 100% correct. Earliest currently known timestamp on an MKB v3 disc (Matrix 2) is April 5th. Latest known timestamp on an MKB v1 (Matrix 1 and Children of Men EU) is March 27th. So it took ~7 weeks for the first MKB v3 discs to make it to comsumers.

So technically, as early as beginning of July we could see new version of MKB.

However....

The earliest MKB v3 was broken would be around May 17th (give or take a few days, but May 22th release date for Matrix was broken, and some people got Matrix boxset early), when AnyDVD HD was updated. So this is the earliest that AACS LA knew that MKB v3 is compromised, and that assumes no time for verifying the claim, technical analysis of the attack, etc.

In addition I am not sure if the agreement states "90 days from the last rollover", or "90 days since we notify you". This could have an effect on the street date of the new MKB too.

There still haven't been any response from AACS LA on the subject.

Last AACS update involved partitioning of the device tree for the software players, which (and FoxDisc will correct me if I misunderstood) currently allowes AACS LA to tell exactly which software player leaked the processing key (Even if we don't know which one it was), since it was the only unrevoked one in the newly partitioned tree. This partitioning was effective in telling which player leaked, but ineffective in preventing the compromise. There is also the possibility that SlySoft is using a different processing key, from a different player, resulting in two compromises (SlySoft is further along in reverse-engineering the updates, since they have the unrevoked private key of a player as well, and can talk to the drive, while we have to do the VID firmware hack).

While you can use SKBs to present different decoded signal to different classes of players (and, say, prevent HTPC users from playing back video, or from playing back a radically different version of the video), it's not where the crack in AACS armor is.

Software players have holes, and when the OS is not fully controlled and trusted, and as long as the kernel debugger can be used to alter the OS, software players will be the point of attack.

At the same time SKBs require engineering time to implement, and master correctly.

If there was a hypothetical black box service, where people could provide to an entity a copy of mkbrom.aacs and VID, and out would pop the VUK, then yes, SKBs would be essential. But the processing keys disclosed here are widely known. Why spend time dealing with something that is not the core problem?

It is possible that at this point AACS LA will push for dropping support of XP as the OS, and forcing people to use Vista, since Vista likely has better support for prevention of things like this. Microsoft is unlikely to oppose this, since that means more OS license sales for them.

At the same time, long term pressure by might be to push for wider adoption of trusted computing modules in hardware and software (and remember that Microsoft is a member of AACS LA and has interest in both BD and HD-DVD, and does dictate to the motherboard manufacturers what to build onto boards).

This doesn't have to be a conventional TCM module either. Cyberlink currently supports only a handfull of higher end cards, to which it offloads the processing. At the same time, remember the older copy protection schemes for expensive software, such as AutoCad? Parallel port dongles?

We might see video decoding chip with keys that is either on the video card (your video card already does HDCP, why not do AACS as well? Force bus encryption from the drive to the video card for new cards as well, while you are at it) or on a USB (or some other) dongle (again, encrypted signal in, unencrypted signal out.)

Various forms of TCM are likely about a year away, if not longer (hopefully longer). Of course, with TCM the problem would change from obtaining the VUK and decoding the data, into convincing the TCP chip that you are an authorised piece of software.

Just some ramblings. Take them with a boatload of sea salt.

So just to summarise:

Problem with AACS is the protection of the players.

It's impossible to protect the current generation of software players, since they run on user-controllable and subvertible OS

SKBs are not (yet) an answer

MKBs will likely roll by middle of August.

[Galileo2000]

For starters, this is not 100% correct. Earliest currently known timestamp on an MKB v3 disc (Matrix 2) is April 5th. Latest known timestamp on an MKB v1 (Matrix 1 and Children of Men EU) is March 27th.

So technically, as early as beginning of July we could see new version of MKB.

However....

The earliest MKB v3 was broken would be around May 17th (give or take a few days, but May 22th release date for Matrix was broken, and some people got Matrix boxset early), when AnyDVD HD was updated. So this is the earliest that AACS LA knew that MKB v3 is compromised, and that assumes no time for verifying the claim, technical analysis of the attack, etc.

There still haven't been any response from AACS LA on the subject.

Last AACS update involved partitioning of the device tree for the software players, which (and FoxDisc will correct me if I misunderstood) currently allowes AACS LA to tell exactly which software player leaked the processing key (Even if we don't know which one it was), since it was the only unrevoked one in the newly partitioned tree. This partitioning was effective in telling which player leaked, but ineffective in preventing the compromise. There is also the possibility that SlySoft is using a different processing key, from a different player, resulting in two compromises (SlySoft is further along in reverse-engineering the updates, since they have the unrevoked private key of a player as well, and can talk to the drive, while we have to do the VID firmware hack).

While you can use SKBs to present different decoded signal to different classes of players (and, say, prevent HTPC users from playing back video, or from playing back a radically different version of the video), it's not where the crack in AACS armor is.

Software players have holes, and when the OS is not fully controlled and trusted, and as long as the kernel debugger can be used to alter the OS, software players will be the point of attack.

At the same time SKBs require engineering time to implement, and master correctly.

If there was a hypothetical black box service, where people could provide to an entity a copy of mkbrom.aacs and VID, and out would pop the VUK, then yes, SKBs would be essential. But the processing keys disclosed here are widely known. Why spend time dealing with something that is not the core problem?

It is possible that at this point AACS LA will push for dropping support of XP as the OS, and forcing people to use Vista, since Vista likely has better support for prevention of things like this. Microsoft is unlikely to oppose this, since that means more OS license sales for them.

At the same time, long term pressure by might be to push for wider adoption of trusted computing modules in hardware and software (and remember that Microsoft is a member of AACS LA and has interest in both BD and HD-DVD, and does dictate to the motherboard manufacturers what to build onto boards).

This doesn't have to be a conventional TCM module either. Cyberlink currently supports only a handfull of higher end cards, to which it offloads the processing. At the same time, remember the older copy protection schemes for expensive software, such as AutoCad? Parallel port dongles?

We might see video decoding chip with keys that is either on the video card (your video card already does HDCP, why not do AACS as well? Force bus encryption from the drive to the video card for new cards as well, while you are at it) or on a USB (or some other) dongle (again, encrypted signal in, unencrypted signal out.)

Various forms of TCM are likely about a year away, if not longer (hopefully longer). Of course, with TCM the problem would change from obtaining the VUK and decoding the data, into convincing the TCP chip that you are an authorised piece of software.

Just some ramblings. Take them with a boatload of sea salt.

So just to summarise:

Problem with AACS is the protection of the players.

It's impossible to protect the current generation of software players, since they run on user-controllable and subvertible OS

SKBs are not (yet) an answer

MKBs will likely roll by beginning of August.

Dongles had proved it's total ineffectiveness long time ago. Adobe used one for AE, it does not use it anymore for any of its software offerings. Quoting one of the vice presidents of Adobe from a year 1999, "Software protection with the dongles is fine, except dongles are expensive and do not really work in terms of protecting the software".

And consumers have another choice: boycott all this stuff. And most of them entertain this choice right now. And once any "unbreakable", "trusted" form of the "protection" (it protects ME from watching my Purchased stuff on the platform of my choice) is implemented, I'll entertain this choice as well in terms of purchasing their new releases which I will not be able to watch unless I throw close to $10K replacing my perfectly working computers and TVs.

Of course it is a technical challenge for them as well as for us.

So it is entertaining for now

But very poor economical choices for the studios. :rolleyes:

[FoxDisc]

I've read this many times now and i think this is not true. The aacs spec (at least the HD-DVD one) talks about a minimum length of a sequence key section, but no maximum length.

I don't recall any maximum length for the SK segments either. Was it my comment that they'd "be used for only a moment on small areas of the data" that you thought was wrong? I suppose they could use it for long sections, subject to the space limits you mentioned, but the alleged purpose of SKs is to watermark the movie for traitor tracing in a way that allows you to identify which specific device in an S-D set did the decryption. Watermarking implies (to me) a fairly short stretch of data - just enough to identify it.

However, I don't think they really are interested in watermarking. They've used the "poor man" method of traitor tracing - they used a tiny S-D set of only one device, so unless they assigned the same device number to different software, they know where the public Processing Key came from (and the hidden PK Slysoft used if it's not the same).

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. Since SK segments eat up disc space 8 times faster than regular data and give an attacker more opportunities to see what's happening, I don't see much reason for longer than minimum segments.

you exactly know when a sequence key section is played back

I agree that SK segments are clearly marked, but then, so are regular DK data portions.

[FoxDisc]

Just some ramblings.

I pretty much agree with all these ramblings. SKBs aren't the answer for the AACS LA. The most they do is add a small additional layer of complexity. Perhaps the LA will find it worthwhile, perhaps not. There will be pressure for trusted computing, but that pressure has been there for a long time. Microsoft would love to see Vista as the sole platform for HD playback, but the software companies will fight that (market too small right now), and probably have contracts that let them sell on other platforms.

[awhitehead]

Dongles had proved it's total ineffectiveness long time ago. Adobe used one for AE, it does not use it anymore for any of its software offerings.

You are right about boycotting.

Regarding dongles.... It all depends on the marketing. Going back to Cyberlink PowerDVD 7.x - it only works with a handfull of ATI and Nvidea video cards. Consumers still buy and use it. So here I think it could also depend on the marketing.

"Buy this 100 USD USB dongle, that has built in VC1 and H.264 compression/decompression chip, and you don't need a 3.2 Ghz Pentium to watch your videos in beautiful smooth 72 frames per second, and your home videos compress 10 times faster for those memories of your baby, and you can do something else on your PC while a video plays in the corner."

I mean, people buy this (http://www.amazon.com/Instant-Video-Encodes-Convert-Faster/dp/B000K2NP1O), so what stops them from revving it to have keys in the hardware? It's a matter of engineering and marketing.