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

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

 

Go Back   Doom9's Forum > General > Decrypting

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th February 2007, 22:43   #21  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by noclip View Post
The logistics of revocation. Essentially, every time a revocation happens a new MKB is issued which can't be decrypted by the revoked devices.

They may be able to change the MKB so that all current device keys are still valid, but then they risk an easy attack on their root key, which will have them running for the hills.
Ah - thanks!
madshi is offline   Reply With Quote
Old 5th February 2007, 22:54   #22  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by noclip View Post
To go after a device key with known plaintext you must first have a known plaintext (the media key). We should focus on working our way up the chain of command from Volume to Media to Device to possibly (but unlikely) Root key.
Thats not entirely accurate. Although I agree its probably easier to go after the Media Key right now.

Why is it not entirely accurate? Well to let a known plaintext work it doesn't have to involve just one encryption step (you do not have to know the Media Key in advance). Lets say we have a disc containing a MKB. In that MKB is a verify media key record. In essense this means: if you think you have found the media key using one of many possible Device Keys (which you try one by one using the memory dump as seed) then you can check if its valid. So yes you can go for Device Keys directly. But its a lot harder I think (because of the way the subset difference algo works).

The future will tell whether its easier to go for Device Keys (and then for Media Keys) or for Media Keys directly.

Ok. Lets go for this Media Key shall we?

And more Volume IDs are helpful too .

Regards,

arnezami

PS. And I'm not talking about variant keys. Those a (little) harder still...

Last edited by arnezami; 6th February 2007 at 08:16.
arnezami is offline   Reply With Quote
Old 5th February 2007, 22:57   #23  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
Quote:
Originally Posted by arnezami View Post
And I'm not even talking about variant keys. Thats a little harder still...
Why would we ever need to go anywhere near variant keys?
noclip is offline   Reply With Quote
Old 5th February 2007, 23:06   #24  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by noclip View Post
Why would we ever need to go anywhere near variant keys?
I was mostly referring to Volume and Media Variant Keys which you definitely need to decrypt all the content (otherwise you would miss like 1% or something and the video would basicly be broken at certain parts). This is the nastiest part of AACS in my opinion and I wonder when (and if) they will use it. Hopefully later than sooner.
arnezami is offline   Reply With Quote
Old 5th February 2007, 23:21   #25  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
Quote:
Originally Posted by arnezami View Post
I was mostly referring to Volume and Media Variant Keys which you definitely need to decrypt all the content (otherwise you would miss like 1% or something and the video would basicly be broken at certain parts). This is the nastiest part of AACS in my opinion and I wonder when (and if) they will use it. Hopefully later than sooner.
I thought the variant keys were used so that AACS-LA could track down which device had been compromised, from small differences introduced into the video and audio streams.
noclip is offline   Reply With Quote
Old 5th February 2007, 23:27   #26  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
Quote:
Originally Posted by noclip View Post
The device key decrypts the media key block to yield the media key. All the disks released so far use the same version of the media key block, thus the same media key.
I just compared the MKBs of 2 disks and they are different. What makes you think they are all the same?
evdberg is offline   Reply With Quote
Old 5th February 2007, 23:51   #27  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by evdberg View Post
I just compared the MKBs of 2 disks and they are different. What makes you think they are all the same?
Assuming thats the case we would indeed need Device Keys (well technically a Process Key would suffice and may be easier to obtain).

But the idea that one difficult to obtain key (in this case a Device/Process Key) would make it possible to decrypt discs using easier to obtain Volume IDs (or even guessable/computable). Therefore making a fairly independent decrypter (not needing too much updates) possible.
arnezami is offline   Reply With Quote
Old 5th February 2007, 23:58   #28  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
A Process Key? Are you making that one up? As I said before, we need a device key to use the - easy to obtain - Volume ID. For the time being grabbing the VUK is the easiest in many ways ...
evdberg is offline   Reply With Quote
Old 6th February 2007, 00:26   #29  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by evdberg View Post
A Process Key? Are you making that one up? As I said before, we need a device key to use the - easy to obtain - Volume ID. For the time being grabbing the VUK is the easiest in many ways ...
Well its called a Processing Key (if you want to split hairs).

