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 15th February 2007, 18:03   #261  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
It's about this:
Quote:
Each AACS movie is encrypted with a unique title key, and several copies of the title key, encrypted with different processing keys, are stored on the disc.
1) Movie data is encrypted with different title keys.
2) Title keys are encrypted with the Volume Unique Key.
3) There is only 1 copy of the titlekeyfile in the backup folder.

He has no clue about the processing key ... just like me in the beginning to be honest !

Last edited by evdberg; 15th February 2007 at 18:10.
evdberg is offline   Reply With Quote
Old 15th February 2007, 19:01   #262  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
I can confirm that it is possible for “them” to make Processing Keys (found in the future) far less valuable.

This is because they can use different but equivalent Explicit Subset-Difference Records. In order to decrypt discs with different of these Records you really need Device Keys (because they can choose different Processing Keys).

But since that wasn’t required (AACS screwed up here big time) only the Processing Key was released (which doesn’t identify the software player it came from btw).

Whether they will actually do this “shuffling” inside this Record in the near future (do they even understand how this works? I started to doubt when I saw this record for the first time) is not clear. Maybe they have some (stupid) policy or their program to create these records isn’t up to this yet. I don’t know. We’ll see .

Not that any of this really/fundamentally matters though…

Last edited by arnezami; 15th February 2007 at 19:29.
arnezami is offline   Reply With Quote
Old 15th February 2007, 19:48   #263  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by arnezami View Post
I can confirm that it is possible for “them” to make Processing Keys (found in the future) far less valuable.....Whether they will actually do this “shuffling” inside this Record in the near future .... I don’t know. We’ll see
Yes, the AACS LA will probably move slowly. They aren't going to want to change things around, for example the "shuffling" you describe, and then find out that half the hardware players out there have poorly written decryption code and won't correctly play newly released discs with revised MKBs. There can certainly be a big difference between what seems to be technically possible under the AACS specifications and what will really work out in the real world with players already on the market.

@evdberg: Thanks for the comments.
FoxDisc is offline   Reply With Quote
Old 16th February 2007, 01:26   #264  |  Link
awhitehead
Registered User
 
Join Date: Jan 2007
Location: Tel-Aviv, Israel
Posts: 185
Some more Volume IDs

The following look totally random to my untrained eye:

Dates are MM/DD/YYYY

Code:
Title: Rambo I
Studio: Studio Canal 
Volume ID: 40 00 e0 d8 46 1e cd ff 74 50 92 11 0c dc 00 00
Timestamp: 10/4/2006 12:05 AM <= Must have been a late night render




Title: Rambo II 
Studio: Studio Canal
Volume ID: 40 00 18 54 3b d6 24 9b 59 f3 31 1e 49 ee 00 00
Timestamp: 10/3/2006 11:38 pm



Title: Rambo III 
Studio: Studio Canal
Volume ID: 40 00 95 ad 18 64 b0 4a 47 9a d2 11 b7 df 00 00 
Timestamp: 10/4/2006 10:53 pm
Question: Are these even relevant any more? I was under impression that "people in the know" now know the device key for at least one player (And it was mentioned that SlySoft uses the key from PowerDVD 6.5, so most likely this player is compromised). It was also mentioned that it's about 8 IDE commands to get the drive to unlock and cough up the volume ID, once a proper device key is fed to it. So am I correct in assuming that a piece of code that does just that is now either "doing the rounds", or pretty close to being completed, and we won't need to do the complicated volume ID extraction using USB sniffer?


Personal Comment:Ordering all three Rambo HD-DVDs from Amazon.fr set me back ~160 USD (including shipping) and showed up in my neck of North American woods in 4 days. Studio Canal also released Basic Instinct and Total Recall on HD-DVD, so I urge anyone who liked old Sly to get a legal HD-DVD version :-)

Last edited by awhitehead; 16th February 2007 at 01:27. Reason: s/copy/version/ to reduce ambiguity
awhitehead is offline   Reply With Quote
Old 16th February 2007, 13:26   #265  |  Link
guile
Registered User
 
