AACS: Blacklisting, Oracles, and Traitor Tracing. 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[base ']Äô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[base '] 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[base ']Äôt magically change, but they can[base ']Äô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[base ']Äô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[base ']Äô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 [base ']Äútraitor tracing,[base ']Äù 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[base ']Äô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[base ']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[base ']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[base ']t decrypt certain headers when it really can; it might try to detect the authority[base ']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[base ']Äôll have more on that in tomorrow[base ']Äôs post.
Share This
[Freedom to Tinker]
4:37:11 PM  PermaLink /
|
