Implementation of MITM Attack on HDCP-Secured Links

Today, I gave a talk on an implementation of a man in the middle (MITM) attack on HDCP-secured video links. Here is a full copy of the slides that I presented (with explanatory diagrams), as well as the text-only of the paper which accompanies the slides, below.

Also, please note that the hardware disclosed in this talk is now available for purchase from the good folks at Adafruit. You can find more technical documentation about the NeTV at the wiki, and you can discuss at the forum.


A man-in-the-middle attack on HDCP-secured video links is demonstrated. The attack is implemented on an embedded Linux platform, with the help of a Spartan-6 FPGA, and is capable of operating real-time on HD video links. It utilizes the HDCP master key to derive the corresponding private keys of the video source and sink through observation and computation upon the exchanged public keys. The man-in-the-middle then genlocks its raster and cipher state to the incoming video stream, enabling it to do pixel by pixel swapping of encrypted data. Since the link does no CRC or hash verification of the data, one is able to forge video using this method.

Significantly, the attack enables forging of video data without decrypting original video data, so executing the attack does not constitute copyright circumvention. Therefore, this novel and commercially useful application of the HDCP master key impairs equating, in a legal sense, the master key with circumvention. Finally, the embodiment of the exploit is entirely open-source, including the hardware and the Verilog implementation of the FPGA.


In September 2010, the HDCP master key was circulated via Pastebin. Speculation ensued around the application of the master key to create HDCP strippers, which would enable the circumvention of certain copyright control mechanisms put in place around video links. Unfortunately, this is a legally risky application, for a number of reasons, including potential conflicts with DMCA legislation that criminalizes the circumvention of copyright control mechanisms.

This talk discloses a new use for the HDCP master key that side-steps some of the potential legal issues. This hack never decrypts video; without decryption, there is no circumvention, and as a result the DMCA cannot apply to this hack. Significantly, by demonstrating a bona-fide commercially significant purpose for the HDCP master key that does not circumvent an access control measure, this hack impairs the equating of trafficking or possession of the HDCP master key to circumvention and/or circumvention-related crimes.

The main purpose of this hack is to enable the overlay of video content onto an HDCP encrypted stream. The simple fact that a trivial video overlay becomes an interesting topic is illustrative of the distortion of traditional rights and freedoms brought about by the DMCA. While the creation of derivative works of video through dynamic compositing and overlay (such as picture in picture) seems intuitively legal and natural in a pre-HDCP world, the introduction of HDCP made it difficult to build such in-line equipment. The putative purpose role of HDCP in the digital video ecosystem is to patch the plaintext-hole in the transmission of otherwise encrypted video from shiny disks (DVDs, BDs) to the glass (LCD, CRT). Since the implementation of video overlay would typically require manipulation of plaintext by intermediate processing elements, or at least the buffering of a plaintext frame where it can be vulnerable to readout, the creation of such devices has generally been very difficult to get past the body that controls the granting of HDCP keys, for fear that they can be hacked and/or repurposed to build an HDCP stripper. Also, while a manufacturer could implement such a feature without the controlling body’s blessing, they would have to live in constant fear that their device keys would be revoked.

While the applications of video overlay are numerous, the basic scenario is that while you may be enjoying content X, you would also like to be aware of content Y. To combine the two together would require a video overlay mechanism. Since video overlay mechanisms are effectively banned by the HDCP controlling organization, consumers are slaves to the video producers and distribution networks, because consumers have not been empowered to remix video at the consumption point.

The specific implementation of this hack enables the overlay of a WebKit browser over any video feed; a concrete example of the capability enabled by this technology is the overlay of twitter feeds as “news crawlers” across a TV program, so that one may watch community commentary in real-time on the same screen. While some TV programs have attempted to incorporate twitter feeds into the show, the incorporation has always been on the source side, and as such users are unable to pick their hashtags. Now, with this hack, the same broadcast program (say, a political debate) can have a very different viewing experience based on which hashtag is keyed into the viewer’s twitter crawler.


A Spartan-6 FPGA was used to implement a TMDS-compatible source and sink. TMDS is the signaling standard used by HDMI and DVI. The basic pipeline within the FPGA deserializes incoming video and reserializes it to the output. In this trivial mode, it is simply a signal amplifier for the video.

In order to enable the overlay of a WebKit browser, an 800 MHz ARM-based Linux computer is connected to the FPGA. The Linux computer is based upon the PXA168 by Marvell, and it features 128 MB of DDR2 and a microSD card for firmware. The distribution is based upon Angstrom and it is built using OpenEmbedded with the help of buildbot. The entire build system for the Linux computer is available through a public EC2 cloud image that anyone can copy and rent from Amazon.

