1. 别急着抓报文：HDCP 1.4 保护的到底是哪一刀

HDCP1.4 这套东西，很多做硬件的同行的认知停留在“插上就黑屏，拔了就好”这个层面。真正被问到“它怎么认证的、密钥怎么来的、为什么接个功放就挂”的时候，能完整讲下来的人不多。我在几个涉及 HDMI 输出的项目里被这件事反复折磨过，最典型的一次是某块自研板卡接某品牌显示器，冷启动十次有三四次黑屏，热插拔一下又好了，示波器上看 TMDS 波形完好，最后挖下去是认证阶段的一次超时重试把链路拖进了死循环。从这个坑开始，我把 HDCP 1.4 的协议流程从头到尾啃了一遍，才发现它的设计其实相当精巧，问题基本都出在“实现方对协议时序的理解不一致”上。

HDCP 全称是高带宽数字内容保护，它要解决的问题很具体：在发送端和显示端之间那段未压缩的数字音视频链路上，数据是明文的，任何人拿个逻辑分析仪挂在中间就能把原始像素扒下来。这段链路的物理范围可能只有半米，也可能经过墙内的长线、经过一台分配器、经过一台功放，中间任何一处都是一个天然的窃听点。HDCP 1.4 就是在这一段上建立一层加密通道，让链路上跑的是密文，同时通过一套认证机制确保“对面那个设备是自己人”。

适合读这篇的人我觉得有三类：做 HDMI 发送/接收 IP 或驱动的固件工程师，需要知道每个寄存器和每个状态位的含义；做音视频系统集成的工程人员，现场遇到黑屏闪烁要能快速判断是线材、EDID 还是认证问题；还有做产品测试和认证的同行，需要理解测试项背后的协议动作。下面的内容只讲协议行为和排查思路，不涉及任何绕过手段，因为绕过这件事既不合规也没有工程价值——你要的是链路稳定，不是破解。

1.1 三种角色与三段链路，先建立一张地图

HDCP 1.4 的拓扑里只有三种角色。发送端是内容的源头，比如机顶盒、播放器、显卡输出；接收端是最终显示设备，比如显示器、投影、电视；中继器是夹在中间那种“有进有出”的设备，功放、分配器、矩阵切换器、采集卡的上游口都属于这一类。这个三分法看着简单，但它决定了后面所有协议分支：发送端和接收端之间是一次认证，发送端和中继器之间是一次认证，中继器再对它的下游每一个设备各做一次认证，形成一棵树。

链路这一段也有讲究。物理层上，HDMI 用的是 TMDS 差分对，DVI 用的是 TMDS 的简化版，DisplayPort 用的是主链路加 AUX 通道。HDCP 1.4 名字里的“1.4”主要对应 HDMI 1.4 那一代的能力，但协议本身是跨物理层复用的：认证报文走的是 DDC（I2C）通道或者 DP 的 AUX 通道，加密作用于主数据通道。所以你在 HDMI 上抓包，看的是 DDC 上 0x3A 这个地址的一组寄存器读写；在 DP 上，看的是 AUX 上的 DPCD 偏移。同一条协议，两套搬运方式，这是很多人在跨接口移植时踩的第一个坑。

提示：DDC 上的 HDCP 从机地址是 0x3A（7 位地址 0x3A，写 0x74、读 0x75），和 EDID 的 0x50 是两个不同的从机。抓包时如果只挂了 0x50 的解析，会完全看不到认证过程。

还有一个容易混淆的点：HDCP 保护的是“链路”，不是“内容文件”。它跟存储加密、DRM 是两回事。片源在硬盘上是不是加密的，HDCP 不管；它只管从发送端芯片出来的那一刻到接收端芯片进去的那一刻。这就解释了为什么有些播放器在检测到下游不支持时会主动把分辨率降到 480p 甚至输出雪花——它是在处理“不能安全传输”的分支，而不是内容坏了。

1.2 它刻意不解决“最终端被录屏”

