Transcript
Intel and DCP LLC Confidential Summary of Testing of HDCP Software Implementation Released by Stony Brook University Utilizing the Previously Published HDCP Key Matrix Objective Assess the resources and effort required to crack an HDCP-encrypted 1080p stream using offthe-shelf hardware and any available software from the Internet. Executive Summary 1.
The published key matrix does produce valid Device Keys
2.
The published decryption code works and, in its unoptimized state, can decrypt 1080p at at least 30 frames/second on a high-end personal computer.
3.
A direct attack on an HDCP-encoded stream would still require specialized hardware.
4.
An indirect (eavesdropping) attack on an HDCP-encoded transfer between two legitimate devices is possible with off-the-shelf hardware and some customized software.
Initial Conditions and Assumptions 1.
Use “legitimate” hardware only. There are already known hardware HDCP crackers on the market; if the user is able to purchase hardware that is non-HDCP compliant, then it is a lot easier to use that hardware.
2.
Use any available software.
Hardware Used 1.
Desktop computer a.
Core i7 920 CPU (2.67GHz/4 Cores/8 Logical Processors)
b.
6GB memory
c.
Asus P6T motherboard
d.
Two Velociraptor 10,000 rpm hard disks in RAID-0 configuration (total storage=1.2GB, write speed=181MB/sec). A note on hard drive requirements: A 1080p stream at 30 frames per second and 24 bits of data per pixel results in approximately 178 megabytes per second of data that must be written to disk. By joining two Western Digital Velociraptor drives in RAID-0 configuration, it is possible to achieve 181 MB/sec write performance using 32-bit Windows Vista. It is expected that it would be possible to raise this performance even higher by using a 64-bit operating system and adding a third drive to the RAID-0 configuration.
Intel and DCP LLC Confidential e.
Blackmagic Intensity Pro HDMI capture card
f.
Dual-boot operating systems i.
Windows Vista 32-bit
ii.
Ubuntu Linux Desktop 10.10, 64-bit
2.
Gefen 2:1 HDMI splitter
3.
Beagle I2C Protocol Analyzer
4.
Pioneer BDP9400HD Blu-Ray player
5.
Toshiba 20HLK86 television
Approach Taken The analysis is broken up into two phases. In Phase One, the objective was simply to record the encrypted video stream. In Phase Two, the objective was to do an offline decryption of the encrypted video. If this approach was successful, then both steps likely could be combined into a single process. Phase 1: Capturing the encrypted video stream 1.
2.
The obvious first attack is to directly connect the output of the HDCP source device (in this case, the Pioneer Blu-Ray player) to the desktop computer. a.
However, most personal computers with HDMI support have output capability only.
b.
Thus, an HDMI capture card was added to the computer. For this analysis, a $200 Blackmagic Intensity Pro was used.
c.
By design, the Blackmagic product refuses to perform the HDCP protocol. Connecting the Blu-Ray player to the Blackmagic resulted in a black video screen on the computer.
d.
A brief search on the Internet revealed that all of the legitimate commercial capture cards found do not support the capture of HDCP-encrypted video.
e.
Conclusion: Capture of HDCP-encrypted video with off-the-shelf hardware is not practical. Even if the details of the protocol are known, there is no simple SW only method to get access to the HDCP messages since they are not parsed off of the HDMI cable and passed up to the stack.
The next step was to capture the video via an indirect approach.
-2-
Intel and DCP LLC Confidential
3.
a.
The output of the Pioneer Blu-Ray player was connected to a Gefen 2:1 HDMI splitter. One of the outputs of the splitter was connected to the Blackmagic capture card. The other output was connected to the Toshiba television. The HDMI control lines of the connection going to the Toshiba were routed through the I2C protocol analyzer, which was connected to a monitoring computer.
b.
Hitting "play" on the Blu-Ray player confirmed that the video was playing correctly on the TV. That the Blackmagic card was capturing random encrypted video, which was displayed as "snow" on the computer.
c.
The Blu-Ray player was stopped and restarted with the I2C protocol analyzer configured to capture any HDMI control line traffic. Using this technique, the KSV values for the Pioneer (Aksv) and Toshiba (Bksv) were observed and recorded. The An, REPEATER, R0', R1, and R2 values were also recorded.
d.
Using the previously published master key matrix, in conjunction with a simple Python script, the secret key values for the Pioneer and Toshiba (Akeys and Bkeys) was able to be computed.
e.
A second simple Python script was written to compute the shared secret value Km using the observed Aksv and Bksv values from step 2(c) and the derived Akeys and Bkeys values from step 2(d).
f.
The Stony Brook C code was then modified to compute the R0', R1, and R2 values using the computed Km value from step 2(e) and the observed REPEATER and An values from step 2(c).
g.
The computed R0, R1, and R2 values matched the R0, R1, and R2 values observed in step 2(c) using the protocol analyzer.
h.
The values matched, indicating that we had successfully eavesdropped on the HDCP setup conversation between the Blu-Ray player and the television.
i.
Because we had been present from the beginning and had recorded everything, we would now be able to decrypt the video packets in lock-step with the source.
Capture of the video stream a.
After performing steps 2(a-i), the unencrypted video was playing on the television and it was possible to capture several seconds of encrypted data using the Blackmagic. This encrypted video showed up as random noise on the PC.
b.
The Blu-Ray player was outputting YUV420 encoded video as requested by the television. YUV420 defines 16 bits of video data per pixel. The HDMI spec provides three 8-bit data channels. The HDMI spec specifies that the YUV data must be zero-padded as necessary up to 24 bits, which are then transferred on the TMDS lines of the HDMI cable.
-3-
Intel and DCP LLC Confidential c.
Prior to encryption, the video player zero-pads the YUV data to 24 bits, which is then encrypted, resulting in 24 bits of encrypted data. The legitimate Toshiba sink then decrypts the encrypted data, strips the zero padding, and produces 16 bits of YUV420 for display.
d.
The Blackmagic Intensity Pro capture card is only capable of capturing 16 bit of video data in YUV420 format.
e.
At the time of the experiment, it was erroneously believed that all 24 bits of encrypted data needed to be captured in order to decrypt the data.
f.
If a 24 bit capture card is required, Blackmagic makes a DeckLink HD Extreme 3D card capable of capturing 24 bits per pixel at a cost of $995.
g.
At this point, the analysis was stopped. However, in a post-experiment analysis, it was determined that the 16-bit capture card should be sufficient. Because HDCP uses a stream cipher, the bytes that are not captured can be ignored.
h.
We are confident that it is possible to eavesdrop on an encrypted communication between two legitimate HDCP devices, record the encrypted video stream, and then decrypt it using information publicly available on the Internet.
Phase 2: Decrypting the video stream 1.
Although we did not attempt to decrypt an encrypted video stream, we determined the feasibility of decryption assuming that we had a complete stream with enough encrypted data to reconstruct the original video.
2.
Because we were able to successfully produce R0, R1, and R2 in step 2(g), we are reasonably confident that the decryption code published by Stony Brook works.
3.
We compiled the unmodified Stony Brook code on 64-bit Ubuntu Linux 10.10 Desktop Edition.
4.
Running the included sample test, we were able to decrypt 640x480 at 277 frames per second.
5.
1080p requires ((1920+56)*1080)/((640+56)*480) = 6.4 times more data than 640x480.
6.
Thus, out of the box, the Stony Brook code is capable of decrypting at least 43 (== 277/6.4) frames per second of 1080p encrypted video.
7.
Because the code is unoptimized, we are confident that this performance can be improved. However, because the current performance is in excess of 30 frames per second necessary for 1080p decryption today, we did not undertake any further optimization. Strictly speaking, real-time decryption is not necessary since the encrypted video can be captured in real-time and then the decryption can be done at any rate.
-4-
Intel and DCP LLC Confidential 8.
We then obtained the source code for mplayer, an open-source video player.
9.
We were able to play back the captured encrypted video stream from step (3). The video was black for several seconds, then a green screen appeared (AVMUTE) during the HDCP exchange, and finally the encrypted snow appeared after that. This confirms that the capture was operating correctly.
10.
We were able to locate the point in the mplayer code where the video is displayed. We verified that we had access to the full data buffer containing the video data.
11.
We ascertained we could pass this data buffer to the Stony Brook code in order to decrypt it, and then either write the decrypted data to disk or return to the normal mplayer code to display it. ###
-5-
