Since the advent of television, transference of video data from source to display has been a challenging task. Video by nature contains large amounts of information that needs to be transferred quickly. As modern digital displays were introduced, new standards to transfer the video were also introduced; such as Digital Visual Interface (DVI), High- Definition Multimedia Interface (HDMI), DisplayPort, UDI, GVIF, etc.
Digital transmission of audiovisual content is desirable when pursuing the highest possible quality, as it allows perfect reproduction of the source content on displays. But that data must be kept secure from unauthorized parties. High- Bandwidth Digital Content Protection (HDCP), developed by Intel®, provided a solution to prevent copying of digital audio and video content as it travels across the devices. HDCP involves multiple standards that contain various complex algorithms used during authentication, which itself is a multi-step flow and hence makes it difficult to use. This article describes various challenges in the field of verifying and debugging HDCP protected interfaces (HDMI and DisplayPort), and how Mentor’s QVIP makes this task easier for users by providing simple to use APIs and debug messages.
INTRODUCTION TO HDCP
HDCP is a system meant to encrypt the audiovisual content in such a way that this HDCP-encrypted content is restricted from being played on unauthorized devices or devices which have been revoked by the system.
Let’s think of a security check at the airport. First, they confirm your identity and an authorized booking. If everything is fine, they allow you to enter, provide you a seat and let you enjoy the journey. Here, tickets, passport, and IDs are like the public and private keys associated with an HDCP Device. Once they are authenticated, you are provided with a session key (similar to a seat allotted in airplane), which is used to encrypt/decrypt the content.
Likewise, whenever a source device detects the presence of a display (through Hot Plug Detect or any other means), it starts an HDCP session. An HDCP session is basically the exchange of keys between source and display devices. Only valid keys will result in successful authentication. Once, the device is authenticated successfully, they generate a shared secret value which cannot be determined by eavesdroppers.
In case the device does not possess valid keys, authentication fails and the secret value to decrypt the content is not shared with the display. And hence the encrypted content received by the display cannot be decrypted.
 |
Figure 1: Airport Security Check
An HDCP system contains:
- One Content Control Function, whose content is encrypted
- One transmitter that encrypts
- One or multiple receivers (or repeaters)
 |
