View Full Version : New Processing Key found!! (MKB v3 is now open)


arnezami
30th May 2007, 06:19
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
30th May 2007, 07:05
damn I need a new jacket.

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

Zotty
30th May 2007, 08:23
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
30th May 2007, 09:27
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
30th May 2007, 12:56
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
30th May 2007, 13:13
i wonder if i can get next week's lotto numbers using the same tool :D

zeroprobe
30th May 2007, 13:44
aacs la must be really unlucky, whats are the odds of that happening lol.

FoxDisc
30th May 2007, 14:50
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
30th May 2007, 15:02
wow very great! i hope i get some days new european bluray disc with new keys. then i check this.

Bystander
30th May 2007, 15:10
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
30th May 2007, 15:19
already on digg :)

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

FoxDisc
30th May 2007, 16:05
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
30th May 2007, 16:53
@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
30th May 2007, 17:23
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
30th May 2007, 17:48
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
30th May 2007, 17:54
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
30th May 2007, 17:56
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
30th May 2007, 18:51
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
30th May 2007, 19:11
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
30th May 2007, 20:28
Priceless :D

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

Revgen
30th May 2007, 20:46
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
30th May 2007, 21:01
Awesome! The fight against AACS continues. I'm proud of you guys!

atzplzw
30th May 2007, 21:44
Hehe! That took quite a while until someone noticed...

Galileo2000
30th May 2007, 23:14
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
30th May 2007, 23:18
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
31st May 2007, 00:03
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
31st May 2007, 00:04
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
31st May 2007, 00:09
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
31st May 2007, 00:16
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
31st May 2007, 01:40
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
31st May 2007, 03:02
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
31st May 2007, 06:43
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
31st May 2007, 07:04
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
31st May 2007, 07:04
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
31st May 2007, 07:07
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
31st May 2007, 07:10
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
31st May 2007, 11:45
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
31st May 2007, 12:51
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
31st May 2007, 13:00
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
31st May 2007, 13:25
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
31st May 2007, 14:00
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
31st May 2007, 15:05
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
31st May 2007, 15:24
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
31st May 2007, 15:33
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
31st May 2007, 16:00
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
31st May 2007, 16:26
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
31st May 2007, 16:39
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
31st May 2007, 16:40
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
31st May 2007, 16:51
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
31st May 2007, 17:01
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.

FoxDisc
31st May 2007, 17:03
I read an analysis by one of the AACS system designers about how to build systems that comply with the AACS license requirements. It was intended for software/hardware guys and he seemed to be saying that the license required more than just trying to prevent cracks, which is what older DVD/CSS licenses required. He seemed to be saying that the AACS license was worded more strictly and required success.

I wonder if the open platform players could end up getting cut off because they could not succeed.

honai
31st May 2007, 17:13
He seemed to be saying that the AACS license was worded more strictly and required success.

Well, in the classified sector government agencies also required success, and still the suppliers' schemes were broken.

As for the Vista DRM capabilities, it has been demonstrated a few months ago that PVP and assorted kernel-mode technologies can be subverted by the user simply because the Windows devs implemented the backdoors themselves (ironically, often in order to grant Windows Media Player and other MS tools direct access to the OS).

Galileo2000
31st May 2007, 17:19
As for the Vista DRM capabilities, it has been demonstrated a few months ago that PVP and assorted kernel-mode technologies can be subverted by the user simply because the Windows devs implemented the backdoors themselves (ironically, often in order to grant Windows Media Player and other MS tools direct access to the OS).

That's what I wanted to hear :D

Can you provide a link?

FoxDisc
31st May 2007, 17:49
Well, in the classified sector government agencies also required success, and still the suppliers' schemes were broken.

The point I was trying to make was that this might be one of the few ways they could actually close off the entire "open platform" i.e. software player market despite contracts that have probably been signed between the software companies and the LA. The LA says "You are in breach since you didn't succeed so you get no more Device Keys."

meditate2
31st May 2007, 17:56
Dongles had proved it's total ineffectiveness long time ago. ....."Software protection with the dongles is fine, except dongles are expensive and do not really work in terms of protecting the software".

