HDCP Handshake Process Over DVI Explained

High-bandwidth Digital Content Protection (HDCP) over a Digital Visual Interface (DVI) connection is a hardware-based cryptographic protocol designed to prevent unauthorized copying of digital video. Before protected media is transmitted, the video transmitter (source) and the display (sink) perform an HDCP handshake to verify that the receiving hardware is authorized to display the content. This article details the specific steps of the HDCP handshake over DVI, from key exchange to real-time stream encryption.

The Physical Communication Path

DVI carries video data over high-speed Transition Minimized Differential Signaling (TMDS) lines, but the HDCP handshake itself occurs over the Display Data Channel (DDC). The DDC is an I²C bus that connects the source and the sink, traditionally used for transmitting Extended Display Identification Data (EDID). When HDCP is active, the source communicates with the HDCP registers on the sink device at I²C slave address 0x74.

Step 1: Initial Key Exchange and Verification

The handshake begins when the source detects that protected content needs to be transmitted.

  1. Initiation: The source generates a 64-bit pseudo-random value called \(A_n\) and transmits it across the DDC bus to the sink, accompanied by the source's 40-bit Key Selection Vector (\(A_{ksv}\)).
  2. Sink Response: The sink receives these values and responds by sending its own Key Selection Vector (\(B_{ksv}\)) back to the source, along with a repeater status bit (indicating whether the device is a final display or an intermediate repeater/switch).
  3. Revocation Check: The source verifies that the received \(B_{ksv}\) contains exactly twenty '1's and twenty '0's (a basic mathematical validity rule for HDCP KSVs). The source also checks the \(B_{ksv}\) against an internal System Renewability List (SRL) to confirm the sink's keys have not been revoked due to security compromises.

Step 2: Shared Secret Generation

Both the source and the sink possess a set of forty secret 56-bit device keys provided by the licensing authority (Digital Content Protection LLC):

  • The source uses its private device keys combined with the sink's public \(B_{ksv}\) to compute a 56-bit shared secret key (\(K_m\)).
  • Simultaneously, the sink uses its private device keys combined with the source's public \(A_{ksv}\) to compute its own version of the shared secret (\(K_m'\)).

Because of the underlying mathematical properties of the HDCP key exchange algorithm, if both devices have valid, uncompromised keys, \(K_m\) will equal \(K_m'\).

To confirm that both devices arrived at the same secret without exposing it over the DDC bus, they generate verification values:

  1. Both devices feed their shared secret into their internal HDCP cipher engines, deriving a 16-bit response value (\(R_0\) on the source, \(R_0'\) on the sink).
  2. The sink writes \(R_0'\) to its DDC registers.
  3. The source reads \(R_0'\) within 100 milliseconds of sending \(A_k\).
  4. If \(R_0\) matches \(R_0'\), authentication is successful, and the source enables content transmission. If the values do not match or the read operation times out, the handshake fails, resulting in a blank screen or an HDCP error message.

Step 4: Stream Encryption and Continuous Authentication

Once authentication succeeds, the source initiates video transmission:

  • Frame Encryption: The HDCP cipher engine on the source generates a pseudo-random bitstream that is XORed with the native 24-bit RGB/YCbCr video data on the TMDS lines before transmission. The sink's cipher engine generates an identical bitstream to decrypt the incoming data in real time.
  • Cyclic Verification (\(R_i\) Check): To prevent an unauthorized device from being swapped in mid-stream, the source reads a new 16-bit verification value (\(R_i'\)) from the sink every 128 frames (approximately every two seconds). If the sink's \(R_i'\) does not match the source's calculated \(R_i\), encryption stops immediately and the display blanks until a full re-authentication occurs.