Figure 2: HDCP System
It provides a three step content protection mechanism:
- Authentication of HDCP Receivers to their immediate upstream connection (to an HDCP Transmitter)
- Revocation of HDCP Receivers that are determined to be invalid by the Digital Content Protection, LLC
- HDCP Encryption of Audiovisual Content over the HDCP-protected interfaces between HDCP transmitters and their downstream HDCP receivers
Before sending data, a transmitting device checks that the receiver is authorized to receive it. If so, the transmitter encrypts the data to prevent eavesdropping as it flows to the receiver.
HDCP supports two versions, HDCP V1.x and HDCP V2.x, where Version 2.x is not a continuation of 1.x and is rather a completely different link protection.
HDCP 1.X
To each adopter of HDCP v1.x, Digital Content Protection, LLC provides a unique set of 40, 56-bit secret device keys and a corresponding 40-bit identifier, Key Selection Vector (KSV). Exchange of these secret device keys between the HDCP devices generates a shared secret value that cannot be determined by eavesdroppers. This shared secret value is then used as a symmetric key to encrypt the HDCP content. If a particular set of keys is compromised, their corresponding KSV is added to a revocation list burned onto new devices. The lists are signed with a DSA digital signature, which is meant to keep malicious users from revoking legitimate devices. During authentication, the transmitting device looks for the receiver’s KSV on the list, and if it is there, will not send protected content to the revoked device. Thus, a communication path is established between the HDCP transmitter and HDCP receiver that can be accessed only by authorized devices.
HDCP 1.x system allows up to seven levels of HDCP repeaters and as many as 128 total HDCP devices, including repeaters.
HDCP authentication protocol is completed in three parts:
- First Part of Authentication Process: Establishes shared values between the two HDCP devices if both devices have a valid Device Key Set from the Digital Content Protection, LLC.
- Second Part of Authentication: Allows an HDCP repeater to report the KSVs of attached HDCP receivers.
- Third Part of Authentication: Occurs during the vertical blanking interval preceding each frame for which encryption is enabled and provides an initialization state for the HDCP cipher for encrypting the HDCP content within that frame.
Once the authentication has been completed successfully, a pseudo-random data stream (24-bit for HDMI and 32-bit for DP) is generated by the HDCP cipher. HDCP encryption consists of bit-wise exclusive-or (XOR) of this data stream with the content to be encrypted.
HDCP 2.X
HDCP Version 2.x is a completely different mechanism for authentication and encryption, HDCP v2.2 being the latest evolution in the 4K era. HDCP 2.0 replaces the ad hoc 56-bit HDCP 1.x encryption scheme with two standard algorithms from the data security industry: for authentication, an RSA system with 1024 and 3072-bit keys, and for content encryption, a 128-bit AES system.
In addition, the maximum number of connected devices is reduced to 32 and the maximum level of repeaters is reduced to four. All of these changes mean that unlike HDCP v1.x specifications, which support backward compatibility, HDCP v2.x is not directly backward compatible with HDCP 1.x. However, the new specifications describe a few converters to interact between HDCP 1.x and HDCP 2.x devices to support mixed A/V systems with both versions of HDCP-compliant devices. Thus, HDCP v2.x interfaces may only interact with HDCP v1.x only by natively supporting HDCP v1.x using a dedicated converter device.
All HDCP v2 adopters are provided with a 128-bit secret Global Constant denoted by lc128 by DCP LLC. The same Global Constant is shared by all the HDCP devices.
All HDCP v2 transmitters are issued a 3072-bit RSA public key of DCP LLC denoted by kpubdcp and receivers are issued 1024-bit RSA public and private keys.
HDCP 2.x features a new authentication protocol and a locality check to ensure that only nearby devices will be able to receive the protected content. This authentication protocol is comprised of the following stages:
- Authentication and Key Exchange (AKE): The HDCP receiver’s public key certificate is verified by the HDCP transmitter and a master key Km is exchanged.
- Locality Check: The HDCP transmitter en- sures that the receiver is located nearby by requiring that the Round Trip Time (RTT) between two messages is not more than 20 ms.
- Session Key Exchange (SKE): Successful completion of AKE and locality check stages affirm to the HDCP transmitter that the HDCP receiver is authorized to receive HDCP content. Then a 128-bit pseudo-random session key is generated by the transmitter and is communicated to the receiver. Whenever, HDCP encryption is disabled due to detection or loss of HPD or authentication failures, this session key is expired.
- Authentication with Repeaters: If the connected downstream port is an HDCP repeater, this step is executed. It is used for the upstream propagation of topology information and the downstream propagation of Content Stream Management information.
Although the mechanisms for HDCP v1.x and v2.x are completely different, still there are few commonalities between HDCP v2 and v1:
- Both are under DCP LLC authority
- Both share the same license agreement, compliance rules and robustness rules
- Both share the same revocation system and same device ID formats, moreover basic HDCP encryption/ decryption fundamentals remain intact.
DIFFERENCES IN HDCP FOR HDMI AND DP
All the HDCP 1.x versions have a similar concept for authenticating the display device, but among the different types of interfaces, few differences occur at the encryption stage. For example, for HDMI the pseudo-random encrypted output is 24-bit wide while for DisplayPort it is 32-bit wide. This concept holds true for Version 2.x as well.
Here we have mentioned some differences in HDCP for HDMI and DP interfaces.
For Version 1.x DisplayPort varies in the following manner:
- Third Step of Authentication, which resets the Cipher in the Vertical Blanking of every frame, is absent
- Authentication process can be started either by sending AKSV and An or by receiving BKSV first
For Version 2.x, it has the following variations:
- Locality timing check
- Field in register rx_status
Few variations that are common among both the versions:
- Wide Offset address range than HDMI
- In DP CP_IRQ interrupt can be sent by receiver which does not exist in HDMI
- Link Integrity check process differs
- Encryption Criteria and Cipher Calculation logics differ
- Stream Mapping over lanes differ in both
Above are the basic differences which exist in HDCP for HDMI and DP along with other minor differences.
VERIFICATION CHALLENGES
Being a content protection protocol, HDCP involves complicated algorithms for authentication and encryption which in turn brings a dilemma for successful verification. Along with the great merits which HDCP bring along, it also introduces the following verification intricacies:
Multi-flavored versions
- Multi-step flow of authentication and encryption/ decryption algorithms
- Two explicit sets of algorithms for Version 1.x and 2.x
- Within a version different flavors for different interfaces
All the above reasons make it cumbersome to create single test bench scenarios that can run on all the versions and their corresponding revisions.
Debugging
- If something goes wrong at some point of the authentication or there are cipher mismatches then it becomes hard to find out the exact cause of the issue as HDCP involves complex algorithms and multiple steps.
Analyzing bus activities
- Multiple private and public keys of wide bit lengths
- Highly iterative logic at every instant
- Multiple cycles to complete each step
All these make it difficult to analyze the bus activities.
Verification closure
- Authentication process is dynamic. It can be initiated at any point of time and any number of times
- Multiple possible scenarios which may lead to authentication failure
These call for a full-fledged functional verification plan to execute all the scenarios.
Content validation
- Once the encrypted audio-visual content received at the display has been decrypted, the actual data before the encryption and after the decryption needs to be compared in order to validate the synchronization of pseudo-random cipher values at both ends.
QUESTA VERIFICATION IP SOLUTION
Mentor’s Display QVIPs provide a user friendly solution to verify various display interfaces like HDMI and DisplayPort. HDCP Versions 1.x and 2.x are available for HDMI and DisplayPort.
Questa VIP provides the following major features to solve HDCP problems:
Consistent HDCP solution
- Consistent HDCP solution across different versions as well as interfaces, HDMI and DisplayPort.
It reduces the test bench development time and effort required to verify HDCP when moving from one version to another or one interface to another.
Dynamic control of HDCP functionality
- Switches to enable and disable HDCP functionality during the simulation at any point of time. Moreover, once devices are authenticated, HDCP encryption can be enabled dynamically.
Easy to use APIs
- APIs to execute the authentication with a single call, which are consistent across versions 1.x and 2.x
For example, a single API call “start_auth” would automatically start the authentication process and all authentication steps will get executed once. A snapshot for the sequence to initiate HDCP authentication is shown below:
 |