刚接触这套机制的人经常问：既然加密了，为什么还是能被录屏？答案是设计目标本来就不同。HDCP 的威胁模型假设接收端设备是可信的，它防的是链路中间被抽头，不防终端设备本身作恶。如果一台显示设备的厂商自己在固件里把解密后的像素搬走，协议层面是拦不住的，能做的只有事后通过撤销机制把这个设备拉黑。

这个假设带来一个很实际的工程后果：HDCP 的强度取决于接收端芯片里密钥的保存质量。密钥一旦泄露，规范方只能把对应的密钥集合放进撤销列表，也就是 SRM（System Renewability Message）。SRM 是一段带签名和版本号的数据，发送端在认证时会检查下游设备的 KSV 是否在列表里。这就意味着，同一台设备在旧固件上能正常工作，升级了 SRM 之后可能突然不认了——现场遇到“昨天还好今天黑屏”的情况，先怀疑这个方向。

我在一个项目里遇到过类似的场景：某批次的分配器在出厂固件里 KSV 烧录有重复，导致多台设备拿到同一组密钥。这个问题在单机测试时完全看不出来，一上多级级联，发送端读到的下游 KSV 列表里出现重复项，直接判定拓扑异常，整条链路降级。这类问题查起来非常费劲，因为现象是“某些组合能亮、某些组合不亮”，很容易被误判为线材兼容性。

1.3 1.4 这个版本号，改的其实不是密码学骨架

很多人以为版本号跳了，加密算法也换了，实际上 HDCP 1.x 系列从 1.0 到 1.4，密码学骨架基本没动。1.4 的主要变化集中在接口能力扩展上：HDMI 1.4 引入了以太网通道和音频回传通道，引入了新的 3D 帧封装格式，这些新增的数据通路需要在保护范围内，所以协议层面做了对应补充。换句话说，1.4 是“把同一套锁装到了新开的几扇门上”，不是换了一把锁。

这一点对排查很重要。如果你手上是一台只支持 1.3 的老设备和一台 1.4 的新设备对接，绝大多数情况下是能通的，因为核心认证流程完全一致；真正出问题的地方往往在帧格式和时钟结构上，比如 3D 帧的帧计数器怎么递增、高帧率模式下每帧的加密周期怎么对齐。这类问题表现出来的现象很怪：2D 内容正常，一播 3D 就闪；或者 60Hz 正常，切到 120Hz 就出彩色噪点。看到这种“跟格式强相关、跟设备无关”的现象，基本可以锁定是帧级密钥调度没对上，而不是认证没过。

2. 一次认证的完整回放：Aksv、An、R0 各自在干什么

要把认证讲清楚，最好的办法是按报文顺序走一遍。整个过程本质上是一次挑战应答：双方各自证明自己拥有一组出厂密钥，但不把密钥本身传出去。这跟很多认证协议的思路一致，HDCP 的特别之处在于它用了一个非常巧妙的数学构造，让两端能各自算出同一个中间值而不用交换它。这个构造我放到第 3 节细讲，这一节先把报文顺序和每个字段的作用捋顺。

整条流程大概是这样：发送端先读下游的 KSV，做合法性检查和撤销检查；然后生成一个 64 位的随机数 An，连同自己的 KSV 一起发给下游；双方各自计算出一个 56 位的中间密钥；发送端用这个中间密钥对一个特定值做加密得到 R0，下游用自己算出的中间密钥对同样的值加密得到 R0'，回传给发送端；两边一致，认证通过，之后才开始传加密数据。整个过程在 DDC 上是十几个寄存器读写，正常情况下几十毫秒内完成。

2.1 第一步永远是读 Bksv，而且必须校验

发送端上电或者检测到 HPD 之后，第一件事是通过 DDC 读取下游设备的 Bksv，这是一个 40 位的值，存在下游的只读寄存器里。这个值的名字叫“密钥选择向量”，从名字就能看出来，它不参与运算本身，而是用来选择运算要用哪些密钥。这个设计是整个协议的关键，后面会展开。

