The impact of the HDCP master key release

On September 13, a file appeared on the Pastebin clipboard-sharing site claiming to contain the "master key" for the High-bandwidth Digital Content Protection (HDCP) encryption system used to restrict digital audio and video content over participating HDMI (High-Definition Multimedia Interface), DisplayPort, and other connections. Intel, which developed the HDCP system internally and now sells licenses to it through its subsidiary Digital Content Protection (DCP), confirmed to the press that the key is legitimate on the 17th. What the development means for open source software is not clear, however. It stands as yet another example of why digital content-restriction schemes consistently offer "protection" that they cannot deliver, but it is not an open door for free access to media that comes in encrypted formats, such as Blu-ray discs.

Primarily this is because HDCP is not the encryption scheme used to scramble content delivery — either on optical disc or delivered to the home via satellite or cable. Rather, HDCP is used exclusively to encrypt the video output signal from the playback source (such as an optical disc player or a cable converter box) to the display. HDCP "protects" the signal both by encrypting it during transmission, and by allowing each device to perform an authentication check against the device on the other end of the connection. A side effect of the scheme is that home theater enthusiasts complain of sometimes lengthy delays when switching from one HDCP-compliant video source to another while the devices step through the HDCP handshake process.

HDCP under the hood

Computer scientist Edward Felten posted an explanation of the HDCP security model on Princeton's Freedom to Tinker blog shortly before Intel verified that the key was indeed genuine. In a nutshell, the HDCP handshake process begins with a key exchange protocol using Blom's scheme. Each licensed HDCP device has a public key and a private key; all of the private keys are generated (in advance) from the public key combined with a secret master key kept by DCP.

That key was the array posted to Pastebin on September 13. It allows anyone to generate a perfectly valid private key at their leisure. Therefore, anyone can correctly perform the handshake, exchange keys with a licensed HDCP device, and decrypt the video signal sent over the cable. No "key revocation" or blacklisting scheme can prevent such an attack, as all would-be attackers can now generate every possible key.

The fact that the secret master key was exposed does not necessarily mean that some ne'er-do-well stole it, however. As far back as 2001, three years before HDCP received regulatory approval by the FCC, two teams of cryptographers announced that the system was fatally flawed, and that an attacker could discover the master key simply by capturing the public keys — something that all HDCP-compliant devices freely report — from as few as 40 legitimate devices .

One researcher, Niels Ferguson, declined to publish his finding citing the threat of prosecution under the US Digital Millennium Copyright Act (DMCA). The other group, Scott Crobsy et al., did publish their paper [PDF], which also notes the amusing property that reverse-engineering the secret master key can be done with no prior knowledge of the algorithm used to generate keys.

Ferguson noted on his site in 2001, however, that "someday, someone, somewhere will duplicate my results. This person might decide to just publish the HDCP master key on the Internet. Instead of fixing HDCP now before it is deployed on a large scale, the industry will be confronted with all the expense of building HDCP into every device, only to have it rendered useless." On September 14, he updated his HDCP page, saying: "My only question is: what took them so long?"

Practicality

Now that HDCP's authentication requirements and content encryption are irrevocably broken, the question many in the open source software community are asking is whether free software media projects will now have an easier time working around HDCP's restrictions. The short answer is that there is little to no practical advantage gained from a broken HDCP, because it is an encryption measure applied only on the raw video signal sent to the display — i.e., over HDMI, DVI, or DisplayPort cabling.

At that stage, the original source media has been decompressed from its delivery format into an audio stream and a sequence of full-resolution video frames. The bandwidth requirements for the current generation of high-definition content are very high (1920 by 1080 pixels, 24 bits per pixel, 30 frames per second, or approximately 1.49 Gbps for video alone). The open source projects that include video capture, such as MythTV, VLC, VDR, and Freevo, focus either on the capture of standard MPEG-based broadcasts or on supporting embedded hardware that performs MPEG-conversion or other compression of analog signals via a dedicated chip.

One of those devices, the Hauppauge HD PVR, does capture full-resolution, high-definition raw video over component inputs. In theory it would be possible to build a similar device that accepted HDCP-locked HDMI input instead, but such a device would either perform the same hardware compression the current devices do (in which case the "bit perfect" copy is lost), or have extremely large, extremely fast storage attached. MythTV's Robert McNamara described the possibility as infeasible.

Doing the same thing with generic PC hardware would not be much easier; there are a few HDMI video capture devices on the market, but the only manufacturer with any Linux driver support at the moment, Blackmagic Design, supplies only binary drivers that do not allow capturing HDCP-copy-protected content.

More importantly, the ability to capture full-resolution, uncompressed video from the HDMI output of a high-definition video player is a moot point considering that the content scrambling schemes employed on the compressed contents of optical discs like HD DVD and Blu-ray are broken as well.

