August 24, 2016

Archives for January 2007


Why So Many Undervotes in Sarasota?

The big e-voting story from November’s election was in Sarasota, Florida, where a congressional race was decided by about 400 votes, with 18,412 undervotes. That’s 18,412 voters who cast votes in other races but not, according to the official results, in that congressional race. Among voters who used the ES&S iVotronic machines – that is, non-absentee voters in Sarasota County – the undervote rate was about 14%. Something went very wrong. But what?

Since the election there have been many press releases, op-eds, and blog posts about the undervotes, not to mention some lawsuits and scholarly studies. I want to spend the rest of the week dissecting the Sarasota situation, which I have been following closely. I’m doing this now for two reasons: (1) enough time has passed for the dust to settle a bit, and (2) I’m giving a joint talk on the topic next week and I want to work through some thoughts.

There’s no doubt that something about the iVotronic caused the undervotes. Undervote rates differed so starkly in the same race between iVotronic and non-iVotronic voters that the machines must be involved somehow. (For example, absentee voters had a 2.5% undervote rate in the congressional race, compared to 14% for iVotronic voters.) Several explanations have been proposed, but only two are at all plausible: ballot design and machine malfunction.

The ballot design theory says that the ballot offered to voters on the iVotronic’s screen was misdesigned in a way that caused many voters to miss that race. Looking at screenshots of the ballot, one can see how voters might miss the congressional race at the top of the second page. (Depressingly, some sites show a misleading photo that the photographer angled and lit to make the misdesign look worse than it really was.) It’s very plausible that this kind of problem caused some undervotes; and that is consistent with the reports of many voters that the machine did not show them the congressional race.

It’s one thing to say that ballot design could have caused some undervotes, but it’s another thing entirely to say it was the sole cause of so elevated an undervote rate. Each voter, before finalizing his vote, was shown a clearly designed confirmation screen listing his choices and clearly showing a no-candidate-selected message for the congressional race. Did so many voters miss that too? And what about the many voters who reported choosing a candidate in the congressional race, only to have the no-candidate-selected message show up on the confirmation screen anyway?

The malfunction theory postulates a problem or malfunction with the voting machines that caused votes not to be recorded. There are many types of problems that could have caused lost votes. The best way to evaluate the malfunction theory is to conduct a careful and thorough study of the machines themselves. In the next entry I’ll talk about the efforts that have been made toward that end. For now, suffice it to say that no suitable study is available to us.

If we had a voter-verified paper trail, we could immediately tell which theory is correct, by comparing the paper and electronic records. If the voter-verified paper records show the same high undervote race, then the ballot design theory is right. If the paper and electronic records show significantly different undervote rates, then something is wrong with the machines. But of course the advocates of paperless voting argued that paper trails were unnecessary – while also arguing that touchscreen systems reduce undervotes.

Several studies have tried to use statistical analyses of undervote patterns in different races, precincts, and machines to evaluate the two theories. Frisina, Herron, Honaker, and Lewis say the data support the ballot design theory; Mebane and Dill say the data point to malfunction as a likely cause of at least some of the undervotes. Reading these studies, I can’t reach a clear conclusion.

What would convince me, one way or the other, is a good study of the machines. I’ll talk next time about the fight over whether and how to look at the machines.


Record Companies Boxed In By Their Own Rhetoric

Reports are popping up all over that the major record companies are cautiously gearing up to sell music in MP3 format, without any DRM (anti-copying) technology. This was the buzz at the recent Midem conference, according to a New York Times story.

The record industry has worked for years to frame the DRM issue, with considerable success. Mainstream thinking about DRM is now so mired in the industry’s framing that the industry itself will have a hard time explaining and justifying its new course.

The Times story is a perfect example. The headline is “Record Labels Contemplate Unrestricted Music”, and the article begins like this:

As even digital music revenue growth falters because of rampant file-sharing by consumers, the major record labels are moving closer to releasing music on the Internet with no copying restrictions — a step they once vowed never to take.

