HDCP and EDID demystified, part one
In a recent survey conducted by Luxi Electronics, it was revealed that one in seven installed digital systems fail in the field initially.
What’s puzzling is that often, when an installer returns the failed product to the manufacturer, they are told that nothing is wrong with it. And what’s even more puzzling is that while installers can sometimes rectify a problem by replacing the product from Brand A with one from Brand B, in a different system the problem is fixed by replacing the product from Brand B with one from Brand A.
It defies logic.
A TECHNOLOGICAL EXPLANATION
High-Bandwidth Digital Content Protection (HDCP), Extended Display Identifi cation Data (EDID), Display Data Channel (DDC) and Inter Integrated Circuits (I2C) are all important factors in making a system work, yet can all cause signifi cant problems if they fail.
So, what do they do?
Inside the multi-pins of the DVI or HDMI interface there’s a pair of wires called the DDC. The DDC carries two kinds of data: HDCP and EDID.
EDID is the data that a display device sends to a source device about its resolution, refresh rate, colour space, audio format and so on, so that the source device can generate the required signal to match.
HDCP is the copyright data. First, the source device requests the key from the display device and validates it. Then, the source device sends the encrypted AV content over four TMDS pairs and the decryption key over the DDC.
The DDC connects multiple devices on the same pair of wires. The protocol chosen by the DVI and HDMI to manage this multi-device two-way communication is I2C.
Many (if not the majority) of the problems installers experience in the field are caused by the I2C protocol chosen by the DVI and HDMI. It works perfectly for communication between IC chips inside a product, but not so for communication between multiple devices with long cables in between.
As a result, communication collisions among devices often happen. When the EDID is corrupted, a screen will probably display the wrong colour, size, position, or a green or pink screen.
When the HDCP data is corrupted, there is likely to be no picture, a flashing screen or a popping sound. A few manufacturers have released ‘EDID minders’, which record EDIDs from displays, then play them back to source devices. This is not a clean fix and these devices won’t work for HDCP issues.
Another solution is to change the communication timing to avoid collision. This fi xes EDID and HDCP issues.
HIGH-BANDWIDTH DIGITAL CONTENT PROTECTION
HDCP was initially developed by Intel in 1999. Currently available in version 2.0, the protocol is incorporated into AV content on many digital formats, including HDMI, DisplayPort, GVIF, DVI, DLI, UDI, IP, WHDI, TCP/IP and USB.
HDCP classifies all devices as transmitters, receivers or repeaters. An HDCP transmitter is the ‘boss’ because it holds the content. It decides which receivers to send to and how to send the content. The repeater is a middle manager; it reports to the transmitter and manages the receivers.
The HDCP transmitter manages three functions:
1. Authentication: It verifies the receiver’s public key certificate, checks locality (primarily for wireless transmission to make sure the receiver is in your house and not your neighbours’) and exchanges the session key.
2. Encryption: After authentication, the transmitter uses its HDCP cipher engine and the shared session key to create a stream of encrypted data that can only be decrypted by the receiver. The receiver uses its HDCP cipher engine and its copy of the session key to decrypt the content. The receiver also sends verification information back to the transmitter every two seconds to ensure the encryption is in sync. (You have probably experienced the two second flash at some stage when a system is not working right. Now you know the reason.)
3. Revocation: The transmitter also checks the receiver’s key against a black list (revoked key list). If a receiver’s key has been revoked, that receiver can no longer receive the copy protected content.
Each transmitter or receiver has 40 keys (device ID) provided by the Digital Content Protection, LLC (DCP). Each key is 56-bit long.
There’s a misunderstanding in the industry that HDCP-related problems are caused by the transmitter or receiver not having “enough keys”. This is incorrect.
In fact, in HDCP 2.0, there is no secret key exchanged between the transmitter and the receiver.
The transmitter sends a Key Selection Vector (KSV) and a random number to the receiver; the receiver sends its public KSV to the transmitter in return. The transmitter checks the public KSV against a secret constant. Once authenticated, both the transmitter and receiver would generate its own secret value based on the other device’s KSV without sending that secret value over the cable.
Since all keys are mathematical related, the secret value generated by both ends would be identical. Since a key is 56-bit long, there are 72 zillion possible device keys. Therefore, the number of keys is not the cause of the HDCP related problem.
But, there is a limit set by the HDCP Standard. Up to four levels of HDCP repeaters and as many as 32 total HDCP devices are allowed to be connected to an HDCP-protected interface port. This is unrelated to the 40 keys per device.
HDCP 2.0 also adds a locality check. In the process, the transmitter sends a set of random numbers to the receiver and must receive a returned value specific calculation within 7ms. This is more for wireless transmission, to separate local and neighbouring devices.
To put that time period into perspective, it takes electrical signals about 7ms time to travel a 1,000km round trip. This does not include the receiver’s data processing time.