Processing Key, Media Key and Volume ID found!!!

[oddball]

Which is why it's probably worthless even trying. Just bypass it altogether like it is now and wait for updates once/if they change things. They are probably relying on this fact to slowdown the process.

[FoxDisc]

Originally Posted by Electrox3d

EDIT: FoxDisc, your post above mine really helped me to understand this thread better. Thanks!

You are welcome, but I've tried to emphasize that I do not see the entire picture yet, and what I do see is not all that clear. I hope this isn't just thread clutter. There are lots of things I said that are perhaps not true, and lots of details I glossed over that might change things. For example, I said the Processing Key works with all disks and all device keys used with all MKBs to end up with the same processing key. I really doubt that all disks have been checked - This thread only seems to list a dozen or so. Perhaps it won't work with some.

Also, there are lots of details in the whole chain of decryption from device keys to title keys via the MKB. Device Keys are used to calculate Subsidiary Device Keys and Processing Keys. The Processing Key is used with the encrypted key data C (found in the MKB) to create the Media Key....etc.

I think they can make the Processing Key invalid without revoking any Device Keys, simply by changing the MKB (maybe changing the key data C), but I'm not sure. I think they have some options with encrypting the USB communication, but I'm not sure. I think they have some options relating to interaction between the optical drive and the disk before any data gets delivered by the drive to the PC via the USB bus, but I'm not sure. You get the idea. As I said, it will be interesting to see how this all plays out.

[guile]

Silly question. I am VERY interested in this amazing development and have been following this thread. My question is with regards to Blu Ray. I do NOT have a hdcp compliant rig but do in fact have a Blu Ray drive (which I plan on housing in an external usb enclosure for experimenting). Powerdvd blu ray will not play but....will play for about 5 seconds (as we all know) before giving me the usuall "Non compliant setup" message.

Will this few seconds of playback be enough to extract anything? Or would it actually have to be the "Movie" (rather then the FBI warning that is usually in the first few seconds of playback). Thanks

g

[Electrox3d]

Originally Posted by guile

Silly question. I am VERY interested in this amazing development and have been following this thread. My question is with regards to Blu Ray. I do NOT have a hdcp compliant rig but do in fact have a Blu Ray drive (which I plan on housing in an external usb enclosure for experimenting). Powerdvd blu ray will not play but....will play for about 5 seconds (as we all know) before giving me the usuall "Non compliant setup" message.

Will this few seconds of playback be enough to extract anything? Or would it actually have to be the "Movie" (rather then the FBI warning that is usually in the first few seconds of playback). Thanks

g

This is probably enough to sniff, I only had the movie play for about 1 second before I closed the program.

Also, if it ends up it doesn't work, then you could always just plug in a VGA monitor, HDCP doesn't activate with VGA cause its analog.

[Multiplex]

Q. Will this few seconds of playback be enough to extract anything?
A. Yes. By the time you see video, the VID is posted to the bus.

Q. What about non-usb connections?
A. Two words: Bus Hound.

Q. Can the drive read the MKB?
A. If I read AACS correctly, part of the MKB can live in the disc lead-in. That is outside file space, so it could be tricky on the host end to get at that part. Still, a read is a read. It's not like CSS, where you can't even read the sectors without a encrypted handshake.

Q. I hate searching gobs and gobs of bus traces
A. The VID is returned in response to a READ DVD STRUCTURE command AD 01 00 00 00 00 00 80. Find that going to the drive, and the data back contains the VID. There are maybe 7 total AD 01 commands in a whole disk trace.

Q. Can somebody just write a utility to grab a media VID from the drive?
A. Yes. It's trivial. Just send around 8 ATAPI commands in a row. The difficulty is that you'll need a trusted player key to establish a bus handshake before READ DVD STRUCTURE will give you a key back. Exposing a trusted player key this way will lead to its being killed sooner than later.

[xyz987]

Originally Posted by Multiplex

