Clarification on the state of AACS

[Gnodab]

So over the past few weeks, I've been keeping updated on the news and forum posts, and have come across two main themes: AACS is cracked and dead, and AACS is not cracked and not dead.

Now, for the average person (lets say...hmm..me, for instance :) ) that is a confusing message to be getting. First the keys were found, and now the software players are requiring updates. So the way Muslix64 found the keys originally is now null and void. However the processing key was also found, and (as far as I, in my noobishness understand), with that, the original method which Muslix used is no longer needed. So that would not be made null and void by the newly required update (correct?).

And now to complicate things even FURTHER (not like trying to lie to your girlfriend about where you were last night and why you smell like either perfume or cologne (whichever way you fly), but complicated in the sense of being as rich as Bill Gates, there is just so much good news that seem similar but are different that one (me again for instance) isn't sure what to make of all of it) Some people (forgive me for not having their handle's in this post, but they know who they are) are now saying that there may, in the not too distant future, be a way to bypass AACS entirely through the modification of firmware on the hardware itself.

So, like the title suggests, If someone could give the Doom9 state of the union, in terms which may be complicated but not including the ins and outs of hex editing, I (as well as many others I am sure) would be greatly indebted for the gift. Thanks.

[arnezami]

Ok. Good points. I will keep this as simple as I can ;).

So over the past few weeks, I've been keeping updated on the news and forum posts, and have come across two main themes: AACS is cracked and dead, and AACS is not cracked and not dead.
AACS contains several parts that have different roles. Some of those have been permanently broken while others have been temporarly "opened". Calling AACS dead or not dead has no meaning.

The functions of AACS could be divided this way:

Copy protection
Modification/Decryption protection
Renewability and revocation

Copy Protection

If you can copy a disc and play it (eg burn it on a recordable) then you could say the copy-protection system is broken. AACS tries to prevent bit-by-bit copying by the use of the Volume ID and a secret way its stored on the disc (also using special keys to let the drive give this VID). When it comes to HD DVDs there is now a possibility to create a firmware (for the xbox drive) that would simulate a prerecorded disc (while using a recordable disc). This allows anyone with a burner to copy and play any HD DVD movie. In essence the AACS copy-protection system will be permanently broken when/if this patch comes out. This is the most basic attack: copy and playback only.

Decryption protection

If you can decrypt a disc you can also copy it (of course). But being able to decrypt a disc is a more severe attack on AACS. Because it also allows you to modify the content (like removing commercials/changing menus/re-authoring etc) and perform playback in (for example) linux or an open source player.

In order to decrypt a disc you need the keys the content is encrypted with. These we usually refer to as Volume Unique Keys (although technically VUKs give Title Keys which are used to decrypt the content but this amounts to the same thing). What is important is that VUKs cannot be revoked. In other words: once we have a VUK for a disc then the AACS decryption-protection is broken for that disc. AACS cannot undo this.

So how can we get VUKs?

There are several ways to get VUKs for discs. But none of them are permanent solutions for retrieving all VUKs for all discs (released in the future).

Get the VUKs out of "old" versions of a Software Player
Get a Volume ID (unique per movie) and a Processing Key (unique per MKB version) and calculate the VUK.
The first method will expire quickly: we can now use WinDVD to retrieve VUKs out of its memory. But when new discs come out they won't work with this old version of WinDVD so you would have to install a new version. Therefore making this method obsolete for new discs.

The second method requires not one piece of information (like taking a single VUK out of the memory of WinDVD) but two pieces of information. We have several techniques now for a drive to reveal the Volume ID of a disc. So this part of the method is permanent. However the Processing Key will change every time they change to a new MKB version. And since we also need this second piece of information to calculate a VUK for a disc we always need to get the new Processing Key out of some player (whether its a Software Player or a standalone). The Processing Key (or better a Device Key) is very powerful though: if found it makes it possible to decrypt all discs released so far (assuming we can also retrieve the Volume IDs of those discs).

Renewability and revocation

With renewability I mean the ability for AACS to use new keys for new discs. This is still intact and will probably never be broken. This creates (for us) the necessity of finding a new Processing/Device Key each time they change to a new MKB version (which they will do in April/May) on new discs.

Revocation is basicly for "getting back" at those who try to open AACS (that would be us :)). Revocation only has real meaning if something unique is revoked. So if I where to use a standalone and reveal the keys then they can simply revoke my standalone meaning it won't play new discs. There is also the matter of tracing (sequence keys) but thats just for making it possible for them to identify the standalone/player used when somebody releases its keys or content itself (read: pirates) decrypted with this player. We have been speculating how to permanently disable this tracing system and if we're lucky this could be done using a reasonable amount of volunteers.