Join Date: Oct 2002
Posts: 65
Quote:
Originally Posted by arnezami View Post
The things we need to see if this processing key works with Blu-Ray aswell (I've already heard the proc key is in a Blu-Ray memdump so its very likely now) is in this post.

So we need:

(1) Title of the Movie (not really needed but is nice to know)
(2) The Verify Media Key Record in the MKBROM.AACS
(3) The first C-Value in the MKBROM.AACS file

Then we will know if it works for Blu-Ray aswell.

And if you will (optional) :

(4) To go towards the VUK we also need the Volume ID (you either should use a sniffer or if you don't have it usb connected: a memdump which is harder, read the instruction in this thread)
Newbish question here. With all 4 of the above (and a VUK), how would this work with the config file in backupbluray?

All I see is a place for title hash and vuk.
guile is offline   Reply With Quote
Old 16th February 2007, 14:49   #266  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
Each player gets a "set of device keys." Each player has a "leaf key" associated with itself. The set of device keys allows the player to decrypt the Media Key in the MKB when the Media Key is encrypted with any other leaf key (associated with another device and another set of device keys), but not its own. That's how revocation
works. As the AACS common crypto spec puts it:

"To revoke only a single Leaf Key (i.e., to enable calculation of the Media Key by any set of device Keys except the set containing that Leaf Key), the Media Key Block will include the Media Key encrypted only by the master tree’s Leaf Key that is being revoked."
I really don't understand this part of the specification. If Media Key is encrypted with that Leaf Key, and you have it, you can decrypt Media Key. But it seems as if specification is saying the contrary.

This is a Device Key tree:

Code:

                       1
                      / \
                     /   \
                    /     \
                   /       \
                  /         \
                 /           \
                /             \
               /               \
              /                 \
             2                   3
            / \                 / \
           /   \               /   \
          /     \             /     \
         /       \           /       \
        4         5         6         7
       / \       / \       / \       / \
      /   \     /   \     /   \     /   \
    8      9    10   11   12   13   14   15
Lets say we manufacture player 9. What Device Keys do we get from AACS LA? If we get 3,5,8 we can derive any key except 9,4,2,1. So I suppose we would get 3,5,8. However, I seems as specification says we get 9, not 8.

BTW, AACS specification clearly states that any lower key is a one-way result of any higher key. If an attacker gets the root key, he can get any Device Key and any Processing Key. I suppose it is far hard to get that root key, but an equivalent effect should be to get the 2 keys at level 1 (keys 2 and 3), or the 4 keys at level 2, and so on. Supposedly, any set of Device Keys includes one of the 2 keys at level 1.
xyz987 is offline   Reply With Quote
Old 16th February 2007, 15:08   #267  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
I realize that I've been making some assumptions that I'm now uncertain of. Has anyone been able to calculate a title key/volume unique key from the Processing Key? If so, is it necessary to use the sniffed volume ID or is there enough info in the processing key to read and decrypt everything on the disc that is required?

It seems reasonably certain that all device keys for HD and BD lead to the same processing key, but is there some other required encrypted component from the disc that still needs the device key to decrypt? Perhaps I'll have time this weekend to read the specs again and answer these questions for myself.

Basically, my Qs are:
1) Does this thread conclude that the processing key is currently equivalent to a device key allowing all discs to be fully decrypted? This would be the most powerful. (Originally, I wasn't sure, then I thought this was the case, now I'm not certain again.)
2) Or do we still need other encrypted content from the disc that is disc dependent that must be USB sniffed in order to get to the title key? (I really need to go back and look at the volume ID and C data stuff) This would make the processing key and the USB sniff procedure an alternative to the mem dump procedure, but require a different type of key DB.
3) or is it not yet possible to calculate the title key/volume unique key from the processing key and sniffed data?
FoxDisc is offline   Reply With Quote
Old 16th February 2007, 15:19   #268  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
I realize that I've been making some assumptions that I'm now uncertain of. Has anyone been able to calculate a title key/volume unique key from the Processing Key? If so, is it necessary to use the sniffed volume ID or is there enough info in the processing key to read and decrypt everything on the disc that is required?
Yes, arnezami calculated the VUK for Talladega Nights (BluRay US PS3 version), and it worked. But it was necessary to sniff VolumeID (no mistery here, it works that way).
xyz987 is offline   Reply With Quote
Old 16th February 2007, 15:51   #269  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
I really don't understand this part of the specification. If Media Key is encrypted with that Leaf Key, and you have it, you can decrypt Media Key. But it seems as if specification is saying the contrary.
This is one of those situations where I know I don't know enough to answer this properly. I probably should stay silent, but I've been in the boat you are in - wanting to understand, not knowing where I've gone wrong and hoping for a hint, so I'll try to give you that hint. Take it with a grain of salt - Arnezami says he's going to address this exactly, so just skip this if you can wait, if not, read on.

