AACS TUTORIAL

Advanced Access Content System Tutorial ff Lotspiech

Jeff Lotspiech jeff@lotspiech.com November 17, 2006 Version 0.8

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 1

11/21/2006

AACS TUTORIAL

Table of Contents
Purpose and Audience.....................................................................................3 Introduction .......................................................................................................3 NNL Key Management.....................................................................................3 Drive Authentication .........................................................................................6 Content Signing, Watermarks, and Playback Control.....................................8 Device Robustness and Proactive Renewal.................................................9 Key Conversion Data ...................................................................................12 Sequence Keys ..............................................................................................13

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 2

11/21/2006

AACS TUTORIAL

Purpose and Audience

This document is primarily intended for licensees or potential licensees of AACS, especially manufacturers who are building new DVD players. It is based on the publicly available specifications and licenses, which are available from the AACS web site. It is not my intention to regurgitate these technical details; instead I want to explain the framework in which these details make more sense. Although I have been involved at times in the development of the AACS specification, nothing I say here should be construed as the official AACS party line; this is just one consultants opinion.

Introduction
The Advanced Access Content System, or AACS, is the system that protects the new generation of DVDs from unauthorized copying. Unlike the protection system of the previous generation of DVDs, called the Content Scrambling System or CSS, AACS is based on soundin fact, state-of-the-artcryptographic primitives. For example, it has an accurate and unlimited revocation capability. AACS consists of several new technical elements: A media key block based on the NNL tree. Two-way public-key drive authentication in the PC environment. Digital watermarking and content revocation. Device robustness and proactive renewal. Key conversion data. Sequence keys. These items are explained in more detail in the following sections.

NNL Key Management

NNL stands for Naor/Naor/Lotspiech, after the inventors of this technology. Of course, I am Lotspiech, and you would expect that at "lotspiech.com" I would emphasize my contribution. Actually, the reverse is true. The main elements were invented by the two Naors (Moni and Dalit, husband and wife) before I got involved. I was Dalit's manager at IBM at the time, and perhaps my only major claim to fame was recognizing immediately that this was an important development. The NNL key management scheme (also called the subset-difference scheme) is as efficient as a public-key system in revoking compromised devices, but unlike a public-key protocol, it does not require devices to have two-way conversation to establish a shared key. This one-way property is called "broadcast encryption" in the cryptographic literature, and it is critical in protecting content on physical media. A disc replicator wants to make a protected movie disc, and a player wants to play it back, without requiring the replicator to communicate the key it used to the player. After all, the player may not even exist when the disc is made, and the replicator may be out of business when the player finally gets around to playing the disc.

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 3

11/21/2006

AACS TUTORIAL

What is needed, then, is some data on the disc that allows both the replicator and the player to agree upon a common key, without even knowing of each other's existence. This piece of data is called the media key block, or MKB. It would be easy to make an MKB the way the existing DVD protection scheme did: assign a unique key to each manufacturer, and then create an MKB that encrypts the disc key over and over again in each manufacturer's key. But then the scheme is at the mercy of the first 16-year-old who discovers one of the manufacturers' keys: it becomes impossible to "revoke" that key without affecting perhaps millions of innocent consumers who own devices using that key. This is exactly what happened with DVD CSS. The system is irretrievably broken. The other obvious alternative, having a unique key for each device, would mean that the media key block would be far too large. There will be about one billion DVD players built over the life of the system, and if each one needed a separate encryption, there would be no room for the movie. The secret is for each device to have a set of keys rather than a single key. Many of those keys are shared with other devices, but no two devices have exactly the same set of keys. It then becomes the job of the licensing agency, which assigns the keys to all the devices, to produce MKBs that allows all uncompromised devices to calculate the disc key correctly, but allows none of the compromised device to do the same thing. In other words, the licensing agency must find a set of keys such that every uncompromised device has at least one of those keys, and none of the compromised devices have any of them. An MKB then becomes the encryption of the disc key, over and over again, in each of these very carefully picked device keys. The NNL scheme is unique because each device knows literally billions of keys. Of course, your device does not have to store all these billions of keys. Instead, it needs to store only 253 keys, and from those, it can calculate the other keys as it needs them. With all these keys to choose from, the licensing agency can always find a small set of device keys that include all the non-compromised devices while excluding every compromised device. Thus the licensing agency can produce a very concise media key block, the hallmark of the NNL scheme.

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 4

