Slashdot Mirror
HDCP Encryption/Decryption Code Released
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."
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.
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.
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.
Dilbert RSS feed
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.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
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.
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.
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.
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..
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
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.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
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.
I said no... but I missed and it came out yes.
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.