Executives of several technology companies meeting here at Midem, the annual global trade fair for the music industry, said over the weekend that at least one of the four major record companies could move toward the sale of unrestricted digital files in the MP3 format within months.

But of course the industry won’t sell music “with no copying restrictions” or “unrestricted”. The mother of all copying restrictions – copyright law – will still apply and will still restrict what people can do with the music files. I can understand leaving out a qualifier in the headline, where space is short. But in a 500-word article, surely a few words could have been spared for this basic point.

Why did the Times (and many commentators) mistake MP3 for “unrestricted”? Because the industry has created a conventional wisdom that (1) MP3 = lawless copying, (2) copyright is a dead letter unless backed by DRM, and (3) DRM successfully reduces copying. If you believe these things, then the fact that copyright still applies to MP3s is not even worth mentioning.

The industry will find these views particularly inconvenient when it is ready to sell MP3s. Having long argued that customers can’t be trusted with MP3s, the industry will have to ask the same customers to use MP3s responsibly. Having argued that DRM is necessary to its business – to the point of asking Congress for DRM mandates – it will now have to ask artists and investors to accept DRM-free sales.

All of this will make the industry’s wrong turn toward DRM look even worse than it already does. Had the industry embraced the Internet early and added MP3 sales to its already DRM-free CDA (Compact Disc Audio format) sales, they would not have reached this sad point. Now, they have to overcome history, their own pride, and years of their own rhetoric.


Wikipedia Leads; Will Search Engines NoFollow?

Wikipedia has announced that all of its outgoing hyperlinks will now include the rel=”nofollow” attribute, which instructs search engines to disregard the links. Search engines infer a page’s importance by seeing who links to it – pages that get many links, especially from important sites, are deemed important and are ranked highly in search results. A link is an implied endorsement: “link love”. Adding nofollow withholds Wikipedia’s link love – and Wikipedia, being a popular site, has lots of link love to give.

Nofollow is intended as an anti-spam measure. Anybody can edit a Wikipedia page, so spammers can and do insert links to their unwanted sites, thereby leeching off the popularity of Wikipedia. Nofollow will reduce spammers’ incentives by depriving them of any link love. Or that’s the theory, at least. Bloggers tried using nofollow to attack comment spam, but it didn’t reduce spam: the spammers were still eager to put their spammy text in front of readers.

Is nofollow a good idea for Wikipedia? It depends on your general attitude toward Wikipedia. The effect of nofollow is to reduce Wikipedia’s influence on search engine rankings (to zero). If you think Wikipedia is mostly good, then you want it to have influence and you’ll dislike its use of nofollow. If you think Wikipedia is unreliable and random, then you’ll be happy to see its influence reduced.

As with regular love, it’s selfish to withhold link love. Sometimes Wikipedia links to a site that competes with it for attention. Without Wikipedia’s link love, the other site will rank lower, and it could lose traffic to Wikipedia. Whether intended or not, this is one effect of Wikipedia’s action.

There are things Wikipedia could do to restore some of its legitimate link love without helping spammers. It could add nofollow only to links that are suspect – links that are new, or were added by an user without a solid track record on the site, or that have survived several rewrites of a page, or some combination of such factors. Even a simple policy of using nofollow for the first two weeks might work well enough. Wikipedia has the data to make these kinds of distinctions, and it’s not too much to ask for a site of its importance to do the necessary programming.

But the one element missing so far in this discussion is the autonomy of the search engines. Wikipedia is asking search engines not to assign link love, but the search engines don’t have to obey. Wikipedia is big enough, and quirky enough, that the search engines’ ranking algorithms probably have Wikipedia-specific tweaks already. The search engines have surely studied whether Wikipedia’s link love is reliable enough – and if it’s not, they are surely compensating, perhaps by ignoring (or reducing the weight of) Wikipedia links, or perhaps by a rule such as ignoring links for the first few weeks.

Whether or not Wikipedia uses nofollow, the search engines are free to do whatever they think will optimize their page ranking accuracy. Wikipedia can lead, but the search engines won’t necessarily nofollow.


Diebold Shows How to Make Your Own Voting Machine Key