11/21/2006

AACS TUTORIAL

Figure 1: Example NNL tree

How does this all look to you, when building a device? The device keys are organized in a tree structure, and each device is associated with a single leaf in the tree. In the simple figure above, assume you are device "4". (Of course, the real AACS system has more than 16 devices231 devices, to be exact.) Let's talk about how nodes in this tree are identified. A node is denoted by its path from the root, with "0" bits meaning "left", and "1" bits meaning "right". Your node is therefore "0100". Interesting, you are device 4, and your node is the binary representation of 4. This is not an accident. What about nodes that are not at the leaves of the tree? Look at the node labeled "u" in the figure. It would be denoted as "0xxx". How does AACS show an "x" instead of a "0" or "1"? They do it by having two values, the path and the mask. The mask denotes which bits are significant. The mask for "u" would be "1000". In other words, only the high order bit is significant, the low order three bits are "don't care" or "x". When your device processes a media key block from AACS, it will encounter a list of socalled subset-differences. (This list is in the Explicit Subset-Difference Record in the MKB.) A subset-difference identifies a set of nodes in the tree, by identifying a root node (called "u" in the specification) and difference node "v" underneath it in the tree. The meaning of this is that the subset-difference is the set of all the nodes that are in subtree rooted in "u" but not in the subtree rooted in "v". For example, if you see a (u,v) subsetdifference (0xxx,0110), the "u" subtree contains all the devices from 0 to 7. The "v" subtree is simply the leaf node for device 6. Thus, this subset-difference applies to devices 05 and device 7. (Device 6 is being revoked by this subset-difference.) Since you are device 4, you are in this subset-difference. The MKB will also have one or more other subset-differences to cover the uncompromised devices in the set 8-15, but

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 5

11/21/2006

AACS TUTORIAL

this is the only one you have to worry about. How did you calculate that you were in this subset, exactly? The "u" node (0xxx) is equal to your node (0100), when you realize that the "x"s are don't cares. The "v" node (0110) is not equal to your node. The simple rule is: if your node equals "u" but does not equal "v", the subset-difference applies to you. Each subset-difference is associated with a different device key, and you know the key for every subset-difference you belong to. This means you know the key, for every node in every subtree you are in, as long as the node is not on the path between you and the root of the subtree. It also means that each subtree has a completely independent system of keys. Because you can calculate keys lower in the tree using the one-way function described in the AACS specification, you actually do not have to store all those keys. Let us see what keys your device 4 has to store: In the subtree rooted at 010x, you must store the key for 0101. In the subtree rooted at 01xx, you must store the keys for 0101, and 011x. You can use the one-way function to derive the keys for 0110 and 0111. In the subtree rooted at 0xxx, you must store the keys for 0101, 011x, and 00xx. The one-way function gets you the rest. In the subtree rooted at xxxx (i.e., the whole tree), you must store the keys for 0101, 011x, 00xx, and 1xxx. The one-way function gets you the rest.

Going back to our example, using your stored key for (0xxx, 011x), you run the one-way function to derive the key for (0xxx, 0110). You do one more one-way function to produce the so-called process key. In another record in the MKB (the Media Key Data record), there will be an encryption of the media key with this process key (as well as encryptions of the media key with other process keys for other subset-differences of other groups of devices not in your subset-difference). You use your process key to decrypt the media key, which then allows you to decrypt all the other keys which are protecting the content on the disc. One note of warning: the value you decrypt from the Media Key Record is not exactly the media key. Instead, as explained in the AACS specification, it is the media key XORed with the value of the "v" path. This avoids a subtle cryptographic attack that is present when a single value is encrypted with many different keys. This ensures that the values encrypted in the MKB are different for each subset-difference.

Drive Authentication
All media protection schemes, if they intend to run on open platforms like PCs, are susceptible to an attack called the Virtual Device Attack. In the DVD version of this attack, the attackers build a device driver that pretends to be attached to a real DVD drive. Instead of having an optical disc, the users of this attack have an image of the legitimate disc on their hard disk. The user invokes a completely legitimate software player to play this disc. Note that attackers never learn the content on the disc in the clear; nonetheless, they have succeeded in making copies of disc. The encrypted disc images, which users share on their hard discs, act as unauthorized copies. The defense against this attack is for the drive to prove that it is a legitimate drive. It does this, of course, by having one or more cryptographic keys. Cryptographers would call this authentication. Authentication protocols are very common in the cryptographic literature,

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 6

