Enabling Faster, More Secure Content with HDCP 2.x

By Peter Lee – Technical Engineer, GRL

Online streaming the biggest development in the entertainment industry since the home video boom of the 1980s. And it faces the same challenge – how to protect millions of dollars’ worth of movies, music and other content from pirates bent on making money from other people’s intellectual property.

Intel’s HDCP (High-Bandwidth Digital Content Protection) encryption technology is designed to encrypt high-resolution digital video and audio content transmitted across digital interfaces, such as HDMI® or DisplayPort™, to prevent video and audio information from being stolen.

Manufacturers who want their multimedia chips to provide such encryption must first purchase an HDCP key license from DCP LLC, a subsidiary of Intel. Likewise, consumers who want to watch video and audio protected by HDCP, such as Blu-ray disc and Netflix video, must purchase HDCP licensed products for both the player (Blu-Ray Player) and receiver (TV). This enables them to enjoy the highest resolution content. If any single device does not support HDCP, the video image quality will be degraded, or the video may not even play.

Currently, the HDMI interface includes HDCP1.4 and the latest version, HDCP2.3 (see Note 1). These correspond to video and audio with resolutions of FHD (1920x1080p) and UHD 4K (3840x2160 or 4096x2160). With the current consumer trend towards higher resolution, 4K video players and displays are becoming more and more popular. HDMI2.1 consumer electronic products supporting 8K resolution have already been launched by a variety of manufacturers. More and more products are expected to adopt the HDCP2.3 protocol, therefore this article focuses on the HDCP2.3 protocol.

Introduction to HDCP 2.3

Figure 1: HDCP System Connections (source: HDCP 2.3 on HDMI Specification)

Introduction to the HDCP2.3 Protocol

Authentication includes several steps. While the terms and concepts of the protocol are introduced below, the encryption algorithm is not discussed in this document.

Authentication and key exchange (AKE)

This process (Figures 2 & 3) calls on the Tx to confirm whether an Rx is a qualified HDCP device. All information is transmitted by the HDMI’s master I2C interface. The beginning of the process is as follows:

