Understanding HDCP

Inside HDCP
The method a particular system uses to communicate is referred to as a protocol. HDCP has its own internal protocol to follow. To understand it, we need to have a clear view of the objects in the HDCP environment. In Figure 1.0, we see three basic components: the upstream control function, the HDCP transmitter and the HDCP Receiver. These simple components make up the HDCP-aware environment.

Within this environment, between the transmitter and HDCP receiver, authentication needs to take place before the devices recognize each other as acceptable hosts. This authentication occurs when the transmitter sends commands to the receiver. At this point, if the display device is compliant, it will send back commands using a set of device keys. These device keys come from Digital Content Protection LLC.

Following this, should the transmitter get back an appropriate set of device keys, it will display its own set of keys to the receiver. Once both sides have displayed to each other their key-set, a checksum for these two specific devices is created in volatile memory, and authentication is completed. The next time a new device or display combination is connected by the user, the same process will take place all over again, and a new checksum will be generated.

It sounds all nice and simple, but how does it all click together?

Fig. 2: Key authentication handshaking for HDCP devices. If R0 is not equal to R0', then it's no dice.

Talk to me baby
Any HDCP compliant device should contain forty 56-bit confidential device keys. These are known as Device Private Keys. The easiest way to visualize keys is as a set of unique fingerprints. No other device has the same keyset, at least in theory. Digital Content Protection also provides a header to these keys, known as a KSV (Key Selection Vector). This is a 40-bit binary value. The process of communication between devices with these key interactions is displayed in Figure 2.0.

Initiation of communication between devices starts with the HDCP transmitter sending a 'hello' message, containing the KSV for the device (Aksv). A value is calculated from the first point of contact, here, named 'An'. The function that controls this calculation is known as 'hdcpBlkCipher'. Once this process has taken place, the HDCP receiver sends back its KSV (Bksv). After this, at some point, if the authentication integrity is in doubt, the transmitter checks (potentially phones home) to make sure the HDCP receivers keys have not been revoked (or, if in the instance they are somehow fake, sends back information saying so, shutting down the device key). So now that the two devices have communicated correctly, can we start sending content? Not quite. First, we need to generate the checksum mentioned earlier. According to the specification, this is a 56-bit binary addition based on the two KSV's 'An' values. If R0 is equal to R0', then content will begin to stream between transmitter and receiver. If for some reason R0 is not equal to R0', the authentication process is reattempted.

This is complicated further if the HDCP transmitter and receiver detect a repeater scenario, where there may be more than one device on a DVI/HDMI link chain. An additional third layer of authentication exists on a per-frame basis. The very frames of data sent through the DVI/HDMI cable are authenticated and verified every two seconds. You know, just to be sure.

Ultimately, it ensures content can be protected if not at the media level, then at the display level. And it's a lot harder to circumvent when it's built into the hardware.

Table 1: HDCP 'compliant' monitors as of the 10th of May, 2006.

So what about me?
Despite marketing hype, and eager companies wanting to ride the buzz bandwagon by adding HDCP early on, the fact remains that today’s 'HDCP capable' components actually aren't. You might be wondering how the vendors claimed that it was to begin with. Originally, ATI and NVIDIA claimed their hardware was HDCP compliant, announcing that it would work with next generation HD content. This was fine, given the GPU was capable of outputting 1080i/p rated resolutions, but as we have discussed, there is more to HDCP than extreme output resolution! The missing piece of the equation comes in the form of HDCP keys from the central authority that cannot be retrofitted onto these graphics cards. It is impossible to flash keys onto the BIOS of the video card, because the addressable space within the PROM is finite and only has enough space for instructions originally coded for it. It needs a dedicated chip designed for this purpose that's simply not present on current generation cards.

So that stunning nVidia 7900GTX system and, chances are, the swanky new LCD monitor too won't be able to display HDCP content, even if the marketing hype has said otherwise. Truly HDCP capable monitors are only now starting to appear on the market. Some relevant reading for the video-card non-compliance issue can be found over at Firingsquad. A list of current model flat panel monitors supporting HDCP are summarized in table 1.0.

All current devices without HDCP compliance are to be dealt with in the following way. If in the instance the output device and video hardware cannot support HDCP authentication and the media/content provider has elected to use the protection bit in HD-DVD/BD-ROM lead in (physical media), the movie/game/content will not be displayed in full, high definition 1080i/p. Instead you will either get:

* A blank screen, telling you that your display device(s) are unsupported or
* A down sampled version of the content, running at 480i/p

Some companies, such as Sony, have back-flipped on the decision to implement this Image Constraint Token (ICT) in their video releases, due to growing pressure from the consumer market and a need to encourage uptake of Blue-Ray players in the home.