11/21/2006

AACS TUTORIAL

where they are invariably based on public/private key pairs. Interestingly, authentication can be done just as securely using broadcast encryption (MKBs). Nonetheless, AACS went the more conventional public-key route. The protocol AACS uses is a version of the well-known Diffie-Hellman protocol. I will explain this later. Authentication protocols are almost always two-way: for example, not only does the DVD drive prove to the software player that it is a legitimate drive, but the software player proves to the drive that it is a legitimate player. The drive would not even release the AACS data on the disc unless the player is legitimate. This seems eminently logical until you look at it more closely. Circumvention software should be blocked because it cannot process the MKB; why does the drive need to further verify this? Also, public-key cryptography is based on revocation lists. How does the drive get the latest revocation list? If the source of the list is coming from the PC, then, of course, the circumvention software will block it. AACS has gone the extra step to make this two-way authentication useful. The drive is required to have non-volatile storage to save the most recent host revocation list it has seen. Furthermore, the drive finds the host revocation list in the lead-in area of the DVD disc, so it can read the list without having to understand the disc's file system. Any time an AACS disc is inserted into a drive, the drive reads the host revocation list and updates its non-volatile storage if the new list is more recent than the one it is currently storing. Now that the AACS drive has an independent source of revocation information, the twoway authentication has a value above and beyond the revocation inherent in the MKB. Imagine a user has a piece of circumvention software that he is using to rip rental movie discs. He rents a new disc and wants to make an unauthorized copy. Let us say that the MKB on this new disc excludes his circumvention program, so he would never have been able to rip the disc. However, if he makes the mistake of putting the disc in his PC, his drive will be updated, and he will no longer be able to use his software to rip any old discs that he were to rent. However, there is still a subtlety: what prevents the user from running a completely legitimate player to handle the handshake with the drive, and then block that player, letting the circumvention software take over? The answer is that the handshake needs to allow both sides to agree upon a secret key, and encrypt the data coming from the drive in this key. This is a double encryption; the data on the disc is already encrypted with key(s) derived from the media key block. AACS anticipated this bus encryption, but due to practicalities drives are not yet required to implement it. They are required to implement the authentication protocol, however, and use the secret key that results (the key that would be used to do bus encryption) to authenticate certain critical values from the disc, such as the volume ID and the pre-recorded media serial number. It is probably worthwhile for me to do a short overview of the Diffie-Hellman protocol which establishes that secret key. Consider the following equation: y = xz mod P (where mod P means the remainder after dividing by prime P). It is believed that, if the numbers are sufficiently large, it is intractable to calculate z given x, y, and P. This is called the discrete logarithm problem. Now imagine drive knows a secret x and the host knows a secret y. They also agree upon P and another number g. Then the drive sends gx mod P to the host, and the host sends gy mod P to the drive. The drive can calculate (gy)x and the host can calculate (gx)y. These two values are, of course, identical, and they have been established in a way so that any device in the middle, even though it can observe the

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 7

11/21/2006

AACS TUTORIAL

values passed back and forth, cannot calculate that value. In order to do so, it would have to solve the discrete logarithm problem to determine either x or y. In actuality, AACS requires that this protocol be performed using elliptic curve calculations. Logically, this is equivalent, but elliptic curve calculations are both more complicated and better suited for hardware implementation. See, for example, the Certicom Inc. site for an explanation of elliptic curve cryptography.

Content Signing, Watermarks, and Playback Control