Figure 3: HDCP authentication initiation sequence
Control for individual authentication steps
- APIs to control individual steps of authentication which can be called again to restart authentication as and when required. These APIs are consistent across different versions.
Informative messages
- Informative messages during authentication process describe the current stage of the authentication and related information
- Status variables show the cipher values at every cycle.
Sample of debug messages provided is shown below in Figure 4.
 |
Figure 4: Debug messages sample
Ease of debugging
- Checks for all kinds of protocol violations along with a detailed description of fired messages.
- When there is illegal activity on a bus or an HDCP specification violation, the corresponding error message is fired.
For example, if KSV of HDCP receiver does not contain 20 0’s and 20 1’s then the following error is shown in Figure 5.
 |
Figure 5: Assertion snapshot
Scoreboarding
- Frame transmitted before encryption and received after decryption is compared to validate the synchronized encryption/decryption cipher values at source and sink.
Coverage
Covers all the HDCP scenarios for getting verification closure.
Snapshot of some coverage points are shown in Figure 6 below.
 |
Figure 6: HDCP Coverage
CONCLUSION
Content protection is required to keep the intellectual rights of audio-visual data safe. Although it is not a mandatory requirement, when data is critical, it becomes imperative to keep it protected from third parties. Verification of HDCP assures its accurate functionality, which guarantees the safety of data.
Display QVIPs provide a solution which solves the verification challenge when dealing with HDCP for HDMI and DisplayPort. It provides a consistent HDCP solution across all the versions/interfaces with APIs that are easy to use, along with fully informative debug messages, thus making the HDCP verification process fast and easy to debug. It also provides assertions to check the protocol violations, coverage and scoreboarding for full-fledged verification.
It reduces the time and effort required by providing an easier way to generate the stimuli and thus simplifying the complexity associated with the verification of HDCP protocols so that engineers can concentrate on higher value design aspects.
To learn more about QVIPs, you can visit several whitepapers on mentor.com, including:
- Verifying Display Standards – A comprehensive UVM based Verification IP Solution
- Verification IP Stimulus APIs – Are They Really Easy to Use?
REFERENCES
- High-Bandwidth Digital Content Protection System Revision 1.4, 8 July, 2009
- High-Bandwidth Digital Content Protection System, Mapping HDCP to HDMI, Revision 2.2, 13 February, 2013
- High-Bandwidth Digital Content Protection System Revision 1.3, 21 December, 2006 [4] High-Bandwidth Digital Content Protection System, Mapping HDCP to DisplayPort, Revision 2.2, 21 December, 2012
Back to Top