Forgot your password?
typodupeerror
Encryption Intel Media Open Source

HDCP Encryption/Decryption Code Released 225

Posted by timothy
from the didn't-take-long dept.
rtj writes "We have released an open-source (BSD licensed) implementation of the HDCP encryption/decryption algorithms. The code includes the block cipher, stream cipher, and hashing algorithms necessary to perform an HDCP handshake and to encrypt or decrypt video. The code passes the test vectors provided in the HDCP specification and can encrypt video at a rate of about 180 640x480 frames/second on a 2.33GHz Intel Xeon CPU. This isn't quite fast enough to decrypt 1080p content in real-time on a single core, but decryption can be parallelized across multiple cores. There are also many opportunities for further optimisation, such as using SSE instructions. We are releasing the code in hopes that others will further optimize it and use it in their HDCP-related projects."
This discussion has been archived. No new comments can be posted.

HDCP Encryption/Decryption Code Released

Comments Filter:
  • No hardware? (Score:3, Interesting)

    by gtvr (1702650) on Wednesday September 29, 2010 @08:12AM (#33732956)
    So does this negate Intel's statement that you can only do this if you build a chip with the code in it?
  • Re:Congrats! (Score:5, Interesting)

    by Bert64 (520050) <bert@@@slashdot...firenzee...com> on Wednesday September 29, 2010 @08:47AM (#33733170) Homepage

    It just means you can't do it in realtime on a 2.5ghz core2... Nothing to stop you dumping the encrypted data somewhere and decrypting it later.

    Also consider a 2.5GHz Core2 isn't all that modern, and it doesn't even specify wether this cpu is dual or quad core. With 6, 8 and even 12 core processors available, plus the possibility to parallelize over multiple processors 60fps is quite achievable today.

    There is also the possibility of using a GPU to do this.

  • Re:No hardware? (Score:4, Interesting)

    by KiloByte (825081) on Wednesday September 29, 2010 @09:03AM (#33733348)

    In other words, the HDCP hardware decryptor is more powerful than the main CPU. Even with the specialized-vs-generic advantage, just think about the power wasted encrypting/decrypting it for no reason but letting the cartel control the market market and the complexity of the electronics you have to buy with your own money.

    Every HDCP device should be slapped with a huge carbon and recycling tax -- with an extra punitive rate, since the waste is introduced intentionally.

  • Re:No hardware? (Score:5, Interesting)

    by blincoln (592401) on Wednesday September 29, 2010 @09:09AM (#33733406) Homepage Journal

    In other words, the HDCP hardware decryptor is more powerful than the main CPU.

    I'm pretty sure it's not, given that the $50 video card I bought last week to run a second monitor at work has an HDMI port on it. If the chip were that powerful, it would be too expensive to put on a card that cheap.

    I'm sure this is just a case where specialized hardware is able to accomplish the task a lot more quickly than the first version of some software running on a general-purpose CPU.

  • Re:That was quick (Score:3, Interesting)

    by Goaway (82658) on Wednesday September 29, 2010 @09:18AM (#33733484) Homepage

    Any bets on when we see this implemented in more full-featured software suites?

    Never, as no software suites have any use at all for HDCP.

    HDCP is used only for encrypting content as it travels across the cable to the display. Only devices connected to the display cable will ever see HDCP-protected content. Software players process the data before it is encrypted with HDCP.

    The only thing this is good for is for wiretapping a display cable to capture uncompressed video, or for making a box that fools your paranoid computer into believing the display connection is protected.

  • by Anonymous Coward on Wednesday September 29, 2010 @09:34AM (#33733642)

    but how are you going to get the HDMI output of your DVR into your GPU?

    without doing the handshake right, there will be no stream to decode later on.

    people will need to build an FPGA implementation of this, maybe parallel, to strip the HDCP.
    by programming the FPGA with loads of possible sink key's they can switch as soon as one is blacklisted.

    I don't know if there are any HDMI grabbers out there, but i don't think they're HDCP compliant.
    i do know there is a component one that does 1080P, so maybe a HDMI->Component converter can be built.
    (i know these exist already, but they might be blacklisted. i don't know if any device can have it's key updated, but this implementation will)

  • by bill_mcgonigle (4333) * on Wednesday September 29, 2010 @10:14AM (#33734020) Homepage Journal

    Nice, a Braille reader for BluRay subtitles should now be technically possible. BluRays make decent eBooks with the right software.

    (HDMI neglects to ship closed-captioning data so you *have* to capture/diff/ocr from HDMI rasters to extract the text).

  • by Anonymous Coward on Wednesday September 29, 2010 @10:16AM (#33734046)

    When you watch a DVD or Bluray, the content is decrypted, then encrypted and decrypted again for HDCP.

    A significant amount of energy is devoted to protecting the pre-internet business model.

    This will only get worse over time, as media gets larger and media companies more aggressively cling to the old business model.

    It took more than 100 years for the world to really adjust to the printing press. I assume at least the same time period for the Internet, before we can have our enlightenment period.

  • by wvmarle (1070040) on Wednesday September 29, 2010 @10:48AM (#33734418)

    DRM must be really really costly. And the bad thing is we're all paying for it - the honest customers even more than the "pirates" against which it is supposed to protect.

    When I see how much computing resources it takes just to en/decrypt a stream - OK it's a general purpose processor, not something dedicated - I am thinking of the cost of those resources in all the devices we have. After all your BluRay player has to read the BR disk, decrypt the content, then encrypt it again to an HDCP stream, which is sent over to say a TV, which then decrypts it again to make it a watchable image.

    Now if only we wouldn't need that encryption.

    BluRay itself is (all but) cracked, that's one decryption step that can be done away with.

    HDCP transfer is now done with; that's another two steps of en- and decryption that can go.

    That is at least three pieces of beefy hardware. That's three chips that won't come for a few pennies each. That's three chips that will be wasting significant amounts of energy.

    Plus of course the huge upfront cost to develop all that: to develop the algorithms, set up the secure key supply, designing the dedicated de/encrypt chips and writing all the software around it to make it work.

    And all of us are paying for it. It makes BR players and disks and HDCP compliant hardware more expensive than necessary, it even increases our power bills unnecessary. I really wonder when this madness can come to an end.

  • by LocalH (28506) on Wednesday September 29, 2010 @11:10AM (#33734658) Homepage

    I'd love to see a device that generates a new key every time it boots up. The ultimate unblockable device, no matter how many keys get revoked.

  • Re:That was quick (Score:3, Interesting)

    by bucky0 (229117) on Wednesday September 29, 2010 @01:38PM (#33736800)

    I don't have a DVR, but a common complaint about CableCard is that a) many cable companies charge $5/mo for the card (which is as much as it costs to rent some of their DVRs), and B) CableCard is only supported using certain PVR software under windows (encrypted things have to be stored encrypted on disk). I could be wrong, but I think only MS's software supports it.

    Though, honestly, with netflix and hulu, I don't see a reason to store gigs and gigs of video like I used to.

  • by awshidahak (1282256) on Wednesday September 29, 2010 @02:32PM (#33737828)
    Problem with this: Your other devices will eventually get restrictions on them that only allow a certain number of new devices to be connected to them before they fry. Every new key counts as a new device.

E = MC ** 2 +- 3db

Working...