These new technical features of AACS are intended to help movie studios to combat commercial piracy of their movies. To the first approximation, pirate DVDs come in two types: 1. DVDs released during the theatrical window, when the movie is only available in theatres. The quality of these pirate videos can range greatly, from poor camcorder recording made in the theater, to videos made with professional equipment using a borrowed theatrical print. 2. DVDs released during the video window, when legitimate DVDs of the same movies are also available in the market. Generally, the video in these pirate DVDs are based on the legitimate DVD, so they are high quality, and may have the same bonus features. In addition, they may be augmented with market-specific features like a Russian soundtrack or Chinese captions. AACS's first line of defense against commercial piracy is a digital watermark. During the period of AACS's interim license, the watermark obligation is not yet in force, and players built now need not implement a watermark detector. In the interest of completeness, however, I will explain the logic behind the watermark. The AACS watermark is an inaudible signal that can be optionally inserted in the soundtrack. There are two watermarks. The first is the theatrical mark, which the studio may insert into the soundtrack of its theatrical prints (but not into the soundtrack of a legitimate DVD). Your device, when playing video off an optical disc, must check for this watermark. If you detect it, you must stop playing the video; the disc must be a type 1 pirate disc. The second watermark, the consumer mark, is used to combat type 2 pirate discs. The studios may optionally insert this inaudible watermark in their legitimate, authorized discs. If your device detects the watermark while playing a video from an optical disc, it must stop playing if it is not playing in an authenticated format. What is an authenticated format? You can refer to the AACS license for the specifics, but fundamentally, signed AACS content is authorized, whereas unsigned in-the-clear content is not. DVD CSS-protected discs, because the CSS scheme has been broken, are unauthorized unless they have been validly signed. AACS has not yet defined the details of the signatures on CSS discs. Note that your device will play all existing DVD CSS discs, both authorized and pirate: they will not have the watermark. If your device finds this watermark in a new DVD CSS disc that has not been signed, it must be a type 2 pirate disc and your device should not play it. AACS recognized that there might be a few rather obscure cases in which the consumer mark might be detected for a short period in legitimate content. For example, imagine you are making a video of your child's birthday party, while the kids are watching a Disney

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 8

11/21/2006

AACS TUTORIAL

movie off a DVD. There is a chance that your video might pick up enough of the soundtrack to detect the watermark. For that reason, as specified in the final AACS license, your device should not immediately stop playing upon detection. Instead, the detection has to be repeated for a significant period before action is taken. This is not true for the theatrical watermark. AACS could think of no legitimate reason for that watermark to be detected in non-pirate content. So far, this scheme seems to have a hole: pirate replicators could effectively launder the authorized distribution watermark by simply encrypting their pirate disc in the AACS format. To plug this hole, AACS discs must be digitally signed by the AACS licensing agency, and the licensing agency will only sign on behalf of licensed replicators. It is still possible that a licensed replicator might go bad, and start producing validly signed type 2 pirate discs. Thus there is a revocation list; your player is required to store the latest version of this that it has seen, and refuse to play any discs on the list. By the same token, your device is required to verify that the signature (the content certificate) does, in fact, correspond to the content on the disc. AACS has defined a hierarchy of hashes define the disc content; you are not required to check everything, but you are required to randomly spot-check throughout the disc. There is one final hole: the pirate copy could be an exact bit-for-bit copy of a legitimate disc; I call that a lithographic copy. This can happen if a contracted replicator does an overrun without informing the studio, or a third-party strips the plastic off of a disc they have purchased in the market, and use it as a master. In these cases, of course, the signature will verify, and revocation is impossible because legitimate discs with that certificate exist in the market. Under this attack, the technical means AACS has defined are no longer effective (although it has been announced that the new Blu-ray DVD format addresses this attack by confidential technical means they call the ROM mark). Also, there are ample non-technical means to combat this attack.

Device Robustness and Proactive Renewal

All content protection schemes must have robustness requirements. These are the clauses in the license that require you as a manufacturer to make it difficult for attackers to extract secrets from your player to build a clone. Also, the attackers must not be able to easily modify your player so that it performs a prohibited function. The license is a legal document, and it is not the purpose of this section to give legal advicenot that any sane company should listen to legal advice from an engineer. Instead, the purpose of this section is to provide some background and context for the legal language in the license. The license is, of course, the final arbiter. Unlike the previous CSS scheme, AACS has a precise and accurate mechanism for revocation. Thus, occasional isolated attacks in which keys are revealed are not disastrous. Instead, the revocation mechanism can effectively prevent a clone based on those keys from accessing new content once the clone as been discovered. With this most likely attack effectively countered, AACS went on to consider other, less likely attacks. Suppose a manufacturer produces a line of players that are so poorly implemented that the average end user can download a program off the Internet, connect his PC to the player with the Ethernet connection, and run the program to extract the device keys from that particular player. The user would then use those keys in another circumvention program to rip DVDs.

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 9