Those are the elements of AACS and their state of "broken-ness" :).

I hope that clears it up a bit. If you have questions just ask :).

arnezami

[Gnodab]

arnezami,

Thanks for your timely reply. I do still have a few questions (don't worry, this shouldn't take a lot of explanation..hell one of them is just what an acronym stands for!), but you've done a fantastic job of explaining what is happening for those of us (or simply just me, although I hope that isn't the case!) who are kind of left in the dust by the complex technical nature of this endeavor.

First, you mentioned "MKB", but there was no explanation for what it was. My guess Master Key Bit, but for some reason (perhaps grammatically, I don't know!) that doesn't seem to fit for me.

Second, and this is in regards to stand alone players and revocation. From my understanding, most (if not all) of these next gen media players have an always on connection to the internet (via an ethernet line). So unlike with software players on a computer, the machine would automatically update without the owner even knowing. When you say "We have been speculation how to permanently disable this system " you mean you think that there is a way to get these stand alone players to stop "phoning home" and yet continue to play media (despite their leaked keys)?

Third and finally, If AACS did trace what standalone machine gave out the key's, and shut it down, does that mean that anyone who bought that player is a proud owner of a new $1000 brick?

Thanks again for the speedy reply, and thanks for all the work you've done on this (I know you have something to do with some of this, and should have mentioned you my first post to give credit where credit is due, so my bad)

[FoxDisc]

arnezami,
First, you mentioned "MKB", but there was no explanation for what it was.
It stands for " Media Key Block" There's a detailed explanation in the sticky on understanding AACS, but basically it's got multiple encrypted copies of the media key. The media key with the voume id let's you get to the VUK. Every player is in a group of players (called a subset difference set of players) and every player in an S-D set can decrypt the same one of the encrypted copies of the media key in the MKB.

[arnezami]

Its really good that you ask these questions. If you have them others will too ;).

First, you mentioned "MKB", but there was no explanation for what it was. My guess Master Key Bit, but for some reason (perhaps grammatically, I don't know!) that doesn't seem to fit for me.

MKB stands for Media Key Block. There is a thread (in the sticky) explaining the subset difference method which uses the MKB. Essentially the MKB contains encrypted keys. A player needs keys to decrypt discs. But from time to time they change the keys used in the MKB so we can't use the old ones (we found) for new discs. This concerns the Processing/Device Key btw.

Second, and this is in regards to stand alone players and revocation. From my understanding, most (if not all) of these next gen media players have an always on connection to the internet (via an ethernet line). So unlike with software players on a computer, the machine would automatically update without the owner even knowing. When you say "We have been speculation how to permanently disable this system " you mean you think that there is a way to get these stand alone players to stop "phoning home" and yet continue to play media (despite their leaked keys)?
The speculation was about effectively disabling the tracing system (not the revocation system). If your standalone gives away its identity (to the AACS LA) then tracing isn't even needed anymore: they can simply revoke you (if there is a valid reason of course). This is why its important to be careful when patching something that is (or has been) attached to the internet.

Third and finally, If AACS did trace what standalone machine gave out the key's, and shut it down, does that mean that anyone who bought that player is a proud owner of a new $1000 brick?

Thanks again for the speedy reply, and thanks for all the work you've done on this (I know you have something to do with some of this, and should have mentioned you my first post to give credit where credit is due, so my bad)

In principle [edited] no. If they would revoke a standalone device this device will basicly stop working from the moment a new disc is inserted or will not be able to play new discs. Of course if they would do that there was a reason for it: maybe the device was hacked. If so then the owner can probably "repair" this standalone since he would (most likely) have low-level access to it (eg use a cloning technique).

[edit]I read your question wrong: only the standalone which keys were released will be revoked. Not others. Sorry.

Regards,

arnezami

[FoxDisc]

Its really good that you ask these questions. If you have them others will too ;).

I'm amazed that arnezami has the time to answer these questions and do all the decrypting, ROM analysis and software writing he's doing. The Understanding AACS sticky thread has a lot of good info, but it is kind of buried and gets deeply technical, so I thought I'd throw a simpler explanation out of the major parts of the AACS system.

An AACS disc can have MKBs, SKBs and revocation lists. These are three broad categories that make up the AACS DRM. Right now only the first category (MKBs) seems to be in use. What are these categories?