读回来之后有两件事必须做。第一件是格式校验：HDCP 1.x 后期版本明确要求一个合法的 KSV 必须包含 20 个 1 和 20 个 0。这条规则看着莫名其妙，其实是为了防止厂商随便填一个全 0 或者全 1 的值导致密钥选择退化成固定模式。第二件是撤销校验：拿这个 KSV 去比对当前的 SRM 列表，命中就拒绝认证。

这里有个实现层面的坑。我在某块桥接芯片的参考代码里看到，它把 KSV 校验放在了读取成功之后、超时重试之前，也就是说如果第一次读失败，重试时不会重新校验。结果就是下游设备在 HPD 抖动期间返回了一个半截的数据，校验被跳过，后续用错误的 KSV 算密钥，认证必然失败，而且失败后没有明确错误码，只表现为超时。这种问题看日志是看不出来的，只能抓总线。所以我的建议是：每次重试都要走完整校验流程，不要为了省几个周期把校验前置。

2.2 An 是随机的，但“随机”这件事本身有讲究

An 是一个 64 位的随机数，由发送端生成后写入下游的寄存器。它的作用是把每次认证区分开，防止重放。如果 An 固定，攻击者录下一次完整的认证过程就能反复回放；每次换一个随机数，回放就没用了。

这里有个细节值得说：An 的随机性质量直接影响认证的唯一性，但规范并没有规定必须用硬件随机数发生器。很多低成本实现用的是伪随机，种子来自上电计数器或者时钟抖动。这在单机场景下没问题，在多机密集部署的场景里就可能出问题——我见过一个机房里几十台设备同时上电，随机种子撞车，导致某些组合的认证数据完全一致。虽然这不影响功能，但如果上层有基于认证过程的统计或者日志去重逻辑，就会看到莫名其妙的重复记录。稳妥做法是用芯片自带的 TRNG，没有的话至少混入足够熵源的时钟抖动。

An 写下去之后，发送端会把自己的 Aksv 也写过去。注意顺序，先 An 后 Aksv，或者说至少要在下游开始计算之前把两个值都准备好。有些实现是分两次写，有些是打包写，协议上没强制，但下游收到 Aksv 之后就会立刻开始算，所以如果 An 还没稳定就写 Aksv，算出来的结果必然是错的。

2.3 R0 与 R0'：用一个 16 位值证明两边算的一样

双方各自算出 56 位的中间密钥之后，还需要一个可验证的凭据。做法是用这个中间密钥对某个固定输入做一次加密，得到一个 16 位的 R0。发送端自己算一遍，下游算完回传 R0'，两边比对。一致就说明中间密钥一致，链路可信。

这个 16 位值的强度经常被质疑：16 位只有六万多种可能，理论上可以暴力试。但要注意，攻击者没有中间密钥，也就无法构造出正确的 R0'；他能做的只是瞎猜，而每次失败都会触发重试退避，实际可行性很低。更重要的是，即便猜中了一次认证，后续的数据流仍然是加密的，没有中间密钥照样解不开。所以这个 16 位不是用来抗暴力破解的，它只是一个低成本的一致性校验。

从实现角度看，这里最容易出问题的是时序。发送端写入 Aksv 之后，下游需要一定时间完成密钥计算和 R0' 的生成，这段时间取决于下游芯片的算力，老设备可能要几十毫秒。发送端如果在固定延时后就去读 R0'，读到的可能是上一次的残留值。规范的写法是轮询状态位，但很多实现图省事用了固定延时。我一般建议把超时窗口设得宽松一些，按百毫秒级判超时，读不到就退避重试，重试间隔按秒级，避免在 HPD 抖动期间疯狂重试把总线占满。

2.4 中继器分支：多出来的两件事

