Become a fan of Slashdot on Facebook


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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:
  • Obligatory (Score:3, Funny)

    by Pojut (1027544) on Wednesday September 29, 2010 @08:09AM (#33732922) Homepage

    Get it on a shirt, on Digg, and in sigs everywhere!

  • 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:No hardware? (Score:5, Informative)

      by Mathinker (909784) * on Wednesday September 29, 2010 @08:18AM (#33732988) Journal

      Intel's statement had to do with the security of the use case of HDCP: digital video encrypted with HDCP being transported over HDMI cables. In other words, the hardware Intel claims is required, is specialized hardware which interfaces with HDMI ports. This software implementation is not interesting for cracking encrypted video if it cannot communicate with the Blu-Ray or other media player in question in a way which tricks the media player into thinking that the computer running the software is a certified display device.

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

        by norpy (1277318) on Wednesday September 29, 2010 @08:34AM (#33733092)
        Errrrr the point of this software is to perform the handshake which authenticates it as a legitimate source or sink device. The master key also allows you to simply generate a NEW device key if the one you are using happens to get blacklisted by a firmware update.

        The reason this is useful is not for bluray, it is for first-run broadcast content.
        • by Kjella (173770)

          Yes, but I doubt most equipment will let you do HDCP handshake over anything but the HDMI(/DVI) port, so you still need to hook up the HDMI-out that you want to decrypt to a HDMI-in port. Can your regular graphisc card be rewritten to use the HDMI out port as an HDMI in port? If not, then the application is limited to the few that have HDMI capture cards. And even then you have to be able to inject the HDMI handshake into the capture card's driver. The easiest would still be to make a HDCP stripper adapter

          • by makomk (752139)

            Yes, but I doubt most equipment will let you do HDCP handshake over anything but the HDMI(/DVI) port, so you still need to hook up the HDMI-out that you want to decrypt to a HDMI-in port.

            The HDCP handshake happens over a low-speed link. If you can capture raw HDMI video at all, in theory it's not that much more work to add HDCP support on top of it.

          • by MoonBuggy (611105)

            Surely one could use this code to create a dummy display driver that dumps an unencrypted video stream?

            Computer's internal blu-ray drive happily handshakes with the virtual monitor and sends it the stream thanks to the master key, whereas before it would've just thrown an error or given a degraded stream. This stream can then be passed unencrypted through the graphics card, or saved for later viewing. Of course, it seems like a resource intensive method of ripping, and you'd need to re-encode the stream to

        • by DrXym (126579)
          The reason this is useful is not for bluray, it is for first-run broadcast content.

          I expect most modern STBs watermark the content leaving the TV in addition to HDCP protection. Therefore anyone stupid enough to release content they've captured on P2P can probably kiss their service goodbye as well as opening up the possibility of prosecution. Just saying.

          • Capture from multiple sources and check for differences. It should be easy enough to find watermarks and not terribly difficult to edit them out automatically. If there's a unique identifier, it can't be in two sources.

            Besides which, making imperceptible watermarks than can survive arbitrary lossy compression techniques is hard. If a person can't see a certain detail, a good video compression algorithm should throw it out. Just saying.

      • As both cheap graphics cards and motherboards with HDMI outputs are very much mainstream nowadays, I think your use of the word "specialized" is inaccurate here.

        • 'special' in that it RECEIVES hdmi.

          no normal pc does that. reminder: pc's SEND hdmi, not receive it.

          • Hmm, lost me there. Answer me this: What separates a HDCP capable computer without the software player from a HDCP capable computer with the software player? All the same parts, from Blu-Ray player to the graphics to the monitor.

            • by hedwards (940851)
              I don't fully understand it, but the point of HDCP is for the signal to not be unencrypted at any point in the journey from the disc to the viewer. That is except for the last hop from the video card to the monitor, and only if the monitor knows the secret password to identify itself as secure.

              What this would theoretically do would be allow for a software program to essentially remove that requirement and decrypt it on its way from the drive to the monitor. If I understand correctly, you'd still need t
              • This was addressed earlier in another post. You get the GPU-monitor and probably optical drive-motherboard (or GPU, if it's "direct" lane)handshakes made, there's (basically) no need for extra hardware, you just need the processing power to get the content decrypted.

                We have seen plenty of specific HDCP breaks that can decrypt a limited set of movies; this is the general break, which does not care much about the HW and firmware (optical drive) details.

                • We have seen plenty of specific HDCP breaks that can decrypt a limited set of movies; this is the general break, which does not care much about the HW and firmware (optical drive) details.

                  Still people who don't understand what HDCP does. It has nothing, nothing whatsoever to do with movies. It encrypts whatever your graphics card displays, and decrypts it on the monitor. If Windows bluescreens then the blue screen will dutifully be encrypted between your PC and the monitor.

                  • Indeed. Even at the "free" price point, nobody seems to want information... unless it has boobies.

    • That statement seemed pretty silly given that most applications will be to transcode the encrypted stream into something more portable, and transcoding doesn't have to be in real time.

      • by Thanshin (1188877)

        Exactly my thought. I suppose he's talking about estimations on building a dedicated hardware HDCP decrypter.

    • by Xest (935314)

      Yep, but I think this much was obvious anyway.

      Apparently Intel's content protection department aren't aware of what the rest of the company does- produces processing equipment precisely so stuff like this can be done with ease.

  • Great stuff! Shows Intel's representative's earlier comments about software implementation not being feasible quite wrong.

    • by imbaczek (690596)
      76fps on a 2.5GHz Core2 isn't impressive TBH, and they say decryption is 7x slower (which means ~15fps). Optimizations will help, but until they figure out how to make it at least 60fps, it's really not feasible.
      • Core 2 Duo P9600 has 2 cores; we have moved much past that stage with six core CPUs and advancements in CPU architecture after C2D, and like mentioned, the code presented is pretty much an early alpha.

      • Re:Congrats! (Score:5, Interesting)

        by Bert64 (520050) <bert@slashdoMENC ... com minus author> 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.

        • by Joce640k (829181)

          Nothing to stop you dumping the encrypted data somewhere and decrypting it later.

          You've got a disk which can store decompressed 1080p in real time? Please let us in on the secret...!

          • Re: (Score:3, Insightful)

            by cynyr (703126)

            a raid 5.1 of 10k rpm sas drives say, 12 spindles, should be enough. maybe 4 500GB SSDs would be as well.

            So no i don't have A disk that can do it, but you can do it with a few disks.

          • Re: (Score:3, Insightful)

            by Just Some Guy (3352)

            You've got a disk which can store decompressed 1080p in real time?You've got a disk which can store decompressed 1080p in real time?

            It's my understanding that many new-fangled media devices have "pause" buttons that would enable you to break the task into manageable chunks.

      • Re: (Score:2, Informative)

        by norpy (1277318)
        Not quite.

        They said decryption of 1080p is 7x slower than 640x480, not that decryption is slower than encryption. This makes sense as 1080p is approximately 7x more pixels than 640x480!
      • by Eivind Eklund (5161) on Wednesday September 29, 2010 @09:02AM (#33733322) Journal

        Those rates are for a single core. They say that decrypting 1080p is ~7x slower than 640x480, which correspond well to 1080p having 6.75x more pixels.

        However, there's no reason for this to be restricted to run on a single core or a single machine. If somebody were to use this for distributing a real time stream (e.g, a sports broadcast) there's no particular reason to not just have each recipient of the stream do their share of the decryption.

        Running the number, getting 60 frames of 1080p from the Core 2 requires 5.33 cores, which would correspond to three dual-core machines. This means you can't, with today's machines, just share it with your friend if you both have dual core Core2 machines - but with two friends it should work, assuming enough bandwidth available from each of the friends: 3Gbit/s for the full unencrypted stream, plus 1Gbit/s down for the stream to be decrypted, plus 1Gbit/s up for the part of the stream decrypted on that machine.

        You'll also get real time decryption on a single Gulftown [] CPU: E.g, a Core i7-980X runs 3200MHz and has 6 cores.

        • You'll also get real time decryption on a single Gulftown CPU: E.g, a Core i7-980X runs 3200MHz and has 6 cores.

          Is this going to be the next decade's bragging rights? "My Tivolike's capture card continuously draws only 130 Watts whenever something is on! (not counting all the case fans)" "Oh yeah? Well mine only uses 73 Watts!!"

          (Just kidding; I get it that we're talking proof-of-concept.)

      • Re:Congrats! (Score:4, Informative)

        by cbope (130292) on Wednesday September 29, 2010 @09:06AM (#33733372)

        60fps, why? That is 2x real-time, or a bit more than 2x if the source is 24fps. Once they are able to break 30fps decrypting in real-time, this is golden. It's only the first step, but it's an important milestone.

        • by Gates82 (706573)

          Question: 60fps, why?

          Answer: Stereoscopic or 30fps x 2 streams

          So who is hotter? Ali or Ali's Sister?

          • Re: (Score:3, Informative)

            by Malc (1751)

            Blu-ray supports 720p at 59.94 fps. That's a greater amount of data than 1080p at 24 fps. 720p59.94 is also one of the Blu-ray 3D supported resolutions (i.e. doubling the differences with 1080p24 further).

            • Re: (Score:3, Informative)

              by AusIV (950840)

              But ripping discs isn't really the target here. There are already tools available which can rip BluRay discs in software, without having to read a disc and play them over the wire in real time. More practically, this is targeted at streaming video sources such as video from your cable company, or perhaps for ripping from your cable company's DVR. Those streams are seldom (never?) higher than 1080i or 720p at standard frame rates, so 30fps in real time gets the job done.

              I'm not saying 720p at 59.94 is worth

      • by cynyr (703126)

        i get 129fps @640x480 on my AMD Athlon X2 BE-2400+ (2.3ghz 4gb DDR2 dualchan ram) according to the test operation suppled with the program.

        • by cynyr (703126)

          and 17fps @1920x1080 so... as it will scale to 64 cores, it should be doable on an X4, or an i7Q or even a lowend gpu.

    • Where you going to get the data from? Being able to implement an algorithm is a far cry from being able to sense and apply a voltage on an HDMI connector. The current HDMI capture cards do not provide access to the raw data stream.

  • 3...2....1....

  • GPU Implementation (Score:5, Insightful)

    by Alias14 (1657713) on Wednesday September 29, 2010 @08:33AM (#33733082) Homepage
    I guess the next logical step would be a GPU implementation....
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      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-

  • 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.

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

      Don't you mean abandon the old business model? The old business model was that you sell un-DRMed content and make a billion dollars. This was deemed unacceptably profitable.

      Don't think of DRM as clinging to the past. The past already proved that DRM is undesirable from the seller's point of view. The new business model is to tell people, "No you can't do that if you buy this;

  • 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.

    • Re: (Score:3, Informative)

      by dpilot (134227)

      Years back I saw a chip-level presentation on the topic. It wasn't just a matter of decrypting the Blu-ray and reencrypting HDCP. Every content signal that came to a chip I/O was encrypted. The intent was that you wouldn't be able to buy hardware, open it up, hang probes on any chip, and capture "their" content.

      Way more encryption hardware than you've suggested, but it's also specialized encryption/decryption engines, not GP processors.

  • I'm waiting... (Score:3, Insightful)

    by bjwest (14070) on Wednesday September 29, 2010 @12:55PM (#33736182)

    China. Where's my pass-through video card I can put in my MCPC to overlay text and graphics on my TV? I want to feed my TIVO into my MCPC so I can control my own PIP and overlays. I couldn't care less about pirating the stuff myself. If I want a local copy of something, it's already out in the wild - I'll get it that way. I just want to be able to control my media and view what I want how I want.

Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?