By now it should be clear that Diebold’s AccuVote-TS electronic voting machines have lousy security. Our study last fall showed that malicious software running on the machines can invisibly alter votes, and that this software can be installed in under a minute by inserting a new memory card into the side of the machine. The last line of defense against such attacks is a cheap lock covering the memory card door. Our video shows that the lock can be picked in seconds, and, infamously, it can also be opened with a key that is widely sold for use in hotel minibars and jukeboxes.

(Some polling places cover the memory card with tamper evident seals, but these provide little real security. In practice, the seals are often ignored or accidentally broken. If broken seals are taken seriously and affected machines are taken offline for inspection, an attacker could launch a cheap denial-of-service attack by going around breaking the seals on election day.)

According to published reports, nearly all the machines deployed around the country use the exact same key. Up to this point we’ve been careful not to say precisely which key or show the particular pattern of the cuts. The shape of a key is like a password – it only provides security if you keep it secret from the bad guys. We’ve tried to keep the shape secret so as not to make an attacker’s job even marginally easier, and you would expect a security-conscious vendor to do the same.

Not Diebold. Ross Kinard of SploitCast wrote to me last month to point out that Diebold offers the key for sale on their web site. Of course, they won’t sell it to just anybody – only Diebold account holders can order it online. However, as Ross observed, Diebold’s online store shows a detailed photograph of the key.

Here is a copy of the page. The original showed the entire key, but we have blacked out the compromising part.

Could an attacker create a working key from the photograph? Ross decided to find out. Here’s what he did:

I bought three blank keys from Ace. Then a drill vise and three cabinet locks that used a different type of key from Lowes. I hoped that the spacing and depths on the cabinet locks’ keys would be similar to those on the voting machine key. With some files I had I then made three keys to look like the key in the picture.

Ross sent me his three homemade keys, and, amazingly, two of them can open the locks on the Diebold machine we used in our study!

This video shows one of Ross’s keys opening the lock on the memory card door:

Ross says he has tried repeatedly to bring this to Diebold’s attention over the past month. However, at the time of this posting, the image was still on their site.

Security experts advocate designing systems with “defense in depth,” multiple layers of barriers against attack. The Diebold electronic voting systems, unfortunately, seem to exhibit “weakness in depth.” If one mode of attack is blocked or simply too inconvenient, there always seems to be another waiting to be exposed.

[UPDATE (Jan. 25): As of this morning, the photo of the key is no longer on Diebold’s site.]


AACS: Modeling the Battle

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

By this point in our series on AACS (the encryption scheme used in HD-DVD and Blu-ray) it should be clear that AACS creates a nontrivial strategic game between the AACS central authority (representing the movie studios) and the attackers who want to defeat AACS. Today I want to sketch a model of this game and talk about who is likely to win.

First, let’s talk about what each party is trying to achieve. The central authority wants to maximize movie studio revenue. More precisely, they’re concerned with the portion of revenue that is due to AACS protection. We’ll call this the Marginal Value of Protection (MVP): the revenue they would get if AACS were impossible to defeat, minus the revenue they would get if AACS had no effect at all. The authority’s goal is to maximize the fraction of MVP that the studios can capture.

In practice, MVP might be negative. AACS makes a disc less useful to honest consumers, thereby reducing consumer demand for discs, which hurts studio revenue. (For example: Alex and I can’t play our own HD-DVD discs on our computers, because the AACS rules don’t like our computers’ video cards. The only way for us to watch these discs on our equipment would be to defeat AACS. (Being researchers, we want to analyze the discs rather than watch them, but normal people would insist on watching.)) If this revenue reduction outweighs any revenue increase due to frustrating infringement, MVP will be negative. But of course if MVP is negative then a rational studio will release its discs without AACS encryption; so we will assume for analytic purposes that MVP is positive.

We’ll assume there is a single attacker, or equivalently that multiple attackers coordinate their actions. The attacker’s motive is tricky to model but we’ll assume for now that the attacker is directly opposed to the authority, so the attacker wants to minimize the fraction of MVP that the studios can capture.

