Some additional thoughts on attacking AACS

| Comments (12) | DRM SYSSEC
Ed Felten and Alex Haldeman have a nice series of posts about AACS, the content control system on HD-DVD and Blu-Ray. You should really go read the posts, but here's what you need to know (somewhat simplified)
  • Each player has its own key (actually set of keys, more detail here).
  • Because of the way disks are manufactured you need to have the same content on each copy, or at least to produce large batches of identical disks. So, there are a lot of movies encrypted with the same key (what's called the title key).

Given the title key, BackupHDDVD can decrypt the content of a disk. If you can compromise a single player and recover its key, you can use that to recover title keys which, of course you can use to decrypt disks.

Where this all went wrong with CSS was there were only a small number of keys, so once you compromised one player and published the key the game was pretty much over. But with AACS each player has a unique set of keys and the AACS includes a scheme for revoking compromised players. When a player is revoked you stop encrypting disks under its key, so it's useless for all future disks, but all disks printed before that time are (at least potentially) compromised. So, if you compromise a player and publish its key, it has a finite window of usefulness.

However, if software players are widely available, the situation is different. There's a large population of keys already available to people and all the attacker needs to do is release a piece of software which extracts the player keys from a player or patches an authorized player to either disclose title keys or the unencrypted data on a disk (as Felten observes), WinDVD already more or less is such a player, but that's presumably a somewhat temporary situation). There are of course techniques you can use to make it harder to hack software, but as far as I can tell none of them stand up to dedicated attack.

It's of course possible for the manufacturers to revoke all the players by a particular manufacturer and force them to download a new player with better tamperproofing. This has two drawbacks. First, the cost is much higher than just revoking the compromised unit because you're not just inconveniencing the attacker but everyone who happens to have a vulnerable player and most of those people are totally innocent. Second, because it's comparatively easy to break the tamperproofing the attacker can force you to incur this cost more or less whenever he wants.

It's hard to see how the studios can really solve this problem as long as purely software players are allowed.

12 Comments

"So, if you compromise a player and publish its key, it has a finite window of usefulness."

Aren't you kind of assuming that consumers will be willing to put up with their HD-DVD/Blu-Ray players suddenly no longer working? Let's say I spend $200 to buy a bluray player at best buy, and 6 months later some kid cracks its key and the bluray industry decides I can no longer watch movies on my bluray player -- sounds likely to result in:

1. Huge support costs as everyone calls in to find out why their player isn't working
2. Hugely pissed off customers as everyone finds out that through no fault of theirs, the movie industry has decided to fuck them
3. Lawsuits

The way that AACS is constructed you can invalidate specific individual players. So in the case of a hardware player the only way that some kid would be able to crack its key is if they had physical access, i.e., if it was your kid. So, I think in that case you wouldn't have much grounds for complaint if your player was then invalidated.

With software players, of course, the situation is different, as indicated in this post.

EKR,
hardware players do not have individual device keys. Each production shares the same key. Device revocation will be in the thousands to tens of thousands at a clip.


Stand alone players will be exploited for harvesting title keys. It is not that hard at all for individuals with a good amount of know how and common equipment to extract the processes and the title keys. My guess is that base is in the high thousands. If a hundred have the interest, and there is a powerful interest in subculture involved, the title keys are just going to keep showing up in the wild. Device revocation will never catch up no matter how draconian.

Today there are close to a billion DVD readers in circulation. (perhaps you have two stand alones, one or two in each pc, a console, and one or two at the office -- then there is a installed or portable player in your car!) There are a thousands different reader/chipset combinations. If revocation starts with HD/BrD while a small number are on the market it will stall the market for players and content. Once more are on the market identification and revocation process will take longer.

I have not seen any authoritative information about whether individual hardware players will have unique keys or not. My guess is that they will be unique because the system is heavily engineered around a revocation infrastructure, and that would be politically very difficult if revocation invalidates thousands of innocent machines. I don't know how reliable Red's claim above is to the contrary.

One missing point is the difficulty of figuring out the player key from the information released. From what I understand there will be some watermarking in the video which is supposed to encode the player key. This relies on what is called a "sequence key" mechanism. Reports are that the initial batch of HD-DVD movies are not yet encoded with sequence keys, hence at this point there seems to be no way for the AACS to figure out which player key to revoke (other than monitoring the hacker boards). Presumably the manufacturers will start phasing in the more elaborate protections as the disks become more popular.

You are all missing the point about AACS and HD DRM as to it intent--it isn't about professional copying at all. Sophisticated professionals will always have the knowledge, money, and time to break any mass-produced protection. The dirty little secret of media industry DRM is that it is really an attempt to destroy fair use and limit options of teh average consumer so they can be charged for each and every use. The content industry are even starting to admit it quietly. And the AACS regime is adequate to acheive that objective for the majority of the customer base. They don't care if a few sophisiticaed folks break it--although they'll try to stop you if they can. They've already factored that into their profit calculations.

Even in the absence of sequence keys, Felten and Haldeman do describe how to do "traitor tracing" in cases where a hacker creates a decryption oracle. Obviously, if the hacker limits his decryption to DVDs in his possession or that of trusted friends, traitor tracing doesn't work. But then the scope of compromise is limited by the ability of the hacker to get trusted access to DVDs--which admittedly might not be much of a limit.

I am very skeptical that there will be "decryption oracles". There is no precedent AFAIK for any such illegal service provided by the hacker community. This smacks of an attempt to take a mathematical result and find some real-world scenario that matches it. I suggest that our analyses will be more successful if we try to make our models fit the world rather than hoping that the world will conveniently fit our models.

Let's set aside software players for the moment. Consider satellite dishes--hackers actually sold compromised hardware. So clearly there is a precedent for hackers offering compromise services when hardware is involved.

Given the lower barrier entry for offering oracle-like services compared to shipping hardware, I don't think it's too much of a stretch for hackers to leverage file sharing networks to offer decryption services. With the RIAAs past attempts to infiltrate such networks, attempting to implement traitor tracing seems like a reasonable response in that case. I'm not saying it's likely, just that it's not a wholly unrealistic scenario.

But as Eric notes, software players are the real problem.

There are of course techniques you can use to make it harder to hack software, but as far as I can tell none of them stand up to dedicated attack.


What about Trusted Computing?


Imagine this scenario:



  1. Player keys do not ship with the software.

  • The first time you start a software-based player, it obtains its key. It does this by contacting a remote service. It uses the TPM's remote attestation feature to provide an unforgeable certificate of all the software (OS up to application) that is currently running on the machine.
  • If the remote service trusts that software stack, it sends back the key (encrypted with some transport-level security so you can't sniff it). It trusts the OS to deliver it straight to the application, and not persist it anywhere.
  • Once the key is delivered to the application, it is persisted in sealed storage, which guarantees at a hardware level that no other stack of software can access it. So you can't just boot Linux and dump all physical storage.


  • Unless you can compromise a trusted OS or application, I think this scheme can make even pure-software players secure against attack.

    When I wrote "pure software players" I meant to be ruling out TC, which requires specialized hardwre.

    louis vaton purse louis vaton wallet [url=http://lvuitton.150m.com/louis-vaton-purse.html]louis vaton purse[/url]

    "Unless you can compromise a trusted OS or application,"

    If you own the hardware it's running on, you can. Period. It can be made harder, but it can't be prevented. Bottom line, run the machine under a hardware debugger.

    Leave a comment