From the Linux computer’s standpoint, the FPGA emulates a parallel RGB LCD, and thus from the programming standpoint looks simply like a framebuffer at /dev/fb0. There is also a device management interface revealed through I2C that is managed using the standard Linux I2C driver. The I2C management interface handles routine status requests, such as reading the video timing and PLL state, and also handles reading out sections of snooping buffers, the significance of which will be discussed later. The FPGA also has a chroma-key feature where a magic color (240,0,240) is remapped to “transparent”.

The FPGA itself is bootstrapped through a programming interface where the device’s compiled bitstream is sent to the FPGA by writing to /dev/fpga. There are also IOCTLs available on /dev/fpga that enable other meta-level functions such as resetting the FPGA or querying its configuration state.

In addition to passing through the TMDS signal, the FPGA also has the ability to listen to *and* manipulate the DDC. The DDC is an I2C link found on HDMI cables that enables the reporting of monitor capability records (EDIDs) and also is the medium upon which the key exchange happens. Therefore, being able to listen to this passively is of great importance to the hack. The FPGA implements a “shadow-RAM” which records all reads and writes to specific addresses that fall within the expected address ranges for EDID and HDCP transactions.

The FPGA also implements a “squash-RAM” which is used to override bits on the I2C bus. Since I2C is an open collector standard, overriding a 1 to a 0 is trivial; but, overriding a 0 to a 1 requires an active pull-up. The hardware implements a beefy FET on the DDC to enable overriding 0’s to 1’s. The DDC implementation uses a highly oversampled I2C state machine. I2C itself only runs at 100 kHz, but the state machine implementation runs at 26 MHz. This allows the state machine to determine the next state of the I2C bus and decide to override or allow the transaction on-the-fly. The “squash-RAM” feature is used to override the EDID negotiation such that the video source is only informed of modes that the FPGA implementation can handle. For example, this implementation cannot handle 3D TV resolutions, so the reporting of such capabilities from the TV is squashed before it can get to the video source. This causes the source to automatically limit its content to be within the hardware capabilities of the FPGA, and to be within the resolutions that are supported by the WebKit UI.

The key exchange on HDCP consists of three pieces of data being passed back and forth: the source public key (Aksv), the sink public key (Bksv), and a piece of shared state (An). The order in which these are written is well-defined. The completion of the transfer of the final byte of Aksv serves as a trigger to initialize the cipher states of the source and the sink. During this time period, each device computes the dot-product of the other device’s KSV with their internal private key (which is a table of forty 56-bit numbers) and derives a shared secret, known as Km. This is basically an implementation of Blom’s Scheme.

In order to implement the man-in-the-middle attack, the three pieces of data are recorded, and the authentication trigger is passed from the FPGA to the Linux computer through an udev event. udev triggers a program that reads the KSVs from the snoop memory, and performs a computation upon the HDCP master key and the KSVs to derive the private keys that mirrors those found in each of the source and sink devices. In a nutshell, the computation loops through the 40×40 matrix of the HDCP master key, and based upon the KSV having a 1 at a particular bit position it sums in the corresponding 40-entry row or column of the master key to the 40-entry private key vector. The use of a row or columns depends upon if the KSV belongs to a source or a sink.

Once the private keys vectors have been derived, they can be multiplied in exactly the same fashion as would be found in the source or sink to derive the shared secret, Km.

This shared secret, Km, is then written into the FPGA’s HDCP engine, and the cipher state is ready to go. In practice, the entire computation can happen in real-time, but some devices go faster or slower than others, so it is hard to guarantee it always completes in time, particularly with the variable interrupt latency of the udev handler. As a result, the actual link negotiation caches the value of Km from previous authentications, and the udev event primarily verifies that Km hasn’t changed (note that for each given source and sink pair, Km is static and never changes, so unless users are pulling cables out and swapping them between devices, Km is essentially static). If the Km has changed, it updates the Km in the FPGA and forces a 150ms hot plug event, which re-initiates the authentication, thereby making the transaction fairly reliable yet effectively real-time.

Significantly, this system as implemented is incapable of operating without having the public keys provided by both the source and the sink. This means that it cannot “create” an HDCP link: this implementation is not an operational HDCP engine on its own. Rather, it requires the user of this overlay hack to “prove” it has previously purchased a full HDCP link through evidence of valid public keys.