如果下游返回的 Bstatus 表明自己是个中继器，认证流程就要多走两步。第一步是读取 KSV List，也就是这个中继器所有下游设备的 KSV 清单，发送端要逐个校验合法性和撤销状态；第二步是检查拓扑是否超限，包括设备总数和级联深度。

这两步是现场问题的高发区。KSV List 是一个变长列表，长度由 Bstatus 里的设备计数字段决定，每个设备占 5 字节。读取的时候要一次性读完，中间不能被打断，否则会读到拼接错误的数据。我在一台矩阵切换器上遇到过这个问题：它在读取过程中被上游的 HPD 抖动打断，返回的列表前半段是旧数据后半段是新数据，发送端校验时发现某个 KSV 的 1 的个数不对，直接拒绝。现象就是“切换信号源之后必黑屏一次，再切一次才好”。

注意：中继器在拓扑变化时必须主动把 HPD 拉低再拉高，通知上游重新认证。如果它只是内部切换而不动 HPD，上游会一直用旧的拓扑信息，等到下一次周期性检查才发现不一致，中间这段时间画面是能出的但状态是错的，一旦有内容触发重新认证就会闪断。

3. 40×40 密钥矩阵：两端凭什么算出同一个数

这是整个协议里最漂亮的部分，理解了它，前面那些字段的意义就全通了。核心问题是这样：发送端和接收端各自持有一部分秘密，不能交换，但需要协商出一个共同的密钥。HDCP 用的不是 Diffie-Hellman 那种指数运算，而是一个基于密钥矩阵的构造，思路非常直观。

想象一个 40 行 40 列的表格，每个格子里放一个 56 位的随机数，整张表有 1600 个密钥。设备出厂时，每台设备分到一行，也就是 40 个密钥，同时还有一个 40 位的选择向量，就是前面说的 KSV。关键在于，这一行密钥和这个选择向量是配对的，而且每台设备拿到的是不同的行。

3.1 出厂烧的到底是什么

具体来说，一台设备出厂时会烧进去两样东西：40 个 56 位的私钥，以及一个 40 位的 KSV。私钥就是矩阵里的某一行，KSV 则是一个有 20 个 1、20 个 0 的向量，它标记了这台设备“占用了哪一行”。规范要求矩阵的构造保证任意两台设备的行不重复，KSV 也不重复。

这就解释了为什么 KSV 的格式校验那么严格。如果某台设备的 KSV 里 1 的个数不是 20，可能是烧录出错，也可能是厂商自己造的假 KSV；这两种情况都会破坏后续运算的对称性，必须拒绝。

烧录环节是我见过问题最多的环节之一。有些小厂的产线为了省事，用同一份固件批量烧录，结果一批设备共享同一组密钥。单机测试完全正常，一旦多台同时接入同一棵树，发送端读到的 KSV List 里出现重复，就会判定拓扑异常。更麻烦的是，这种问题在保修期内不会暴露，等到用户搭了多设备系统才炸。

3.2 按位选择求和的对称性推导

真正的运算只有一步：按位选择求和。发送端拿到下游的 Bksv 之后，看这个向量的每一位。第 i 位是 1，就把自己第 i 个私钥加进来；是 0 就跳过。40 位全部看完，把选中的那些 56 位私钥累加起来，得到一个 56 位的值，记作 Km。

下游做同样的事：拿发送端的 Aksv，按位选择自己那一行的私钥，累加，得到 Km'。

现在关键来了：为什么 Km 一定等于 Km'？

想清楚这件事，只要注意到两个事实。第一，两台设备的 KSV 各有 20 个 1，也就是说各自会选中 20 个私钥。第二，发送端选的是“自己这一行里、对应 Bksv 为 1 的那些列”，下游选的是“自己这一行里、对应 Aksv 为 1 的那些列”。而矩阵的构造保证了一个性质：这两个选择集合在矩阵上指向的是同一批格子，只是从不同的行去看。

用个类比：把矩阵想成一张城市地图，行是街道，列是门牌。发送端住在 A 街，他按照 B 街住户给的名单去自己街上找对应门牌的 20 户人家；下游住在 B 街，他按照 A 街给的名单去自己街上找对应门牌的 20 户。因为名单是互相给的，且行列对称，最终两边统计的其实是同一个“街区组合”的总和，只是视角不同。这就是为什么两边的和必然相等。

这个构造的巧妙之处在于，即使有人在链路上监听了 Aksv 和 Bksv（这两个值确实是明文传输的），他也无法还原出 Km。因为他不知道任何一行的私钥内容。他唯一能做的是找一台合法设备，读它的 KSV——但这台设备的私钥他也拿不到。整个安全性建立在“私钥不可读”这个物理假设上。

3.3 从 Km 到 Ks：56 位是个历史包袱

算出 Km 之后还不能直接用，需要派生出会话密钥 Ks。这一步的设计受限于当年的算力和硅片面积，Km 只有 56 位，直接当密钥用强度偏低，所以规范里做了一层扩展，把 56 位扩展成更长的会话密钥，用于后续的帧密钥生成。

56 位这个长度在今天看确实不够，但在协议设计的年代，它是一个工程折中：一方面 40 个 56 位私钥的存储量对当年的芯片来说已经不小（1600 个密钥的矩阵分摊到每台设备是 40 个，约 280 字节），另一方面运算要在一个像素时钟周期内完成的部分不能太复杂，否则硅面积吃不消。所以 HDCP 1.x 整体的密码学强度是被硬件成本压着走的。

这个历史包袱带来的实际影响是：HDCP 1.x 在面对有算力的攻击者时，理论上不如后来的 2.x 版本稳。但对我们做工程的来说，这个层面的安全性不是关注重点，我们关心的是兼容性和稳定性。KM 的计算量很小，一次认证在微秒级就能完成，这是它能在低成本设备上普及的原因。

3.4 撤销机制：SRM 一升级，老设备就下岗

前面提到 SRM，这里补完。SRM 是一段带数字签名的数据，里面列着一批被撤销的 KSV。发送端在认证前会检查下游的 KSV 是否在列表里，如果命中，认证直接失败，链路不输出内容。

SRM 的版本号是单调递增的，发送端只接受比自己当前版本更新的 SRM（通过下游设备上报）。这个设计是为了防止降级攻击：如果有人拿一份旧的、不含某设备撤销记录的 SRM 去欺骗发送端，版本号检查会拦住。

现场遇到“设备突然不认了”，除了线材和固件，一定要查 SRM 版本。我遇到过一次：某批设备在新固件里更新了 SRM，把一批老型号的 KSV 拉黑了，结果用户的老功放接上去直接黑屏。这种问题在协议层面完全合理，但对用户来说就是“升级完就不能用了”，沟通成本极高。做产品的时候，如果涉及 SRM 更新，一定要提前评估下游设备的兼容性，别一刀切。

4. 帧级与像素级加密：Kj、Ri、Ci 三者怎么咬合

认证通过只是拿到了钥匙，真正的加密从这一刻开始。HDCP 1.4 的数据加密是两级的：每帧生成一个帧密钥，帧内每个像素再用帧密钥和像素位置生成一段密钥流。这个结构是为了平衡安全性和实现成本——如果每个像素都用独立密钥，密钥分发开销受不了；如果整段视频用一个密钥，又太脆弱。

4.1 为什么是“每帧换一次”而不是“每像素换一次”

每帧换密钥的好处很实际。帧率是 24 到 120 帧每秒，换密钥的频率不高，硬件上只需要在帧消隐期做一次计算，不影响像素通路的吞吐。同时，即使某一帧的密钥被攻破，影响范围也只是一帧，不会扩散到整段视频。

帧密钥的生成用到了会话密钥 Ks 和帧计数器 Ri。Ri 是一个每帧递增的值，规范里定义了它的位宽和翻转规则。这里的关键是收发两端的 Ri 必须严格同步，任何一帧的错位都会导致后续所有帧解不出来。所以 Ri 不是简单加一，而是要跟帧同步信号绑定。我在一个项目里见过因为场同步信号的极性配反，导致接收端的 Ri 比发送端多走了一帧，现象是画面整体偏移一行并且带彩色噪点——看着像时序问题，实际是密钥错位。

4.2 像素计数器 Ci 与每帧的重排动作

帧内每个像素有自己的计数器 Ci，它标记了这个像素在帧内的位置。加密的时候，用帧密钥对 Ci 做运算，得到一段密钥流，和像素值异或。这样每个像素用的密钥流都不同，即使画面大面积纯色，密文也不会呈现规律。

这里有个细节容易被忽略：规范里要求每帧对 Ci 的处理做一次重排，重排的方式由帧密钥的某些位决定。这个设计的目的是打乱像素顺序与密钥流的对应关系，避免固定模式被利用。实现上，这意味着加密引擎不能简单地按扫描顺序处理像素，而要维护一个重排后的索引表。

这个重排对硬件实现的影响不小。如果你的加密模块是流水线结构，重排会导致地址跳变，需要额外的缓存来吸收。低成本方案里经常看到为了省缓存而简化重排逻辑，结果就是某些特定分辨率下画面出现细密的条纹噪点。这类问题特别难查，因为它只在特定分辨率和特定帧内容下出现。

4.3 硬件实现的真实难点在时序，不在算法

算法本身不复杂，难的是让它跟像素时钟严格同步。一条 4K60 的链路，像素时钟几百兆，每个时钟周期都要完成一次密钥流生成和异或，延迟必须固定且可预测。如果加密模块引入了不确定的延迟，接收端的解密就会错位，表现为画面撕裂或者整屏花。

我总结下来，这块最容易翻车的地方有三个。第一是行首延迟，加密模块处理第一个像素的时间比后续像素长，如果没做预填充，行首几个像素会解错。第二是消隐期处理，消隐期间没有有效像素，但计数器要不要走？规范里对这点有明确规定，实现错了会导致每行的密钥流起点偏移。第三是时钟域 crossing，加密模块往往跑在像素时钟域，而控制逻辑在另一个域，跨域握手没做好就会出现偶发的密钥不同步。

提示：调试这类问题，最有效的手段不是看画面，而是在发送端和接收端各挂一个逻辑分析仪，抓同一帧的前几个像素，比对两边的 Ci 序列。序列一对，问题立刻定位。

4.4 音频数据岛也在保护范围内

HDMI 链路上除了视频像素，还有音频数据岛和辅助数据。在 HDCP 生效的情况下，这些数据同样处于保护范围。实现上，音频数据岛通常复用同一套密钥流调度，但打包方式和视频不同，需要单独处理边界对齐。

这块的问题一般表现为“画面正常但没声音”或者“声音断续”。我遇到过一次，某方案的音频包在加密时没有正确处理包尾的填充字节，导致接收端解出来的音频帧长度字段错误，音频解码器直接丢弃。排查的时候先看视频是否正常——视频正常说明认证和帧密钥都没问题，问题一定在音频通路的包处理上。

5. 中继器拓扑：127 和 7 这两个数字怎么在现场爆炸

中继器的存在让协议复杂度上了一个台阶。发送端看到的不再是单一设备，而是一棵树，它需要知道这棵树的结构、每个节点是否合法、总规模有没有超限。规范给了两个硬性上限：下游设备总数 127，级联深度 7 层。这两个数字不是随便定的，127 对应 8 位计数字段，7 对应 3 位深度字段。

5.1 Bstatus 的字段拆解

Bstatus 是一个 16 位的状态字，中继器通过它向上游汇报自己的拓扑情况。字段大致是这样分配的：最高位标识自己是不是中继器，接下来的位标识是否超出了设备数上限、是否超出了级联深度，再往下 3 位是当前的最大深度，最低 8 位是下游设备总数。

这张表看着简单，实际用起来坑不少。最典型的是“超限标志位和计数字段不一致”：有些中继器在超限时把计数截断到 127 但仍然返回，上游看到计数没超但标志位超了，处理逻辑就分裂了。规范的意图是超限时直接拒绝认证，但实现方经常抱着“尽量让用户能看”的心态放行，结果就是部分设备能出画面部分不能。

5.2 每次热插拔都是一次全树重建

中继器有一个强制行为：只要下游拓扑发生变化（插拔设备、切换输入源），就必须把上游的 HPD 拉低再拉高，让发送端重新走一遍完整认证。这个动作的代价很大，因为整棵树都要重新认证一遍，耗时可能到几百毫秒甚至秒级。

现场很多“切换信号源黑屏几秒”的现象就是这么来的，属于正常行为。真正的问题在于那些没触发 HPD的拓扑变化。比如某些矩阵切换器内部切换时只切了数据通路，没有动 HPD，上游以为树没变，继续用旧的 KSV List 和旧密钥，但实际下游已经换了设备。这种状态下画面可能还能出（因为加密通道还在），但一旦有内容触发重新认证就会立刻断，表现为“看十分钟突然黑一下”。

我处理过一个案例：某会议室的系统，用一台分配器带四台投影，正常使用没问题，但每次有人插拔其中一台的线，其他三台会同时黑一下。这就是 HPD 联动导致的，属于设计上的取舍。如果分配器能做端口级隔离，只让受影响的分支重新认证，体验会好很多，但那需要更复杂的硬件支持。

5.3 分配器、矩阵、功放的典型翻车点

按我的经验，现场问题里中继器占的比例远高于直连。原因很直接：中继器要同时扮演接收端和发送端两个角色，任何一侧的实现有偏差都会暴露。

分配器最常见的问题是电源和 HPD 时序。便宜的分路器上电慢，上游已经发完 HPD 开始认证了，它还没准备好，返回的 Bksv 是无效值。表现为“冷启动必黑屏一次，重新插拔就好”。矩阵切换器的问题集中在KSV List 的拼接，切换瞬间读到半新半旧的数据。功放的问题多在音频回传通道，因为 1.4 引入了新的通道，很多老功放对这部分处理不完整，导致视频正常音频不通，或者反过来，音频通了视频闪。

6. 版本协商：2.x 优先、1.4 兜底的现实逻辑

HDCP 1.4 在今天的位置有点尴尬：4K 及以上的内容基本都要求 2.x，1.4 成了兜底选项。但只要还在做兼容性产品，这套逻辑就必须搞明白，因为降级链条断在哪一环直接决定了用户体验。

6.1 谁来决定用哪个版本

决定权在发送端。发送端会先读下游的能力信息（在 HDMI 上是通过 EDID 里的相关字段，在 DP 上是通过 DPCD），如果下游支持 2.x，就尝试 2.x 认证；失败或者不支持，回退到 1.4。这个顺序是规范建议的，不是强制的，所以不同厂商的行为可能有差异。

麻烦在于“尝试”这个动作本身有成本。2.x 认证失败会消耗时间，回退到 1.4 又要重新走一遍流程，如果中间还有 HPD 抖动，整个链路建立时间可能拉到好几秒。用户看到的就是“开机黑屏很久才出画面”。

6.2 降级失败最常见的三种表现

第一种是卡在 2.x 不降级。有些发送端在 2.x 认证失败后不主动回退，直接报错。这种情况通常是下游设备上报能力时出了错，说自己支持但实际不支持。排查方法是把下游换成一个明确只支持 1.x 的设备，如果正常，就是能力上报的问题。

第二种是降级后不重新读 EDID。1.x 和 2.x 支持的分辨率范围可能不同，降级后如果不重新协商格式，会出现“认证过了但格式不支持”的黑屏。

