14 September 2010. Via Reddit, HDCP Master Key: http://pastebin.com/kqD56TmU

20 November 2001. See latest report on cryptanalysis of HDCP by Scott Crosby and others:

http://www.cryptome.org/hdcp-weakness.htm
http://cryptome.org/hdcp/hdcp111901.htm

6 May 2001. Thanks to krazyninja on Slashdot, this document is available in its original PDF format on the Digital Content Protection site: http://www.digital-cp.com The version there includes a page on authorship missing from the version sent to Cryptome.

5 May 2001. Thanks for hardcopy from Anonymous.

See related 18 February 2000 news report: http://www.techweb.com/wire/story/TWB20000218S0008

This file, text and  21 JPEG images, is available Zipped: http://cryptome.org/hdcp-v1.zip (567KB)

[61 pages; no indication of authorship.]

High-bandwidth Digital Content
Protection System

Revision 1.0

17 February 2000

______________________________________

1 Introduction

1.1 Scope
1.2 Overview
1.3 References

2 Authentication

2.1 Overview
2.2 Protocol
2.3 Video Transmitter State Diagram
2.4 Video Receiver State Diagram
2.5 Video Repeater State Diagrams
2.6 HDCP Port
2.7 DVI Control Signal Protocol

3 Data Encryption

4 HDCP Cipher

4.1 Overview
4.2 Linear Feedback Shift Register Module
4.3 Block Module
4.4 Output Function
4.5 Operation

5 Renewability

Appendix A. Test Vectors

Appendix B. Confidentiality and Integrity of Values

1 Introduction

1.1 Scope

This specification describes the High-bandwidth Digital Content Protection (HDCP) system for protecting Digital Visual Interface (DVI) outputs from being copied. The system requires modifications to both display devices and to host graphics systems to provide a protected link between the host (video transmitter) and the display device (video receiver).

Implementations must include all elements of the content protection system described herein, unless the element is specifically identified as informative or optional. Adopters must also ensure that implementations satisfy the robustness and compliance rules described in the technology license. Additionally, video transmitters may be subject to additional robustness and compliance rules associated with other content protection technologies.

1.2 Overview

HDCP is designed to protect the video transmission between a DVI video transmitter and a DVI video receiver. The system also allows for video receivers that support protected downstream DVI connections. These devices are referred to as video repeaters in Figure 1-1, which illustrates an example connection topology for video transmitters, receivers, and repeaters. The HDCP system allows up to seven levels of video repeaters and as many as 128 total devices, including repeaters, to be attached to a host DVI port.

Figure 1-1. HDCP Connection Topology

There are three elements of the content protection system. Each element plays a specific role in the system. First, there is the authentication protocol, through which the video transmitter verifies that a given video receiver is licensed to receive protected content. With the legitimacy of the video receiver determined, encrypted data is transmitted between the two devices based on shared secrets established during the authentication protocol. This prevents eavesdropping devices from utilizing the content. Finally, in the event that legitimate devices are compromised to permit unauthorized use of content, renewability allows a video transmitter to identify such compromised devices and prevent the transmission of protected content.

This document contains chapters describing in detail the requirements of each of these elements. In addition, a chapter is devoted describing the cipher that is used in both the authentication protocol and in the encryption of the video. All aspects of HDCP map easily onto the existing DVI specification.

1.3 Terminology

Throughout this specification, names that appear in italic refer to values that are exchanged during the HDCP cryptographic protocol. Names that appear in CAPS refer to status values from the video receiver. C-style notation is used throughout the state diagrams and protocol diagrams, although the logic functions AND, OR, and XOR are written out where a textual description would be more clear.

The concatenation operator ' || ' combines two values into one. For eight-bit values a and b, the result of (a || b) is a 16-bit value, with the value a in the most significant eight bits and b in the least significant eight bits.

1.4 References

Digital Display Working Group (DDWG), Digital Visual Interface (DVI) Revision 1.0, April 2, 1999.

National Institute of Standards and Technology (NIST), Digital Signature Standard (DSS), FIPS Publication 186-1, December 15, 1998.

National institute of Standards and Technology ( NIST), Secure Hash Standard (SHS), FIPS Publication 180-1, April 17, 1995.

Philips Semiconductors, The I²-Bus Specification, Version 2.0, December 1998.

2 Authentication

The HDCP Authentication protocol is an exchange between a video transmitter and a video receiver that affirms to the transmitter that the receiver is authorized to receive the protected information. this affirmation is in the form of the receiver demonstrating knowledge of a set of secret device keys. Each authorized device is provided with a unique set of secret device keys from the Digital Content Protection LLC. The communication exchange, which allows for the receiver to demonstrate knowledge of such secret device keys, also provides for both parties to generate a shared secret value that cannot be determined by eavesdroppers on this exchange. By having this shared secret formation melded into the demonstration of authorization, the shared secret can then be used as a symmetric key to encrypt video content intended only for the authorized receiver. Thus, a communication path is established between, the transmitter and receiver that only authorized parties can access.

2.1 Overview

Each authorized participant (e.g. licensed monitor device, graphics controller device, etc.) receives an array of 40, 56-bit secret device keys and a corresponding identifier from the Digital Content Protection LLC. This identifier is the Key Selection Vector (KSV) assigned to the device. The KSV is a 40-bit binary value.

The HDCP Authentication Protocol can be considered in three parts. The first part establishes shared values between the two devices if both devices have a valid array of secret device keys and corresponding KSVs. The second part allovis a video repeater to report the KSVs of attached video receivers. Ihe third part occurs during the vertical blanking interval preceding each video frame for which encryption is enabled, and provides an initialization state for the HDCP Cipher for encrypting the RGB pixel strearn of that frame.

2.2 Protocol

Figure 2-1 illustrates the first part of the authentication exchange. The video transmitter (Device A) can initiate authentication at any time, even before a previous authentication exchange has completed. Authentication is initiated by the video transmitter by sending an initiation message containing its KSV (Aksv) and a 64-bit pseudo-random value (An) generated by the HDCP Cipher function hdcpRngCipher (Section 4.5) to the video receiver (Device B). The video receiver responds by sending a response message containing the video receiver's KSV (Bksv) and the REPEATER bit, which indicates if the video receiver is a repeater. The video transmitter verifies that the video receiver's KSV has not been revoked (section 5), and that the received KSV contains 20 ones and 20 zeros.

