HDCP Encryption/Decryption Code Released 225
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."
Re:No hardware? (Score:5, Informative)
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)
The reason this is useful is not for bluray, it is for first-run broadcast content.
Re:No hardware? (Score:4, Informative)
But the sink keys they used could be banned, no? Having the master key means you can't ban them, because you can generate any possible key.
Re:Congrats! (Score:2, Informative)
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!
Transforming the numbers (Re:Congrats!) (Score:4, Informative)
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 [wikipedia.org] CPU: E.g, a Core i7-980X runs 3200MHz and has 6 cores.
Re:Congrats! (Score:4, Informative)
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.
Re:No hardware? (Score:4, Informative)
In theory they could be banned, but in practice, due to sloppy distribution of keys, they can't ban them without breaking too many innocent devices, so they haven't.
Re:No hardware? (Score:2, Informative)
who says the output of your card is HDCP encrypted?
HDMI != HDCP
Re:What would be the issues with a hardware versio (Score:5, Informative)
There are already bootleg hardware HDCP strippers on the market. It used to be possible to shut down these devices by revoking their keys, but that's now gone out the window with the master-key leak. Expect the next generation of devices to let you upload new keys to them, or maybe generate new keys themselves.
Software decryption is kinda interesting but you're right, hardware is where it's at.
Re:No hardware? (Score:4, Informative)
even in theory they couldn't be banned because they have the master key - meaning they can create any and all keys on the fly and at will - the only way to "ban" them would be to not use HDCP and use something else..
Re:No hardware? (Score:3, Informative)
Has no-one here ever used a SOFTWARE renderer in their games? Software on a general CPU is atrocious at accomplishing a task optimally. Hell, it sucked years before graphics required an extra card in your machine and it sucks even more now - how many "GHz" do you think your CPU would have to run at in order to match the performance of an average GPU by using software rendering? Probably a lot more than double what the best computer processor runs at now, or we'd be throwing GPU's away and buying quad-core's instead. Software implementations on a generic processor can't even come close to competing with a hardware device designed to do just that one task. Especially not on something that uses the x86 instruction set (go look at the speed of ARM chips compared to their heat / power / price).
Software implementations are basically emulations - take MAME or other emulators for example - you are software implementing a device that probably originally run at a handful of MHz and now requires a GHz PC to keep up with it, even if you remove quite a lot of the unnecessary interface logic. Now this is an entirely encryption affair here but even back in the days of VIA EPIA boards, VIA's on-chip encrypt/decrypt logic could outperform even the best Intel CPU.
It's a software implementation. Expect it to suck until it's optimised, and even then expect it to be way behind what a £10 FGPA could be programmed to do with the same base code.
Re:Congrats! (Score:3, Informative)
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:No hardware? (Score:4, Informative)
This.
Simple bit operations are vastly faster when implemented in silicon.
Think of it. A simple "&" is 8 logic gates in silicon. In CPU it's a fetch value into register, reroute ALU to the bit-and operation, route source to source registers, target to target registers, select word sizes, perform the operation, fill the flag register in...
Or take something else. Reverse order of bits in a word. First is last, last is first. A very common operation, and if I recall correctly, essential in FFT.
How many CPU cycles would that be...?
Now in silicon, it takes 0 transistors. You just connect first input pin directly to last output pin, second to second-to-last and so on - "twist the ribbon 180 degrees". Zero cycles, zero transistors, speed - as long as the impulse takes to traverse a featureless path in silicon between the steps before and after this one.
Re:Congrats! (Score:3, Informative)
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 worthless, but 30fps would support the majority of use cases.
Re:No hardware? (Score:1, Informative)
There are DVDI-I and DVI-D. The former has analog AND digital, the latter digital only. Either can transmit HDCP encrypted video over the digital channel, and as you state, HDCP cannot be applied to the analog video in DVI-I.
There is no analog only DVI. After all, it is the DIGITAL Video Interface.
Re:DRM is so costly, it should be forbidden. (Score:3, Informative)
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.
Re:No hardware? (Score:4, Informative)
Again, the point being that specialized, dedicated circuits can far outperform software on a predetermined algorithm. HDCP is a subset of the AES cypher, and is pretty heavy on the CPU. I've implemented AES on nVidia's CUDA and it would be difficult to get better then 50MB/sec. A 1080p30 stream should use a little less than 60 MB/sec - so it's going to be work, but considering HDCP is less complicated, it should be doable.
Re:No hardware? (Score:4, Informative)
HDMI port != HDMI cable. The active hardware has to output audio and be HDCP 1.1 compliant to be HDMI. An HDMI-DVI adapter is not active hardware, but a cable (or dongle; but as far as the tech goes they are the same anyway) so is not subject to the same standards. However, I am fairly certain that such adapters cannot be HDMI certified, therefore cannot display the HDMI logo (but can be labelled as HDMI, since saying that it converts DVI->HDMI or vice versa is not false advertising).
Now I think about it, I don't know if HDMI outputs are required to have audio, but certainly all inputs are required to accept at least stereo LPCM (which is why HDMI equipped monitors have audio-outs), so I may have got a little muddled up there.