Slashdot Mirror

To HDCP, one can merely say: "You are dead, dead, dead. Thought you were hot, guess what, you're not!"

Then they can merely manufacture their own keys. Granted, it requires knowledge of the private keys of a number of devices, but once that's done, game over. The paper also shows how to impersonate another device by only using its public key.

It's already been done as far back as 2001. The gist of it is this:

Each device has its own secret key, which is 40 numbers long, that the device isn't supposed to reveal to any other device. In addition each device gets an addition rule, which basically says "Add the numbers at positions x and y of your private key together and give me the result". This addition rule is public, all you need to do to acquire it is try to start a HDCP handshake with the device in question. So device A wants to complete a handshake with device B, both B and A send each other their addition rules, carry out the addition on the specified numbers and send each other the result. Through some mathematical voodoo (thanks to the ultra secret "Master key") the result will always match if both devices are legitimate.

As it turns out it's pretty easy to guess a device's secret key by using at least 40 other devices. All you need is the addition rule of the device to be broken, which is publicly available. You then apply the addition rule to each of the 40 other devices and store every result. When you're done you're left with 40 algebraic equations, like x1 + x4 = 23, x7+x12 = 65 etc. From here you can use some algebraic voodoo to reconstruct the target's private key, which you then spoof to authenticate any HDCP session to any device (until that key is revoked).

But it's worse than that. Turns out it's also possible to figure out the master key (a 40x40 matrix of 56 bit numbers) used to create all the private keys once you uncover at least 40 private keys. It's not easy, but it can be done, and since the whole system relies on the secrecy of this matrix once it's released to the public HDCP will be useless. This break was discussed here on /. 3 years ago, and it's just one of several methods that can break HDCP. As far as I know this particular vulnerability still exists, though I haven't been keeping up with developments lately.

Now they need to crack HDCP.

No, Lieutenant, your HDCP is already dead.

But HDCP is broken.

HDCP is really no problem. It's a linear cipher of all things!

Erm, exactly. Once the keys have been compromised, the keys will (in theory) be revoked and new ones will be put in place.

Problem is, there's nothing stopping people from finding additional keys, and then in combo with the "all it takes is one" thought process, it's really kind of pointless. Who cares if a future copy of the same movie has new keys? We already have the straight data!


Of similar interest, it turns out that HDCP, the DRM for these new-fangled HDMI ports, is fundamentally flawed. From the link: "This flaw is fundamental, and cannot be worked around."

The point of the DRM on the discs is to prevent people ripping and burning/torrenting them. Seeing as - somewhere, somehow, the key must be loaded into a computer's memory eventually, this is already broken.
The point of the DRM on the cable is to prevent people from plugging their fancy new HDDVD/Blu Ray player into a computer, and simply recording what comes over the wire. Turns out (reference above link), this can be defeated with basic linear algebra. Oops.

It reminds me of a post I made a while back, on a similar matter. As I posted that, I thought to myself, "the only way they could prevent someone from just plugging in a cable from audio out to line in, is by making brand new jacks for everything, which have DRM built in." Sadly, that's exactly what HDMI/HDCP is. Fortunately, they did an absolute crap job of implimenting it.


There's no secrets here. DRM isn't here to stop pirates, that's just what they tell the public. And, when you look at the facts on the matters, it's pretty blindingly obvious.

There's more to this, such as HDCP, prevention of screenshots, etc.

HDCP is cryptographically broken to begin with, and there are already consumer devices available to output HDMI from a supposedly secure HDCP device.

Memory Curtaining allows a program to protect its memory from being read by other processes and the kernel.

