HDCP: (Sub)Standard Security pt.1

I owe the readers of this blog an explanation (or two).  I promised to explain "Why Security Systems Fail" and so far, after more than a month, there was only one such post (on RSA SecurID).

To make up for this I'll do a series of posts on a group of security systems describing how and why they were breached. What these systems have in common is that they were each defined as a "standard" - i.e. a specification for the security system was published and was implemented by multiple parties. The first post in the series is dedicated to HDCP. Subsequent posts will cover GSM, X.509 certificates and others.

Some background on HDCP. The introduction of the HDMI standard for digital communication of high definition content raised the issue of content protection. Traditional analog communication methods suffer from the Analog hole, which allows attackers to freely access content as it is communicated to a rendering device (e.g. a television). Content providers such as the movie studios wanted to use the opportunity of the introduction of a new standard to close this hole in the digital output (which gives access to higher quality video and is easier for pirates to process and manipulate).

Higher quality video?

To meet these concerns Intel, who promoted the HDMI standard, also included as part of this standard a content protection scheme called High Density Content Protection (or HDCP). In the HDCP content protection scheme every device has a unique set of keys. These keys are generated by the HDCP licensing authority and distributed to devices in such a way that any two devices can use their unique set of keys to create a shared key which they can then use to encrypt communications between the devices. The HDCP licensing authority requires the HDCP licensees to protect these keys and to not allow misuse of content received encrypted under the HDCP scheme.

Two distinct tracks have been taken to break HDCP - cryptanalysis and hacked devices.

Cryptanalysts found various weaknesses in the HDCP scheme for generating keys until finally, in September 2010, the root key used by the HDCP licensing authority was revealed and posted on the Internet. The HDCP key exchange protocol was thus rendered useless - using this root key anyone can produce a device that will be able to impersonate any other HDCP device.

But devices that circumvent HDCP security have been around since at least 2005, long before the HDCP root key was revealed. Known as "HDCP Strippers", these are devices that received HDCP keys from the HDCP licensing authority but whose software was modified to allow misuse of content received under the HDCP key - specifically these devices "strip" the HDCP security from content and output it "in the clear".

The development of such HDCP strippers exemplify a major obstacle that many standardized security schemes stumble on. Any company can develop a device that is supposed to implement the standard. But since “a system is only as secure as its implementation” (corollary of law #1) it is very likely that at least some of the implementations will be less robust and can be exploited to compromise the entire system.

If the standard is implemented by a large number of companies there is no practical way to get all the implementers to produce a robust implementation. Regular non-security standards define certain functions a compliant implementation needs to perform and it is quite easy to build a test suite to confirm that a specific implementation is in fact compliant. It's much more difficult, if not impossible, to test if a specific implementation is robust. To verify this you need to analyze the implementation and look for possible holes - a predefined automated testing suite can't fully cover this.

So did HDCP fail? Actually, despite the fact that HDCP has been deeply compromised, I wouldn't say it has failed. The goal of HDCP was to get content providers to adopt HDMI and HDCP has in fact achieved this goal! In this case the defender's motivation (see law #4) is not to protect the system, but to get buy-in. This is a case where the security is "good enough" for the commercial purposes but is not good enough to actually prevent hacking (see law #5).

This is quite typical in standardized security schemes. Many such schemes are put in place to enable a certain business model. Once the business model is in place there is no real motivation for the defenders to keep the system secure.

Some security standards contain penalties for the manufacturers of devices that are compromised, but these are rarely effective. For example, HDCP includes a revocation mechanism which could be deployed to shut down compromised devices. But such revocation mechanisms are not usually practical either because of difficulties in the distribution of revocation messages to all devices or because of a lack of commercial willingness to deal with the wrath of legitimate users of these devices. Even if such revocation is performed, the device manufacturer has already sold the devices and doesn't really care anymore.

The conflict of interests in HDCP and other such standards between the implementers of the security standard (the device manufacturers) and the companies the security standard is intended to protect (the content providers) creates a clear conflict of interests that is very difficult, of not impossible, to overcome. As Dan Ariely says, beware conflicts of interest: