HDCP完整握手流程：AKE、SRM、Repeater认证阶段解析
好，我们直接进入HDCP握手最核心的部分。很多工程师调不通HDCP，就是因为对整个握手的"三步走"没有底。说白了，AKE（Authentication and Key Exchange）、SRM（System Renewability Message）和Repeater认证，这三步必须串起来，少一步都不行。
我个人习惯把这三步比作"查身份"、"翻黑名单"、"拉群聊"。你想想看，是不是这个理？
Phase 1: AKE —— 密钥交换与身份验证
AKE是所有的基础。我见过不少工程师一上来就查Repeater的问题，结果发现是AKE阶段就没走通。为什么要先做AKE？因为只有通过这个阶段，通信双方才能建立起共享的加密密钥。
具体流程是这样的：
- 发起认证请求：HDCP上游（比如电视）通过AUX通道发送AKE_Init，带上自己的AKSV。
- 交换公钥：下游设备回复AKE_Send_Cert，这包含了它的公钥证书和RSA加密的公钥。
- 验证Master Key：上游用私钥解密，计算出共享的Master Key。
- HMAC验证：双方交换HMAC-SHA256校验值，确认密钥没有被篡改。
我的调试习惯：在实际调测中，我强烈建议你在HDCP上游做完AKE初始化之后，马上抓一把AUX总线。如果看到AKE_Send_Cert迟迟不返回，大概率是下游设备证书解析失败或硬件链路不稳定。
这里有个关键的参数——Master Key。它是后续所有加密的基础。我记得有一次调试，发现Master Key计算出来全是0x00，一查是公钥传递时CRC校验没通过。
Phase 2: SRM —— 吊销列表验证
SRM是HDCP的安全铁闸。为什么会搞这么个东西？就是为了防止被破解的设备继续使用。
SRM本质上是一个明文列表，记录了所有被吊销的设备KSV。流程分两步：
- 加载SRM：上游设备（source）从本地或系统层获取最新的SRM数据，通过AKE_Send_SRM推送给下游。
- KSV比对：下游设备（sink/repeater）把自己的KSV与SRM列表中的吊销KSV进行匹配。
⚠ 曾经踩过的坑：SRM的版本号非常容易被忽略。我曾经遇到过一台播放器，它内置的SRM是2018年的旧版本，而新发布的中继器KSV恰好就在2022年的吊销列表里。因为版本太旧没有加载到，导致盗版设备照样能解锁HDCP——这在合规审查时属于致命缺陷。
说白了，SRM如果没生效，你的HDCP就是假加密。调测时要特别注意：SRM是否真的被写入了HDCP芯片的寄存器。
Phase 3: Repeater —— 拓扑广播与深度验证
这一步只针对中继器（Repeater）设备，比如回音壁、HDMI分配器。如果只是直连的source→sink，不需要走这一步。
当链路中存在Repeater时，它必须将自己下游所有连接设备的KSV、深度信息、状态广播给上游。上流设备会逐级验证整个过程：
| 步骤 | 动作 | 关键数据 |
|---|---|---|
| 第1步 | Repeater 发送AKE_Transmitter_Info | 下游设备数量、拓扑深度 |
| 第2步 | Repeater 发送AKE_Receiver_Info_List | 所有下游KSV的完整列表 |
| 第3步 | 上游计算V_prime并与V值比对 | HMAC值，验证列表真实性 |
| 第4步 | Repeater 读取AKE_Stream_ID_Type | 流标识与加密策略 |
这里有个硬约束：HDCP 2.2 要求 Repeater 的拓扑深度不能超过 4 级。超过 4 级直接握手失败。你想想看，如果链路上串了电视、回音壁、游戏机，一不小心就超标了。
深度验证的核心是V_prime。我把它叫做"拓扑指纹"。意思是说，上游把收到的KSV列表重新排序、哈希计算，然后和自己缓存的数据比较。如果对不上，那就是有人篡改了列表——立刻断开连接。
三个阶段的依赖关系
再强调一遍，这三个阶段是强串行的：
- AKE失败 → 根本到不了SRM阶段。你会看到下游不断重试AKE_Init，AUX上全是重复帧。
- SRM失败 → HDCP会断开，但断开前可能会闪一下画面。因为加密已经建立，但安全性检查没通过。
- Repeater失败 → 只影响中继拓扑。如果是直连设备，这一阶段会被跳过，别傻等着。
一个现场经验：我经常在示波器上同时抓AUX数据和HDCP中断引脚。AKE完成后会触发一个中断，SRM通过后又有中断。通过中断时间点，能快速定位卡在哪一步。这个习惯帮我省了大量排查时间，你也可以试试。
AKE初始化代码要点
最后，贴一段实际调试用的AKE初始化代码片段。这不是完整的生产代码，而是用来验证AUX通道是否通的关键步骤：
// 伪代码示例：AKE阶段关键寄存器操作
uint8_t rx_buf[256];
hdcp_tx_write(HDCP_AKSV_REG, source_ksv, 5);
// 启动AKE
hdcp_tx_write(HDCP_CTRL_REG, 0x01, 1);
// 等待接收证书（建议超时100ms）
int ret = wait_for_interrupt(IRQ_AKE_SEND_CERT, 100);
if (ret != SUCCESS) {
// 这里就是问题点：下游没回应
log_error("AKE Send Cert timeout");
return HDCP_ERROR_AKE_TIMEOUT;
}
// 读出下游公钥，并进行Master Key计算
hdcp_rx_read(HDCP_CERT_REG, rx_buf, 528);
// 验证证书签名...
这段代码你可以在任何HDCP 2.2的sink端芯片上跑通。关键是那个超时值——我建议设成100ms，太长会影响用户体验，太短又容易误判。
嗯，AKE、SRM、Repeater这三步就这么个逻辑结构。每一条链路、每一个中继器，都要老老实实把这三步走完。我见过太多"握手失败"的案例，最后发现是SRM根本没加载——你说这冤不冤？