If a driver has to be signed to be loaded (as in 64-bit Windows Vista*) then none of the drivers will be able to look at the curtained memory (unless you're able to pay Microsoft some money /and/ slip the debugging functionality of your driver past their noses). The next version of PowerDVD could require all unsigned drivers to be unloaded.

I'll begin to take this possibility seriously as soon as anyone is able to make perfectly secure software from the kernel all the way down to each device driver loaded in kernel mode. How much do you want to bet that by buying X-brand device with a shoddy driver and plugging it into your Vista media PC you'll suddenly have a huge backdoor to exploit? My guess is that will be one of the first easily available breaks. Memory curtaining is only effective after the program has been loaded and has turned on curtaining for itself. Having a backdoor driver allows the movie player process to be modified before it executes, removing its desire to curtain itself.

If record companies are willing to take the plunge and go all the way in DRM (requiring TC, using the ICT http://en.wikipedia.org/wiki/Image_Constraint_Toke n, revoking keys of cracked players, shutting off most of their current market) it could be the end of piracy and fair use too.

All piracy needs is one cracked player kept in secret. It's nearly impossible to watermark a disc so that one can tell which player key was used to extract the unprotected media, since it would be an obvious thing like a playlist changing based on the vendor ID of the player or something equally transparent. Since there's only enough room on the disc for one encrypted movie, what matters is whether any player can obtain that master key by any means, and it's virtually untraceable. All fair use needs is an exploitable kernel driver or software player, or a combination of a working player and HDCP->HDMI converter, or a cryptographic attack on the player as described in "A Cryptanalysis of the High-bandwidth Digital Content Protection System", or a list of encryption keys extracted from players. Note that fair use is actually harder than piracy, because it assumes the open sharing of knowledge which can be used by the media companies to counteract exploits by revoking drivers and keys for weak players. As usual, normal customers suffer while true pirates have it pretty easy.

Conclusion: We can:

• Eavesdrop on any data
  
• Clone any device with only their public key
  
• Avoid any blacklist on devices
  
• Create new device keyvectors.
  
• In aggregate, we can usurp the authority completely.

One [sic, once] blu-ray/hd-dvd is cracked HDCP will be moot.

HDCP is already moot. Of course, even though HDCP doesn't work, they still charge license fees for it, which is the whole reason it exists in the first place.

If you really want to copy a blue-ray movie, there are easier ways, such as decrypting HDCP.

HDCP has been broken, and has been proved to be weak in 2001 twice. See http://apache.dataloss.nl/~fred/www.nunce.org/hdcp /hdcp111901.htm

Uh... that's not the way it works, generally. The drive might not decrypt content without trusted drivers, but at a low enough level, it's still an ATAPI block device, and an ATAPI block read still reads a block. The only way they could even make this difficult would be to make the drive reject read requests to a particular "special" region of the disc containing decryption key data, much like DVD-R drives reject writes to those regions. However, since the hardware must, by definition, be able to read those blocks, even if they put limits on what blocks can be read, it would still be a mere firmware limitation, and we've seen just how well firmware limitations have worked with region codes....

At some point, it comes down to this: an ATA bus isn't encrypted. The bus is easily snoopable. Ditto for USB, ditto for FireWIre, SCSI, etc. Any key data that leaves the drive can be snooped, so if the drive hands the key and the data to your video card to do the decoding, you can snoop it on the ATA bus. If the reverse happens---if key data is sent from the video card to the drive---it can be snooped on the ATA bus. Either way, there must be a key exchange. That means that it is vulnerable to a man-in-the-middle attack. Any technology not vulnerable to a man-in-the-middle attack, by definition, is a shared secret algorithm, which is inherently vulnerable to the revelation of the shared secret by unscrupulous people (social engineering), which is how CSS was broken, I believe.

Fundamentally speaking, HDCP will be a joke, just like CSS, because all content protection is, my its very nature, a joke. It relies on an inherently flawed premise, specifically the assumption that you can give someone a piece of data and a decryption key and then somehow dictate how and when they can use that key to decrypt the data. It doesn't work that way. The only way to prevent decryption is by withholding the key, which would prevent it from ever being decrypted in any way. The best HDCP can do is add more initial shared secrets to steal.

Besides, unless they have improved it in recent years, HDCP has already been broken.

You should read this:

http://apache.dataloss.nl/~fred/www.nunce.org/hdcp /hdcp111901.htm

I'm certain it was a story in itself on /. not too long ago, but I'm too lazy to go find it. Here's there conclusion:


HDCP's linear key exchange is a fundamental weaknesses. We can:

        * Eavesdrop on any data
        * Clone any device with only their public key
        * Avoid any blacklist on devices
        * Create new device keyvectors.
        * In aggregate, we can usurp the authority completely.

The weaknesses are not easy to repair. Two proposed modifications are broken and still susceptible in O(n^2) work and n sets of keys to:

        * Eavesdrop on any data
        * Clone any device with only their public key
        * Avoid any blacklist on devices


So even if they use copious amounts of keys (a unique one per device), HDCP will fail all the same and their blacklists won't matter.

But this is the video stream, not the data encrypted on the disk (analogous to CSS) so the "per disk" comment you made isn't applicable. HDCP & AACS are two separate issues/battles.

we just don't quite know what killed it yet.

Oh, but I think that we do! And we even know who... it was DVD Jon, on the Internet, with a DeCSS decryption alogithm.

High bandwidth Digital Content Protection (HDCP) is a system for preventing access to plaintext video data sent over Digital Visual Interface (DVI). Any technique that allows access to the plaintext data is considered breaking the system.

I show that with the public and private keys from 40 devices and O(40^2) work I can violate the design requirement--I can access the plaintext. Furthermore, with the 40 sets of keys and at most O(2^40) offline work I can usurp the central authority completely.

A good number of attacks have already been found:

http://www.mail-archive.com/cypherpunks-moderated@ minder.net/msg11705.html

http://apache.dataloss.nl/~fred/www.nunce.org/hdcp /hdcp111901.htm

You just need to be able to stream the raw data to storage fast enough (or simply pass it on to your display device of choice).

Don't tell anyone, but apparently it's not the most secure thing ever: http://apache.dataloss.nl/~fred/www.nunce.org/hdcp /hdcp111901.htm

Just a quick quote from that paper:

"HDCP's linear key exchange is a fundamental weaknesses. We can:

• Eavesdrop on any data
• Clone any device with only their public key
• Avoid any blacklist on devices
• Create new device keyvectors.
• In aggregate, we can usurp the authority completely."

See this paper.

Give me a board with two HDCP connectors, an FPGA and a USB port and I'll spoof any commercial HDCP display in a day or two.

The scoop: google returned 403 on mail-related queries, putting frequent abusers on a banlist. IP's on the banlist receive 503. From what I can gather, Google had no performance/scalability issues. The only negative side-effect was innocent IP's being put on the banlist, for example some webproxy's.

Actually, I bought a PCMCIA card with an Amd WiFi chipset in it just 2 weeks ago, so they're certainly not out of that market.

No Linux or FreeBSD support, so I used the NDIS wrappers in FreeBSD-current. Cool stuff.

Now if only my AP will run Linux or NetBSD ;)