High-Bandwidth Digital Content Protection (HDCP) is an emerging digital rights management technology which is intended to plug the analogue hole for the upcoming high-def broadcast and disc formats. It operates over HDMI cables, and is about the worst idea I’ve heard this year. And that’s going some.
It’s a requirement for both Blu-Ray and HD-DVD discs - so without an HDCP-enabled TV you could be locked out of playing high-def versions of content on these discs. Instead you’ll see the standard-definition version. The problem is, just because your TV has an HDMI port doesn’t mean that it supports HDCP. Only about 10% of HDTVs currently in US homes support it, for example. And to make matters worse, whether the locking-out takes effect is entirely the decision of the disc publisher. At the moment most of the major studios have promised not to use the HDCP ‘flag’ for launch titles, but who knows what they’ll do in the future?
All of this ignores the fundamental problem with HDCP, and all other forms of DRM though. HDCP attempts, as you’ll see from Ed Felten’s excellent article, to apply cryptographic principles in a completely non-sensical way.
In traditional cryptography, two people want to send a message to each other (in examples, it’s usually Alice to Bob) without nasty Eve being able to eavesdrop. Aside from the requirements of exchanging a key and using a reliable crypto algorithm, the critical point is that both Alice and Bob want the message to stay secret. And Eve should never be able to see the key - as this would render the process of encryption useless.
HDCP works like this: the studios play the role of Alice, the sender. The ‘message’ is the movie, send from the high-def player to the TV. The consumer, owns a TV. The consumer has no interest in maintaining the integrity of the encryption, as in practice all the crypto means is restrictions on usage. But wait a minute - if the consumer is has no interest in maintaining the crypto, then they have all the ‘nefarious’ properties of Eve. And by effectively receiving the ‘message’, they must also have all the advantages of Bob - i.e. being in possession of the key.
In practice the way this works is that you buy a TV that has to be capable, somehow, of decrypting protected content. Therefore, it must know about, and contain, the encryption keys used. So you have them in your possession. And you also have the encrypted media, being sent from your high-def DVD or satellite box to your TV. And, crucially, you have no reason to maintain the encrypted state of the content.
So what’s stopping you from permanently decrypting the media?
Well, nothing really. As Ed points out, HDCP is mathematically flawed as well as possessing fundamental logical errors as I’ve shown. Far from attempting to actually break the crypto by force, you would only need to take the decryption keys out of your TV and build a ‘receiver’ to decode the media into its native format. As HDCP will eventually be available for computers as well as TVs, it’s probable to certain that someone will firstly come up with a physical box which decrypts content and sends it along a wire. And eventually someone (perhaps DVD Jon) will come up with a blanket cracking tool for it and its companion system AACS, just like DeCSS did for DVD. After all, it could use your own device’s decryption keys to do the job.
All will take is for one person to figure it out and write the software. In fact, academic researchers like Niels Ferguson and separately a team led by Scott Crosby of Carnegie Mellon University have already done full cryptananalysis of HDCP. Of course, if they publish their findings they’ll probably be prosecuted (or extradited then prosecuted like DVD-Jon) under the Digital Millennium Copyright Act.
Update: I found Crosby’s paper here, hosted on a Dutch server.
This all points out the degree to which DRM is a really bad deal for consumers. These technologies aren’t designed to protect content. They’re intended to protect markets.
Isn’t technology great?
HDCP, by the way, will also be used in Sky’s upcoming HD satellite service.
Making and Breaking HDCP Handshakes:
I wrote yesterday about the HDCP/HDMI technology that Hollywood wants to use to restrict the availability of very high-def TV content. Today I want to go under the hood, explaining how the key part of HDCP, the handshake, works. I’ll leave out some mathematical niceties to simplify the explanation; full details are in a 2001 paper by Crosby et al.
Suppose you connect an HDMI-compliant next-gen DVD player to an HDMI-compliant TV, and you try to play a disc. Before sending its highest-res digital video to the TV, the player will insist on doing an HDCP handshake. The purpose of the handshake is for the two devices to authenticate each other, that is, to verify that the other device is an authorized HDCP device, and to compute a secret key, known to both devices, that can be used to encrypt the video as it is passed across the HDMI cable.
Every new HDCP device is given two things: a secret vector, and an addition rule. The secret vector is a sequence of 40 secret numbers that the device is not supposed to reveal to anybody. The addition rule, which is not a secret, describes a way of adding up numbers selected from a vector. Both the secret vector and the addition rule are assigned by HDCP’s central authority. (I like to imagine that the central authority occupies an undersea command center worthy of Doctor Evil, but it’s probably just a nondescript office suite in Burbank.)
An example will help to make this clear. In the example, we’ll save space by pretending that the vectors have four secret numbers rather than forty, but the idea will be the same. Let’s say the central authority issues the following values:
|
secret vector |
addition rule |
| Alice |
(26, 19, 12, 7) |
[1]+[2] |
| Bob |
(13, 13, 22, 5) |
[2]+[4] |
| Charlie |
(22, 16, 5, 19) |
[1]+[3] |
| Diane |
(9, 10, 15, 17) |
[3]+[4] |
Suppose Alice and Bob want to do a handshake. Here’s how it works. First, Alice and Bob send each other their addition rules. Then, Alice applies Bob’s addition rule to her vector. Bob’s addition rule is “[2]+[4]”, which means that Alice should take the second and fourth elements of her secret vector and add them together. Alice adds 19+7, and gets 26. In the same way, Bob applies Alice’s addition rule to his secret vector — he adds 13+13, and gets 26. (In real life, the numbers are much bigger — about 17 digits.)
There are two things to notice about this process. First, in order to do it, you need to know either Alice’s or Bob’s secret vector. This means that Alice and Bob are the only ones who will know the result. Second, Alice and Bob both got the same answer: 26. This wasn’t a coincidence. There’s a special mathematical recipe that the central authority uses in generating the secret vectors to ensure that the two parties to any legitimate handshake will always get the same answer.
Now both Alice and Bob have a secret value — a secret key — that only they know. They can use the key to authenticate each other, and to encrypt messages to each other.
This sounds pretty cool. But it has a very large problem: if any four devices conspire, they can break the security of the system.
To see how, let’s do an example. Suppose that Alice, Bob, Charlie, and Diane conspire, and that the conspiracy wants to figure out the secret vector of some innocent victim, Ed. Ed’s addition rule is “[1]+[4]”, and his secret vector is, of course, a secret.
The conspirators start out by saying that Ed’s secret vector is (x1, x2, x3, x4), where all of the x’s are unknown. They want to figure out the values of the x’s — then they’ll know Ed’s secret vector. Alice starts out by imagining a handshake with Ed. In this imaginary handshake, Ed will apply Alice’s addition rule ([1]+[2]) to his own secret vector, yielding x1+x2. Alice will apply Ed’s addition rule to her own secret vector, yielding 26+7, or 33. She knows that the two results will be equal, as in any handshake, which gives her the following equation:
x1 + x2 = 33
Bob, Charlie, and Diane each do the same thing, imagining a handshake with Ed, and computing Ed’s result (a sum of some of the x’s), and their own result (a definite number), then setting the two results equal to each other. This yields three more equations:
x2 + x4 = 18
x1 + x3 = 41
x3 + x4 = 26
That makes four equations in four unknowns. Whipping out their algebra textbooks, the conspiracy solves the four equations, to determine that
x1 = 25
x2 = 8
x3 = 16
x4 = 10
Now they know Ed’s secret vector, and can proceed to impersonate him at will. They can do this to any person (or device) they like. And of course Ed doesn’t have to be a real person. They can dream up an imaginary person (or device) and cook up a workable secret vector for it. In short, they can use this basic method to do absolutely anything that the central authority can do.
In the real system, where the secret vectors have forty entries, not four, it takes a conspiracy of about forty devices, with known private vectors, to break HDCP completely. But that is eminently doable, and it’s only a matter of time before someone does it. I’ll talk next time about the implications of that fact.
(Via Freedom to Tinker).