Q. Can the drive read the MKB?
A. If I read AACS correctly, part of the MKB can live in the disc lead-in. That is outside file space, so it could be tricky on the host end to get at that part. Still, a read is a read. It's not like CSS, where you can't even read the sectors without a encrypted handshake.

No, MBK is entirely on a file. VolumeID is outside file space.

Note VolumeID is not encrypted. If you hack your device firmware you don't need USB sniffing, neither bus handshake.

Xbox HD-DVD drive and PS3 are good candidates for firmware hacking. It is necessary a hight level to hack a firmware, but not so hight to "update" firmware to a hacked one.

[xyz987]

Originally Posted by evdberg

As far as I know there is no such thing as a 'master key', so it will be very hard to find ...

You are probably right (I am still trying to understand AACS).

Note however there are just 253 Device Keys per product (a BluRay home theater, for instance). As far as i can see, if there is no such "master key", after 253 Device Key revocations some legitime players will stop playing newly released movies.

Is it so easy?. Do we need just to get 253 Device Keys from different players to break the revocation system?

[arnezami]

You guys are asking all the right questions .

Because you are so eager I will give you a little sneak peak of what is to come:



Thats a blue truck with a looong trailer and no reverse... (and some Parking spots)

Regards,

arnezami

PS. I will have lots of time tomorrow (and in the weekend) so hopefully you won't have to wait too long .

[jokin]

Lol , ok looks good but I hope the truck has brakes to keep from rolling back down the hill.

[xyz987]

I think I am starting to understand how this thing works. AACS LA gives each player manufacturer a set of Device Keys (probably just ramdom keys). Each time a movie is printed AACS LA gives disk replicator a Media Key (a ramdom key) and a MKB, i.e. a set of copies of the encrypted Media Key. Each copy is just the Media Key encrypted with a different Device Key. AACS LA chooses the Device Keys to generate MKB in a way that any non-revoked player has at least one Device Key that can decrypt one of the copies of the encrypted Media Key.

Disk replicator combine Media Key with a VolumeID they choose (VolumeID is just to avoid bit-per-bit home disk copying) to produce Volume Key. The movie is encrypted using a random key (Title Key) and the Title Key is encrypted with the Volume Key.

Players just read MKB, look for the fist copy of the encrypted Media Key they can decrypt (because player has the Device Key it was used to encrypt this copy of the Media Key), and get it decrypted. Then they read VolumeID (with a previous cryptographic handshake in case of soft players), calculate Volume Key, use it to decrypt Title Key, and decrypt the movie.

However, I still don't understand the role of the Processing Key. It seems that the Processing Key is just a Device Key. Why it is named differently?

[cyber1]

AACS LA have an elliptical curve Root private key, this key is used for signing different things, like Drive Certificate, Revocations List, Media Key Blocks. The public key of AACS LA:s Root key is stored inside every HD-DVD/Blu-ray compatible player. But it will be impossible to get the Root private key since probably only a handful of people at the AACS LA have access to it. But if you only want to play an decrypted move from your harddisk you dont need this Root key.

[FoxDisc]

Originally Posted by xyz987

I still don't understand the role of the Processing Key. It seems that the Processing Key is just a Device Key. Why it is named differently?

I'm not going to comment on the part I didn't quote, only this part. Arnezami's tree diagram is part of the "subset difference" crypto system used by AACS and his explanation should help a lot, but I can add some preliminary details. At the top of his tree (the root) will be the AACS LA. At the bottom will be players/devices (leaves).

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.

The Processing Key is an intermediary key calculated in the decryption process going from the Device Keys to the Media Key.

In the master tree (the one that starts at the AACSLA as the root), every node from the leaf to the root has an associated key, and the set of device keys for a player won't work when the Media Key has been encrypted with a key that is in its own upward chain of nodes from its own leaf to the root. By using a higher level key in the master tree to encrypt the media key, a whole group of adjacent devices (devices with adjacent leaf nodes in the tree) gets revoked (becasue they will all have that node and its key in their upward chain of nodes to the root).

There is a whole parallel system of multiple subtrees and keys associated with all the nodes of those subtrees that start at a node below the AACSLA. They are used to allow revocation of noncontiguous groups of devices.

[Blkbird]

Everybody who's confused about how AACS works should read Prof. Ed Feltons fascinating series about circumventing AACS:

http://www.freedom-to-tinker.com/?p=1110 (7 articles)
http://www.freedom-to-tinker.com/?p=1121 (today's entry about the newst development - the one this very thread is about; it explains - in very few words - exactly what a processing key is)

Actually it should be a very interesting read even for those who do understand how AACS works.

[jkenzie]

Not sure if this means anything, but I have seen the seed register
7B103C5DCB08C4E51A27B01799053BD9 pop up in memory a few times

[SvT]

Originally Posted by jkenzie

Not sure if this means anything, but I have seen the seed resister
7B103C5DCB08C4E51A27B01799053BD9 pop up in memory a few times

From the AACS specs page 25:

3.2.2 Calculation of Subsidiary Device Keys and Processing Keys
For the purpose of processing an MKB to calculate Km, Device Keys are used to calculate subsidiary Device
Keys and Processing Keys using the AES-G3 function depicted in Figure 3-2.

A 128-bit input Device Key (which may be a subsidiary Device Key) is denoted ‘k’ in this diagram. This loop
is executed three times to produce 384 output bits, incrementing the seed register by one each time. The output
of AES-128D is XORed with the seed register’s output at each step. For each AES-G3 calculation, the seed
register is initialized by the 128-bit value “s0”, which is given by the following constant:
7B103C5DCB08C4E51A27B01799053BD916

So it means something but it's not the key we want.

[FoxDisc]

Originally Posted by Blkbird

Everybody who's confused about how AACS works should read Prof. Ed Feltons fascinating series about circumventing AACS:

Thanks for the link. I'd read the original series, but not the post today, and it does fill in some holes about the processing key. The situation appears to be about what we thought. They'll be able to make this processing key useless if they want to.

[evdberg]

Originally Posted by Blkbird

Everybody who's confused about how AACS works should read Prof. Ed Feltons fascinating series about circumventing AACS:

http://www.freedom-to-tinker.com/?p=1110 (7 articles)
http://www.freedom-to-tinker.com/?p=1121 (today's entry about the newst development - the one this very thread is about; it explains - in very few words - exactly what a processing key is)

Actually it should be a very interesting read even for those who do understand how AACS works.

Unfortunately this guy is plain wrong in what he writes about the processing key ... sigh ... he should have read this thread more carefully ...

[jkenzie]

Originally Posted by SvT

So it means something but it's not the key we want.

I understand what it is.

[FoxDisc]

Originally Posted by Blkbird

Feltons fascinating series about circumventing AACS:

BTW, I just realized that todays post is by J. Alex Halderman.
I think Halderman is accurate when he characterizes the current situation as a "gradual meltdown" of the AACS system. Felton and Halderman appear to have studied the system closely, so anyone interested in how it works should read those links.

They're also interested in game theory - what is the best strategy for the AACS LA and what is the best strategy for those breaking the AACS system. In that vein, since the processing key allows decryption of all current disks, anyone who has extracted a device key can hold off disclosing it until the AACS LA reacts to the processing key disclosure. Perhaps there are lots of device keys already extracted that are just sitting in the background waiting to pop up.

[FoxDisc]

Originally Posted by evdberg

Unfortunately this guy is plain wrong in what he writes about the processing key ... sigh ... he should have read this thread more carefully ...

Can you give us a lead on how you think he's wrong? I'm not agreeing or disagreeing with you, just trying to divine the truth. There were some parts of his post that I couldn't verify from my own study of the AACS, but I didn't see anything I was certain was wrong, and his conclusions seemed to fundamentally match my own. The earlier posts in the series (by Felton) seemed to show a high level of understanding of the AACS system.