DisplayPort Intel® FPGA IP User Guide

ID 683273
Date 9/02/2022
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents

5.7. HDCP 2.3 TX Architecture

The HDCP 2.3 transmitter block encrypts video and secondary data, including main stream attributes (MSA), prior to the transmission over serial link that has HDCP 2.3 device connected.
The HDCP 2.3 TX core consists of the following entities:
  • Control and Status Registers Layer
  • Authentication and Cryptographic Layer
  • Video Stream and Secondary Data Layer
Figure 17. Architecture Block Diagram of HDCP 2.3 TX IP

The Nios® II processor typically drives the HDCP 2.3 TX core. The processor implements the authentication protocol. The processor accesses the IP through the Control and Status Port (tx_csr interface) using Avalon® memory-mapped interface.

The HDCP specifications requires the HDCP 2.3 TX core to be programmed with the DCP-issued production key – Global Constant (lc128). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port (tx_hdcp interface). The on-chip memory must store the key data in the arrangement in the table below.

Table 20.  HDCP 2.3 TX Key Port Addressing
Address Content
2'h3 lc128[127:96]
2'h2 lc128[95:64]
2'h1 lc128[63:32]
2'h0 lc128[31:0]

The Video Stream and Secondary Data Layer receives audio and video content over its Video and Secondary Data Input port, and performs the encryption operation. The Video Stream and Secondary Data Layer detects the Encryption Status Signaling (ESS) provided by the DisplayPort TX core to determine when to encrypt frames.

You can use the HDCP 2.3 registers to perform authentication. The HDCP 2.3 TX core supports full handshaking mechanism for authentication. Every issued command should be followed by polling of the assertion of its corresponding status bit before proceeding to issuing the next command. The value of CRYPTO_CMD must be in one-hot encoding format that only one bit can be set at a time.

Table 21.  HDCP 2.3 TX Register Mapping
Address Register R/W Reset Bit Bit Name Description
0x00 CRPYTO_CMD (one-hot) WO 0x00000000 31:11 Reserved Reserved
10 GO_HMAC_M Set to 1 to compute M and verify against M’. Self-cleared upon operation is busy.
9 GO_HMAC_V Set to 1 to compute V and verify against V’. Self-cleared upon operation is busy.
8 GEN_RIV Set to 1 to generate and receive new random riv. Self-cleared upon operation is busy.
7 GEN_EDKEYKS Set to 1 to generate and receive new random Edkey(ks). Self-cleared upon operation is busy.
6 GO_HMAC_L Set to 1 to compute L and verify against L’. Self-cleared upon operation is busy.
5 GEN_RN Set to 1 to generate and receive new random rn. Self-cleared upon operation is busy.
4 GO_HMAC_H Set to 1 to compute H and verify against H’. Self-cleared upon operation is busy.
3 GO_KD Set to 1 to compute kd (dkey0, dkey1). Self-cleared upon operation is busy.
2 GEN_EKPUBKM Set to 1 to generate and receive new random Ekpub(km). Self-cleared upon operation is busy.
1 GO_SIG Set to 1 to verify signature (certrx or SRM). Self-cleared upon operation is busy.
0 GEN_RTX Set to 1 to generate and receive new random rtx. Self-cleared upon operation is busy.
0x01 CRYPTO_MSGDATAIN WO 0x00000000 31:8 Reserved Reserved
7:0 MSGDATAIN