We’ll assume the studios release discs at a constant rate, and that the MVP from a disc is highest when the disc is first released and then declines exponentially, with time constant L. (That is, MVP for a disc is proportional to exp(-(t-t0)/L), where t0 is the disc’s release date.) Most of the MVP from a disc will be generated in the first L days after its release.

We’ll assume that the attacker can compromise a new player device every C days on average. We’ll model this as a Poisson process, so that the likelihood of compromising a new device is the same every day, or equivalently the time between compromises is exponentially distributed with mean C.

Whenever the attacker has a compromised device, he has the option of using that device to nullify the MVP from any set of existing discs. (He does this by ripping and redistributing the discs’ content or the keys needed to decrypt that content.) But once the attacker uses a compromised device this way, the authority gets the ability to blacklist that compromised device so that the attacker cannot use it to nullify MVP from any future discs.

Okay, we’ve written down the rules of the game. The next step – I’ll spare you the gory details – is to translate the rules into equations and solve the equations to find the optimal strategy for each side and the outcome of the game, that is, the fraction of MVP the studios will get, assuming both sides play optimally. The result will depend on two parameters: L, the commercial lifetime of a disc, and C, the time between player compromises.

It turns out that the attacker’s best strategy is to withhold any newly discovered compromise until a “release window” of size R has passed since the last time the authority blacklisted a player. (R depends in a complicated way on L and C.) Once the release window has passed, the attacker will use the compromise aggressively and the authority will then blacklist the compromised player, which essentially starts the game over. The studio collects revenue during the release window, and sometimes beyond the release window when the attacker gets unlucky and takes a long time to find another compromise.

The fraction of MVP collected by the studio turns out to be approximately C/(C+L). When C is much smaller than L, the studio loses most of the MVP, because the attacker compromises players frequently so the attacker will nullify a disc’s MVP early in the disc’s commercial lifetime. But when C is much bigger than L, a disc will be able to collect most of its MVP before the attacker can find a compromise.

To predict the game’s outcome, then, we need to know the ratio of C (the time needed to compromise a player) to L (the commercial lifetime of a disc). Unfortunately we don’t have good data to estimate C and L. My guess, though, is that C will be considerably less than L in the long run. I’d expect C to be measured in weeks and L in months. If that’s right, it’s bad news for AACS.


AACS: Sequence Keys and Tracing

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

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

It’s time to introduce another part of AACS: the Sequence Key mechanism. Throughout our AACS discussion, we have done our best to simplify things so readers could follow our logic without having to digest the entire technical specification. At this point, continuing the discussion requires some background about Sequence Keys.

We wrote previously about the AACS traitor tracing algorithm, which the AACS central authority can use (under some circumstances) to figure out which device keys have leaked. The Sequence Key mechanism gives the authority further help in figuring out which devices are compromised.

Sequence keys don’t seem to matter as of yet. Discs are not required to use sequence keys, and indeed we have yet to see a disc that uses them. We would be interested to hear of any current HD-DVD discs that use them. (Your disc uses sequence keys if it contains the file “AACS/SKB.AACS”.)

The sequence key mechanism uses two tricks. First, it assigns each player device a unique (or nearly unique) set of sequence keys. Discs that use the mechanism contain a special header that a player can decode, using the player’s sequence keys, to get a group of six decryption keys called the variant volume keys. Things are set up so that different players, presented with the same disc, will often end up with different variant volume keys.

The second trick is to take a few snippets of the movie, and put those snippets on the disc several times, encrypted under different variant keys. The movie publisher might create eight slightly different variants of the snippet, and encrypt each variant under a different key. Every player will know one of the eight variant keys, so it will be able to decrypt one of the variants – but different players will decrypt different variants.

The effect of this is that the movie will look slightly different, depending on which player was used to decrypt it. If a ripped copy of a movie is redistributed, the central authority can look at which variant of each snippet is in the rip, and can then identify which player device did the ripping. Each snippet lets it narrow down the number of suspected players by roughly a factor of eight (assuming roughly one-eighth of the players get each variant of that snippet). Given multiple snippets, they can divide by eight for each snippet, rapidly narrowing down the suspects to a few players, or even just one.

