HDCP 2.3 (authentication protocol)

An independent clean-room HDCP 2.3 authentication-protocol VIP: a transmitter BFM, a separately written receiver/repeater BFM, and a passive protocol checker (“hdcp/, make hdcp_oss, 11/11 checks). It verifies the AKE / locality-check / SKE / repeater sequence, the specification’s timing bounds and the topology limits. SCOPE BOUNDARY, deliberate and stated in the code as well as here: this VIP models MESSAGE SEQUENCING, TIMING and TOPOLOGY only. It contains no HDCP cipher, no device keys and no key-selection-vector data, and it cannot decrypt content or enable its decryption — every cryptographic field is an opaque token. That is also the right engineering scope: the rules worth checking (no SKE before locality passes, no encryption before authentication completes, DEVICE_COUNT/DEPTH limits enforced) are exactly the ones implementations get wrong, and none of them is cryptographic. This catalog has no HDCP DUT, so it is a BFM<->BFM self-check rather than DUT interop. HDCP 1.4’s cipher-based authentication is NOT covered, so the entry claims 2.3 only rather than 2.4/2.3/1.4. Every rule is proven by an INJECTED violation the checker catches (T5-T8), plus a T9 control showing the transmitter REFUSES the illegal topology and the checker then stays silent.

Key Features

• AKE (paired and unpaired), locality check, SKE and repeater-authentication sequencing
• Timing bounds: 20 ms locality check, 200 ms / 1 s AKE_Send_H_prime paired/unpaired
• Repeater topology limits (MAX_DEVS 31, MAX_CASCADE 4) enforced on the OUTCOME, not the intent
• R6: content encryption may never be enabled before authentication completes — the one rule here with a security consequence

Standards & Compliance

Digital Content Protection LLC HDCP 2.3 — authentication protocol (no cipher, no keys)