11/21/2006

AACS TUTORIAL

This attack, which I call the Getkey Attack, can effectively defeat the revocation mechanism. Suppose one million players with this flaw have been produced, and ten thousand users have taken advantage of the circumvention program. Assuming the users are not widely redistributing the ripped movies, the licensing agency has no way of knowing which keys are being used legitimately, and which keys have been circumvented, so it has no way to apply revocation. The AACS license is designed to prohibit the Getkey Attack, and it offers you two alternative strategies to accomplish this. The first strategy is called proactive renewal. If you choose this approach, all of your devices will share a single set of device keys and sequence keys. You must be prepared to securely update these devices in the field with new keys periodically. At the same time, you are expected to change and strengthen your tamper-resistance implementation, especially if the old set of keys has been compromised. AACS actually enforces this periodic update by eventually revoking device keys that are out-of-date. (It only revokes the less important sequence keys if they have actually been compromised.) The proactive renewal approach is expected to be more popular on PC-based software players, especially since the alternative requires special hardware on the PC. However, special-built hardware players can use proactive renewal, and software players can use special PC hardware, so this is not a hard-and-fast rule. Obviously, if you use proactive renewal, the update mechanism must be convenient to your customers. You have to be prepared for the normal update cycle, and also for emergency updates, if your current set of keys is compromised. The second strategy for defeating the Getkey Attack is called enhanced robustness. If you choose this approach, the license requires your device to be clearly designed to prevent the Getkey Attack. This terminology is new; most licenses use robustness terminology like effectively frustrate. Preventing is stronger than frustrating. If your device is successfully attacked in a Getkey Attack, it is almost certain that your company would be found to have violated this provision of the license. How do you prevent the Getkey Attack? I will discuss some approaches which might, and some approaches which might not, prevent the attack. This is just one person's opinion, and is in no way binding on AACS. Remember the model: a set of clever, experienced hackers find a flaw in your player. They then write a program such that the average end-user can exploit this flaw to extract keys. There is not much you can do about the hackers in an absolute sense. In particular, you cannot depend on any secrets: how can you prevent a talented hacker from eventually learning any secret which is in a box in his possession, even if the secret is buried deep in an LSI chip. Instead, you have to focus on the average end-user. You can assume that the average end-user cannot modify hardware. The AACS license confirms this by restricting the attack to one that is carried out solely by electronically distributable means. You have two approaches to block the end-user, and they are not mutually exclusive: 1. You can prevent him from inserting a malicious program into your player. 2. You can prevent any program, running in the application space of your processor, from accessing the AACS secret keys. What vectors could be used to insert a malicious program into your player? Three possible sources come to mind:

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 10

11/21/2006

AACS TUTORIAL

1. A bug in your Ethernet driver and protocols could be exploited to insert malicious code. 2. A bug in your movie navigation virtual machine mistakenly allows a virtual program on the disc to insert native code into your processor. 3. The user removes the hard disk in your player, puts it in his PC, runs a program on the PC that modifies your player code, and places the disk back in your player. The first two attacks depend on some bug in your implementation. You might say, OK, I'll design without bugs, but that is probably not an adequate defense if a exploitable bug is later found. No one believes that bug-free code is possible in something as large and complex as a movie player. Real life is full of buffer overruns in the link level, and memory overruns in the virtual machine, that have been used to achieve consequences the designers did not intend. Fortunately, simple hardware can prevent bugs like this from being exploited. For example, after your ROM-based bootstrap completes, it could set a hardware register that partitions the memory so that the instruction memory can no longer be written, and the data memory can no longer be executed as instructions. People often ask, Why do you need that second part? If the instruction memory cannot be modified, how can it ever point out into data memory to cause it to be executed? Wrong. Especially if you are writing in an object-oriented computer language, addresses to instruction space are often stored in data memory. If the attacker can modify those addresses, he can get the processor to start executing anywhere he wants. For that reason, the native program should never write the partition register back to power-on state; the attacker might be able to find that instruction fragment and get it to execute. This approach also prevents the hard disk swap attack, if the ROM-based bootstrap code also checks a signature on the native code before executing it. Of course, there are other approaches that help against this attack. You can make the hard disk physically hard to remove. Or, you can use a hard disk with a non-standard interface that does not work on a PC. Finally, low-end players may not have hard disks at all, and their flash memory might be soldered in. You might argue that swapping the hard disk is a hardware attack, but I think most people would think that inserting and removing hard disks are within the capabilities of an average user. Unfortunately, this simple hardware approach is not possible if the navigation (or security) virtual machine can require you to execute signed native code as part of playing the movie. The approach outlined above would not let your player execute new signed code unless it went through a power-reset cycle. If this approach is not possible, you have to fall back on the second approach: isolating the AACS secrets from the memory space of the application processor. For example, you might have a small separate security processor, whose memory is not accessible to the application processor, which is the only one that uses the AACS secrets. In other words, it would process the media key block, store media keys and title keys, and perhaps even decrypt the movie itself. If its program is small enough, you can have confidence that there are no bugs in it, at least none that would expose the AACS secrets outside of the security processor's memory. It is also possible to do the security processor function in an LSI chip. This would be a very good approach, but only if some different key data can be place in each chip at manufacturing time. If, on the other hand, there is a single master key which is wired in to the chip, and that is used to decrypt AACS secrets fetched from the bulk memory, that approach does not prevent the Getkey Attack. You must assume that the hackers can reverse-engineer the master key.

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 11

