[KeithIrwin]

I've written a brief paper which can be found at http://www.angelfire.com/realm/keith...CPAttacks.html which details four specific vunerabilities in the HDCP copy-protection scheme.


Keith

 

[vruiz]

Very interesting findings, but aren't you opening yourself to a DMCA violation charge by doing this?


------------------

Vic Ruiz
STOP HDCP/DFAST/5C

 

[KeithIrwin]

No, almost certainly not. The DMCA forbids breaking of copyright protection schemes and distribution of devices for breaking copyright protection schemes. As I have no HDCP device myself, I've never actually broken the copyright protection scheme and although software has been ruled to constitute a device, a description of how one could do something has never been ruled to be a device. (And if it ever is, I'm moving to Canada or Australia or somewhere). This, of course, doesn't mean that I couldn't be sued for such anyway, but Intel/Digital Content Protection, LLC is certainly not going to do so. They've been very friendly towards me and released the standard to the public precisely so that it could be reviewed and flaws found. There is a small chance that the MPAA would sue me, but they likely don't even have standing to sue. Certainly, the overall result of any such lawsuit would only be a bunch of publicity for me, which, to be frank, I could use.


Keith

 

[kagato]

With the exception of the title, the whole thing reads like a research paper. I think the MPAA will take a note from the RIAA that going after research papers is a sliperly slope that will get at least parts of the DMCA tossed.

 

[KeithIrwin]

I would describe it as a research paper. Actually, the title is not out of line with normal titles for cryptographic research papers which find flaws in existing cryptographic systems.


I don't expect that even the MPAA would sue me over this, but with them one never quite knows.


Keith

 

[vruiz]

Hopefully this will serve to slow down the adoption of the standard while they try to fix the flaws. In the meantime, more HDTV equipment gets sold giving us a more solid installed base, and therefore more political (i.e. screaming) power.


------------------

Vic Ruiz
STOP HDCP/DFAST/5C

 

[cymro]

Keith,


Very interesting.


Your first proposal "just record it", however, is impractical because, assuming 10 bit digitizing, and sampling at the nyquist rate, it would require a storage device capable of swallowing a data rate of:


(1080*1920*30/2)*10*2=622.08 Mbits/second.


Furthermore, the storage capacity needed would be:


(622.08*10^6)*3600/(8*10^9)=279.936 GBytes per hour.


Part of the reasson that they want to transmit the uncompressed data is to make recording the uncompressed stream prohibitively expensive.


I'm not qualified to judge the rest of your paper, but I suspect that ciphers used can make the matrix defining the coefficients of the simultaneous equations be ill conditioned.


[This message has been edited by cymro (edited 07-30-2001).]

 

[KeithIrwin]

Although currently prohibitively expensive, it would not be technically difficult to build an array of hard drives or of RAM which could log the information at those rates. Given that technology becomes steadily cheaper as time progresses, in a decade or two, it probably won't even be prohibitively expensive any longer. More to the point, though, we have to assume the existance of the sort of opponent that the system is aimed at preventing. As I say at the beginning of the paper, if we assume that it is impossible to record the data stream, then there isn't any point in encrypting it to begin with, so clearly the encryption system must be designed with the assumption that its output could be recorded.


The cyphers do not affect the coefficients of the matrix. The coefficients are all defined to be either zero or one. There's only so much you can do with zeroes and ones. The only assumption concerning the properties of the coefficients that I make is that the Key Selection Vectors comprise a basis for the space, and I explain why I make that assumption in the last paragraph of the fourth attack, and if that assumption is not true, it would require changes in the fourth attack, but would almost certainly not remove the vunerability of the system to attacks of that nature. Also, there is no indication in the standard that anything of that nature is being attempted.


Thanks for your feedback, though. I always appreciate thoughtful commentary.


Keith

 

[Spoffo]

One thing eludes me about the "no HD analog output" of this thing:


Any CRT-based display device, even an HDCP-compliant one, is going to have to ultimately put analog R G & B video signals through some kind of analog video amps to drive the CRT. It's not trivial, but it wouldn't be much of a deal for a competent video EE to tap into these and, presto! you've got in-the-clear, full-resolution analog video, which you can then re-compress into your pirate DVDs or e-store or whatever.


In other words, DCHP may effectively stop casual home copying or some kid who wants to rip an HD movie on his computer, but it doesn't seem like more than a speed bump for the serious commercial pirates, who are the people the studios are supposedly worried about.


Other than not being paranoid about studio plots to control my life, what am I missing here?

 

[harlock]

Exactly Spoffo,

MPAA wants people to believe they're doing this to protect against pirates but it's really about turning you play/on button to a pay button.


Jim

 

[work permit]


Quote:

Any CRT-based display device, even an HDCP-compliant one, is going to have to ultimately put analog R G & B video signals through some kind of analog video amps to drive the CRT. It's not trivial, but it wouldn't be much of a deal for a competent video EE to tap into these