Write messages (in byte) from receiver in burst mode.

  1. Signature verification (certrx): Prior to setting GO_SIG to 1, the following messages had to be written in this sequence:
    1. 384 bytes of signature with least significant byte (lsb) first
    2. 5 bytes of Receiver ID with most significant byte (msb) first
    3. 128 bytes of Receiver Public Key modulus (n) with msb first
    4. 3 bytes of Receiver Public Key exponent (e) with msb first
    5. 2 bytes of Reserved with msb first
  2. Signature verification (SRM): Prior to setting GO_SIG to 1, the following messages had to be written in this sequence:
    1. 384 bytes of signature with lsb first
    2. All preceding fields of the SRM (except signature) with msb first
  3. Master Key encryption: Prior to setting GEN_EKPUBKM to 1, the following messages had to be written in this sequence:
    1. 128 bytes of Receiver Public Key modulus (n) with msb first
    2. 3 bytes of Receiver Public Key exponent (e) with msb first.
  4. Compute kd for HMAC: Prior to setting GO_KD to 1, the following messages had to be written in this sequence:
    1. 8 bytes of rrx with msb first
    2. 3 bytes of RxCaps with msb first
  5. H-H’ comparison: Prior to setting GO_HMAC_H to 1, the following messages had to be written in this sequence:
    1. 32 bytes of H’ with msb first
  6. L-L’ comparison: Prior to setting GO_HMAC_L to 1, the following messages had to be written in this sequence:
    1. 32 bytes of L’ with msb first
  7. V-V’ comparison: Prior to setting GO_HMAC_V to 1, the following messages had to be written in this sequence:
    1. 16 bytes of V’ with msb first
    2. Variable length of ReceiverID_List with msb first
    3. 2 bytes of RxInfo with msb first
    4. 3 bytes of seq_num_V with msb first
  8. M-M’ comparison: Prior to setting GO_HMAC_M to 1, the following messages had to be written in this sequence:
    1. 32 bytes of M’ with msb first
    2. 2 bytes of StreamID_Type with msb first
    3. 3 bytes of seq_num_M with msb first
0x02 CRYPTO_STATUS RO 0x00000000 31 SIG_OK Asserted by the core to indicate signature verification is passed. Poll SIG_DONE until it is set before reading SIG_OK.
30 H_OK Asserted by the core to indicate H-H’ comparison is passed. Poll H_DONE until it is set before reading H_OK.
29 L_OK Asserted by the core to indicate L-L’ comparison is passed. Poll L_DONE until it is set before reading L_OK.
28 V_OK Asserted by the core to indicate V-V’ comparison is passed. Poll V_DONE until it is set before reading V_OK.
27 M_OK Asserted by the core to indicate M-M’ comparison is passed. Poll M_DONE until it is set before reading M_OK.
26:11 Reserved Reserved
10 M_DONE Asserted by the core when M-M’ comparison is done. Self-cleared upon next GO_HMAC_M is set.
9 V_DONE Asserted by the core when V-V’ comparison is done. Self-cleared upon next GO_HMAC_V is set.
8 RIV_DONE Asserted by the core when riv is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_RIV is set.
7 EDKEYKS_DONE Asserted by the core when Edkey(ks) is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_EDKEYKS is set.
6 L_DONE Asserted by the core when L-L’ comparison is done. Self-cleared upon next GO_HMAC_L is set.
5 RN_DONE Asserted by the core when rn is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_RN is set.
4 H_DONE Asserted by the core when H-H’ comparison is done. Self-cleared upon next GO_HMAC_H is set.
3 KD_DONE Asserted by the core when kd is generated. Self-cleared upon next GO_KD is set.
2 EKPUBKM_DONE Asserted by the core when Ekpub(km) is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_EKPUBKM is set.
1 SIG_DONE Asserted by the core when signature verification is done. Self-cleared upon next GO_SIG is set.
0 RTX_DONE Asserted by the core when rtx is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_RTX is set.
0x03 CRYPTO_MSGDATAOUT RO 0x00000000 31:8 Reserved Reserved.
7:0 MSGDATAOUT

Read messages (in byte) from the IP in burst mode.

  1. Rtx generation: When RTX_DONE is set to 1, reading this offset 8 times to obtain rtx with msb first.
  2. Master Key generation: When EKPUBKM_DONE is set to 1, reading this offset 128 times to obtain Ekpub(km) with msb first.
  3. Rn generation: When RN_DONE is set to 1, reading this offset 8 times to obtain rn with msb first.
  4. Session Key generation: When EDKEYKS_DONE is set to 1, reading this offset 16 times to obtain Edkey(ks) with msb first.
  5. Riv generation: When RIV_DONE is set to 1, reading this offset 8 times to obtain riv with msb first.
0x04 VID_CTL RW 0x00000000 31:2 Reserved Reserved.
1 TYPE
  • 0: Type 0 content stream
  • 1: Type 1 content stream
0 HDCP_ENABLE Set to 1 to enable HDCP 2.3 encryption. Set to 0 if HDCP 2.3 encryption is not required especially when it is in unauthenticated state.