How DisplayPort MST Handles HDCP Key Exchange

High-bandwidth Digital Content Protection (HDCP) over DisplayPort Multi-Stream Transport (MST) secures individual video streams routed to multiple displays through a daisy-chain or hub. When distributing protected content, the DisplayPort source does not authenticate with each display directly. Instead, intermediate MST branch devices act as HDCP repeaters that establish authenticated, encrypted connections downstream to individual sink devices, assemble a comprehensive topology and key list, and propagate this cryptographic validation back upstream to the source.

The Role of the MST Branch Device as a Repeater

In an MST topology, a single physical DisplayPort output from the source transmitter connects to one or more branch devices (such as an MST hub or a daisy-chained monitor). Under the HDCP specification (both HDCP 1.3/1.4 and HDCP 2.2/2.3), any intermediate device that splits or routes video streams must function as an HDCP Repeater.

The repeater decouples the physical transmission layer from the content validation layer, managing security on two fronts: downstream toward connected displays and upstream toward the host GPU.

Downstream Authentication and Topology Mapping

Before protected content can flow, the repeater establishes independent cryptographic trust with every connected downstream display:

  1. Downstream Authentication: The branch device initiates standard point-to-point HDCP authentication with each attached sink (or further downstream branch devices). It reads each display’s public key certificate or Key Selection Vector (KSV) and verifies that the displays are valid HDCP receivers.
  2. Topology Aggregation: The repeater tallies the total number of connected downstream displays (device count) and the depth of the daisy chain (cascade depth). HDCP specifications impose strict limits on these values—HDCP 2.x, for example, limits topologies to a maximum depth of 4 levels and up to 31 devices.
  3. Compiling Receiver IDs: The repeater compiles a list of all downstream Receiver IDs (or KSVs) into a single cryptographic structure called a Receiver ID List (or KSV FIFO in older specifications).

Upstream Authentication with the Source

Once the downstream links are established, the repeater completes its authentication with the source GPU:

  1. Repeater Flag Assertion: During the initial key exchange with the source, the branch device sets its Repeater bit to notify the source that downstream devices exist.
  2. Transmitting Topology Data: The branch device sends the compiled list of downstream Receiver IDs, device counts, and depth topology to the source via the DisplayPort Auxiliary (AUX) channel.
  3. Revocation and Rule Verification: The source checks every ID against its local System Renewability Message (SRM) to ensure no connected display or hub has been revoked due to security compromises. The source also confirms the topology does not exceed maximum allowable device or depth thresholds.
  4. Computation of Shared Secrets: The source and the repeater exchange random nonces and calculate cryptographic verification values (such as \(V\) or \(V'\) in HDCP 2.x) to verify that the list of downstream devices has not been tampered with in transit.

Stream Management and Content Encryption

With authentication complete, the transmission of protected video across the shared link is managed through Virtual Channel (VC) payloads:

  • HDCP 2.x Stream Management: The source issues a RepeaterAuth_Stream_Manage message over the AUX channel. This maps specific content streams (identified by Stream IDs) to specific displays in the topology. It also enforces content stream types: Type 0 content may be passed to legacy (HDCP 1.x) repeaters, while Type 1 content mandates that every downstream link and device strictly comply with HDCP 2.2 or higher.
  • Per-Hop Encryption: Encryption across DisplayPort MST occurs per-hop rather than end-to-end. The source encrypts the interleaved MST transport stream sent over the main link to the primary branch device. The branch device decrypts the stream to route the individual virtual channel payloads, then re-encrypts each sub-stream using the distinct session keys negotiated during downstream authentication before sending the data to the final monitors.