Tamper proof electronics can be made. Imagine encasing the video amps and wiring in an epoxy which can't be "broken into" without destroying the wiring for the devices. Don't forget, you don't need it to be impenetrable by the CIA, just your average EE sitting at home.


Tamper proof chip technology is very well developed and has been applied in the military, smart cards, and even the DIVX decoding chip.


------------------

Alex

 

[JustMike]

Quote:

Originally posted by Spoffo: One thing eludes me about the "no HD analog output" of this thing: Any CRT-based display device, even an HDCP-compliant one, is going to have to ultimately put analog R G & B video signals through some kind of analog video amps to drive the CRT.

Well, there are of course non-CRT options, like DLP and D-ILA. Aren't they digital all the way to the chip?


------------------

Mike Kobb

(Formerly "ReplayMike", but no longer affiliated with the company; these opinions are mine alone.)

 

[work permit]

Keith:


Great article. I'll admit that I am not familiar with HDCP, I've only read the tech docs on DTCP, so my question is on that technology.


On your first point:

Quote:

The First Attack - Just Record

In DTCP, the source and sink must authenticate each other through a public-key-based digital signature algorithm

and key-exchange algorithm, which includes the use of random number generators by both source and sync devices to "challenge" each other.


Is this the case with HDCP? If so, than doesn't that eliminate the "record everything" approach?



------------------

Alex

 

[work permit]


Quote:

Well, there are of course non-CRT options, like DLP and D-ILA. Aren't they digital all the way to the chip

Even easier to encase in tamper proof way.


------------------

Alex

 

[rlsmith]

I don't want to get into the business of breaking security schemes. But the thing to remember is that you don't try to break the scheme by a frontal, brute-force approach based on the astronomical mathematics; you want to find some side approach that will exploit an unexpected fault.


If this works, there are going to be literally millions of copies of these devices built into hundreds of different models of machines, with many companies and individuals having access to the information.


There will also be an unprecedented number of hackers going after this. While I will not be one of them, I will watch the proceedings with amusement.


My prediction is that it will be gloriously broken in many ways by many people.


I do BTW think that the MPAA has some valid points and that some system is called for. The 5C system is too draconian, open to blatant misuse. If the studios press it too far, it will be smashed to smithereens.

 

[work permit]

HDCP only uses 56 bits? The dtcp uses 320 bits for its public key (160 private). Yes, I do see the possibility of a detrmined hack to compromise a single device; the entire system could be broken a few years .


I'd in fact imagine seti-like "HDCP breaking" screen savers popping up all over on HTPC's throughout the country.


How many keys can a 1 gighz pentium go through? I think its something like 3 million/second, so if you had 1000 machines working on it you would crack a single device in a little under a year? Do I have the math right?


------------------

Alex

 

[work permit]


Quote:

I don't want to get into the business of breaking security schemes. But the thing to remember is that you don't try to break the scheme by a frontal, brute-force approach based on the astronomical mathematics; you want to find some side approach that will exploit an unexpected fault

One thing that is uncertain is the degree to which the internal electronics will be protected. Certainly the chips will be, but protecting the entire display driver electronics will be expensive and manufacturers won't do it unless they're forced to by the licensing boards.


------------------

Alex

 

[KeithIrwin]

To answer Alex's questions:


No, HDCP does not use random numbers from both sides, only the source side. Which is precisely why the "just record" attack would work. You are absolutely correct that if the sink-side used random numbers as part of the authentication protocol too that the first attack would be void.


Yes, it does only use a 56-bit key. Amazing, huh? In fact, people have built DSP arrays which have broken 56-bit keys in as little as three days. I almost wonder if they didn't choose 56 due to some form of import/export restriction rather than because of it being a robust key-size.


Keith

 

[dkeller_NC]

Well, if this system isn't modified to contain longer key lengths and is as straitforward to break as Keith suggests (notice I didn't say easy - just straightforward), one can only hope that it is broken immediately and often. Doing so would perhaps convince the dolts at the MPAA that they need a new business model, not a better cryptographic scheme.


------------------
ABC = Another Boring Channel. Watch CBS on Monday Nights!

 

[work permit]

56-key rsa was broken back in 1997 if i remember correctly. I think they're working on 64 bit now. Surprising choice. I would guess the real time encoders in the displays that would have work at the uncompressed bit rates are too expensive?


I'm also surprised they're not using dual challenge authentication.


Given that these sets won't be out for another year, and will take a couple of years to reach critical mass, I could see the system broken by the time its used on a widespread basis. Also, real time hdtv mpeg boards will be available as well.


HDCP is beginning to sound like macrovision: An annoying feature meant to keep "honest people honest".


I stand by my original view, though, that dtcp is not crackable through the front door.


------------------

Alex