You had exactly the same question I had, and like me, you confused the leaf/node keys in the tree with the device keys and simplified the system way too much. A device key is not a leaf or node key. The tree shown in the AACS system is a tree of node and leaf keys, not a tree of device keys, like you drew. In fact, there is a master tree that starts at the AACSLA root and ends at all devices, but there are other subtrees, that start one down from the root, and two down from the root, etc. These are not subtrees within the master tree, they are separate subtrees that are parallel to the master subtree, with another set of leaf keys and node keys.

Device keys allow you to get the answer when the data is encrypted with anyone elses leaf key or any node key for a node above their leaf that is not also in the path from your own leaf to the root. You can't get the answer when it's encrypted with your own leaf key or any node key above you, at least not for this subtree.

Here my own knowledge of the details goes hazy. I'm not sure if one media key is encrypted multiple ways using keys from different subtrees, or if multiple copies are encrypted using different subtrees/keys, but I do know that the decryption process keeps trying, cycling through different decryption attempts until it reaches an end. It's only after it gets to the end and hasn't gotten a valid decrypted answer, that it can conclude its own set of device keys has been revoked.
FoxDisc is offline   Reply With Quote
Old 16th February 2007, 16:09   #270  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by xyz987 View Post
Yes, arnezami calculated the VUK for Talladega Nights (BluRay US PS3 version), and it worked. But it was necessary to sniff VolumeID (no mistery here, it works that way).
Thanks, I missed that. I knew the VolumeID was being sniffed, but I also know it's stored on the disc, but not stored in a way that can be copied to a recordable disc. Do you know if it can be read directly, and if not, why not?

I should probably point out to anyone reading this, that I'm much like Professor Felton and the "Freedom to Tinker" guys. I'm simply interested in fair use, crypto, copyright and the social effects of the battle between those who are in favor of DRM and those who are opposed. I find this thread particularly interesting - pitting the most advanced and expensive DRM crypto system ever implemented against the real world of people who want to enjoy their fair use rights by watching their discs on Linux based systems or systems that have everything except HDCP.
FoxDisc is offline   Reply With Quote
Old 16th February 2007, 16:31   #271  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
Thanks, I missed that. I knew the VolumeID was being sniffed, but I also know it's stored on the disc, but not stored in a way that can be copied to a recordable disc. Do you know if it can be read directly, and if not, why not?
VolumeID is stored in an especial area of disk, and it can not be directly read (except if you have a device with hacked firmware, but nobody has done it yet).

Its purpose is to avoid bit-by-bit (verbatim) home copying of the disk. You can not do a verbatim copy of all the disk because you (supossedly) don't know the VolumeID.
xyz987 is offline   Reply With Quote
Old 16th February 2007, 16:42   #272  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
Quote:
Has anyone been able to calculate a title key/volume unique key from the Processing Key?
Yes, the MKB tool that I released can do this.
evdberg is offline   Reply With Quote
Old 16th February 2007, 16:55   #273  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by FoxDisc View Post
You had exactly the same question I had, and like me, you confused the leaf/node keys in the tree with the device keys and simplified the system way too much. A device key is not a leaf or node key. The tree shown in the AACS system is a tree of node and leaf keys, not a tree of device keys, like you drew. In fact, there is a master tree that starts at the AACSLA root and ends at all devices, but there are other subtrees, that start one down from the root, and two down from the root, etc. These are not subtrees within the master tree, they are separate subtrees that are parallel to the master subtree, with another set of leaf keys and node keys.

Device keys allow you to get the answer when the data is encrypted with anyone elses leaf key or any node key for a node above their leaf that is not also in the path from your own leaf to the root. You can't get the answer when it's encrypted with your own leaf key or any node key above you, at least not for this subtree.
Thanks a lot. This is probably the right view.
xyz987 is offline   Reply With Quote
Old 16th February 2007, 17:08   #274  |  Link
guile
Registered User
 
Join Date: Oct 2002
Posts: 65
Quote:
Originally Posted by guile View Post
Newbish question here. With all 4 of the above (and a VUK), how would this work with the config file in backupbluray?