1. When the devices are connected, the Tx will transmit AKE_Init, which contains a group of 64-bit pseudo-random codes, rtx and TxCaps (Tx HDCP version information) to the Rx, indicating that the HDCP authentication process is beginning.
2. After the Tx transmits AKE_Init, the Rx needs to return an AKE_Send_Cert within 100ms, and if the time is exceeded, the authentication will fail. The AKE_Send_Cert content consists of certrx (including Receiver ID, Public Key and DCP LLC Signature), a group of 64-bit pseudo-random codes, rrx and RxCaps (Rx HDCP version information and a Repeater bit.
3. After the Tx confirms the Receiver ID (equivalent to the ID card of the Rx) in certrx, there will be two different processes: if the Master Key (km) corresponding to the Receiver ID is not stored at the Tx terminal, the process in Figure 2 – AKE Without a stored km – will be carried out. If the Master Key (km) corresponding to the Receiver ID is stored at the Tx terminal, the process in Figure 3 will be carried out.
4. If the devices of both parties are linked for the first time, the process in Figure 2 will be carried out. In addition to checking the Receiver ID, the Tx will also use the Public Key of the Tx to confirm whether the DCP LLC Signature in certrx is legitimate. If it is illegitimate, the authentication will fail.
5. The Tx generates a group of 128-bit pseudo-random codes as a Master Key (km), encrypts it with the Rx Public Key to generate Ekpub (km), and transmits AKE_No_Stored_km containing Ekpub (km) to the Rx.
6. The Rx uses its own private key (kprivrx) to decode Ekpub (km) to restore km.
7. The Tx checks the legitimacy of the System Renewability Message (see Note 2), and also confirms whether the Signature in the SRM is legitimate through the Tx Public Key.
8. After confirming the legitimacy of the SRM, it will confirm whether the Receiver ID of the downstream device is legitimate. (The above SRM and Receiver ID confirmation will only be carried out by the most upstream Tx)
9. The Tx and Rx carry out Key derivation and calculate the obtained Master Key (km) to obtain kd .
10. The Tx and Rx recalculate the exchanged information (rtx, RxCaps and TxCaps) and kd to obtain H and H' respectively.
11. The Tx reads AKE_Send_H_Prime transmitted by the Rx terminal. If the H and H' values are not equal or are not received within the specified time (1s), the authentication will fail.

Pairing

1. Following the above steps, the Rx calculates 128bit kh by using kprivrx, and then encrypts km with kh to obtain Ekh(km).
2. The Rx transmits AKE_Send_Paring_Info containing Ekh(km) to the Tx.
3. The Tx reads AKE_Send_Paring_Info within a time limit of 200ms, and stores m, km and Eke (km) corresponding to the Receiver ID of this process in memory.
4. When pairing, devices of both parties are re-authenticated. The Tx has stored a Master Key (km) corresponding to the Receiver ID, it will directly enter as part of the Figure 3 process. Compared with the Figure 2 process, some steps (such as Master Key calculation) are omitted, so the HDCP authentication time can be reduced.

Figure. 2: Authentication and Key Exchange (Source: DCP 2.3 on HDMI Specification)

Figure 3: Authentication and Key Exchange (Source: HDCP 2.3 on HDMI Specification)

Locality check

This step is a new mechanism introduced in HDCP2.3 to ensure that the distance between the devices is within the legitimate range. If the link distance is too far, the message will not be received within the time limit, resulting in an authentication failure. The authentication process is as follows:

1. The Tx transmits LC_Init (including 64-bit pseudo-random code rn) to the Rx.
2. The Tx and Rx calculate L and L' respectively.
3. If L and L' are different, or the Tx does not receive L' within 20ms, the authentication will fail.
4. If the authentication fails, the protocol stipulates that the Tx can generate a new rn and retry up to 1,023 times.

Figure. 4: Locality Check between HDCP Transmitter and HDCP Receiver (Source: HDCP 2.3 on HDMI Specification)

Session key exchange

Once the AKE and Locality checks are completed, it means that the transmission devices are legal and can start image encryption transmission. The purpose of this step is to exchange encryption/decryption keys between the devices. The SKE process is as follows:

1. The Tx generates a 128-bit pseudo-random code Session Key (ks) and a 64-bit pseudo-random code riv.
2. The Tx carries out Key derivation to generate 128-bit dkey2 and encrypts ks to generate Edkey (ks).
3. The Tx transmits SKE_Send_Eks(Edkey(ks), riv) to Rx.
   The Rx carries out Key derivation to generate 128-bit dkey2 and interprets Edkey (ks) to obtain ks.
4. Session Key and Secret global constant (lc128, all devices have the same value) are used to start video and audio encryption/decryption.

Authentication with Repeater

In AKE, this process will only be carried out if the Repeater bit in Rxcapps returned by Rx is 1. This is for two reasons:

1. The repeater collates downstream information, such as the number, hierarchy, version and Receiver ID of devices, and then sends them back to the most upstream Tx. If any information is illegitimate, such as if the number and hierarchy of downstream devices exceeds the specification (4 layer hierarchy, 31 units), or the Receiver ID is on the revocation list, the authentication will fail.
2. The repeater transmits the HDCP Content type information (see Note 3) to be transmitted by the Tx to the downstream devices.

Comments

• Note 1: HDCP2.3 is different from HDCP1.4 in design architecture, so it is not downward compatib However, by using an HDCP2.3 to HDCP1.4 converter, the HDCP2.3 content at the player can be displayed on receivers that only support HDCP1.4.
• Note 2: The System Renewability Message is stored by the Tx, and its content contains the revoked Receiver ID. Therefore, the Tx needs to confirm the legitimacy of the SRM before checking the Receiver ID of downstream devices.
• Note 3: HDCP content can be divided into Type0 & Type1 content during transmission. Type0 content can be transmitted to and received by most HDCP devices after passing through a Repeater, while Type1 content cannot be received by downstream HDCP 1.x and 2.x devices after passing through a Repeater.

References

• HDCP on HDMI Specification Rev2_3

Author
By Peter Lee – Technical Engineer, GRL

A graduate of National Cheng Kung University’s Department of Materials, Peter Lee has two years of experience in HDMI testing and familiar with HDMI2.1 and HDCP technology testing. As a Technical Engineer for GRL, he helps customers solve problems and successfully obtain certification.

Specifications and descriptions in this document can be subjected to changes by GRL without prior notice.

Release date 2021/05/21 AN-210521-TW