Figure 2-1. First Part of Authentication Protocol

At this point, if both devices have a valid array of secret device keys and corresponding KSv from the Digital Content Protection LLC, then they can each calculate a 56-bit shared secret value, Km (or Km' in the video receiver). Each device calculates Km (or Km') by adding a selection of its private device keys described by the other device's KSV, using 56-bit binary addition (i.e. unsigned addition modulo 2⁵⁶). The selection of secret device keys that are added together consists of those corresponding to the bit indexes of all of the 1-bits of the binary representation of the KSV.

For example, suppose Bksv equals 0x5A3. For the binary representation of 0x5A3, bit positions 0, 1, 5, 7, 8, and 10 are ones and all other bit positions are zeros. Therefore, Device A will add it's own secret device keys at array indexes 0, 1, 5, 7, 8, and 10 together to calculate the shared secret value, Km. Device B will perform an analogous calculation using its own private key array and Device A's KSV to get Km'.

If either device has an invalid set of secret device keys or corresponding KSV, then Km will not be equal to Km'.

The HDCP Cipher function hdcpBlockCipher (Section 4.5) is then used to calculate three values, Ks, M₀, and R₀. The cipher initialization values for this calculation are Km (or Km'), and the 65-bit concatenation of REPEATER with An. The video receiver status bit REPEATER indicates that the video receiver supports retransmission of video to additional DVI video receivers. The session key Ks is a 56-bit secret key for the HDCP Cipher. M₀ is a 64-bit secret value used in the second part of the authentication protocol, and as a supplemental HDCP Cipher initialization value. R₀' is a 16-bit response value that the video receiver returm to the video transmitter to provide an indication as to the success of the authentication exchange. R₀' must be available for the video transmitter to read within 100 milliseconds from the time that the video transmitter finishes writing Aksv to the video receiver.

If authentication was successful, then R₀' will be equal to R₀. If authentication was unsuccessful, then R₀' and R₀ will, in most cases, differ. Future R_i' values, produced during the third part of the authentication protocol, will reveal that authentication has failed in the event that the R₀ values erroneously indicate that authentication was successful.

Figure 2-2. Second Part of Authentication Protocol

The second part of the authentication protocol (Figure 2-2) is required for all video transmitters and video repeaters. The video transmitter executes the second part of the protocol only when the REPEATER bit is set,indicating that the attached device is a video repeater. This part of the protocol assembles a list of all KSVs attached to the DVI host through a the permitted connection tree, enabling video source functions at the host to perform revocation.

Video repeaters assemble the list of all attached devices as the downstream ports of the video repeater complete the authentication protocol with attached video receivers. The list is represented by a contiguous set of bytes, with each KSV occupying five bytes stored in little-endian order. The total length of the KSV list is five times the total number of attached devices. An unconnected port adds nothing to the list. A port connected to a video receiver (as opposed to a video repeater), adds the Bksv of the attached video receiver to the list. Ports that have a video repeater attached add the KSV list of the attached video repeater, plus the Bksv of the attached video repeater. In order to add the KSV list of the attached video repeater, it is necessary for the video repeater to verify the integrity of the list by computing V and checking this value against V' received from the attached video repeater. If V does not equal V', the downstream KSV list integrity check fails, and the upstream video repeater must not assert its READY status. Upstream devices will detect this failure by the expiration of a watchdog time set in the video transmitter.

When the video repeater has assembled the corriplete list of attached devices' KSVs, it computes and appends to the list the verification value V. This value is the SHA-1 hash of the concatenation of the KSV list, Bstatus, and the secret value M₀. When both the KSV list and V are available, the video repeater asserts its READY status indicator.

The video transmitter, having determined that the REPEATER bit read earlier in the protocol is set, sets a five-second watchdog timer and polls the receiver's READY status bit. When READY is set, the video transmitter reads the KSV list and V from the repeater. The video transmitter verifies the integrity of the KSV list by computing the SHA-1 hash value V and comparing this value to V'. If V is not equal to V', then the authentication protocol is aborted.

If the asserted READY status is not received within a maximum-permitted time of five seconds, authentication of the video repeater fails. With this failure, the video transmitter abandons die authentication protocol with the video repeater. Authentication can be reattempted with the transmission of a new value An and the Aksv.

In addition to assembling the KSV, list video repeater propagates topology information upward through the connection tree to the DVI host. A video repeater reports the topology status variables DEVICE_COUNT and DEPTH. The DEVICE_COUNT for a video repeater is equal to the total number of attached downstream video receivers. The value is calculated as the sum of the number of attached downstream ports plus the sum of the DEVICE_COUNT of all attached video repeaters. The DEPTH status for a video repeater is equal to the maximum number of connection levels below any of the downstream DVI ports. The value is calculated as the maximum DEPTH reported from downstream video repeaters plus one (accounting for the attached downstream video repeater). For example, a video repeater with zero downstream devices reports a value of zero for both the DEPTH and the DEVICE_COUNT. A video repeater with four downstrearn video receivers (not repeaters) reports a DEPTH of one and a DEVICE_COUNT of four. If the computed DEVICE_COUNT for a repeater exceeds 127, the repeater must assert the MAX_DEVS_EXCEEDED status bit. If the computed DEPTH for a repeater exceeds seven, the repeater must assert the MAX_CASCADE_EXCEEDED status bit. When a repeater receives a MAX_DEVS_EXCEEDED or a MAX_CASCADE_EXCEEDED status from a downstream repeater, it is required to assert the corresponding status bits upstream.

Authentication fails if the topology maximums are exceeded. All video transmitters check to see if the KSV of any attached device is found in the current revocation list, and. if present, the authentication fails. The video transmitter verifies the integrity of the current revocation list by checking the signature of the system renewability message (SRM) using the Digital Content Protection LLC public key L¹. Failure of this integrity check constitutes an authentication failure.

Table 2-1. Video Repeater Protocol Timing Requirements

Table 2-1 specifies video repeater timing requirements that bound the worst-case propagation time for the KSV list. Note that because each video repeater does not know the number of downstream video repeaters, it must use the same five-second timeout used by the host when polling for downstream READY.

The video transmitter enables data encryption when the second part of the authentication protocol successfully completes.

Figure 2-3. Third Part of Authentication Protocol

The third part of the authentication protocol, illustrated in Figure 2-3, occurs during the vertical blanking interval preceding the frame for which it applies. Each of the two devices calculates new cipher initialization values, K_i and M_i, and a third value R_i, where i is the frame number starting with one for the first video frame for which content protection is enabled. K_i is a 56-bit key used to initialize the HDCP cipher for encryption or decryption of the RGB information for the video frame. M_i is a new 64-bit initialization value for the HDCP cipher. R_i is a 16-bit value used for link integrity verification, and is updated for every 128th frame, starting with the 128th frame. The video transmitter verifies this value against its own calculations to insure that the video receiver is still able to correctly decrypt the information. This verification is made at the rate of once every two seconds, plus or minus one-half second. It is required that the R_i' read operation complete within 250 milliseconds, from the time that it is initiated by the video transmitter. Failure for any reason causes the video transmitter to consider the DVI link to be unauthenticated.

2.3 Video Transmitter State Diagram

The transmitter device state diagram (Figure 2-4) illustrates the operation states of the authentication protocol for a video transmitter.

Figure 2-4. Video Transmitter Authentication Protocol State Diagram

Transition Any State:A0. Reset conditions at the video transmitter cause the video transmitter to enter the unauthenticated state. Video receiver detach as sensed by the hot plug pin of the DVI interface also cause a transition to the unauthenticated state.

State A0: Unauthenticated. In this state the device is idle, with encryption disabled, awaiting an event to trigger the authentication protocol. Such events include completion of certain phases of the operating system startup and the hot-plug detection of an attached video receiver.

Transition A0:A1. A trigger event, such as hot-plug detection of an attached video receiver, initiates the authentication protocol.

Transition A0:A10. This transition is made when the hot plug pin of the DVI interface indicates that no device is attached.

State A1: Exchange KSVs. In this state, the video transmitter generates a 64-bit pseudo-random value (An) in hardware and writes that value and its key selection vector (Aksv) to the video receiver. The video transmitter also reads the video receiver key selection vector (Bksv) and the REPEATER status bit necessary for cipher initialization. Hardware generation of An using the HDCP Cipher is described in section 4.5.

Transition A1:A0. Failure to read a key selection vector containing 20 zeros and 20 ones is considered a protocol failure and causes this state transition to State A0.

Transition A1:A2. The random value An and video transmitter KSV have been written, and a valid video receiver Bksv and REPEATER bit have been read. Video transmitter hardware is required to check that Bksv contains 20 ones and 20 zeros.

State A2: Computations. In this state, the video transmitter computes the values Km, Ks, M₀, and R₀, using the video transmitter private keys, Bksv read during State A1, and the random number An written to the video receiver during state A1.

Transition A2:A3. When the computed results from State A2 are available, the video transmitter proceeds to State A3.

State A3: Validate Receiver. The video transmitter reads R₀' from the video receiver and compares it with the corresponding R₀ produced by the video transmitter during the computations of State A2. If R₀ is equal to R₀', then data encryption is immediately enabled. The video transmitter must allow the video receiver up to 100 ms to make R₀' available from the time that Aksv is written. The video transmitter also checks the current revocation list for the video receiver's KSV Bksv. If Bksv is in the revocation list, then the video receiver is considered to have failed the authentication and is not allowed to receive protected content. Note: checking the revocation list for Bksv may begin as soon as the Bksv has been read in State A1, asynchronously to the other portions of the protocol, but, it must complete prior to the transition into the authenticated state (State A4).

The integrity of the current revocation list must be verified by checking the signature of the SRM using the Digital Content Protection LLC public key L¹, as specified in Section 5.

Transition A3:A0. The link integrity message R₀ received from the video receiver does not match the value calculated by the video transmitter, or Bksv is in the current revocation list.

Transition A3:A6. The link integrity message R₀ received from the video receiver matches the expected value calculated by the video transmitter and Bksv is not in the current revocation list.

State A4: Authenticated. The device has completed the authentication protocol. The verification timer is set up to generate timer events at the nominal rate of once every two seconds, plus or minus one-half second. At this time, and at no time prior, the HDCP system may indicate to upstream content protection technologies (eg. conditional access technologies for direct broadcast satellite) that the system is fully engaged and able to deliver protected content.

Transition A4:A5. A verification timer event causes this transition to State A5.

State A5: Link Integrity Check. In this state, the video transmitter reads R_i' from the video receiver and compares that value against its value R_i. If the values are equal, then the video receiver is correctly decrypting the transmitted stream. The R_i' value may be re-read to allow for synchronization and 1²C bus errors.

Transition A5:A4. The link integrity message from the video receiver correctly matches the expected value.

Transition A5:A0. The link integrity message from the video receiver does not match the expected value, or the value was not returned to the video transmitter within 250 milliseconds from the initiation of the read operation.

State A6: Test for Repeater. The video transmitter evaluates the state of the video repeater capability bit (REPEATER) that was read in State A1.

Transition A6:A4. The REPEATER bit is not set (the video receiver is not a repeater).

Transition A6:A8. The REPEATER bit is set (the video receiver is a repeater).

State A8: Wait for Ready. The video transmitter polls the video receiver READY bit.

Transition A8:A0. The watchdog timer expires before the READY indication is received.

Transition A8:A9. The asserted READY signal is received.

State A9: Read KSV List. The watchdog timer is cleared. The video transmitter reads the list of attached KSVs from the KSV FIFO, reads V, computes V' and verifies V == V', and the KSVs from the list are compared against the current revocation list.

The integrity of the current revocation list must be verified by checking the signature of the SRM using the Digital Content Protection LLC public key L¹, as specified in Section 5.

Transition A9:A0. This transition is made if V != V', verification of the SRM fails, or if the any of the KSVs in the list are found in the current revocation list. A retry of the entire KSV FIFO read operation may be implemented in the case of an incorrect V value. Two additional status bits cause this transition when asserted. These are MAX_CASCADE_EXCEEDED and MAX_DEVS_EXCEEDED.

Transition A9:A4. If V == V', the SRM is valid, none of the reported KSVs are in the current revocation list, and the downstream topology does not exceed specified maximums.

State A10: No Device Attached. The hot plug pin of the DVI interface indicates that there is no DVI device attached. Video data is not transmitted.

Transition A10:A1. The authentication protocol begins when the hot plug pin of the DVI interface indicates attachment of a device.

2.4 Video Receiver, State Diagram

The operation states of the authentication protocol for a video receiver are illustrated in Figure 2-5.

Figure 2-5. Video Receiver Authentication State Diagram

Transition Any State:B0. Reset conditions at the video receiver cause the video receiver to enter the unauthenticated state.

State B0: Unauthenticated. The device is idle, awaiting the reception of An and Aksv from the video transmitter to trigger the authentication protocol.

Transition B0:B1. The final byte of Aksv is received from a video transmitter.

State B1: Computations. In this state, the video receiver calculates the values Km', Ks', M₀', and R₀' using the video receiver private keys and the received values of An and Aksv. The video receiver is allowed a maximum time of 100 milliseconds to complete the computations and make R₀' available to the video transmitter. Should the video transmitter write the Aksv while the video receiver is in this state (State B 1), the video receiver abandons intermediate results and restarts the computations.

Transition B1:B2. The computations are complete and the results are available for reading by the video transmitter.

State B2: Authenticated. The video receiver has completed the authentication protocol and is ready to generate the first video frame key when signaled by the video transmitter.

Transition B2:B1. Re-authentication is forced any time the Aksv is written by the attached video transmitter.

Transition B2:B3. The third part of the authentication protocol requires periodic updates to the R_i' value.

State B3: Update R_i'. During the vertical blank interval preceding each encrypted frame the video receiver determines whether or not to update the response value R_i' with HDCP Cipher output value available during the frame key calculation. The R_i' value is updated when (i mod 128 == 0). The updated value must be available through the HDCP Port no more than 128 pixel clocks from the time that CTL3 signals data encryption for the next frame. Section 2.7 specifies CTL3 signaling.

Transition B3:B2. Once R_i' has been updated, return to the authenticated state.

2.5 Video Repeater State Diagrams

The video repeater has one connection to an upstream video transmitter and one or more connections to downstream video receivers connected via DVI and HDCP as permitted in the Digital Content Protection LLC license. The state diagram for each downstream connection (Figure 2-6) is substantially the same as that for the host video transmitter (Section 2.3), with two exceptions. First, the repeater is not required to check for downstream KSVs in a revocation list. Second, the video repeater initiates authentication downstream only when it receives an authentication request from upstream, rather than at hot plug detection on the downstream port. The video repeater signals the hot plug event to the upstream host by pulsing the HPG signal of the upstream DVI interface. The pulse width must be greater than 100 Ms.

Figure 2-6. Video Repeater Downstream Authentication Protocol State Diagram

Transition Any State:F10. Reset conditions at the video repeater and downstream hot plug detach cause the video repeater port to enter state F10, no device attached.

State F0: Unauthenticated. In this state the device is idle, with encryption disabled, awaiting an upstream authentication request (upstream Aksv write) to trigger the authentication protocol.

Transition F0:F1. The upstream authentication request initiates the authentication protocol.

State F1: Exchange KSVs. In this state, the downstream transmitter of the video repeater generates a 64-bit pseudo-random value (An) in hardware and writes that value and its key selection vector (Aksv) to the video receiver. The video repeater also reads the video receiver key selection vector (Bksv) and the repeater capability bit (REPEATER) necessary for cipher initialization. Hardware generation of An using the HDC.P Cipher is described in Section 4.5.

Transition F1:F0. Failure to read a key selection vector containing 20 zeros and 20 ones is considered a protocol failure and causes this state transition to State F0.

Transition F1:F2. The random value An and downstream transmitter KSV have been written, and a valid video receiver Bksv and REPEATER bit have been read. Downstream transmitter hardware is required to validate that Bksv contains 20 ones and 20 zeros.

State F2: Computations. In this state, the downstream transmitter computes the values Km, Ks, M₀, and R₀, using the downstream transmitter private keys, Bksv read during State F1, and the random number An written to the video receiver during state F1.

Transition F2:F3. When the computed results from State F2 are available, the downstream transmitter proceeds to State F3.

State F3: Validate Receiver. The downstream transmitter reads R₀' from the video receiver and compares it with the corresponding R₀ produced by the downstream transmitter during the computations of State F2, then immediately enables data encryption if R₀' is equal to R₀. The video receiver must be allowed up to 100 ms to make R₀' available from the time that Aksv is written. The downstream Bksv is added to the KSV list for this video repeater.

Transition F3: F0. The link integrity message R₀' received from the video receiver does not match the value calculated by the downstream transmitter.

Transition F3:F6. The link integrity message R₀' received from the video receiver matches the expected value calculated by the downstream transmitter.

State F4: Authenticated. At this time, and at no prior time, the device has completed the authentication protocol and is fully operational, able to deliver protected content. The verification timer is set up to generate timer events at the nominal rate of once every two seconds, plus or minus one-half second.

Transition F4:F5. A verification timer event causes this transition to State F5.

State F5: Link Integrity Check. In this state, the downstream transmitter reads R_i' from the video receiver and compares that value against its value R_i. If the values are equal, then the video receiver is correctly decrypting the transmitted stream. The R_i' value may be re-read to allow for synchronization and I²C bus errors.

Transition F5:F4. The link integrity message from the video receiver correctly matches the expected value.

Transition F5:F0. The link integrity message from the video receiver does not match the expected value, or the value was not returned to the downstream transmitter within 250 milliseconds from the initiation of the read operation.

State F6: Test for Repeater. The downstream transmitter evaluates the state of the video repeater capability bit (REPEATER) that was read in State F1.

Transition F6:F4. The REPEATER bit is not set (the video receiver is not a repeater).

Transition F6:F8. The REPEATER bit is set (the video receiver is a repeater).

State F8: Wait for Ready. The downstream transmitter sets up a five-second watchdog timer and polls the video receiver READY bit.

Transition F8:F0. The watchdog timer expires before the READY indication is received.

Transition F8:F9. The asserted READY sigrial is received.

State F9: Read KSV List. The watchdog timer is cleared. The downstream transmitter reads the list of attached KSVs through the KSV FIFO, reads V, computes V' and verifies V == V', and the KSVs from this port are added to the KSV list for this video repeater. Two additional status bits (MAX_CASCADE_EXCEEDED and MAX_DEVS_EXCEEDED) from the downstream video receiver are read and if asserted, cause the repeater to also assert them upstream.

Transition F9:F0. This transition is made if V != V'. A retry of the entire KSV FIFO read operation may be implemented in the case of an incorrect V value. It is also made if either MAX_CASCADE_EXCEEDED or MAX_DEVS_EXCEEDED are asserted.

Transition F9:F4. This transition is made if V == V' and the downstream topology does not exceed specified maximums.

State F10: No Device Attached. The hot plug pin of the DVI interface indicates that there is no DVI device attached. Video data is not transmitted.

Transition F10:F0. The downstream port transitions to the unauthenticated state when the hot plug pin of the DVI interface indicates attachment of a device.

The video repeater upstream state diagram, illustrated in Figure 2-7, makes reference to states of the video repeater downstream state diagram.

Figure 2-7. Video Repeater Upstream Authentication Protocol State Diagram

Transitions Any State:C0. Reset conditions at the video repeater cause the video repeater to enter the unauthenticated state. Re-authentication is forced any time the Aksv is written by the attached video transmitter, with a transition through the unauthenticated state.

State C0: Unauthenticated. The device is idle, awaiting the reception of An and Aksv from the video transmitter to trigger the authentication protocol. The READY status bit, in the HDCP port, is de-asserted.

Transition C0:C1. The final byte of Aksv is received from a video transmitter.

State C1: Computations. In this state, the video repeater calculates the values Km', Ks', M₀', and R₀' using its private keys and the received values of An and Aksv. The video repeater is allowed a maximum time of 100 milliseconds to complete the computations and make R₀' available to the video transmitter. Should the video transmitter write the Aksv while the video repeater is in this state (State C1), the video repeater abandons intermediate results and restarts the computations.

Transition C1:C5. The computations are complete and the results are available for reading by the video transmitter.

State C2: Authenticated. The video repeater has completed the authentication protocol and is ready to generate the first video frame key when signaled by the video transmitter. The READY status bit is asserted.

Transition C2:C0. The upstream connection becomes unauthenticated if any downstream video receiver enters the unauthenticated state OR if a downstream port that previously had no downstream device attached senses an attachment via the hot plug detection pin.

Transition C2:C3. This transition is made during the vertical blank interval preceding encrypted frames.

State C3: Update Ri'. During the vertical blank interval preceding each encrypted frame the video repeater determines whether or not to update the response value Ri' with HDCP Cipher output value available during the frame key calculation. The Ri' value is updated when (i mod 128 == 0).

Transition C3: C2. Once Ri' has been updated, return to the authenticated state.

State C5:Wait for Downstream. The upstream state machine waits for all downstream ports of the video repeater to enter either the unconnected (State F10) or the authenticated state (State F4).

Transition C5:C0. The watchdog timer expires before all downstream video ports enter the authenticated or unconnected state.

Transition C5:C6. All downstream ports with attached video receivers have reached the state of authenticated or unconnected.

State C6: Assemble KSV List. The video repeater assembles the list of all attached devices as the downstream ports reach terminal states of the authentication protocol. A port that advances to State F10, the unconnected state, does not add to the list. A port that arrives in State F4 that has a video receiver attached (as opposed to a video repeater), adds the Bksv of the attached video receiver to the list. Ports that arrive in State F4 that have a video repeater attached will cause the KSV list of the attached video repeater, plus the Bksv of the attached video repeater, to be added to the list. The video repeater must verify the integrity of the downstream list by computing V and checking this value against V' received from the attached video repeater. If V does not equal V', the downstream KSV list integrity check fails. When the KSV list for all downstream video receivers has been assembled, the video repeater computes the upstream V. The DEVICE_COUNT for a video repeater is equal to the total number of attached video receivers. The value is calculated as the sum of the number of attached downstream ports plus the sum of the DEVICE_COUNT of all attached video repeaters. The DEPTH for a video repeater is equal to the maximum number of connection levels below any of the downstream DVI ports. The value is calculated as the maximum DEPTH reported from downstream video repeaters plus one (accounting for the attached downstream video repeater). If the computed DEVICE_COUNT for a repeater exceeds 127, the repeater must assert the MAX_DEVS_EXCEEDED status bit. If the computed DEPTH for a repeater exceeds seven, the repeater must assert the MAX_CASCADE_EXCEEDED status bit. When a repeater receives a MAX_DEVS_EXCEEDED or a MAX_CASCADE_EXCEEDED status from a downstream repeater, it is required to assert its corresponding upstream status bit.

Transition C6:C0. If any downstream port should transition to the unauthenticated state, the upstream connection transitions to the unauthenticated state. This transition is also made when any downstream video repeater reports a topology error, or when the KSV list integrity check for a downstream video repeater fails.

Transition C6:C2. The KSV list and V are ready for reading by the upstream video transmitter.

2.6 HDCP Port

The values that must be exchanged between the video transmitter and the video receiver are communicated over the I²C serial interface of the DVI interface. The video receiver or video repeater must present a logical device on the I²C bus for each T.M.D.S. link that it supports. No equivalent interface to video transmitters is specified. The seven-bit I²C device address for the primary link is 0111010x binary, or 0x74 in the usual hexadecimal representation of I²C device addresses where the read/write bit is set to zero. The device address for the secondary link is 0x76. Table 2-2 and Table 2-3 specify the address space for these devices, which act only as slaves on the I²C bus. Multi-byte values are stored in little-endian format.

Read and write operations must complete within 100 ms per byte transferred. It is strongly recommended that slave devices never stretch the I²C clock. Master devices may elect to repeat any transfers believed to have previously completed with errors.

Table 2-2. Primary Link HDCP Port (I²C device address 0x74)

Table 2-3. Secondary Link HDCP Port (I²C device address 0x76)

Table 2-4. Bstatus Register Bit Field Definitions

The CP devices at these slave addresses respond to I²C accesses as diagrammed in Figures 2-7, 2-8, and 2-9. The nomenclature within these diagrams, and used to describe them, is the same as found in The I²C Bus Specification Version 2.0.

Figure 2-8 illustrates a combined-format byte read, in which the master writes a one-byte address to the slave, followed by a repeated start condition (Sr) and the data read. With the exception of combined-format reads from the KSV FIFO, HDCP port devices must support multi-byte reads, with auto-increment. Combined-format reads from the KSV FIFO have an implicit address increment though the FIFO data structures.

Figure 2-8. HDCP Port Combined-Format Byte Read

Figure 2-9 illustrates a byte write access. As for combined-format read accesses, the HDCP port must support multi-byte writes with auto-increment, again with an exception for KSV FIFO writes where the implicit address increment moves through the KSV FIFO data structure rather than through the HDCP port address space. Auto-incremented sequential accesses that start before the KSV FIFO address and cross through the KSV FIFO address read only the first byte of the KSV FIFO and then continue incrementing through the HDCP port address space.

Figure 2-9. HDCP Port Byte Write

In order to minimize the number of bits that must be transferred for the link integrity check, a second read format must be supported by all video receivers and by video transmitters that do not implement a hardware I²C master. This access, shown in Figure 2-10, has an implicit address equal to 0x08, the starting location for R_i'. The short read fortnat may be uniquely differentiated from combined reads by tracking STOP conditions (P) on the bus. Short reads must be supported with auto-incrementing addresses.

Figure 2-10. HDCP Port Link Integrity Message Read

2.7 DVI Control Signal Protocol

The transmitter signals the receiver to begin the second part of the authentication protocol through the previously reserved control signal CTL3 in the DVI interface. This is done with a single high-going pulse, during the vertical blanking interval, of sufficient width that it may be distinguished from bit errors on the channel or any effects due to resynchronization events in the receiver.

The timing requirements for CTL3 are specified in Table 2-5. Note that for typical display timings with positive polarity vertical sync, it is possible to satisfy these requirements by tying the CTL3 signal to the vertical sync signal when content protection is enabled.

Table 2-5. DVI Control Signal Timing Requirements

3 Data Encryption

Data encryption is. applied at the.input to the T.M.D.S. transmitter and decryption is applied at the output of the T.M.D.S. receiver (Figure 3-1). Data encryption consists of a bit-wise exclusive-or (XOR) of the video data with a pseudo-random data stream produced by the HDCP Cipher. In dual-link implementations the video data is 48-bits wide and requires two HDCP Ciphers to produce the required pseudo-random streams.

Figure 3-1. HDCP Encryption and Decryption

During the vertical-blanking interval, the hdcpBlockCipher function prepares the HDCP Cipher to produce the 24-bit wide key-dependent pseudo-random stream during active pixel data. The HDCP Cipher generates a new 24-bit word of pseudo-random data for every active pixel of video data, as defined on the interface by the data enable (DE) signal. The 24-bits of cipher output are applied to the RGB video data as shown in Table 3-1.

Table 3-1. Encryption Stream Mapping

During horizontal-blanking intervals on the interface, the HDCP Cipher is re-keyed for 56 pixel clocks as described in Section 4.5. This complicates the task of breaking the encryption from line to line.

Figure 3-2 illustrates the encryption fimctions as they relate to horizontal sync (HSync), vertical sync (VSync), data enable (DE), and Control3. Because this diagram is applicable to both transmitters and receivers, the state and transition descriptions below use the term "transceiver" to refer to either transmitters or receivers. Encrypt/Decrypt refers to the appropriate operation for the transceiver.

Figure 3-2. Encryption/Decryption State Diagram

Transition Any State:D0. Reset conditions or transitions into the unauthenticated state at the video transceiver cause the encryption state machine to transition to the idle state.

State D0: Idle. The HDCP Cipher is free running and available for use as hdcpRngCipher (Section 4.5).

Transition D0:D1. The assertion of CTL3 (as specified in Table 2-4) at a time when the video transceiver is authenticated causes frame key calculation. Authenticated states for video transmitters are State A4 and State A5. Authenticated states for video receivers are State B2 and State B3. Authenticated states for video repeaters are State C2 and State C3.

State D1: Frame Key Calculation. The frame key for the next video frame is calculated as described in section 4.5, using hdcpBlockCipher.

Transition D1:D2. Data enable (DE) on the T.M.D.S. link signals the beginning of active pixel data to be encrypted/decrypted by the transceiver.

State D2: Encrypt/Decrypt. Video transmitters encrypt pixel data in this state, while video receiver decrypt data. Both use the hdcpStreamCipher as described in section 4.5.

Transition D2:D3. The end of pixel data is signaled by DE.

State D3: Unknown Blank. At the end of active pixel data, it is not assumed that video transceivers are able to distinguish between horizontal and vertical sync. In this state, video transceivers must begin to rekey the HDCP cipher using hdcpRekeyCipher as described in section 4.5.

Transition D3:D1 Frame Key Calculation. The assertion of CTL3 as specified in Table 2-4 results in the generation of a new frame key.

Transition D3:D4. The assertion of HSync identifies the horizontal blank.

Transition D3:D5. The assertion of VSync identifies the vertical blank.

State D4: Horizontal Blank. The rekey operation continues if not completed during State D3.

Transition D4:D2. The assertion of DE begins encryption/decryption of the next line of video data.

Transition D4:D1. The assertion of CTL3 as specified in Table 2-4 results in the generation of a new frame key.

Transition D4:D5. The assertion of VSync identifies the vertical blank.

State D5: Vertical Blank. This state waits for one of the exit conditions.

Transition D5:D1. The assertion of CTL3 as specified in Table 2-4 results in the generation of new frame key.

Transition D5:D0. The return to active pixel data signaled by the assertion of DE prior without a CTL3 assertion during the vertical blank indicates that encryption. has been disabled for the next frame. This path might be taken in the event of link integrity message failure.

4 HDCP Cipher

4.1 Overview

The HDCP cipher is a special-purpose cipher designed for both the appropriate robustness of the authentication protocol as well as for the high-speed streaming requirement of uncompressed video data encryption.

The overall structure of the HDCP Cipher can be thought of as three layers. The first layer consists of a set of four Linear Feedback Shift Registers (LFSRs) that are combined to one-bit. This one bit feeds into the middle layer when enabled via the rekey enable signal. The middle layer consists of two halves that are very similar in design. One half, Round Function B, performs one round of a block cipher using three 28-bit registers, Bx, By, and Bz. The other half, Round Function K, is similar in structure to Round Function B, but provides the output of latch Ky as a stream of 28-bit round keys to Round Function B at the rate of one 28-bit round key per clock pulse. The final layer takes four 28-bit register outputs from the round functions, By, Bz, Ky, and Kz, through a compression function to produce a 24-bit block of pseudo-random bits for every clock pulse.

Figure 4-1. HDCP Cipher Structure

The block module operates as a block cipher during the authentication protocol. There is a single sequence, hdcpBlockCipher, which is used for both parts of the authentication protocol. Although decryption in block mode is possible for the HDCP cipher, it is not necessary for this application and thus is not described in this document.

The block module and the output function are used together to produce the 24-bit pseudo random sequence that is used to encrypt the video data. In this mode. hdcpStreamCipher, the module produces 24 bits of output for every input clock.

The LFSR module is used to re-key the block module between lines of video.

4.2 Linear Feedback Shift Register Module

The linear feedback shift register module consists of four LFSRs of different lengths and a combining function that produces a single bit strewn from them. The combining function takes three taps from each LFSR. The generator polynomials and combining function taps for the LFSRs are specified in Table 4-1.

Table 4-1. LFSR Generation and Tapping

Figure 4-2 illustrates the tap locations of LFSR0 as well as the XOR term feedback into the least significant bit of LFSR0.

Figure 4-2. LFSR0

The combining function contains four cascaded shuffle networks, each of which includes two state bits. One tap from each of the four LFSRs is XORed together to form the data input to the first shuffle network. One tap from each of the four LFSRs is used as the select input to one of the four shuffle networks. The output of the fourth shuffle network is XORed together with one tap from each of the LFSRs. The Combiner Function illustrated in Figure 4-3.

Figure 4-3. LFSR Module Combiner Function

The shuffle network is represented schematically in Figure 4-4. If the shuffle network contains the ordered pair of boolean values (A, B) and has boolean data input D and selection input S, the S value controls the next state. If S is zero, it outputs A and assumes state (B, D). If S is one, it outputs B and assumes state (D, A).

Figure 4-4. Shuffle Network

In all modes of operation the LFSRs and combining function are initialized by a 56-bit value. The 60 bits of LFSR state use these 56 bits directly plus the complements of four of the bits. The shuffle networks are each initialized with the same constant value. 'Me initialization of the LFSR module is specified in Table 4-2 for a 56-bit initialization value.

Table 4-2. LFSR Module Initialization

This one-bit stream output of the combining fimetion is the only output from the LFSR module. This bit stream provides key material to the block module when the rekey enable signal is active.

4.3 Block Module

The block module consists of two separate "round function" components. One of these components, Round Function K, provides a key stream for the other component, Round Function B. Each of these two components operates on a corresponding set of three 28-bit registers. The structure of the block module is diagrammed in Figure 4-5.

For Round Function K, bit 13 of the Ky register takes its input from the LFSR module output stream when the external rekey enable signal is asserted.

Figure 4-5. Block Module

The S-Boxes for both round functions consist of seven 4 input by 4 output S-boxes. Round function K S-Boxes are labeled SKO through SK6 and round function B S-Boxes are labeled SB0 through SB6. The Ith input to box J is bit 1*7+J from the round x register (Bx or Kx), and output I of box J goes to bit I*7+J of register z of the round function (Bz or Kz). Bit 0 is the least significant bit. The S-box permutations of round functions K and B are specified in Table 4-3.

Table 4-3. Block Module S-Box Values

Both linear transformation K and linear transformation B produce 56 output values. These values are the combined outputs from eight diffusion networks that each produces seven outputs. The diffusion network function is specified in Table 4-4. Each diffusion network has seven data inputs labeled I₀ - I₆, seven outputs O₀ - O₆, plus an additional seven optional key inputs K₀ - K₆.

The diffusion networks of round function K are specified in Table 4-5. Note that none of the round function K diffusion networks have the optional key inputs. The diffusion units of round function B are specified in Table 4-6. Half of these diflusion networks have key inputs that are driven from the Ky register of round function K. A dash in the table indicates that the key input is not present.

Table 4-4. Diffusion Network Logic Function

Table 4-5. K Round Input and Output Mapping

Table 4-6. B Round Input and Output Mapping

4.4 Output Function

The Ky, Kz,, By, and Bz registers drive the final output fimction. Each of the 24 outputs consists of the XOR of nine terms given by the following formula:

(B0*K0) (+) (B1*K1) (+) (B2*K2) (+) (B3*K3) (+) (B4*K4) (+) (B5*K5) (+) (B6*K6) (+) B7 (+) K7

Where "(+)" represents a logical XOR ftinction and "*" represents a logical AND function. Table 4-7 specifies the input values B and K to the 24 logic fimctions.

Table 4-7. Output Function Input and Output Mapping

The HDCP cipher is used in four different ways during operation: hdcpBlockCipher, hdcpStreamCipher, hdcpRekeyCipher, and hdcpRngCipher. No change in HDCP cipher state occurs that is not explicitly identified in the following descriptions.

hdcpBlockCipher

This sequence is used during the first part of authentication to establish the session key, Ks, and during the vertical blanking interval preceding encrypted video frames to establish the frame key, Ki. Table 4-8 and Table 4-9 describes this sequence. The initial value for the B round register is specified with the concatenation operator " || ". For eight-bit values a and b the result of (a || b) is a 16-bit value, with the value a in the most significant eight bits and b in the least significant eight bits.

Table 4-8. hdcpBlockCipher Sequence Steps

Table 4-9. hdcpBlockCipher Initial Values and Outputs

For both the B and K round functions, the x, y, and z registers may be viewed as comprising a single register 84 bits in length, identified by B[83:0] and K(83:0]. The mapping of the x, y, and z registers into the full round register is specified by Table 4-10.

Table 4-10. Round Register Bit Precedence

When fewer than 84 bits of output of a round register are required, the least significant bits are used. When fewer than 84 bits are available for initialization, the least significant bits are filled and the most significant bits are set to zero. For example, the 65-bit concatenation of REPEATER with An will be loaded into the Bx and By registers, plus the least significant nine bits of the Bz register, and the most significant 15 bits of the Bz register are set to zero. Similarly, the 56 bits from the Bx and By registers are saved as Ks or K_i during hdcpBlockCipher.

The origin of the M_i and r_i bits from the output function is specified by Table 4-11.

Table 4-11. hdcpBlockCipher Output Function Bit Map

hdcpStreamCipher

For every video pixel as defined by the T.M.D.S. data enable (DE) signal, hdcpStreamCipher produces 24-bits of output data. Both the LFSR and block modules are clocked. The rekey enable signal is de-asserted.

hdcpRekeyCipher

During horizontal blanking intervals that immediately follow active lines of pixel data, hdcpRekeyCipher moves new key material from the LFSR module into the Block module. No other initialization of the cipher state is made, and no outputs are taken from the cipher during re-keying. Both the LFSR and block modules are clocked 56 times. The rekey enable signal is asserted.

hdcpRngCipher

The HDCP Cipher must be used as defined in Figure 4-6 to produce the value An required for the authentication protocol. This state diagram references video transmitter states from Figure 2-4.

Figure 4-6. hdcpRngCipher State Diagram

Transition Any State:E0. On power up the HDCP Cipher is allowed to free run from its initial state, clocked by the pixel clock.

State E0: Free Run. The HDCP Cipher is clocked, from its current state, using the pixel clock.

Transition E0:E1. An authentication request to the video transmitter causes this transition. Authentication requests are identified by a video transmitter state transition to State:A1.

State E1: Store An. An is taken from the HDCP Cipher output function bits that are ordinarily used to produce M_i. This requires four pixel clocks.

Transition E1:E2. This transition is made immediately upon storage of An.

State E2: Ready. The An value is available for the authentication protocol.

Transition E2:E0. This transition is made if the current authentication fails, as indicated by a video transmitter state transition to State:A0.

Transition E2:E3. A new authentication request causes a new An value to be derived.

Transition E2:E4. The authentication protocol using the derived An is successful, as indicated by a video transmitter state transition to State:A4.

State E3: Derive Next. A new An is derived using the hdcpBlockCipher sequence, using the current values stored in the M_i and K_i registers.

Transition E3:E2. This transition is made immediately upon storage of An.

State E4: Active. The video transmitter is authenticated with a video receiver.

Transition E4:E0. This transition is made whenever the video transmitter becomes unauthenticated or if the video receiver is detached, as sensed by the hot plug pin of the DVI interface.

Transition E4:E3. An authentication request to the video transmitter causes this transition.

5 Renewability

It is contemplated that an authorized participant in the authentication protocol may become compromised so as to expose the secret device keys it possesses for misuse by unauthorized parties. In consideration of this, each video receiver is issued a unique set of secret device keys, matched with a non-secret identifier (the KSV). Through a process defined in the HDCP Adopter's License, the Digital Content Protection LLC may determine that a set of secret device keys has been compromised. If so, it places the corresponding KSVon a revocation list that the video transmitter checks during authentication. Other, authorized, receivers have different sets of secret device keys and, thus, are not affected by this revocation.

The video transmitter is required to manage system renewability messages (SRMs) carrying the KSV revocation list. These messages are delivered with content and must be checked when available. The validity of an SRM is established by verifying the integrity of its signature with the Digital Content Protection LLC public key, which is specified by the Digital Content Protection LLC.

Table 5-1 gives the format of the HDCP SRM. All values are stored in big endian format.

Table 5-1. System Renewability Message Format

The SRM contains the vector revocation list, variable-length list of KSVs that belong to compromised devices. The format of the revocation list is specified in Table 5-2.

Table 5-2. Vector Revocation List Format

Appendix A Test Vectors

Appendix A provides 20 tables of test vectors. They are provided in a separate Zipped file of 20 JPEG images: http://cryptome.org/hdcp-appa.zip (2.6MB)

Appendix B Confidentiality and Integrity of Values

Table B-1 identifies the requirements of confidentiality and integrity for values within the protocol. A confidential value must never be revealed. The integrity of many values in the system is protected by fail-safe mechanisms of the protocol. Values that are not protected in this manner require active measures beyond the protocol to ensure integrity. Such values are noted in Table B-1 as requiring integrity.

____________________

t According to the robustness rules in the HDCP Adopter's License.

* Only within the video transmitter

Table B-1 Confidentiality and Integrity of Values

High-bandwidth Digital Content Protection (HDCP) Specification Changes 0.95 to 1.0

Reference	Change
Throughout	Name changed from DVI-CP to High-bandwidth Digtial Content Protection (HDCP)
Throughout	"Digital Content Protection LLC" replaces "license administrator"
Throughout	Minor clarifications and edits.
Contact information	Mailing address added, phone number correction
Chapter 1	Terminology section added.
Section 4.5	Random number generator hdcpRngCipher is now required
Protocol, HDCP port	Bstatus defined as the collection of topology values and errors (DEPTH, DEV_COUNT, MAX_CASCADE_EXCEEDED, MAX_DEVS_EXCEEDED) and added to the computation of hash value V. These 12 bits have been separated from the remaining bits of status, which remain in the same HDCP port address offset and bit locations, but are renamed Bcaps.
Protocol, Video transmitter state diagram	Changes in the protocol to make it consistent with the state diagram on the matter of when the revocation list is checked for Bksv. In the state diagram it is checked in State A3, but the protocol diagram did not represent that check until after the second part of the protocol, which would be at State A6. The check has been added to the first part of the protocol.
Video transmitter, reciever, and repeater state diagrams	Wording changes reflect the fact that the REPEATER bit must be read much earlier in the protocol in order for the HDCP Cipher to be initialized.
Ri update clarification	New protocol value "ri" defined to clarify the mod 128 update of the existing "Ri". The ri takes a new value every frame, but Ri is only updated every 128th frame (it's assigned the value of ri.) There has been some confusion regarding the mod 128 update of Ri.
Section 2.5	Video repeaters have a new downstream state diagram due to small differences from host transmitter requirements related to hot plug. Also, hot plug signaling requirement on video repeaters is described. The video repeater upstream state diagram is changed to reflect downstream states "F" rather than "A".
Protocol, repeater state diagram	Topology reporting and error handling specified.
Protocol, repeater state diagram	KSV list assembly details specified.
HDCP port	Read timing requirement and recommendation that slave devices not stretch I2C clocks.
Encrypt state diagram	Naming consistency of CTL3. Earlier revision used "control3" in the state diagram and state descriptions.
Section 5	Change from non-volatile SRM storage to delivery with content; the revision field of the SRM is now reserved.
Test vectors	Test vectors added to include all authentication combinations of the four facsimile key sets, for REPEATER equal zero and one.
Confidentiality	Definitions of integrity and confidentiality added. Integrity of Bksv and An in transmitter only. Aksv integrity requirement eliminated.

HDCP 1.0 Erratum

On page 21, the Bcaps register definition is incomplete. Bits 3, 2, 1, and 0 should be specified as reserved, with read value zero.