第三种是反复横跳。发送端在 2.x 和 1.x 之间来回试，每次失败都触发重试，形成循环。这种现象在日志里表现为认证状态位快速翻转，用示波器看 HPD 线会发现周期性脉冲。这种问题必须从发送端固件解决，加一个“一旦降级就锁定”的逻辑。

6.3 和 EDID、HPD 的交互顺序不能乱

这三者的顺序是有讲究的：HPD 拉高，发送端读 EDID，根据 EDID 决定尝试哪个版本的 HDCP，然后开始认证。任何一个环节提前或延后都会出问题。

我见过最离谱的一个案例是某方案在 HPD 拉高之前就去读 EDID 和做认证，靠的是内部固定延时。大部分设备能撑住，个别启动慢的显示器就挂。这种“靠延时赌运气”的实现是小厂方案的典型特征，量产的时候一定要用多种设备做交叉测试，尤其是老设备和低价设备。

7. 现场定位：把“偶发黑屏”拆成几个可观测的步骤

说了这么多协议，最终还是要落到排查上。我的习惯是先把现象分类，再决定抓什么数据，因为 HDCP 问题的现象和原因之间的映射其实相当有规律。

7.1 先按现象分四类

全黑但设备有信号：显示器识别到了输入，分辨率信息也对，但画面全黑。这种情况九成是认证没过，发送端按规范要求不输出内容。查认证状态位和错误码。

周期性闪断：画面正常但每隔几秒到几十秒黑一下。典型原因是认证重试、SRM 检查失败后重建、或者中继器拓扑反复变化。抓 HPD 和 DDC 看有没有周期性动作。

彩色噪点或条纹：画面能出但带规律性噪点。这不是认证问题，是加解密不同步，重点查帧计数器、像素计数器和重排逻辑。

分辨率掉到很低：发送端主动降级。这是保护机制在起作用，说明它判断下游不可信，查认证结果和 SRM。

7.2 抓总线的正确姿势

DDC 是 I2C，用普通的逻辑分析仪就能抓。关键是把 SCL、SDA 和 HPD 三根线一起抓，因为时序关系比数据本身更重要。解码的时候按 0x3A 从机地址过滤，能看到所有 HDCP 寄存器读写。

看数据的时候重点看三件事：Aksv 写入和 R0' 读取之间的时间间隔，这个间隔反映了下游的计算能力；R0' 的返回值是否稳定，如果同一个 An 下多次读取结果不同，说明下游计算有问题；KSV List 的读取是否完整，有没有被中途打断。

7.3 一张常见失败原因的对照表

7.4 几条我踩过坑之后的经验

第一条，不要相信“换个线就好了”。线材问题确实存在，但 HDCP 认证失败和线材问题的现象很像，都是黑屏。区别在于线材问题通常伴随 TMDS 时钟不稳或者误码率上升，用示波器看眼图能区分。如果眼图很好但认证不过，别在线材上浪费时间。

第二条，把认证状态做成可观测的。我在自己的板子上加了一个调试接口，能实时读出当前的认证状态、重试次数、最后一次失败的原因码。这个投入在后面排查时省下的时间远超成本。产品化的时候可以不做成对外接口，但内部调试版本一定要有。

第三条，多设备交叉测试要覆盖“最差组合”。不是测十台同型号设备，而是测一台最新款、一台五年前的老款、一台便宜的杂牌、一台带中继功能的。这四台能过，基本就没大问题了。

第四条，关注上电顺序。很多偶发问题的根源是设备上电的先后顺序不同。测试的时候刻意打乱上电顺序，先开显示再开源、先开源再开显示、同时开，三种都跑一遍。

最后分享一个我自己的做法：在项目初期就把 HDCP 认证的完整流程画成一张状态机图贴在工位上，每个状态标注对应的寄存器和预期值。调试的时候对着图走，比翻规范快得多，而且能很快发现“某个状态根本没进去”这种问题——很多时候不是认证失败，是流程压根没走到那一步。这套东西后续换成 2.x 的时候还能复用大半，因为状态机的骨架是相通的。