I doubt it, the ONLY "normal" protection i know which is not broken for over a year now, is a dongle protection. And it is used for THE programs in the audio area(new Cubase for example , #1 audio sequencer), so many groups tried but bitten their teeth out of this. Syncrosofts previous protection was cracked by "H2O", formerly THE cracking group in the audio area, but they said that it was such a huge work that it took easily over 1000 hours and that they dont want to do something like this again....

http://www.syncrosoft.com/Jan._25_2007_Products_uncracked_for_more_than_12_months-78-86.html

Fortunatly this protection wouldnt work that easily with movies....

Anyway keep up the good work, guys...:thanks:

diogen
31st May 2007, 18:40
That's what I wanted to hear :D
Can you provide a link?I think this is the one.
Security researcher Alex Ionescu claims to have successfully bypassed the much discussed DRM protection in Windows Vista, called 'Protected Media Path' (PMP)...http://it.slashdot.org/article.pl?sid=07/01/29/1811201
Microsoft would love to see Vista as the sole platform for HD playback, but the software companies will fight that...The are just two: Cyberlink and Intervideo. And according to Chris, nobody will get new licenses for XP players, nor will XP be updated to prevent key sniffing.
they will never enable HD DVD playback in any other method then what's there now (eg. PowerDVD/WinDVD) in Windows XP...
Windows XP is done in terms of new features. That's it, nothing new will become.http://www.avsforum.com/avs-vb/showthread.php?p=10649617&&#post10649617

Diogen.

FoxDisc
31st May 2007, 19:22
Microsoft would love to see Vista as the sole platform for HD playback, but the software companies will fight that...
The are just two: Cyberlink and Intervideo. And according to Chris, nobody will get new licenses for XP players, nor will XP be updated to prevent key sniffing.

Those were interesting links - thanks. I'm not quite sure of the point you are making though. It seems likely that Cyberlink and Intervideo are the only two because they're the only ones with enough cash to pay license fees and other costs and still expect to make a profit. To recover those costs, they need to keep selling to the XP market. Microsoft will certainly not improve XP, so if the key leakage continues, as seems likely, the question becomes what the LA will do.

Do they have the right to terminate Cyberlink and Intervideo? Would they want to? The studios want to sell discs and at least for now, large file sizes, slow transfer speeds and high blank media costs limit the actual financial impact of any hidef copying. Customers will scream pretty loudly if their software suddenly turns off as the LA cuts off Cyberlink and Intervideo.

It looks to me like the LA will keep on struggling by playing the cat and mouse game. There seems to be few other options for them.

Galileo2000
31st May 2007, 19:40
I think this is the one.
http://it.slashdot.org/article.pl?sid=07/01/29/1811201
Diogen.

Thanks Diogen.

I think the entire PMP thing is an insult to the consumers, plain and simple.

Quote from the comments to the article:
"As a user of the Windows Home Operating Rights Environment, I must state for the record that all of my transactions with said system are completely clean, and take place using the most effective protection available. If you truly feel that some of your Media exchanges are tainted, I'd suggest it's probably because you didn't pay the requisite PMP fees."

honai
31st May 2007, 20:25
Do they have the right to terminate Cyberlink and Intervideo? Would they want to? The studios want to sell discs and at least for now, large file sizes, slow transfer speeds and high blank media costs limit the actual financial impact of any hidef copying. Customers will scream pretty loudly if their software suddenly turns off as the LA cuts off Cyberlink and Intervideo.

I tend to believe that the opposite is true, i.e. if it weren't for proliferation of HD media to the PC desktop market both formats would be dead by now. The AACS LA actually needs the Windows XP player sales for now.

Same thing happened to the DVD. Sales went up, not down, after CSS was beaten. Though that might be a correlation rather than causality.

diogen
31st May 2007, 21:43
...Do they have the right to terminate Cyberlink and Intervideo? Would they want to?That's the million dollar question... :)
I think MS and the rest of the gang have different views on this issue.
...The studios want to sell discs and at least for now, large file sizes, slow transfer speeds and high blank media costs limit the actual financial impact of any hidef copying.Let's hope their priorities are in this order.
The very fact that DVDDecryptor and RipIt4Me were "killed" today when only a lazy can't copy a regular DVD, means that they take it "personally".
Hence, I have a hard time to imagine they would let this game continue for long.
...Customers will scream pretty loudly if their software suddenly turns off as the LA cuts off Cyberlink and Intervideo.They certainly will. But will studious listen?

Diogen.

mlansell
31st May 2007, 21:52
Same thing happened to the DVD. Sales went up, not down, after CSS was beaten. Though that might be a correlation rather than causality.

The vast majority of people do not copy DVDs, either for backup, media serving or for piracy. They simply do not have the technical know-how to do it, even with all the tools that are available.

They may buy knock-off movies from some stall in a market, but that's irrelevant to my point - which is that 99% of sales are driven by the availability of cheap, dedicated, under-the-telly boxes to play the disks.

Frankly I'm amazed (after the CSS debacle) that PC drives and software players are even available - if it were not possible to play HD DVDs or BluRay disks on a PC, I doubt that movie sales would have been harmed much at all, and cracking the copy protection would be so much harder.

Johhn
31st May 2007, 23:08
....................

Frankly I'm amazed (after the CSS debacle) that PC drives and software players are even available - if it were not possible to play HD DVDs or BluRay disks on a PC, I doubt that movie sales would have been harmed much at all, and cracking the copy protection would be so much harder.

I believe that market research showed that unless HD movie disks were playable on pc's and games machines, with the same disk format being available as a recordable media, and the drives having normal usage in pc's, that the whole enterprise would not have been viable.

bourke
1st June 2007, 01:50
I think they will give CyberLink and InterVideo a couple of attempts at obfuscating their code - probably a three strikes and you're out policy. So I think they are down to having one or two strikes remaining each and then 'sorry you breached your AACS license agreement'.

Sure I think they'll now treat every breach as entirely separate since now they can pinpoint the culprits easier - i.e they'll revoke licences for XP players long before Vista players.

If this is in part of their agreement - then you will probably see CyberLink and InterVideo trying to crack each other's programs in order to have them removed from the market and so create a monopoly on HD player software for themselves!

So roughly by what magnitude is it more difficult to kernel debug a Vista application compared to the equivalent XP app?

insomniak1981
1st June 2007, 02:27
I think the bypassing of vista DRM belongs to both Alex and Joanna , both formerly of COSENIC. They ran training courses at the recent black hat conference describing kernel attacks which could also be used to bypass vista DRM.
As the training will be focused on Windows platform and Vista x64 specifically, we will also present some new kernel attacks against latest Vista x64 builds. These attacks, of course, work on the fly and do not require system reboot and are not afraid of the TPM/Bitlocker protection. (Although they could also be used to bypass Vista DRM protection, this subject will not be discussed during the training).

From http://theinvisiblethings.blogspot.com/
Seems the Alex mentioned previously and the Alex I was thinking of are not the same. Sorry.

xyz987
1st June 2007, 09:34
Frankly I'm amazed (after the CSS debacle) that PC drives and software players are even available - if it were not possible to play HD DVDs or BluRay disks on a PC, I doubt that movie sales would have been harmed much at all, and cracking the copy protection would be so much harder.

Soft players are available because Hollywood needs them to convert PCs in a DRMed by hardware platform (Trusted Computing and alikes).

DRM is all about market control, not about piracy. Piracy is just a false motivation, a lie. DMCA was passed on 1998 (furthermore DMCA is based on 2 WIPO treaties passed on 1996), DVD Video spec (with DRM) was approved on 1995, Napster was first released on 1999 (only for music). DRM was first, piracy was later. You can check the dates at Wikipedia.

So they need soft players because they want to control PC market.

Of course market control is useful to destroy fair use (and other purposes).

arnezami
1st June 2007, 09:57
Just to clear up usage of aacskeys: if you put only the new Processing Key in the ...Simple.txt file then it will only be capable of finding keys for new discs (MKB v3 discs). So its better to put both the old Processing Key (09F9) and the new one (455F) in the ...Simple.txt file.

In other words: the new Processing Key cannot open up old discs only new ones. So you need both to find keys for all released discs so far.

richardlee
1st June 2007, 10:55
Quick question, but as far as I know there are two processing keys floating around, but the MKB is on version 3.

Did we miss out a processing key somewhere, or did the AACS LA just skip version 2?

FTX
1st June 2007, 11:02
Do they have the right to terminate Cyberlink and Intervideo? Would they want to? The studios want to sell discs and at least for now, large file sizes, slow transfer speeds and high blank media costs limit the actual financial impact of any hidef copying. Customers will scream pretty loudly if their software suddenly turns off as the LA cuts off Cyberlink and Intervideo.

It seems that Intervideo has gone "vista only" with WinDVD 8 Platinum HD/BD (http://www.intervideo.com/nVidia/WinDVD8_3in1_landing.jsp):
System Requirements
Operating System: Microsoft® Windows Vista™ only
VGA card: NVIDIA GeForce 8500GT, GeForce 8600GT, GeForce 8600GTS only

F

aKzenT
1st June 2007, 11:19
Quick question, but as far as I know there are two processing keys floating around, but the MKB is on version 3.

Did we miss out a processing key somewhere, or did the AACS LA just skip version 2?

AFAIK there are no known HDDVDs with an MKBv2. My guess is that after they designed the MKBv2 (but before it was used) there was some critical new attack (e.g. leaking of processing key, device key, ...) which they wanted to prevent in new HDDVD releases. So they quickly designed the new one.

Also if there are in fact HDDVDs with a MKBv2, then there is a high propability that the new processing key can also be used for this MKB IMO, since they are propably very similar and share many subset differences.

arnezami
1st June 2007, 11:23
It seems that Intervideo has gone "vista only" with WinDVD 8 Platinum HD/BD (http://www.intervideo.com/nVidia/WinDVD8_3in1_landing.jsp):
System Requirements
Operating System: Microsoft® Windows Vista™ only
VGA card: NVIDIA GeForce 8500GT, GeForce 8600GT, GeForce 8600GTS only

F

Interesting. Btw: it still says XP is ok here:

http://www.intervideo.com/jsp/bdhdTool_Download.jsp

KenD00
1st June 2007, 11:45
Quite interesting that it only works on the GF8 series and even there only on the mainstream series, not the high end ones. If i remember correctly the mainstream series supports HDCP over dual-link DVI and has some extra video features, maybe also more DRM? I wonder how many they will sell...
How did you get that link? Seems not to be reachable over the main site, this even states that the HD pack will be available soon (says that for 4 months now...).

:rolleyes:

arnezami
1st June 2007, 11:54
How did you get that link? Seems not to be reachable over the main site, this even states that the HD pack will be available soon (says that for 4 months now...).

:rolleyes:

Looking at the url its possible this is for WinDVD 8 trial versions bundled with certain nVidia cards? And they get redirected here maybe? It also says "Limited time offer" at the right top of the page.

FTX
1st June 2007, 12:24
Interesting. Btw: it still says XP is ok here:

http://www.intervideo.com/jsp/bdhdTool_Download.jsp

Yes, but that is only the "advisor"

FTX
1st June 2007, 12:25
Quite interesting that it only works on the GF8 series and even there only on the mainstream series, not the high end ones. If i remember correctly the mainstream series supports HDCP over dual-link DVI and has some extra video features, maybe also more DRM? I wonder how many they will sell...
How did you get that link? Seems not to be reachable over the main site, this even states that the HD pack will be available soon (says that for 4 months now...).

:rolleyes:

Probably only on the 8600/8500 cards because only they come with the VP2 while the 8800 only has VP1

arnezami
1st June 2007, 12:31
Yes, but that is only the "advisor"

Not just the advisor. Requirements for the advisor are shown at the top of the page under "Notes".

But a little lower there are the "High-Definition Suggested System Requirements" and there it says XP too. These are the requirements for HD playback. (btw this is the page you get when clicking in the advisor itself on something that isn't ok).

FTX
1st June 2007, 12:35
Someone on AVS has bought it and apparently, it doesn't support the Xbox add-on... so much for HD-DVD playback with it.

F

SuperGoof
1st June 2007, 12:38
How did you get that link?


My guess is:

The front page has this link :

Corel Announces InterVideo® WinDVD® BD/HD-DVD Playback/Navigation Support for NVIDIA® GeForce® 8 Series GPUs (http://www.intervideo.com/jsp/Press.jsp?mode=05-31-2007)

which in turn says:

Availability, Licensing
WinDVD 8 BD/HD-DVD is available through Corel’s worldwide resellers and online at www.intervideo.com/nvidia (http://www.intervideo.com/nvidia).

And the last link redirects to

http://www.intervideo.com/nVidia/WinDVD8_3in1_landing.jsp

Galileo2000
1st June 2007, 13:20
Not just the advisor. Requirements for the advisor are shown at the top of the page under "Notes".

But a little lower there are the "High-Definition Suggested System Requirements" and there it says XP too. These are the requirements for HD playback. (btw this is the page you get when clicking in the advisor itself on something that isn't ok).

According to AVS there are problems with S/PDIF out on playback. Doesn't work with AnyDVD HD and doesn't like 360 xbox HD DVD add-on."Connected HD DVD device is not supported".
The last one is pretty bad.

Just 3 video cards supported?

They probably were so scared by AACS they only tested for the leaked keys and not much more.

Peer van Heuen
1st June 2007, 14:25
According to AVS there are problems with S/PDIF out on playback. Doesn't work with AnyDVD HD and doesn't like 360 xbox HD DVD add-on."Connected HD DVD device is not supported".
The last one is pretty bad.

Just 3 video cards supported?

They probably were so scared by AACS they only tested for the leaked keys and not much more.

I haven't looked at this too closely yet, but it appears to me, that this is just another WinDVD OEM version, that comes bundled with select NVidia cards. The fact that the link also includes an offer to buy it, is a puzzle to me though.

That it doesn't work with AnyDVD - well WinDVD didn't play unencrypted Blu-Ray discs before either, so that's no wonder (unencrypted BDMV is not in the specs anyway, we're all lucky, that PowerDVD is such a friendly software - I hope, you're all buying their stuff :) they actually deserve it).

Whether it would play HD-DVD with AnyDVD remains to be confirmed, though, if it really doesn't work with the X-Box drive, there is no way to tell at the moment...

Peer van Heuen
1st June 2007, 14:30
AFAIK there are no known HDDVDs with an MKBv2. My guess is that after they designed the MKBv2 (but before it was used) there was some critical new attack (e.g. leaking of processing key, device key, ...) which they wanted to prevent in new HDDVD releases. So they quickly designed the new one.

Also if there are in fact HDDVDs with a MKBv2, then there is a high propability that the new processing key can also be used for this MKB IMO, since they are propably very similar and share many subset differences.

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

aKzenT
1st June 2007, 15:30
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
1st June 2007, 19:51
What the hell is the point with cracking and releasing AACS keys if it can be updated with new keys?

KenD00
1st June 2007, 20:10
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.
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.

:rolleyes:

FoxDisc
1st June 2007, 21:34
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
1st June 2007, 22:47
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
1st June 2007, 23:32
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
1st June 2007, 23:48
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
2nd June 2007, 00:46
I think they hate us all ;)

psme
2nd June 2007, 02:51
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
2nd June 2007, 05:20
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
2nd June 2007, 06:44
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
2nd June 2007, 10:07
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
2nd June 2007, 10:28
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
2nd June 2007, 10:31
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
2nd June 2007, 23:07
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
2nd June 2007, 23:21
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
3rd June 2007, 00:31
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
3rd June 2007, 00:40
@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 (http://www.avsforum.com/avs-vb/showthread.php?p=10058863&&#post10058863).
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
3rd June 2007, 02:53
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
3rd June 2007, 04:00
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.

Galileo2000
3rd June 2007, 04:07
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.:)

@FoxDisc:
I love this post. I love Ed Felten's automatic key assignment on the web page.

Now it is clear how the key was obtained.

Chances are high the key will be obtained again pretty soon using the same assignment.

Hyp-X
3rd June 2007, 10:09
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.

Not really. Finding the key used out of 30 possible takes 5 tries using divide and conquer.
Also finding the key of Black Box Server is not harder for them than finding which key is used in AnyDVD.
(And rate limiting doesn't necessarily work if one uses a different machine with a different IP for each query.)

arnezami
10th June 2007, 12:18
@Boing99 and @FoxDisc: please log on and read your pms. :)

blutach
11th June 2007, 04:07
If he wanted to do that Gilileo2000, he woulda posted it instead of using PMs. The "P" in PM stands for private.

Regards

Galileo2000
11th June 2007, 04:17
If he wanted to do that Gilileo2000, he woulda posted it instead of using PMs. The "P" in PM stands for private.

Regards

OK.


Deleted.

"Gilileo2000" is not my user name.

Regards.

blutach
11th June 2007, 14:43
My apologies for the typo.

Regards

arnezami
17th June 2007, 21:18
Does anybody else find that the AACS LA is a little silent lately?

No response to any of the new events since May 7th. ;)

Galileo2000
18th June 2007, 02:36
Does anybody else find that the AACS LA is a little silent lately?

No response to any of the new events since May 7th. ;)
They are silent, mostly thanks to you and Ed Felten's method of discovering the keys:D

They are facing a big dilemma along with their customers I think.

They can try full-strength and tremendously increase the manufacturing costs for the formats that are not mature yet and haven't been established into the mainstream.

This way they will cut on profits and might just kill both formats.

And yet they have no guarantee it will be bullet-proof 100%.

Or they can do nothing. And see what happens to the sales figures.

I know I won't be buying their "newly protected" stuff. (unless we need it for testing :D).

Just think about the following picture for a second:

- I don't use AnyDVD and don't decrypt the disc.

- I just put my purchased Matrix HD DVD into my purchased Xbox HD DVD to play on my carefully assembled HTPC ( and the video card is HDCP-compliant btw ). PowerDVD flashes nice bitmap which says something about 5 years in federal prison and then puts a dialog saying it cannot play because my driver (the latest ATI driver) is not good enough.

I have no HD DVD or Blu Ray STB boxes.

If I have no tools at my disposal to play HD DVDs I bought, I will return them for the full refund and will never buy them again.

They should thank people for opening the gate.

They got their money.

We got our HD DVD playback and spent money they got.

Johhn
18th June 2007, 10:44
Does anybody else find that the AACS LA is a little silent lately?

No response to any of the new events since May 7th. ;)

Maybe they are waiting until software players have to be "updated" again, and then the press releases on their site dated January 24th 2007, February 15th 2007, and April 16th 2007, will, in true Hollywood fashion, be re-released.

bourke
19th June 2007, 01:21
Sounds plausible - it will probably give them an extra week's worth of security by not telling us when the new keys are due to come out!

That way we wont be able to have a day-0 (or day -1) attack ready ;-)

jojo4u
26th July 2007, 11:15
Probably only on the 8600/8500 cards because only they come with the VP2 while the 8800 only has VP1

Source: german printed magazine C't 15/07 page 136.
Yes, nvidia is supposed to encrypt the data over the PCIe bus (AES 128 bit engine). This probably only works for VP2. The author speculated wether ATI does not encrypt since the CPU load with encryption is lower. Also nvidia only considers Vista and PCIe for security reasons.

noclip
30th July 2007, 04:23
I seem to recall some research that looked into the feasibility of obtaining the LA root certificate using some heavyweight cryptanalysis (and 10^7 revoked keys). Is this being looked into? I'm doubtful it's possible, but I imagine it would be be checkmate for the LA if we got our hands on it.

abcx
30th July 2007, 06:14
I seem to recall some research that looked into the feasibility of obtaining the LA root certificate using some heavyweight cryptanalysis (and 10^7 revoked keys). Is this being looked into? I'm doubtful it's possible, but I imagine it would be be checkmate for the LA if we got our hands on it.10^7 revoked keys?! Where would we get that?