Once the FPGA’s HDCP cipher state is matched to the video source’s cipher state, one can now selectively encrypt different pixels to replace original pixels, and the receiver will decrypt all without any error condition. This is because encryption is done on a pixel by pixel basis and the receiver does little in the way of verification. The lack of link verification is in fact quite intentional and necessary. The natural bit error rate of HD video links is atrocious; but this is acceptable, because the human eye probably won’t detect bit errors even on the level of 1 in every 10,000 bits (at high error rates, users see a “sparkle” or “snow” on the screen, but largely the image is intact). Therefore, this latitude in allowing pixel-level corruption is necessary to keep consumer costs low; otherwise, much higher quality cables would be required along with FEC techniques to achieve a bit error rate that is compatible with strict cryptographic verification techniques such as full-frame hashing.

The selection of which pixel to swap is done by observing the color of the overlay’s video. The overlay video is not encrypted and is generated by the user, so there is no legal violation to look at the color of the overlay video. Note that other pixel-combining methods, such as alpha blending, would necessitate the decryption of video. If the overlay video matches a certain chroma key color, the incoming video is selected; otherwise, the overlay video is selected. This allows for the creation of transparent “holes” in the UI. Since the UI is rendered by a WebKit browser, chroma-key is implemented by simply setting the background color in the CSS of the UI pages to magic-pink. This makes the default state of a web page transparent, with all items rendered on top of it opaque.

Note that pixel-by-pixel manipulation of the incoming video feed is done without any real buffering of the video. A TMDS pixel “lives” inside the FPGA for less than a couple dozen clock cycles: the lifetime of a pixel is simply the latency of the pipelines and the elastic buffers required to deskew wire length differences between differential pairs. This means that the overlay video from the Linux computer must be strictly available at exactly the right time, or else the user will see the overlay jitter and shake. In order to avoid such artifacts, the time resolution requirement of the pixel synchronization is stricter than the width of a pixclock period, which can be as short as dozen nanoseconds.

In order to accomplish this fine-grain synchronization, a genlock mechanism was implemented where vertical retrace signals (which are unencrypted) trigger an interrupt that initiates the readout of /dev/fb0 to the FPGA. However, the interrupt jitter of a non-realtime Linux is much larger than a single pixel time, so in order to absorb this uncertainty, a dynamic genlock engine was implemented in the FPGA. An 8-line overlay video FIFO is used to provide the timing elasticity between the Linux computer and the primary video feed; and the vertical sync interrupt-to-pixel-out latency of the Linux computer is dynamically measured by the FPGA and pre-compensated. In effect, the FPGA measures how slow the Linux box’s reflexes are, and requests for the frame to start coming in advance of when the data is needed. These measures, along with a few lines of FIFO, ensure pixel availability at the precise time when the pixel is needed.


A system has been described that enables a man-in-the-middle attack upon HDCP secured links. The attack enables the overlay of video upon existing streams; an example of an application of the attack is the overlay of a personalized twitter feed over video programs. The attack relies upon the HDCP master key and a snooping mechanism implemented using an FPGA. The implementation of the attack never decrypts previously encrypted video, and it is incapable of operating without an existing, valid HDCP link. It is thus an embodiment of a bona-fide, non-infringing and commercially useful application of the HDCP master key. This embodiment impairs the equating of the HDCP master key with copyright circumvention purposes.