MKBs - revoking players
An AACS disc has a movie on it that is encrypted (doh!) and you need a key to decrypt and play it. You get that key from an MKB on the disc. A player starts with one of its "device keys" and goes through a lengthy process to get the final decryption key. Right now the entirety of each movie is encrypted with one key, and the "lengthy process" involves a number of keys including: "processing key," "media key," "title key," "volume unique key" and a "volume id" on the disc. Basically, this category relates to who gets to decrypt the bulk of the movie (right now the "bulk " of the movie is all of the movie). The MKB has multiple copies of the same key you need for decryption of the movie (right now 512 copies), but they are all encrypted differently so that each group of players can decrypt only one of them. The group of players for each encrypted copy of the key in an MKB is known as a "subset difference set" (see the sticky to find out why). By changing the MKB, different groups of players (S-D sets) can be defined, and any combination of one or more players can be implicitly "revoked" and prevented from getting the key they need to decrypt the movie simply by leaving out of the MKB the key they could decrypt.

SKBs - Sequence Key Blocks and traitor tracing
This system is not currently in use, but may be soon. Essentially, it is a method of figuring out which device has been compromised so that its keys can be eliminated from the MKB, making the device revoked. Although the majority of a movie is encrypted using the MKB and device key system above, on a disc having SKBs, part of the movie (up to 32 short segments) can be encrypted with multiple additional keys. At each of the 32 spots, there are up to 8 different short segments, only one of which is used by by a player at each of the 32 points. A player has "sequence keys" and those keys are used with the SKB to decrypt one of the 8 variations at each of the 32 points in the movie. Different players would decrypt a different variation at each segment. Looking at the decrypted movie (or alternatively at released sequence keys) tells the AACS LA (Licensing Authority) which of the eight variations at each segment was decrypted. This produces an identifiable "fingerprint" that is tied to the device that decrypted the movie and tells them something about who released the keys. It is intended to let them figure out who should be revoked with the next MKB they release.

Revocation Lists - Drives, Hosts and Content
Last comes the revocation lists. There are 3 - the HRL - Host Revocation List, the DRL - Drive Revocation List, and the CRL - Content Revocation List. These explicit revocation lists are also not currently known to be in use, but may be used soon. The lists are located on the AACS disc and once the disc is inserted into a compliant device, the device (in theory) forever after keeps that list of revocations. A "Host" is software - like WinDVD. A drive (like the Xbox HD-DVD add-on drive) reads an AACS disc and if the disc has a new HRL, the drive stores that new list in non-volatile RAM. The drive will then refuse to hand over information to the revoked host/software that it needs to play an AACS encrypted movie. Similarly, the drive can be revoked by a DRL and the software can refuse to play discs on the revoked drive. Content revocation seems unlikely to be used as they would have to start replacing discs to everyone.

I hope that summary helps explain where the various parts fit in to the whole picture.

[Gnodab]

Thanks to all that have replied, reading through all that technical jargon in some of the other threads...well...lets just leave it at that and you can use your imaginations :) I thank you (arnezami and Foxdisc) for giving a lay explanation of what is happening, and now I have an entirely new appreciation of the work you are doing. Keep it up!! :)

and p.s. wouldn't it suck to buy a $1000 brick? Someone could come out with a www.smashmyBDplayer.com (think smashmyWii and smashmyPS3)....By the way, I patent, trademark, and copyright that idea, and will sue anyone who tries to steal it from me!!!!!! hmm there are no emotiocons while editing, otherwise I would have one of those "looking to take over the world" faces. :)

[mgpc]

And the Revocation Lists are versioned...

Would it be possible to fake an empty or false Revocation List with the highest possible version number, and what would happen to a Drive after that happened? Presumably it would no longer be possible for the AACS LA to brick your drive or software player?

Has anyone looked at this method of attacking AACS yet?

[HyperHacker]

Someone mentioned the idea once, but apparently it'd have to be signed with their digital signature, so it's not going to happen any time soon. However, we may be able to use debug commands or firmware hacks to just insert a list of our own, bypassing signatures entirely, but this would be on a per-drive basis.

[arnezami]

And the Revocation Lists are versioned...

Would it be possible to fake an empty or false Revocation List with the highest possible version number, and what would happen to a Drive after that happened? Presumably it would no longer be possible for the AACS LA to brick your drive or software player?

Has anyone looked at this method of attacking AACS yet?

We can't fake a HRL. Like HyperHacker said its digitally signed.

We can (in principle) tell our own drive to ignore new HRL versions on new discs. But the only thing this will do is that our drive will still give its Volume ID to old versions of WinDVD and PowerDVD. But this won't do us much good (well maybe sometimes an older version works a little better than a newer one but usually its the other way around) because new discs won't play on these old versions anyway (because of the new Processing Key used in the new MKB version).