Anyway. Here is the quote from AACS common specs dealing with Processing Keys:

Quote:
Once the device has the correct Device Key D, it calculates a Processing Key K using AES-G3 as described
above. Using that Processing Key K and the appropriate 16 bytes of encrypted key data C, the device calculates
the 128-bit Media Key Km as follows:
Km = AES-128D(K, C) ⊕ (00000000000000000000000016 || uv)
The appropriate encrypted key data C is found in the Media Key Data Record in the Media Key Block.
The Processing Key (and a C value) results in the Media Key. Its generally wise not to reveal your Device Keys themselves (although the last Subsidiary Device Key or the resulting Processing key is least damaging because they won't be able to determine which exact stored Device Keys you have and thus cannot revoke at once) unless they already know/guessed which device (= eg WinDVD player) you got it from.

Anyway. I think we should start thinking about what happens in a few months or so. They will probably revoke the current version of WinDVD and possibly other software players (just to be safe). The questions is: How are non technical people without too much hacking/programming experience (but with lots of new movies) gonna retrieve keys?

I believe a higher order key (Processing/Subsidiary Device Key/Media Key) could be very helpful for them to extract volume keys (assuming the simple mem search used right now with WinDVD won't work anymore for them). I think we are not disagreeing on that part. And I agree its very easy now (even without higher order keys) because of WinDVD. But thats the only thing now that allows many people to get VUKs. But thats not gonna last.

I guess the thought behind all this is: lets prepare for what will happens next.

Let me be straight: I don't want to replace something that is clearly working (extracting VUKs) but I want to add something in the context of probable future events.

Regards,

arnezami

Last edited by arnezami; 6th February 2007 at 08:19.
arnezami is offline   Reply With Quote
Old 6th February 2007, 07:40   #30  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Concerning the differences in the MKBROM.AACS files. I am wondering which parts of the MKBROM.AACS file differ from movie to movie (or from disc to disc?).

The most important part (for us here) is the Verify Media Key Record. In my MKBROM.AACS its at position 74h (just before the Copyright text):

Code:
00000070: xx xx xx xx 81 00 00 14  87 B8 A2 B7 C1 0B 9F AD 
00000080: F8 C4 36 1E 23 86 59 E5  xx xx xx xx xx xx xx xx
The bolded part is the actual Verification Data (for the Media Key).

I am now very curious if this part if different for other movies. Or if some movies have the same one. So if somebody could check. That would be great .

arnezami

PS. The start of the MKBROM file is probably the same for everyone: 10 00 00 0C 00 04 10 03 00 00 00 01. The last four bytes represent the version number.

Last edited by arnezami; 6th February 2007 at 08:14.
arnezami is offline   Reply With Quote
Old 6th February 2007, 08:33   #31  |  Link
jokin
Dwight Schrute's homeboy
 
Join Date: Jan 2007
Location: The Office
Posts: 136
Is this the right area?

Code:
00 00 00 00 00 00 00 00 00 22 00 00 40 00 04 06 32 04 20 11 57 47 48 44 56 4D 00 00 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx

Last edited by jokin; 6th February 2007 at 13:04.
jokin is offline   Reply With Quote
Old 6th February 2007, 10:07   #32  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Code:
Lentgh Code: 00 22 00 00
  Volume ID: 40 00 04 06 32 04 20 11 57 47 48 44 56 4D 00 00 
        MAC: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
Thats a Volume ID indeed. And the unique 12 bytes are much more random in this case (although the last six sort of look like ascii characters: assuming you got this from WinHex: how does it show up in the Ascii part of WinHex?). What movie/distributer is this from?

I still see structure. Maybe we can figure out what it stands for (like the date/time thing in my example).

arnezami

PS. Its best to remove the MAC bytes like I just did for your own protection.

Last edited by arnezami; 6th February 2007 at 22:30.
arnezami is offline   Reply With Quote
Old 6th February 2007, 10:47   #33  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
Quote:
The Processing Key (and a C value) results in the Media Key.
But to calculate the processing key you still need the device key(s) ... and that's my whole point.
evdberg is offline   Reply With Quote
Old 6th February 2007, 10:53   #34  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by evdberg View Post
But to calculate the processing key you still need the device key(s) ... and that's my whole point.
As far as I understand it, if someone manages to get hold of a device key and posts it on the internet, the AACS guys will come and revocate this device key. But if you post a processing key on the internet, the AACS guys will not know from which device key this processing key was calculated, so they cannot revoke the device key.

In other words posting a processing key on the internet allows many people to decrypt their HD DVD discs without having to search for VUKs first. At the same time the device key is still secret and so cannot be revoked.

Did I get this right?
madshi is offline   Reply With Quote
Old 6th February 2007, 12:03   #35  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by evdberg View Post
But to calculate the processing key you still need the device key(s) ... and that's my whole point.
There are two ways to get Processing keys: using (1) Device Key(s) or (2) hacking them directly out of the software player. I'm not claiming you (or WinDVD) don't/doesn't need Device Keys to get the Media Key. The point is: you should only release the Processing Key or Last Sub Device key.

When I've got more time I may be able to explain this better. Personally I believe its much more likely we will only find one Device Key (while we should release a sub device key or processing key) when hacking a software player. But I can only explain that while also explaining the full subset difference algo.

arnezami
arnezami is offline   Reply With Quote
Old 6th February 2007, 12:06   #36  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
Quote:
Originally Posted by madshi View Post
In other words posting a processing key on the internet allows many people to decrypt their HD DVD discs without having to search for VUKs first. At the same time the device key is still secret and so cannot be revoked.

Did I get this right?
Yes, you got it right, although "discs" should be "disc" (single). The processing key will just like the VUK be different for every disks ... and the way you have to search for the processing key is the same as for the VUK, so why bother ?
evdberg is offline   Reply With Quote
Old 6th February 2007, 12:16   #37  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by evdberg View Post
Yes, you got it right, although "discs" should be "disc" (single). The processing key will just like the VUK be different for every disks ... and the way you have to search for the processing key is the same as for the VUK, so why bother ?
I will go into this later. When I have more time.

But what I'm really interested in the the difference you mentioned between the MKBs. Are the versions different? Are the Verify Media Key Records different? Or is it for example the Copyright text (eg 2006 changed into 2007) which causes the signature to be completely different and it may therefore look like a quite different MKB (while the Media is still the same). I just don't know. I only have one disc. Please help us out here .

arnezami

Last edited by arnezami; 6th February 2007 at 12:25.
arnezami is offline   Reply With Quote
Old 6th February 2007, 12:34   #38  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
I double checked the files at the location you showed in post #30 (0x78 to 0x88), and they are different for all movies (and different from your values).
evdberg is offline   Reply With Quote
Old 6th February 2007, 13:02   #39  |  Link
K40
Registered User
 
Join Date: Jan 2007
Posts: 57
In the MKBROM.AA.. of Serenity are these values:

00000070: xx xx xx xx 81 00 00 14 F0 5A D7 30 E4 1A DE 4E
00000080: B4 2A 11 61 0B DC C5 41 xx xx xx xx xx xx xx xx

If this is helping you i can post some more later
K40 is offline   Reply With Quote
Old 6th February 2007, 13:11   #40  |  Link
zeroprobe
Registered User
 
Join Date: Jan 2002
Posts: 155
Quote:
Originally Posted by evdberg View Post
The processing key will just like the VUK be different for every disks ...
disc not disks.
zeroprobe is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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

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

Forum Jump


All times are GMT +1. The time now is 10:43.


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