Domain: digital-cp.com
Stories and comments across the archive that link to digital-cp.com.
Comments · 26
-
Not Blu-Ray. Cable, and iTunes
This isn't about Blu-Ray. That's already copyable. It's about cable, satellite, and Internet pay TV. What this really does is allow building a DVR that will record anything you can get out on an HDCP port.
It's also an issue in that manufacturers who are not paying fees under the HDCP contract could now make HDCP devices. Displays, for example. We're going to see a big boom in cut-rate grey market displays.
-
Open source not really the thrust of the brief
I found the footnote where they invoke the name of the W3C to justify patents interesting:
Software interoperability standards such as those promulgated by the World Wide Web Consortium (w3c) and the Internet Engineering Task Force (IETF) are necessary to enable the important uses of software, supra at 18-23, which require acquisition and assimilation of data from numerous heterogeneous sources. With the advent of patent protection for software, firms are able to selectively license innovations on favorable terms to the community of standards users, thus encouraging other firms to participate in and adopt standards.
Emphasis in original (page 29, 42 in pdf). I don't think that is the purpose of the W3C's patent policy, which states that any patented methods described in w3c standards must be freely licensed. The W3C makes recommendations based on common industry practice. IBM's interpretation implies that Patents must be used to rigorously impose standards as is done by: 3D-3C, LLC, DVD Format/Logo Licensing Corporation, 4C Entity, Digital Content Protection LLC, and Digital Transmission Licensing Administrator.
The main point of the Brief seems to be that the test for patentability should not rely on an arbitrary method of implementation. The Brief explicitly states that it relies on the US constitution that says that advances in the "useful arts" (technology) are patentable. As such, many of the claims may not apply in other jurisdictions such as my own. From the brief:
Patenting technological inventions promotes innovation. No sound patent policy supports protection for non-technological processes, including non-technological business methods.
- Page 7.8 of Brief (pages 20,21 of pdf)
I supposed if the scope of software patents is limited enough such that entire fields of innovation are not cut-off (a patent on Morse code was used as an example), I suppose they can't do to much harm.
-
Re:Wrong again.
> Vista never had any DRM of any kind built-in, other than
> the DRM support in WMP that was in XP.Actually, it does.
It is otherwise known as Intel's "High Bandwidth Digital Content Protection", and implemented by Microsoft as "Protected Video" and
Protected Audio" Paths.The following links may be of some use to you:
http://en.wikipedia.org/wiki/High-bandwidth_Digital_Content_Protection
Enjoy.
-
MOD GP DOWN
WTF? Why is GP being modded interesting?
Summary: GP is objectively wrong. Look it up if you must.
Here's a link to the white paper from DCP (owners of HDCP) (pdf).
I suppose Microsoft could agree to require it on DRMed media [...]
One the fancy new "features" of Vista is "Output Content Protection", which makes your pc compatible with HDCP-enabled sinks (and now with hdmi, any 1080p device). Here's the docs (from 3 years ago): http://www.microsoft.com/whdc/device/media/output_protect.mspx.
@Ahnteis: Nothing personal.
-
Re:The Dark Side?I suppose the developer of this piece of shit technology was well-paid for it (MUCH more than they deserved). So I guess there's a bright side for them.
But as for the other 99.999% of the population who will be screwed by it...We're out of luck.
-Eric
-
Re:Analog hole unnecessary(I realized, when seeing that your post was AC, that there was a risk that English was not your first language. That was why I gave the English lesson.)
No, the hacker would get 2 seconds of snowy static, until Ri and Ri-prime matched again. Ri and Ri-prime aren't the decryption keys, but they are hashes of the current encryption/decryption key. So the xmitter assumes that if Ri and Ri-prime match, that the receiver has calculated the next decryption key the same way it has. If Ri and Ri-prime did not match, then the keys on either end of the pipe will not match either; causing decryption to fail... and I can vouch from experience that this results in snowy static. (Ri is the xmitter's calculated hash, and Ri-prime is the receiver's. They are exchanged over the serial DDC bus. Also, since Ri is a shorter # of bits than the actual key, you can occasionally get a false-positive, wherein Ri==Ri_prime, but the keys are different. But because of the way the scheme is designed, this would only be a one-in-65536 chance, and wouldn't happen repeatedly in succession... so it's a detectable corner case.)
Also, the "2 second scenario" would only happen on a temporary cable disconnect, or a glitch in the signal (perhaps caused by EMI.)
You also asked:But then what's the added value of using the video stream data as an extra protection?
The "added value of using the video stream" as a salting process for subsequent key computations would have been to address the security issue presented by gnasher719:
HDCP generates a cipher bitstream. The cipher depends on the key in the graphics card, the key in the receiver, and a random seed. The graphics card outputs (content xor cipher). If you can record the encrypted output stream, and then convince the graphics card to send a black screen to the monitor, encrypted using the same random seed (and the keys are the same because you use the same graphics card and monitor), then you can know record (black xor cipher).
(content xor cipher) xor (black xor cipher) = content xor black = contentI think gnasher719 assumes that the encryption method itself makes primary use of an XOR gate to mask the cleartext with the encryption key. If his conjecture is right, then he has a good point. But I countered by stating that the HDCP folks could alleviate that risk somewhat by using the CRC of the decrypted frame as a salt when calculating the next encryption key. Then gnasher719's scheme (as stated) becomes ineffective, because he has 2 unknowns to solve for now, not just 1. Of course, he might be able to compensate by adding a new XOR term to his stated formula, provided that he can learn the value of that new term. I believe he can.
But, I still maintain that gnasher719's greatest hurdle is coaxing the transmitter to use the same pseudorandom seed for both the black stream, and the subsequent real stream. That's where his exploit really falls down.I think the re-synching scheme is intended for error tolerance only. The problem can be seen today with normal DVDs. If a DVD is damaged, the decompression may fail and cause blocks on the screen. Fast forward resets the decompression and the blocks go away.
In the case of HDCP, it is for both error tolerance, and for detecting man-in-the-middle attacks. DVDs correct them selves when you do that, because of how MPEG is set up; every so often, there is a full still image of a frame on the disk (I think they are called "I frames".) Stuff in between the I frames are temporal deltas. So, when things get out of whack, just skip past the deltas to the next I frame (or whatever its called) and you're back to good.
BTW, it seems that the HDCP 1.1 spec is free (libris) for viewing by anyone: Link
Consequently, I just re-RTFM'd, and... revision 1.1 -
Re:This is ribiculious...
That might well make you wonder what happens when someone like Sony or Toshiba eventually accidentally release a device with a flaw... Would Hollywood have the balls to make a million TVs go black with one stoke of their magic red pen?
The HDCP Speicification (PDF warning), available from Digital Content Protection, LLC describes the copy protection mechanism in detail, including the key revocation mechanism. They don't turn keys off per brand-name, as many here assume. Each piece of electronics equipment has its own key.
To summarize, the key vector is a 40-bit word that contains 20 zeros and 20 ones. That means there are [40:20] ("40 choose 20") combinations, or roughly 137 billion unique keys, enough for each CE equipment. Sender and receiver exchange key vectors and, using secret tables, compute a common 56-bit secret. To verify that they have the same sacret, the receiver sends a hash back to the sender, then waits for a stream. That effectively makes the time required to verify a valid key vector cost prohibitive for a brute force attempt, at least on the receiver side. Now, if someone wanted to brute-force a sender, it may be easier, but hackers want to be able to decode, not encode.
The key tables, electrical traces, timeouts, and several other tangible things that could be used to hack a link or transceiver are mandated and audited by DCP before they grant a license for the real keys. In all, it looked pretty air tight in my review. The media controllers seem to have learned from past mistakes and are employing smart people now to develop their content protection schemes. Strong encryption is becoming the norm... -
Re:This is ribiculious...
That might well make you wonder what happens when someone like Sony or Toshiba eventually accidentally release a device with a flaw... Would Hollywood have the balls to make a million TVs go black with one stoke of their magic red pen?
The HDCP Speicification (PDF warning), available from Digital Content Protection, LLC describes the copy protection mechanism in detail, including the key revocation mechanism. They don't turn keys off per brand-name, as many here assume. Each piece of electronics equipment has its own key.
To summarize, the key vector is a 40-bit word that contains 20 zeros and 20 ones. That means there are [40:20] ("40 choose 20") combinations, or roughly 137 billion unique keys, enough for each CE equipment. Sender and receiver exchange key vectors and, using secret tables, compute a common 56-bit secret. To verify that they have the same sacret, the receiver sends a hash back to the sender, then waits for a stream. That effectively makes the time required to verify a valid key vector cost prohibitive for a brute force attempt, at least on the receiver side. Now, if someone wanted to brute-force a sender, it may be easier, but hackers want to be able to decode, not encode.
The key tables, electrical traces, timeouts, and several other tangible things that could be used to hack a link or transceiver are mandated and audited by DCP before they grant a license for the real keys. In all, it looked pretty air tight in my review. The media controllers seem to have learned from past mistakes and are employing smart people now to develop their content protection schemes. Strong encryption is becoming the norm... -
Re:This WAS going to happen
Have a gander at:
http://www.digital-cp.com/home/HDCPLicense01262006 .pdf
Obviously, ATi and nVidia licensed to make "inactive robust" devices. That would let them put "HDCP-ready" in the lit.
How are what forces these to become "active", I wonder? Technically, its Vista. Now, we have to dig into Vista HDCP plans: A quote from Microsoft:
".. video resolution will need to be set to 480p. Display device drivers must support the DirectX Video Acceleration Certified Output Protection Protocol (COPP) for software signaling of HDCP ..."
And how do we support COPP?
Vista support IAMCertifiedOutputProtection class. Method KeyExchange() returns the driver cert (including public key) to Vista.
And how do we obtain such a driver cert?
From Microsoft, who also signs the driver.
So, there should be no problem supporting driver-based HDCP.
Now this link tells us that the cable industry has to sign off on the whole thing:
http://news.com.com/Microsoft+inks+cable+deal+for+ HDTV+support/2100-1042_3-5956408.html
Which they JUST have. But, I can't get my hands on a copy of that agreement.
What this boils down to:
- You can be compliant with HDCP as an "inactive" device
- You can be compliant with HDCP as an "active" device
- The difference seems to be the "trust" level that Microsoft has in your device driver, and the presence of another chip
- The entire secure path in XP/2 and VISTA appears to require the vetting of the copyright interests (CableLabs, others?)
- There appears to be agreement in that area, but exactely what, we are not sure
- Even if you have an HDCP "ready" video card, it may not be able to participate, UNLESS Microsoft keys and certifies a new driver.
- Even if you have an HDCP video card WITH a key-chip, it STILL requires a Microsoft certified driver.
- Drivers are probably going to be "time-stamped" (my read on the HDCP licensing, but I may be wrong -- my head started to hurt). Expiry based on certificate expiry.
And, no, I don't know for sure that the HDCP will be retrofitted, or not. Mostly because I can't get my mitts on the Cable/MS agreement.
Ratboy. -
Re:Makes Sense
For a practical look at the level of hardware protection that will be in such devices, take a look at the HDCP specifications, or more specifically the license agreement (PDF), look in Exhibit D (page 45 of the linked PDF) for the "Robustness Rules".
It won't be anywhere near impossible, but it will take significant effort to crack. If they do it right, a successful crack will only allow them to compromise the specific device they're working on. While that will certainly be enough to then start siphoning out protected content, it won't be able to be done on a wide-scale basis, and that's all they need to do to keep most people from re-distributing tunes they've bought.
What it doesn't solve is that content will still be found on the Internet, and if they make it too difficult to use what you buy in the way you want to use it, people will start turning to such unauthorized copies as the only way to do it - and a significant number of them, who never would have done it otherwise, will then decide "why bother paying" for a crippled version.
-
Some background on the politics of this standard
One of the biggest reasons that many companies want a standard outside of DVI and HDMI is the fact that Silicon Image and Intel basically control the show when it comes to digital interfaces. Intel needs to be mentioned because, although Silicon Image appears to spearhead the standards and controls key patents (e.g. TMDS), Intel exerts a high level of influence due to partial ownership of Silicon Image and DCP LLC. In fact, if you look at DCP LLC's address at the bottom of its web page, it resides inside Intel!
When DVI first came out, it was in a camp that was separate from VESA, the independent standards body responsible for the video signalling standards for PCs. VESA had been looking for a digital alternative for years but the Digital Display Working Group promoted DVI through some of the bigger manufacturers of both computer displays and manufacturers of electronics of those displays. DVI was ok but it was plagued with problems like a poor quality connector, limited cable length and very poor standards compliance. This largely limited DVI's adoption in the market for a number of years. The copy protection standard, HDCP, was added in the usual fashion of trying to "protect" the content providers. As for the standards compliance, Silicon Image knew it had screwed up and so created a compliance test center. The irony here is that Silicon Image's own first generation receivers don't even work with some of its own transmitters!
Though most consumer electronics manufacturers were included in the DDWG, at least one was conspicuously absent during the formation of HDMI, which is backwards compatible with DVI but has a smaller and more robust connector and more geared for consumer electronics rather than PC applications. That absent company was Samsung, and Ian Miller of Samsung was quite important in the VESA organization. VESA had continued during the time of HDMI's creation and ramp-up of making a new standard, the latest one being NAVI that died on the vine. Having been excluded, and knowing Samsung's growing presence in many markets and the stranglehold of Silicon Image and Intel with respect to patents and copyright protection control with limp alternatives, I believe that the current companies within DisplayPort led by Ian Miller decided to take the initiative and move forward with an independent DisplayPort standard and independent copy protection mechanism. The new copy protection scheme, called DPCP, is administered by Philips rather than Intel.
The physical layer of DisplayPort is largely based on PCI Express in order to leverage the intellectual property already within these companies and avoid licensing and royalties associated with Silicon Image's TMDS and Intel's HDCP. One very interesting point for all /.ers - the interface standard is optionally encrypted with DPCP, but it can apply to every single link both outside and inside the display! This means that you may not be able to crack your panel open and hack the hardware inside without a hacked encryption key (which is heavily guarded at all points within its acquisition and programming into devices). Even with HDCP, it would be a simple matter in a flat panel to take the unencrypted LVDS output and fabricate a small board with an unencrypted DVI digital output for HDTV. Therefore, don't look at DisplayPort as anyone's savior. It also remains to be seen if people will accept yet another display connector for their PCs and the resultant fragmentation, though both ATI and Nvidia are on board DisplayPort.
In short, don't expect a whole lot of advantages for the end user here. The politics of the display industry are significant and the average consumer will continue to suffer as these politics play out in the grander scheme of business. -
HDCP is in the hardware
HDCP devices exchange a key that is embedded in the device itself -- in this case, a key that would be embedded in the monitor. You should read the spec here to improve your understanding:
http://www.digital-cp.com/home/HDCPSpecificationRe v1_1.pdf
So there is no need for name-calling -- it is a monitor thing. -
Re:You have no clue.
Unless you only have one video source, you probably want to do that anyway. Even if you have multiple video inputs on the display, you want the sound to follow the video. So either you connect the audio/video from each device to the amp, and send the video to the display (and do the switching in the amp), or send the audio/video to the display and send the audio to the amp.
My preference is for a straight monitor that does nothing but display a video signal. All the processing/switching is done in the receiver, including a TV tuner (which would do any closed captioning, for instance). No speaker in the "TV", it is JUST a monitor. Sending everything to the receiver first also means I can route stuff out to other devices besides the TV - e.g. copy from Replay to VCR.
But then HDCP comes along and screws all of that up. You can't copy from one thing to another (my understanding is that limited recording will probably be allowed, but only if played back on the same device, and no copying of that signal will be allowed at all). So the idea of a central hub becomes much less useful. Send everything to the TV, which sends audio to the receiver (if you want to) (but only using an HDCP-protected link, i.e. HDMI, which means you're totally wasting it as there's no need for the video signal - going the other way there's no need for the audio signal).
For content that is sent encrypted under HDCP, you are required to route the audio and video to only HDCP-compliant devices (if you want to stay with high-quality digital). For re-sending audio as digital signals using other formats, the HDCP standard requires that it be no better than CD quality. There are a variety of digital standards that are allowed in the license agreement. Of interest is that IEC-958/60958 (S/PDIF) is not allowed to be supported for DVD-Audio (it isn't clear if that includes IEC-61937) in equipment manufactured after July of this year. Analog quality is not restricted by the HDCP standard for "Presentation Devices", but I think that means the quality sent to the screen or speakers, as there are all sorts of requirements that the analog signals inside the device not be easily useable. I'm not sure if that means that an HDCP-compliant receiver can only send audio to HDCP-compliant speakers. There are also several odd requirements that audio may not be presented at more than 1.5 times speed unless it is pitch-corrected (differs for different source material, e.g. Super Audio CD, DVD-Audio, etc). I don't know if that's to try to prevent high-speed dubbing or what.
What I find particularly obnoxious is the requirement that all material sent on digital outputs effectively has to have the "never copy" flag set in the SCMS info, even if it is coming from something that says "copy always", although there are various exceptions. The whole document is fairly confusing with lots of special cases and apparently conflicting requirements.
They've locked it up pretty tight, with interlocking agreements on manufacturers of components, resellers of components, manufacturers of systems, and content producers. Transmitting components are relatively unrestricted, but receiver components are strictly controlled. Software has to be obfuscated and protected against attacks using ICE and debuggers and the like.
-
Re:Firewire?
Existing boxes ($600+) may allow firewire transfers for now, but the new ones will have copy protection built in, possibly even in Firewire (1394/5C). The powers that be want to do away with current DVI and move to HDCP compliant DVI/HDMI which will prevent us from doing anything with the content on our computers unless we're willing to use analog converters. I have a dream, that one day society will unite and boycott the entire entertainment industry and content providers.
:-) -
DRM for TV is already here
i won't buy anything like that. i doubt you will see anything new with drm for tv outside of the next 10 years.
It's already here. It's called High-Definition Content Protection (HDCP, intro here, and definition here). This system provides serious crypto, unlike CSS. It also has provisions for devices to exchange lists of compromised keys, so they can "blacklist" any key which the crackers break.
I've already seen one retailer listing HDCP as a feature on a big-screen TV.
-
So does DVI
What, have you never head of HDCP before? You haven't been shopping for an HDTV lately, I take it. In fact, the new HDTV tuner cards from ATI and others all have HDCP support to prevent you from bypassing the damned digital broadcast flag.
-
Re:"TrustedTV(tm)Well, any display with a DVI/: HDCP (as developed by Intel), or HDMI connection, or IEEE 1394 (Firewire/iLink) with 5C.
Mitsubishi have Firewire, most new displays have DVI w/HDCP, and the DVD players that upconvert to HD resolutions are only output over their HDCP enabled DVI ports! Granted, at present HDCP is rather kludgy, have read articles on problems connecting with the latest boxes and displays. Not to mention the test channel on DirecTV that doesn't always work.
Also, 5C works, since you can't record a D-Theater movie (warning flash), to a computer with a firewire port, or use the VGA connector from the Samsung SIR-T165 firewire STB when playing a tape. Oh, you say that's not fair use, but, it's just a glorified VHS tape, so how robust is that? Are you not allowed to make a backup of your flimsy tape?
And, in the last year or so one of the cable companies in New York "accidentily" enabled 5C copy-never on their cable boxes.
DRM for HD is just getting started. Can't wait for the Broadcast Flag.
But, back to the article, hopefully Intel can get better yeilds since Hitachi and Mitsubishi have pulled their sets (ahh, can't find any links.) erik g
-
The DVI Output is COPY PROTECTED!Come on guys get a clue. The DVI signal (which contrary to other silly opinions CAN be used to make perfect little digital copies if you are clever) includes something called HDCP (High-bandwidth Digital Content Protection) which is transmitted over the I2C pins on the DVI connector. If you are not decoding this signal you get a lousy snowy picture. And yes your computer system includes those same pins and you will ultimately find yourself dealing with precisely the same problem when you play DVD's on your computer so you might as well start crying now.
Alternatively you could start working on building yourself an HDCP pass through dongle right now. Can't be all that hard.
The motion picture industry is certainly concerned about you making copies of DVD's but let's face it those have been cracked already. They are a somewhat lost cause. What they are now attempting to guard against is people making copies of High Definition video. The content that will be coming out on blue laser equiped DVD's at 720p+ resolutions. The notion is, that end to end encryption is the answer. By putting the decoder in the display you are screwed. OK not really but it does become ever so slightly harder.
BTW Samsung makes a VERY nice DVD player (DVD-HD931) with DVI out that additionaly does scaling to 720p and 3:2 pulldown using the Faroudja chip. Now at $250 that is a bargain and a half. If only the damn thing would put that signal out RGB so I could watch it on my Sony 1271 projector... I'd be a happy camper. We need the Europeans to put out 720p on SCART connectors (OK so maybe just I do). Curious that none of European market machines include the Faroudja chip.... Actually really irritating is more like it (once again possibly editorial).
So.... this is all FULLY above the Radar and be prepared to grab your ankles because you know what is coming...
Where all think alike, no one thinks very much
-
Link to the official specification
Check this out. It's the home page for Digital Content Protection, LLC -- the folks who administer the HDCP protocol licensing system. At this site you'll find HDCP's specifications, upstream protocol, license agreements, reseller agreements, etc.
Of interest, also, may be Niels Ferguson's paper in which he details the cryptographic weaknesses in HDCP. Unfortunately, he won't publish the document due to fears of being prosecuted under the US DMCA. -
this isn't compliant with the hdcp license itself
here's the license pdf from the makers of hdcp
sections 3.3/3.4 clearly state that it's not legal to have a dvi/hdcp receiver with any analog outputs (save 16/48 audio).
not having dvi on your set (or not having a mitsubishi 'promise') is nigh a death knell for future hdtv compliance.
here is an excellent writeup on the present situation -
What this really is aboutThese FCC rules are designed to enforce the proposed HDCP (High-Bandwidth Digital Content Protection) standard over DVI/Firewire connections. HDCP will be used to "protect" all high-definition video content starting with over the air, cable, and satellite digital television signals and eventually hi-def videotapes and DVDs. Details may be found here, but basically HDCP ensures that only HDCP enabled devices can play hi-def video. Non-HDCP devices will only receive down-converted (S-VHS quality) signals.
So what does that mean for you. If you were planning on "sharing" hi-def movies over the web, you are probably out of luck (of course the multi-day downloads for a hi-def movie might also discourage you). Otherwise, this won't affect you much. When you buy your new hi-def TV, it will show you great looking hi-def video from your antenna or cable. You can still play your old video tapes and DVDs. Your new hi-def DVD player will look great.
So where is the problem? In most cases, you will be able to tape shows onto your existing VCR and TIVO as well as your nifty new hi-def VCR or TIVO. But there are several "flags" in the HDCP protocol that allow the broadcasters to either limit taping to low-def resolution or to prohibit it all together. The intent is to prevent you from making copies of hi-def DVDs or pay-per-view movies. The networks are unlikely to decide to prevent you from time-shifting, they understand it's value, but there is nothing stopping them. There has also been talk of a flag which would disable the fast-forward function (aka commercial skipper) on hi-def recorders/players. Then there are those of us who have spent thousands of dollars as early adopters and helped work the kinks out of the DTV system. If HDCP gets implemented, all existing DTV equipment becomes useless.
-
Re:Where we can go from here...
So the question is this: how hard is it to build a black box that takes an mpeg2 video stream over 1394 and strips it of its copy protection?
Pretty hard, since your black box won't have a certificate issued by the DTCP certificate authority. You can read more about DTCP at the official site.
However, it looks like the manufacturers are turning from 1394/DTCP to DVI/HDCP (and later, HDMI/DTCP). Theoretically, HDCP has been cracked, but it looks like it would take a lot of resources to actually execute the crack. -
Not leaked.
These specs are put up on the digital-cp site itself. I dont think that they have been "leaked".
-
CPRM is just the tip of the iceberg!!!
Have a look at what those industry morons are up to:The proposal to enhance the ATA-spec with copy protection extensions is an enhancement of CPRM.
CPRM itself is just one of several technologies which are part of the so-called "Content Protection System Architecture" (CPSA).[http://www.4centity.com/4centity/data/tech/cps
a /c psa081.pdf]
Enter CPSA, servants, attendants.
CPSA is an attempt to define a technological framework in order to fulfill the entertainment industry's (RIAA, MPAA etc.) demand for complete control of distribution and copies of audio/video content. The idea is to create a secure end-to-end chain from cable-station/satellite-receiver/settopbox/DVD etc. to the enduser's speaker/digital-display etc.
CPSA is supposed to include the following content protection technologies among others:
Content Protection for Recordable Media (CPRM)
- protected exchange of audio/video on DVD, FlashMedia, (ATA-hdds planned)
- encrypted storage of content
- protected storage of content management information (CMI)
- system renewability
- methods to prevent playback of bit-by-bit copies
developed by: 4C (IBM, Intel, Matsushita (MEI), Toshiba) http://www.4centity.comContent Protection for Pre-recorded Media (CPPM)
- robust protection of DVD-Audio content on DVD-ROM media
- encrypted storage of content
- protected storage of content management information (CMI)
- system renewability
- methods to prevent playback of bit-by-bit copies
developed by: 4C (IBM, Intel, Matsushita (MEI), Toshiba) http://www.4centity.comContent Scrambling System (CSS)
- protecting DVD-Video cotent via authentication and content scrambling
developed by: DVD Copy Control Association (CCA) http://www.dvdcca.orgDigital Transmission Content Protection (DTCP)
- robust encryption of content passing between digital devices in the home e.g. IEEE 1394, USB
- copy control information
- authentication and key exchange
- digital encryption [sic!]
- system renewability
developed by: 5C (Hitachi, Intel, Matsuhita (MEI), Sony, Toshiba) http://www.dtcp.comHigh-bandwidth Digital Content Protection (HDCP)
- encryption on high-bandwith interfaces to digital displays e.g. DVI
developed by: Intel http://www.digital-CP.com4C/Verance Watermark
- technology for creating/reading watermarks (Content Management Information - CMI) in audio content
developed by: Verance Corporation http://www.4centity.comFinally, a video watermarking scheme (to be selected by the DVD CCA)
All information above taken from:
http://www.4centity.com/4centity/data/tech/cpsa/cp sa081.pdf
(Dated February 17th, 2000; revision 0.81) Absolutely recommended reading!!!
So much for the overall framework.
Some interesting details on the technologies described above:
Content Management Information (CMI)
- additional information added to the content in order to establish rules and conditions restricting its usage
Copy Control Information (CCI - a subset of CMI)
- copy restrictions through data flags: copy free, copy once, copy nomore, copy never
There is an enlightening presentation on DTCP (warning: horrible layout):
http://www.dtcp.com/data/dtcp_tut.pdf
A preliminary version of the DTCP specification (v1.1) can be found here:
http://www.dtcp.com/data/DTCP_spec11_informational
A few buzzwords to wet your appetite:
- content encryption, supported ciphers: M6, Blowfish (modified), DES
- authentication: Diffie-Hellman key exchange, PKI
- cryptographic functions: SHA-1, random number generator
[cf. Chapter 4.4 Cryptographic Functions]
The next document makes for another interesting read:
http://www.dvdcca.org/4centity/data/licensing/adop ter/interim_CPRM_CPPM_agreement.pdf
let's have a look at some excerpts:
Exhibit B-1 CPPM COMPLIANCE RULES FOR DVD-AUDIO (p.35ff):
Section 3. Encoding Rules for individual parameters of prerecorded DVD-Audio disc
- specifications for control of copy permission (3.2)
- specifications for control of copy numbers (3.3.1)
- specifications for audio-quality control of copies (3.3.2):
The Audio Quality Parameter (Q) consists of 2 bits and defines the number of channels (ch), sampling frequency (fs), and quantization bit level (Qb) of permitted copies.
another example:
section 4. Playback and output control rules for participating player devices
- playback control by audio watermark: unencrypted content with CCI bit of Audio Watermark set to any other state than "copy freely" will not be played (4.1.1)
- player devices built after Dezember 31, 2000 have to respond to the Verance/4C Audio Watermark (4.1.2)
- as soon as a method is determined players shall, through media type detection, prevent playback of recordable media with CPPM protected content(4.1.3)
An interesting tidbit on HDCP can be found in an article at maximumpc.com:
http://www.maximumpc.com/reprint/intel_revamps/
a quote from that article:
(...) Intel has proposed the High-Bandwidth Digital Content Protection encryption spec. Using hardware on both the videocard and the monitor, HDCP will encrypt data on the PC before sending it to the display device, where it will be decrypted. The rub is that only new DVI-equipment will have the feature, which creates a slight risk of obsolescence for those who invest in DVI early on.
Intel officials have downplayed that issue. They claim that any DVI monitor will be able to display protected content, because the HDCP-equipped DVI card will simply sense that an older DVI monitor lacks HDCP features and will lower the image quality to keep the content protected. Of course, no one has accounted for consumer acceptance. Will people embrace a standard that reduces image quality on their older equipment? Intel officials say the loss won't be enough to irk people.how about this one:
http://www.techweb.com/wire/story/TWB20000218S0008
"HDCP uses a 56-bit key, with individual keys distributed to the various vendors. A violated key could be tracked down and revoked over a satellite broadcast network, for example."Apart from the documents obtained from the specification websites referenced above a search on the manufacturer's websites (Panasonic, Sony, etc.) for keywords like DTCP, CPRM etc. yields further information such as press-releases and other documents.
A couple of devices that already make use of these technologies have already been announced and/or gone into production such as:
Matsushita (Panasonic) DVD-RAM recorder DMR-E10
Panasonic D-VHS VCR PV-HD1000
Silicon Image SiI 168 PanelLink transmitter chip for DVI hardware
Silicon Image SiI 861 PanelLink controller chip for DVI hardware chip
And you guys thought CSS was the only thing to be worried about.
---Police Line - Do Not Cross !--- -
The Digital Video Interface - DVI
This one is quite scary, with an encrypted signal leaving your computer to your monitor. See http://www.digital-cp.com/.
All new monitors have both analog/DVI inputs. Eventually new monitors will have only DVI inputs, and computers only DVI outputs. This will force countless computer upgrades, as making a box to decode the DVI to run to analog will be illegal under the DMCA. So, summarily we have;
1) Our right to "reverse engineer" stripped away form us,
2) Software that will control what we see and when we see it, taking away any last remnant of "first sale" rights,
3) People who can not afford to purchase "the right equipment" left further behind and denied access to what others are seeing and using,
4) As copyright law is "primarily defined by use" it will become accepted business practice to charge a "per use" fee for everything, including public domain material like "facts" (i.e. phone books)
5) Richard Stallman's right to read scenario becomes reality.
To say this comes from the pits of hell is an understatement. -
Re:Sounds like more access control to me..."...putting a recording device between the input and the screen, recording the encrypted signal, and then sending exactly the same encrypted signal to the screen again?"
Now THAT's a good point. Wish I'd thought of it. But according to the company behind it (linked to from the eetimes.com story) their business certainly is "protecting commercial entertainment content".