So in the end breaking the HRL isn't so exiting. Breaking the DRL would be (if your drive happens to be revoked) but that can only be done by hacking/cracking each new version of a Software Player. And since there won't be much demand for it (who has their drive revoked?) and don't see this happening soon.

arnezami

[pacman2006]

Thank you Arnezami and Foxdisc. Now I understand the basics of AACS too. This is a very good thread for noobs like me to start. It gave me a much need overview.

Thanks again! :)

[HD><Blu]

@ arnezami

good work man really appreciate your help :thanks:


CU

[Socio]

This thread is a good read very educational!

Here is more on the impending revocation;

More Cracks Appear in AACS High-Def Armor (http://news.digitaltrends.com/news_printerfriendly12663.html)

[mrazzido]

On German News site "heise" ,

they write the "blueray team" brings in some month the Next generation of AACS " BD+ " .

FOX will release the first Title with the new protection!

SONY @the end off the Year!

NEWS LINK (http://www.heise.de/newsticker/meldung/88307)

[greath]

On German News site "heise" ,

they write the "blueray team" brings in some month the Next generation of AACS " BD+ " .

FOX will release the first Title with the new protection!

SONY @the end off the Year!

NEWS LINK (http://www.heise.de/newsticker/meldung/88307)

Does it sound to anyone, much like BD-J, that BD+ is still in a state of flux and may not even have been ready when Blu-Ray was released? I just hope that the early-release drives can handle BD+ when it finally hits the street.

[KenD00]

I hope they can't so that even more people are pissed off by AACS and show the movie studios how they like the brave new world...

:rolleyes:

[snipper_cr]

This has been an extremely informative read! Thank you to all who added to it to help explain it.

I know for sure I have spent quite sometime trying to understand how AACS works (reading the stick at teh top of this forum) and sure cannot get much to work (except that there are trucks and presents!)

When they revoke a player, is it some John B Hacker personal player or is it all of the same models that John has? Like if Leglit Lanny had the same player John had, would hers be disabled so to say? Or am i completely missing the concenpt here.

[FoxDisc]

When they revoke a player, is it some John B Hacker personal player or is it all of the same models that John has?
They can revoke individual devices, provided that the individual devices have different device numbers (and, equivalently, are provided with different device keys). No one here has reported opening up any hardware players, so there is not a lot of information on this subject.

A reasonable guess is that all hardware players have a different device number so that John's hardware player can be revoked without revoking any other hardware players. All copies of a software player at the same version level from the same company are likely to have the same device number and would be revoked as a group.

[louhaven]

Thank you all for the most informative writeup on AACS. Whilst the technojargon is way above my head, the down-to-earth discussion in this thread was nice to see.

Regards,

Louis
:)

[arnezami]

Thank you all for the most informative writeup on AACS. Whilst the technojargon is way above my head, the down-to-earth discussion in this thread was nice to see.

Regards,

Louis
:)

You're welcome :).

I've added a link to this thread in my sticky post (the one about the subset difference)

arnezami

[JK1974]

Hi,

I tried to understand most of the AACS hacking threads, but as I don´t have the knowledge (and time) to understand the AACS original documents, there are still some things I don´t understand clearly.

arnezami wrote at http://forum.doom9.org/showthread.php?p=995233#post995233, that on the news discs aacskeys should still give a media key if they did not chance the MKB.

If the MKB stays the same, am I correct that then only a host revocation list would be the way to stop old PowerDVD and WinDVD versions playing new discs?
What about PowerDVD´s host private key discovered and used by aacskeys? Is it exactly this one which would become invalid due to a host revocation (and which would mean that the processing keys/media keys still work but you don´t get the needed volume IDs for decrypting)?

What if they change the MKB to a new version (so called MKB v2)? In my understanding this would not change anything for us as we have the processing key, and arnezami said on "understanding AACS": Subset-Difference Tree system: essentially a giant and largely secret collection of never changing Processing and Device Keys derived from one Master Device Key (or a few)

Sorry, little confused... :)

[arnezami]

I tried to understand most of the AACS hacking threads, but as I don´t have the knowledge (and time) to understand the AACS original documents, there are still some things I don´t understand clearly.
Let me try to explain. :)
arnezami wrote at http://forum.doom9.org/showthread.php?p=995233#post995233, that on the news discs aacskeys should still give a media key if they did not chance the MKB.
If the MKB stays the same, am I correct that then only a host revocation list would be the way to stop old PowerDVD and WinDVD versions playing new discs?