The initial scheme deployed on HD DVD and Blu-ray is called Advanced Access Content System (AACS), and it has suffered numerous key discoveries that allow its decryption. AACS incorporates a key revocation scheme that can lock up new releases with new keys, and which is currently believed to be in either the 17th or 18th round of revocation and key replacement.

Some newer Blu-ray discs are encrypted with a different system called BD+ centered around a small virtual machine in the player, which runs VM code included on the disc. The VM code can perform integrity checks to make sure that the player has not been tampered with, force player firmware upgrades, and other security tasks. Nevertheless, at least two proprietary companies sell BD+-stripping software, and there is an open source effort to reverse-engineer the BD+ VM, spearheaded by developers at the Doom9 forums.

High-definition cable and satellite transmissions are protected by other schemes sold by proprietary vendors, including DigiCipher 2, PowerVu, and Nagravision. There appears to be no large-scale interest in reverse-engineering any of these schemes in open source software.

Legal threats

When it verified publicly that the Pastebin key was in fact the HDCP secret master key, Intel spokesman Tom Waldrop levied ominous-sounding threats of legal action against anyone who incorporated the master key into a product, saying "There are laws to protect both the intellectual property involved as well as the content that is created and owned by the content providers, [...] Should a circumvention device be created using this information, we and others would avail ourselves, as appropriate, of those remedies."

Which laws those are were not specified. The key itself could probably be considered a trade secret under US law, and if anyone with access to it disclosed it, he or she could face a civil breach-of-contract lawsuit. Both Waldrop and independent cryptographer Paul Kocher have publicly opined that the key was probably calculated through reverse engineering as Ferguson and Crosby predicted, however.

Nevertheless, any hardware manufacturer that currently produces HDCP equipment has purchased a license from DCP, which would presumably prohibit it from producing a competing product using the leaked master key. What remains unclear at this stage is whether DCP asserts any patents on HDCP, which could be used to mount a legal challenge to any HDCP-bypassing device even from a non-licensee. DCP's web site and the license agreements offered there mention patents among other broad "intellectual property" claims, but do not specify any particular patent grants. The opacity of patent filings and the difficulties of performing an adequate patent search are but two of the flaws in the US patent system already familiar to most readers.

The anti-circumvention provisions of the DMCA are yet another possible legal avenue; section 103 states that "No person shall circumvent a technological measure that effectively controls access to a work protected under this title." Whether or not the completely broken HDCP scheme would be ruled as "effectively" controlling access to a work is a matter of speculation. In recent years, the copyright office has expanded the regulatory list of allowed exceptions to section 103, including specific examples of copying CSS-protected DVD content, but individual court cases continue to rule both ways on whether fair use permits circumvention.

The future

Many people are speculating that the broken-beyond-repair HDCP scheme will lead to new hardware devices, perhaps monitors or video switches that can connect to HDCP content sources but that can ignore the restrictions imposed from HDCP content sources on the other end of the cable. That is certainly a possibility, though it could be a while before such products reach the market, and they may initially come from overseas suppliers far from the reach of DCP's legal threats.

From the software angle, however, it is difficult to come up with a scenario in which sidestepping HDCP constitutes a major gain. For video capture applications, it occurs way too close to the final display to be valuable — working around the on-disc scrambling schemes is far faster, and the raw output that might be captured over HDMI must immediately be compressed again to be practically stored. Given that no content sources (cable, satellite, or optical disc) originate in uncompressed formats, this would be a "recompression" anyway, not likely to provide any discernible quality improvement. Perhaps playback applications could fake being a licensed HDCP source, but what good is that, when HDCP is broken? In addition, display devices are all considered downstream from content sources; adding HDCP encryption would not make a signal more widely viewable, only less. Nevertheless, on September 29, two developers posted some BSD-licensed code implementing HDCP in software, so time will tell if the global software community finds it useful.

In conclusion, as the world says goodbye to HDCP, it is probably worth noting that the technology did little or nothing to actually prevent the unauthorized copying of digital audio and video content, so it is logically befitting that its passing will probably have little effect either. Whether the consumer electronics and entertainment industries learn a lesson from its brief lifespan or not is another matter entirely. DCP is already promoting a newer product called HDCP 2.0, which it advertises as being based on public key RSA authentication and AES 128 encryption, targeting wireless audio/video transmission standards. I have not yet found any serious cryptanalysis of HDCP 2.0 (there are several white papers promoting the standard, however), but then again the technologies that implement it — Digital Interface for Video and Audio (DiiVA), NetHD, Wireless Home Digital Interface (WHDI), and Wireless HD (WiHD) — have yet to reach the mass-market.