Intel confirmed last Thursday that a hack to its High Definition Content Protection (HDCP) link protection scheme for high-def video had been discovered and published online.  HDCP is used in Blu-ray players, DVD players, set-top boxes, and other devices to protect high-definition content when it is transferred to other devices, such as TV monitors.  After several days of conjecture and  dubiously informed blog posts, some facts have become clear that enable us to assess both the nature and impact of this hack.

First, given that Intel designed HDCP in the first place, we can take its word as authoritative.  Second, someone either leaked or discovered the master key^* that is used within the “root of trust” for the HDCP system, which is the Intel subsidiary Digital Content Protection LLC (DCP). They also figured out a way to use that master key to generate the unique private keys that DCP normally generates per device, which enable HDCP-compliant devices to encrypt and decrypt content.

There are two big differences between the nature of this hack and that of the CSS encryption scheme for DVDs, to which DRM hacks are often compared. First, CSS was so weakly designed that all the hackers had to do was discover a single set of keys which are present on all DVD players; in contrast, HDCP does not actually store its master key on user devices. Hollywood has at least learned that lesson about key management.  In contrast, the HDCP hack depends on computing device private keys on a per-device basis.

Second, not only is computing device keys harder to do, but it can’t be done in software; it has to be done in silicon.  We’ll talk more about this shortly when we discuss the impact of the hack.

HDCP is designed to be able to revoke devices with compromised keys.  The hack, once someone actually implements it, makes this task essentially useless.  An HDCP ripper would keep generating new device private keys, which the overall HDCP scheme would have to revoke by constantly updating lists of revoked devices that are embedded into HDCP-encrypted content, such as Blu-ray discs.  It would be both inordinately expensive and ultimately futile to do this.

Worse, it’s only possible to revoke HDCP device keys, not renew them, as is possible in DRM schemes that take advantage of device connectivity, such as Marlin.  This design decision results from the fact that many current HDCP-compliant devices are unconnected devices such as Blu-ray players, and it’s only practical to renew keys over a network (just ask makers of SmartCard-based conditional access systems for cable TV, which have to physically ship new SmartCards if old ones are compromised).

The master key for HDCP, like that of other DRMs, was only supposed to be known to a “root of trust” (central security authority) — in this case DCP.  Either the key was leaked or it was discovered.

Researchers in 2001 had found a hack for discovery of the HDCP master key that involves collecting 40 different HDCP-compliant devices and working backwards from their private keys to calculate the master key.  The number 40 is a function of the configuration of the cryptographic algorithm that HDCP uses: Blom’s scheme, invented in the early 1980s.  It determines a data matrix that would have to be kept in memory, the size of which increases geometrically with the size of the number. So, the choice of 40 was a compromise — inevitable in all DRMs — between security and implementation cost.

The eminent cryptographer Paul Kocher — one of the brains behind the BD+ protection scheme for Blu-ray discs — says that the hack resulted from poor design.  But it’s also possible that a DCP insider leaked the key.   Even if the latter was the case, the system was designed with the weakness that knowing the master key makes it possible to use it outside of the root of trust environment to create device private keys.  This was another choice made in the interest of low implementation cost rather than security.

Now let’s talk about the practical impact of the hack.  It is just as wrong to suggest, as some have, that the HDCP hack has the same impact on high-definition video as the CSS hack has had on DVDs.  Part of the assessment of the strength of the security of a DRM system is that of the fallout when the system is inevitably cracked.

First of all, the impact of the HDCP hack is such that it would be necessary to create chips that implement it.  As some have pointed out, a fabrication facility somewhere in China may well be working on just such a chip as I write this, and soon Blu-ray players and other devices with the chip, or standalone HDCP ripper devices, could appear on the black market or outside the United States.

This is a “hardware speed bump” in the sense that someone has to manufacture the devices and sell them, presumably at a profit.  Such devices would be illegal in the US and various other countries under anticircumvention law.  People would have to find, buy, and use the devices; and the devices would require real-time playback of the video to make the decrypted content available.

In contrast, the CSS hack led to software DVD rippers that anyone could download over the Internet, and the odds of detecting such (also illegal) activity are virtually nil.  Furthermore, so-called DeCSS rippers work almost instantaneously and do not require real-time playback.  With movies, this is a big difference.

Intel’s stance on the HDCP hack is that it won’t affect their business.  You’d expect Intel to say that, but in this case it’s basically true.  Unencrypted, uncompressed movies appear on BitTorrent sites now; this process will become somewhat easier for dedicated rippers to do once HDCP rippers become available, but the average BitTorrent user won’t experience much difference.

Let me say this one more time: just because there’s a hack to a DRM scheme does not necessarily mean that every piece of content encrypted with that DRM scheme is suddenly in the clear.

Here is the analogy I like to use to explain this; it is not terribly accurate but illustrative anyway.  Let’s say I develop a technique for picking a certain popular brand of combination locks and publish it on a web page.  That does not mean that every school locker using that lock is suddenly open and millions of backpacks, sweatshirts and textbooks are stolen.  Even leaving aside the fact that a lock-picker has to physically go to each lock and operate on it, taking advantage of the hack may require special skills, special tools, and time to work.

I have not in recent years met anyone in the media industry who believes that any DRM is hackproof.  Furthermore, studios treat HDCP and other DRMs as just a few of many tools for keeping consumers buying their content and not infringing their copyrights.  Thus, this hack is unlikely to affect the attitudes that Hollywood studios have towards DRM.

^*I made a comment on a popular tech blog that there wasn’t a single master key.  My comment was incorrect.  At the time, I did not properly understand the nature of the hack, and I did not make the distinction between master keys that are actually present on client devices by design (a la DVDs and CSS) versus those that are designed to exist only within the confines of the root-of-trust facility (DCP in the cast of HDCP).  However, the author of this blog piece also failed to make that distinction and generally under-researched and mischaracterized the hack, in his usual fashion.  For that reason, I won’t name the blog or author.