17 Responses to “Implementation of MITM Attack on HDCP-Secured Links”

  1. Alex says:

    So if I understand correctly, this is basically a “na na na na I’m not breaking any rules you can touch me!” hack against HDCP that complies with the DMCA, and anyone who’s smart enough to set it up is smart enough to just dump the raw unencrypted video stream to external storage.

    Pretty neat all things considered.

    • Christian Vogel says:

      No, as I understand it it’s a hack to superimpose pixels onto a HDCP encrypted video stream without ever modifying the encrypted and copyrighted pixels…

      Someone who knows enough about FPGAs and coding VHDL (I don’t like the term “smart enough”) has been able to use the leaked keys to build a HDCP stripper in the past (I remember that there has been at least one research project on a university). For this clientèle of course the NeTV could provide for a affordable FPGA board with the relevant connectors already in place :-).

      And actually, even before that was the case, people had used commercially available HDCP decryption chips (which are legitimately used in TVs or LCD monitors) to build devices that remove the encryption from your blueray player’s output. (and bunnie mentioned that in the talk).

      But assuming that you wanted to actually use the board to dump “unencrypted video stream to external storage”:

      HDTV = 1920 x 1080 = 2,073,600 pixel * 3 byte/pixel * 60 Hz = 380 Mbyte/second. Need I say more?

      • dennis says:

        More likely someone would just feed that uncompressed stream into an h.264 encoder and bring it down to a much more manageable size.

        Also, depending on the mode of the connection, you may be getting YUV 420 out, which halves the storage requirement as well.

  2. Aris says:

    Perhaps the ambiguity in the DMCA law explains Sutajio Ko-Usagi’s Singapore domicile. If the product were under the ‘Chumby’ umbrella, the product could well be sanctioned under US law.

    I’m guessing Bunnie has left Chumby, but Sutajio Ko-Usagi is just the asian arm of the company :-)

  3. Mihai Todor says:

    Nice job, Bunnie! :)

    Out of curiosity, you mentioned that HD video links have a very high error rate and, in order to bring it down, “much higher quality cables would be required” along with some other stuff. Does this mean that such a cable, which costs around 1000$, would be a justified investment? Personally, I consider it a ripoff, but I’d like to hear your opinion.

    • bunnie says:

      No, it doesn’t justify the cost of an expensive cable. When I say a “very high error rate” I mean in comparison to cabled technologies intended for data transfer (such as ethernet, SATA or PCI-X), where a single bit-error in an executable stored on a hard drive can be disastrous. On the other hand, a single bit-error in a field of a movie is totally undetectable by the human eye. You probably have dead pixels and color offset issues on your monitor that are by far perceptually worse than a single transient bit error in a video frame, yet you don’t notice them.

      So, the HDMI standard was designed explicitly to accommodate cheap twisted-pair technology, and the picture quality is fine as long as the cable is made to spec. You have a waaaay better cost to benefit ratio spending $1k on a better TV screen (better contrast ratio, brighter backlight, bigger diagonal) than on cables. With cable technology, you are really chasing diminishing returns. The key is to just get a cable that is properly made, and there are lots of them out there for a really reasonable price.

      If you’re trying to do something like go over a long distance (greater than a couple of meters) then certain cabling technologies might help, but the $1,000 cables you buy in the store don’t have that technology. The purity of copper or the gold plating doesn’t make a darn bit of difference for digital signals. What you’re looking to do is to keep the “eye” wide and open at the end of the run, and the major factors that will hurt you are dielectric loss tangent and intra/inter pair skew. There are technologies that can help combat that, but I have yet to see a “premium” cable manufacture speak to these important parameters. It’s not a premium cable unless they include hand-measured S-parameters, TDR and TOF for the cable to demonstrate their superior construction. And at $1k, I’d expect nothing less than that!

      fwiw, I’ve found inexpensive, conventional twisted-pair construction cables go through runs of 5+ meters, and I’ve also found 1 meter “premium” cables that can’t hold a candle to the performance of their cheaper conventional counterparts.

      • Mihai Todor says:

        Thank you very much for the detailed explanation. Now I understand clearly why everybody is yelling at cable manufacturers to stop selling “premium cables” at absurd prices.

  4. Mike says:

    Excellent technical work and fabulous writeup. Thanks so much for sharing!

  5. chexum says:


    Although I am a big fan of yours, I’ve never felt moved to write to you before. This hack exhibits all the technical wizardry I’ve come to expect from you, but in a world where content protection legislation seems to have gone mad I feel the most important achievement is this one:

    “Therefore, this novel and commercially useful application of the HDCP master key impairs equating, in a legal sense, the master key with circumvention.”

    This is hacking of a very different kind, and I for one am very grateful for it. Keep it up.

  6. […] is up to his old tricks again. He successfully implemented a man-in-the-middle attack on HDCP-secured connections to overlay video in any HDMI video stream. There’s a bonus, too: his hack […]

  7. […] is up to his old tricks again. He successfully implemented a man-in-the-middle attack on HDCP-secured connections to overlay video in any HDMI video stream. There’s a bonus, too: his hack doesn’t […]

  8. […] is up to his old tricks again. He successfully implemented a man-in-the-middle attack on HDCP-secured connections to overlay video in any HDMI video stream. There’s a bonus, too: his hack […]

  9. […] about? Already on the docket is his latest fight surrounding his new neTV device and doing so without violating the DMCA. We also want his perspective about working directly with suppliers in Singapore (his hometown) and […]

  10. […] He also recently released the NeTV, which was met with some DMCA resistance due to the method in which he injects pixels. […]

  11. “Read my lips… No new WINDOWS!”

  12. Bryan says:

    Can this be used to block undesired content, e.g. censoring nudity and bleeping out profanity, without violating the legal precedences used to shut down CleanFilms and CleanFlicks?