If they haven't changed the "Explicit Subset-Difference Record" inside the new MKB then no new Processing Key is needed. If they inrtoduce revocations in the Host Revocation List then we (technically) need a new Host Private Key from a new player. But we already have several methods of retrieving Volume IDs so we do not really need a HPK (so Host Revocation doesn't really hurt us). In other words: if they haven't changed the "Explicit Subset-Difference Record" we basicly don't have to do anything.

But if they do change the "Explicit Subset-Difference Record" we will need to find new Processing Key(s). It is very likely that they will do this so when I talk about MKB v2 I'm assuming this will be the case.


What about PowerDVD´s host private key discovered and used by aacskeys? Is it exactly this one which would become invalid due to a host revocation (and which would mean that the processing keys/media keys still work but you don´t get the needed volume IDs for decrypting)?

Yes. It is very likely they will put this Host Private Key on the HRL. But as said above this doesn't really hurt us much.

What if they change the MKB to a new version (so called MKB v2)? In my understanding this would not change anything for us as we have the processing key, and arnezami said on "understanding AACS": Subset-Difference Tree system: essentially a giant and largely secret collection of never changing Processing and Device Keys derived from one Master Device Key (or a few)

Sorry, little confused... :)
If they change the MKB (the "Explicit Subset-Difference Record" to be more precise) then we will need a different Processing Key. The current Processing Key can still be used for decrypting all old discs though.

Hope this helps a bit ;).

arnezami

[chrismrulz]

what's to stop people selling revoked drives on ebay or something?
and if they file complaints that it doesn't work, you just say that person must have had cracks in their software player..
or exploiting it to make a virus that performs a crack known by the AACS to create unhappy owners of hd-dvd/blu-ray owners?

[mlansell]

what's to stop people selling revoked drives on ebay or something?
and if they file complaints that it doesn't work, you just say that person must have had cracks in their software player..
or exploiting it to make a virus that performs a crack known by the AACS to create unhappy owners of hd-dvd/blu-ray owners?

Nothing. There is a similar problem with used Xbox360s that have been barred from the online service because Microsoft thinks they have been tampered with. Some game stores (in the UK at least) have stopped selling second-hand 360s for this reason.

[vkarthik]

I thought that the genius hackers never use terms that commoners like me understand. But arnezami and FoxDisc proved me wrong. :goodpost: Thanks a lot!

Some things that weren't clear to me .. When you say that "player can be revoked", is it the model, or an individual player bought by some poor soul? If it is the model, wouldn't everyone who bought it suffer? Is there any way to get the player to work again - may be with an updated firmware that has new device keys?

[LoRd_MuldeR]

Some things that weren't clear to me .. When you say that "player can be revoked", is it the model, or an individual player bought by some poor soul? If it is the model, wouldn't everyone who bought it suffer? Is there any way to get the player to work again - may be with an updated firmware that has new device keys?

If I got that part correctly: If one player is revoked, than all players are revoked that share the same set of Device Keys.
And usually at least all standalone players of the same model (or even all players from the same manufacturer) share the same Device Keys.
Hence all these players would stop working for new discs, unless a Firmware update is made available.
That's because new discs would then start to require Processing Keys that cannot be derived from the "revoked" Device Keys.

With software players all copies of a certain version of a certain player software would be revoked.
But this is less critical, as you'd simply need to download and install the latest software update to get it working again with new discs.
...given that you own a license for the player software -and- the developer continues to release updates.

[Mug Funky]

from what i understand of the situation, standalone players can be revoked individually, in the same way that every hardware dongle for a piece of software can be different.

but if one whole line of players share the same keys, a simple firmware update should give them new keys.

[FoxDisc]

Some things that weren't clear to me .. When you say that "player can be revoked", is it the model, or an individual player bought by some poor soul? If it is the model, wouldn't everyone who bought it suffer? Is there any way to get the player to work again - may be with an updated firmware that has new device keys?

It depends on how the "player" was designed, but the best information I've seen indicates that all software players of a specific version have the same device keys and are revoked together as a group, while each individual hardware player has a unique set of device keys and each one can be revoked individually. The revocation procedure is very flexible, so they could revoke whole groups of hardware players if they want to, but they wouldn't have to.

AFAIK, no hardware players have ever been revoked, it's only been software players. The decryption process differs slightly between hardware and software players.

As to whether the device keys can be changed by firmware update - I don't know. I suspect it would be possible, but have never seen any definitive information on this.