AACS- how it works and its attacks

Here is a brief overview of AACS, a DRM mechanism used in Blu-ray disk and HD DVD.

The algorithm used for (Cryptographic) Key Distribution and Revocation process is core

to the AACS security. Naturally, a good amount of effort has been put into making this

mechanism better in AACS taking into account that it was broken in CSS

(Content Scrambling System). CCS is used in DVDs and has led to the failure of DRM

enforcement on them.

How AACS works:

AACS uses a popular algorithm called Subset Difference Revocation (SDR) for key

assignment and revocation. SDR has led to many papers in the Crypto conference.

Many of them are variants or enhancements over the basic SDR algorithm.

In the SDR algorithm, cryptographic keys (used for encryption) are represented as a

complete (full) binary tree. For AACS, a tree with 32 levels is used. That means 2³²

unique keys are generated.

The leaf nodes of this tree represent both hardware and software devices. The keys

assigned to the leaf nodes are called device keys. Each device stores a subset of keys

from the binary tree. The subset of keys is formed in such a way that only devices whose

keys are not revoked are able to decrypt the content. In other words, the revoked devices,

even if they all collude won't be able to decrypt the content using their keys. This is the

core of Subset Difference Revocation method.

In Figure 1, a simple binary tree is shown. The leaf nodes n8 – n15 represent the devices.

Ki,j means the key associated with node nj assigned with subtree rooted at ni .

For example, the device n8 stores the keys: k1,3 k2,5 and k4,9. Here, k4,9 is the key

associated with node n9, assigned with subtree rooted at n4. Note that the keys stored

in device n8 are associated with its ancestor's siblings all the way up the root of the tree-

n9, n5 and n3.

Click here to view Figure 1

Diving one more step into the details of how this works, the subset of keys on a device

(referred to as device keys) are not directly used in encrypting the media content.

They are used in deriving a key called "Media Key" which is used in content encryption.

The media key is encrypted using a carefully formed subset of device keys. A new media

key is generated for each title just like a new secret key generated in each SSL session.

The content on the disk is encrypted as below:

[n₁, n₂, …,n_m], E_{k1 (K),} E_{k2 (K),} … , E_{km (K) | (EK}(_M)

Where, n₁, …,n_m are subset of nodes of the binary tree, whose keys k₁, …,k_m are

used for encrypting the media key K. The content M is encrypted using the media

key K.

Note, the subset of nodes is formed in such a way that the non-revoked leaf nodes can

derive one of the keys _ki from the set: _{k1, .. ,km} using node information n_i from the

set: _{n1, ..,nm.} In Figure 1, the media key is encrypted using the set: {k1,3 k1,2}

Here is an interesting part of the SDR algorithm when a device is compromised, its keys

need to be revoked. The subset of keys associated with a device or a leaf node includes

keys for its ancestor's siblings but not the key associated with itself or its ancestors all the

way up to the root of the tree. The subset of keys for the leaf nodes in the binary tree

of Figure 1 is shown at the bottom of the tree. Also, using GGM algorithm, described later,

given a root key K, it is possible to derive the keys for its left child K_L and its right child K_R.

A leaf node in the binary tree is able to derive keys for all the nodes in the subtrees rooted

at its ancestors but not its own key or its ancestor's keys.

Click here to view Figure 2

When a device needs to be blocked from decrypting the media key, the key corresponding

to that device is used for encrypting the media key. That's because the revoked device

cannot derive its own key.

When there are multiple devices that need to be blocked, a subset of keys is formed such

that only non revoked nodes are able to decrypt the media key.

In Figure 2, nodes n8, n9, n12, n14 are marked as revoked. According to SDR algorithm,

the following set of keys is used for encrypting the media key:

{k2,4 k6,12 k7,14}

For more information on SDR algorithm please refer to this presentation.

Device keys:

Device keys are assigned by AACS LA. A set of device keys may either be unique per device

(they do are unique on each hardware player), or used commonly by multiple devices

(typically the software players distributed by a specific software vendor carry same set of device

keys). It is expected that each device or player manufacturer treat these keys as highly

confidential. AACS uses 128-bit AES keys as opposed to 40-bit DES keys used by CCS in

DVDs.

What is GGM?

The algorithm to determine the set of keys (to be held the device) need to take into consideration:

1. The storage required by the keys that depends on the number of keys.

2. Processing requirement for the device - time taken for each decryption and the number

   of times a decryption is performed.

In addition to using SDR algorithm, a key generation techniue called GGM (Goldreich,

Goldwasser & Micali) is used. This technique helps in keeping a small subset of keys that are

stored on each device and a short encrypted header (for retrieving the media key).

Given a key K for the root node, one can derive K_L -key for the left child and K_R -the key for the

right child.

AACS Attacks:

First report:

The first attack was reported by a programmer, who identified himself as Muslix64, announced

in the Internet discussion forum Doom9 on Dec. 18 2006. This programmer said he has

successfully copied movies distributed in the HD-DVD format. Decryption keys were extracted

from a weakly protected player (WinDVD^?)

In an accompanying video demonstration posted on the YouTube^? Web site, the programmer

showed encryption keys for six movies (this video is not accessible any more).

--Source NY Times (Jan 1st 2007)

Second Report:

SlySoft, an Antigua-based company that sells software to defeat various forms of copy protection,

updated its AnyDVD^? (a commercial) product to allow it to copy the new AACS discs. Apparently,

SlySoft had extracted a key from a different player and had kept the attack a secret. They waited

until all other compromised keys were blacklisted before switching to the new one. And they came

out openly 6 days after the new discs came out with updated keys

Why Revocation has not worked as expected in AACS?

After noticing the complexities surrounding AACS, the question that bothers is that, if some of the

keys are exposed by hackers why isn't there a mechanism to revoke those keys and move on?

There seems to be a deployment problem with the way revocation works now:

AACS license agreements allow 90 days for the player vendors to update the revoked keys,

which is considered to be a very long period, that puts AACS and the studios in trouble.

The website: http://www.freedom-to-tinker.com/?p=1158 points out that that-

“at this point, Hollywood has released four generations of AACS-encoded discs, each encrypted

with different secret keys. The industry is stuck on a treadmill: AACS changes keys every ninety days,

and attackers promptly reverse-engineer the new keys and carry on decrypting the discs. And they

wait and then publicly release the keys one by one, after a new disc has come out with different set

of keys.

To be successful in the long run, AACS needs to out pace such attacks. Its backers might be able

to accelerate the blacklisting cycle somewhat by revising their agreements with player

manufacturers, but the logistics of mastering discs and shipping them to market mean the shortest

practical turnaround time will be at least several weeks. Attackers don’t even have to wait this long

before they start to crack another player. Like Slysoft, they can extract keys from several players

and keep some of them secret until all publicly known keys are blacklisted. Then they can release

the other keys one at a time to buy additional time. “

While, AACS is the only protection that HD-DVD, Blu-ray claims that BD+ can further enhance

Blu-ray disk security. Below is some information gathered from the web on BD+.

What is BD+ ?

BD+ lets Blu-ray Discs install and run a piece of encryption software on the player, allowing each

title to have it's unique encryption scheme. Hacking into a protected disc only affects that single

copy, it won't cause security breaches across the board for the same title.

BD+ can detect tampering to a player, refusing to play once the intrusion is discovered. Sony and

other studios that support Blu-ray believe this technology produces a secure, yet user friendly

product that only punishes hackers for copy right violations.

BD+ was developed by Cryptography Research Inc. and is based on their Self-Protecting Digital

Content concept. BD+ is effectively a small virtual machine embedded in authorized players.

It allows content providers to include executable programs on Blu-ray Discs.

On November 19 2007, Macrovision announced that it planned to acquire the SPDC technology

(including patents and software code) from CRI for US$45 million in cash plus stock warrants.

On November 8, 2007, SlySoft^? announced that they had completely cracked BD+. This turned

out to be not quite correct however. The crack allowed a user to copy a BD to the hard drive and

play it back from there using only a specific version of Cyberlink's PowerDVD^?, but not to transcode,

otherwise manipulate the content or play it back from a burned BD-R or BD-RE.

References:

http://www.aacsla.com/ (AASC spec)

http://www.aacsla.com/news/

http://www.wisdom.weizmann.ac.il/~naor/PAPERS/stateless.ppt (SDR Algorithm)

http://www.freedom-to-tinker.com/?p=1158 (discussion on AACS attacks)