January 20, 2019

Archives for January 2007

AACS: Title Keys Start Leaking

[Posts in this series: 1, 2, 3, 4, 5, 6, 7.]

Last week we predicted that people would start extracting the title key (the cryptographic key needed to decrypt the contents of a particular next-gen DVD disc) from HD-DVD discs. Indeed, it turns out that WinDVD, a popular software player that runs on PCs, leaves the title key laying around in memory when it finishes playing a disc. This may seem like an elementary mistake, but it is more common and harder to avoid than you might think. Fairly easy methods for capturing these keys are already well known.

There are even websites, such as aacskeys.com and hdkeys.com, that claim to contain title keys for about fifty HD-DVD discs. (That’s about one-third of the discs available on Amazon.) At least some of these title keys are correct. Within days, expect to see a software program that downloads keys from such a site and uses the keys to play or copy discs.

So far the attackers have published most of what they know. We know which title keys they (claim to) have found, and we know they extracted those keys from WinDVD and possibly PowerDVD. As Alex explained on Thursday and Friday, a clever attacker will withhold some information strategically so as not to provoke a response from the AACS central authority.

The authority might respond by blacklisting the device keys assigned to WinDVD. To avoid angering honest WinDVD users, they might first push out a software update to WinDVD containing new keys along with new programming to better protect the keys.

But as Alex suggested last week the authority might not want to blacklist WinDVD, even if it can. As long as the attackers limit what they publish, the authority might be better off accepting the damage they see now rather than provoking more damage by cutting off the usefulness of WinDVD to the attackers. The result is a kind of uneasy equilibrium between the attackers and the central authority.

Even if the attackers want to cause maximum financial harm to Hollywood (which probably isn’t their goal), their most effective strategy is to limit how many title keys they publish. One way to do this is to give Hollywood a “release window” – a kind of grace period after each disc is released, in which the title key doesn’t get published. A site could let people upload the headers of a disc; the site would then wait N days before decrypting and releasing the title key.

Interestingly, this release window strategy resembles the studios’ current approach to extracting revenue from films, in which a film is available first in the highest-revenue format – in theaters – then later in a succession of lower-revenue formats – DVD and television. The idea is to extract more revenue from the most enthusiastic fans in early stages and pick up whatever revenue is available from everyone else later.

What’s the optimal length of the release window (for the attackers); and what is the financial effect on the studios? We can answer these questions with a simple economic model; but that’s a topic for another day.

AACS: Game Theory of Blacklisting

[Posts in this series: 1, 2, 3, 4, 5, 6, 7.]

This is the fourth post in our series on AACS, the encryption scheme used for HD-DVD and Blu-Ray discs.

We’ve already discussed how it’s possible to reverse engineer an AACS-compatible player to extract its secret set of device keys. With these device keys you can extract the title key from any disc the player can play, and the title key allows anyone else with the same disc to decrypt the movie. Yesterday we explained how the AACS central authority has the ability to blacklist compromised device keys so that they can’t be used to decrypt any discs produced in the future. This defense is limited in two obvious ways: the central authority needs to know which keys have been compromised in order to put them on the blacklist, and this only protects future discs, not ones that have already been produced.

It turns out there’s a third way in which blacklisting is limited. Counterintuitively, it is sometimes in the central authority’s best interest not to blacklist a compromised device key even when they have the ability to do so.

We can model one such scenario as a simple game between the central authority and an attacker. Suppose there is only one attacker who has compromised a single player and extracted its device keys. Initially, he keeps the device keys secret (for fear they will be blacklisted), but he and his friends acquire some number of discs every week and post the title keys on the web. Let’s also suppose that the central authority has enough resources to infiltrate this cabal and learn which player has been cracked, so that they can blacklist the device keys if they wish.

The authority faces a very interesting dilemma: if it does blacklist the keys, the attacker will have no reason to keep them secret any longer. He will publish them, irrevocably breaking the encryption on all previously released discs. If the authority doesn’t blacklist the keys, the attacker will continue to trickle out title keys for certain movies, but the rest will remain secure.

In other words, the authority needs to weigh the value of continuing to protect all the old discs for which title keys have not been published against the value of protecting the new releases that will be cracked if it doesn’t blacklist the keys. The result is that the central authority will need to exercise more restraint than we would naively expect when it comes to blacklisting. Once attackers realize this, they will adjust how quickly they release title keys until they are just below the threshold where the authority would resort to blacklisting.

Things get even more interesting if we consider a more realistic scenario where different players are gradually cracked over time. We’ll write more about that next week.

AACS: Blacklisting, Oracles, and Traitor Tracing

[Posts in this series: 1, 2, 3, 4, 5, 6, 7.]

This is the third post in our discussion of AACS, the encryption scheme used for HD-DVD and Blu-Ray discs. Yesterday Ed explained how it is possible to reverse-engineer a player to learn its secret device keys. With the device keys, you can extract the title key for any disc that the device can play. Anybody with the same disc can use this title key to decrypt the movie.

We’ve already talked about two scenarios where this information could be used for widespread circumvention. One possibility is for the attacker to keep the device keys to himself and publish title keys for discs he has access to. This means anyone can decrypt those discs, but other discs remain secure.

Another option is for the attacker to publish the device keys outright. That would let anyone decrypt any available disc, but it would also tell the AACS central authority which device keys were compromised. Once the central authority knows which device keys to target, it can blacklist those device keys.

Blacklisting in AACS works like this: disc producers can change the way new discs are encrypted so that the blacklisted device keys cannot decrypt the new discs’ headers and therefore cannot extract title keys or decrypt the movies. Of course, blacklisted device keys can still decrypt all the older titles they could before, since the data on old discs doesn’t magically change, but they can’t decipher any new discs.

Blacklisting would be a PR and business disaster if it meant a lot of consumers had to throw away their fancy players as a result of a crack. That’s why AACS allows each individual player to be assigned its own unique set of device keys that can be uniquely blacklisted without adversely affecting other players.

(Some serious crypto wizardry is required to enable a huge number of distinct device keys with surgically precise blacklisting, while keeping device memories and disc headers manageably small.)

Can blacklisting be avoided? Here’s one way an attacker might try: He could keep his device keys secret and create a web site where people can upload header information from discs they want to decrypt. Then he would use his device keys to extract the title keys for those headers and post the title keys back to the site—a sophisticated attacker might automate this process. Cryptographers call this kind of site a decryption oracle.

As it turns out, the designers of AACS anticipated decryption oracles, so the system includes a way to track down and blacklist the device keys used to operate them. This process is called “traitor tracing,” and it works roughly like this: The central authority creates a phony disc header that can be decrypted by about half of the possible devices. (They just need the header, so there’s no need to press an actual disc.) They upload this to the oracle and see whether it can find the title key. The result lets the authority narrow down which devices the oracle’s keys might have come from. The authority repeats the process, creating a new header that will reduce the set of suspects by half again. With a few of these probes, the authority can home in on the oracle’s device keys.

(The full story is more complicated. The oracle might know keys from more than one device; it might try to trick the authority by pretending it can’t decrypt certain headers when it really can; it might try to detect the authority’s probing and change its behavior; and so on. Regardless, the authority can use a sequence of probes to devise a blacklist that will make new discs immune to decryption by the oracle, without affecting noncompromised players.)

The upshot is that if the attacker makes an oracle available to the public, the central authority can render the oracle useless for future discs. However, a clever attacker has another surprisingly effective strategy: limiting who can submit queries to his oracle. We’ll have more on that in tomorrow’s post.