All I see is a place for title hash and vuk.
Anybody??
guile is offline   Reply With Quote
Old 16th February 2007, 17:38   #275  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by guile View Post
Anybody??
It won't directly work with backupbluray.....yet.
FoxDisc is offline   Reply With Quote
Old 16th February 2007, 17:57   #276  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by evdberg View Post
Yes, the MKB tool that I released can do this.
I'll look at it, but am I right to think you have to give your MKB tool the sniffed volume ID (plus the processing key, which you probably have hard coded in)?

It occurs to me (obvious things sometimes do that :-) that even with a device key, a player would need the volume id to get from the processing key to the media key and on to the title key. So this means the software player can get the volume id, presumably by asking the drive to send it over from the disc. I don't see any reason why hacked firmware or sniffing would be required to get the volume id if the player can get it. Perhaps this has been solved (does your tMKB ool do that?) or there's some part of this that hasn't sunk in yet.
FoxDisc is offline   Reply With Quote
Old 16th February 2007, 18:20   #277  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
Quote:
Originally Posted by FoxDisc View Post
I'll look at it, but am I right to think you have to give your MKB tool the sniffed volume ID (plus the processing key, which you probably have hard coded in)?
Yes, you need to provide the Volume ID. Without it, the MKB tool only calculates the Media Key.

Quote:
Originally Posted by FoxDisc View Post
It occurs to me (obvious things sometimes do that :-) that even with a device key, a player would need the volume id to get from the processing key to the media key and on to the title key. So this means the software player can get the volume id, presumably by asking the drive to send it over from the disc. I don't see any reason why hacked firmware or sniffing would be required to get the volume id if the player can get it. Perhaps this has been solved (does your tMKB ool do that?) or there's some part of this that hasn't sunk in yet.
You need to 'sniff' the Volume ID, because you need a trusted connection with the drive before the drive will send it over. To setup a trusted connnection with the drive you need a Host Certificate which are issued by th AACS-LA. Therefor you need a software player setup that connection. See also my comments on how AnyDVD works.

Last edited by evdberg; 16th February 2007 at 18:25.
evdberg is offline   Reply With Quote
Old 16th February 2007, 18:22   #278  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by FoxDisc View Post
I'll look at it, but am I right to think you have to give your MKB tool the sniffed volume ID (plus the processing key, which you probably have hard coded in)?

It occurs to me (obvious things sometimes do that :-) that even with a device key, a player would need the volume id to get from the processing key to the media key and on to the title key. So this means the software player can get the volume id, presumably by asking the drive to send it over from the disc. I don't see any reason why hacked firmware or sniffing would be required to get the volume id if the player can get it. Perhaps this has been solved (does your tMKB ool do that?) or there's some part of this that hasn't sunk in yet.
You need the Private Host Key (+Certificate) for that. Otherwise your drive won't give away the Volume ID.

In principe: to decrypt a disc you need two things: Device Keys and a Private Host Key (+Certificate).

We can replace the Device Keys with one Processing Key but we still need the Private Host Key to give us the Volume ID. Otherwise we have to sniff it (or guess it etc)
arnezami is offline   Reply With Quote
Old 16th February 2007, 18:48   #279  |  Link
SBeaver
Registered User
 
Join Date: Dec 2002
Posts: 86
Quote:
Originally Posted by arnezami View Post
You need the Private Host Key (+Certificate) for that. Otherwise your drive won't give away the Volume ID.

In principe: to decrypt a disc you need two things: Device Keys and a Private Host Key (+Certificate).

We can replace the Device Keys with one Processing Key but we still need the Private Host Key to give us the Volume ID. Otherwise we have to sniff it (or guess it etc)
how many bytes is this host key certificate as sent to the drive?
SBeaver is offline   Reply With Quote
Old 16th February 2007, 19:37   #280  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by arnezami View Post
Yto decrypt a disc you need two things: Device Keys and a Private Host Key (+Certificate).
Thank you! It's starting to make sense now. I've gone back to the specs and read the 29 steps for drive authentication (Section 4.3) followed by the 6 step protocol for delivery of the volume id (Section 4.4). This also filled in some questions I had about the drive revocation list and the host revocation list. It also filled in why you were asking about bus encryption.

Someone asked about size - Section 4.2 seems to say the whole host certificate data block is 92 bytes long. The Host ID is 8 bytes, the key is 40 bytes and the signature is 40 bytes.
FoxDisc 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 05:11.


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