11/21/2006

AACS TUTORIAL

Key Conversion Data

In addition to the enhanced robustness, AACS has another mechanism to help prevent Getkey attacks, called key conversion data, or KCD. The KCD is a 128-bit value that is encoded in a special way on a prerecorded disc. Each movie has a different KCD value. The details of how the KCD is encoded is one of the few confidential aspects of the AACS specification. Only DVD drive manufacturers and disc replicators need to know these details; most licensees do not. The KCD value is used as a final step to calculate the media key. If you are building a KCD-based player, your player will calculate a precursor media key instead of the media key itself when it processes the media key block. Then, you use a one-way function of the precursor media key and the KCD value to calculate the actual final media key. The important point is that not all players use the KCD; only some of them. To a first approximation, hardware players use KCD; software players do not. Thus, in the single NNL tree AACS uses, some fraction of the tree returns the media key directly, while the other part returns the media key precursor. What is the advantage of all this? First of all, standard AACS-licensed DVD drives on open platforms like PCs are not allowed to return KCD values. Instead, they do drive authentication. If the hackers have a set of keys from a player that is using KCD, it is very difficult for them to produce a clone that works on a PC or on any other open platform. At the very least, it changes the nature of the attack: the attackers have to provide a server that serves KCD values for each movie. And, if they are going to that much trouble, they might as well serve the movie media keys themselves rather than the KCD values, and the clone would not even need device keys. In effect, KCD turns a Getkey attack into a server-based attack. Server-based attacks can also be combated by non-technical means. The KCD mechanism is made even more effective because most software players are expected to use proactive renewal instead of enhanced robustness to protect their device keys. There are going to be far, far fewer proactive renewal keys out in the world than enhanced robustness keys, because a single set of proactive renewal keys will cover the entire product; whereas with enhanced robustness, each individual player has its own set of keys. Thus, most of the device keys in the world are not usuable on the PCa very desirable outcome, because the most easily distributed circumvention device is actually a program on the PC. What forces hardware manufacturers to use KCD drives? Actually, nothing. However, KCD drives should be cheaper because they do not have to do drive authentication. In particular, they do not have to store the host revocation list in non-volatile storage on the drive, which is probably the major cost of drive authentication. There is nothing in the AACS license today that compels close-platform hardware players to use KCD drives. Instead, AACS is depending on simple economics, rather than license provisions, to achieve the desired result. In contrast, software playersor to be more precise, open platform playersmust use non-KCD drives. This rule is implicit rather than explicit: 1) software players must use drive authentication, 2) any drive/player combination using KCD must protect the KCD values from interception, and 3) AACS has deliberately not defined any way in the drive authentication protocol to protect a KCD value.

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 12

11/21/2006

AACS TUTORIAL

Sequence Keys
This section is under construction.

JEFF LOTSPIECH, LOTSPIECH.COM

PAGE 13

11/21/2006