Having identified a specific player, the authority can then blacklist its keys, as we described in previous posts, so the player will be unable to decrypt or play any new discs. (It will still be able to access existing discs.)

The BackupHDDVD tool, as it is today, cannot cope with discs that use the Sequence Key mechanism – it uses only the per-disc volume keys and does not have or use any sequence keys. It wouldn’t be hard to modify BackupHDDVD so that it also downloaded and used the variant keys for a disc, allowing it to access discs that use the Sequence Key mechanism. This would require reverse engineers to extract and publish more keys (probably the so-called Volume Variant Unique Keys, along with the associated Variant Data) but that probably isn’t a fundamental impediment.

Doing this would allow the central authority to look at the newly added keys and figure out which player they were extracted from. (Actually things get interesting if the attackers get Variant Keys from many different players and then combine them cleverly to try to avoid being identified; there’s a whole theory considering how well such attacks will work.)

In the end, none of this affects our basic analysis much. Our modeling of the interaction between attackers and the central authority already assumes that the central authority will be able to identify a compromised player, whenever that player is used to capture a significant number of keys. Sequence keys make the mechanism more complicated but they don’t make AACS much more effective, if the attackers are smart.


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 and, 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.


AACS: Extracting and Using Keys

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

Let’s continue our discussion of AACS (the encryption scheme used on HD-DVD and Blu-Ray discs) and how it is starting to break down. In Monday’s post I gave some background on AACS and the newly released BackupHDDVD tool.

Recall that AACS decryption goes in two steps. First, the player device uses its device keys to decrypt the disc’s header, thereby getting a title key that is unique to the disc. Then the player uses the title key to decrypt the movie. The BackupHDDVD program does only the second step, so it is worthless unless you can somehow get the title key of the disc you want to access.

But decryption tools will evolve. Somebody will make an online database of title keys, and will modify BackupHDDVD so it automatically consults that database and gets the title keys it needs. This new decryption program will be able to decrypt any disc whose title key appears in the database. This decryption software and database don’t exist yet, but they seem inevitable.

It’s interesting to compare this system with an alternative that distributes decrypted movies. One difference is that a 16-byte title key is much smaller and easier to distribute than a huge movie file – even a dialup line will be able to download title keys in the blink of an eye. Of course, the title key is useful only if you have access to a disc (or a copy of the full encrypted contents of a disc), so some kinds of infringement will be easier with movie files than with title keys. Title keys will, however, be enough to enable in-home fair use.

But where will title keys come from? Probably they’ll be captured by reverse-engineering a player. Every player device, when decrypting a disc, must recover the title key and store it somewhere in the player’s memory, so that the title key can be used to decrypt the movie’s contents. A skilled engineer who works hard enough will be able to find and extract that stored title key. This will probably be easier to do for software players that run on PCs, and somewhat more difficult for dedicated player boxes; but in either case it will be possible. An engineer who extracts a key can upload it to the online database or share it with his friends.

There are economies of scale in key extraction. Having extracted the title keys for a few discs, the engineer will learn how and where the keys can be found and will have a much easier time extracting keys from other discs. Eventually, the extraction might be automated, so he need only insert a disc into his player and then activate a key-extractor device (or program) that he built.

Alternatively, he might try to extract the device keys from his player device. If he can do this, then he can write a software program that can do everything his player can do, including decrypting disc headers and extracting title keys from them. In other words, his program will be able to do both steps of AACS decryption.

Once he has device keys, he could in principle publish them (or equivalently publish a program containing them), thereby allowing everybody to extract title keys and decrypt discs. But if he does this, the AACS central authority will learn which device keys he is using and will blacklist those keys, which will prevent those keys from decrypting discs manufactured in the future. (The next post will discuss the blacklisting mechanism in more detail.)

So the engineer, if he is clever, won’t necessarily publish everything he knows. The more he publishes, the more he helps others freely use their discs – but the more he also helps the central authority fight back. This leads to an interesting strategic game between the engineer and the central authority, which we’ll explore in the next post.