display:HDCP协议简述

传输数字内容时,容易受到未经授权的复制和拦截。保护​​内容已经成为视听内容传输中的重要因素。 2003年,英特尔开发了一种加密技术,称为高带宽数字内容保护(High-bandwidth Digital Content Protection:HDCP)协议,用于保护发送器(发送诸如蓝光播放器之类的视听内容)和接收器(如显示屏)之间的音频和视频数据。如果发送设备正在发送受保护的HDCP内容,则接收器还必须支持HDCP,以便正确接收内容。

早期版本

在支持HDCP 1.X版本的早期设备(例如HDCP1.4)中,接收方(显示器)会演示其具有有效的秘***(设备私钥)。发送器验证接收者是否具有有效**,然后两个设备共享一个秘密会话**,该会话**将在加密期间使用,如图1所示。在**交换中使用SHA-1加密算法,认证强度是合理的。大多数身份验证和加密是在支持HDCP1.4的设备之间专有的。加密使用专有的流密码。

display:HDCP协议简述

HDCP1.x认证协议 

每个HDCP设备包含一个40项的数组,包括56位的秘密设备**,这些**组成了设备的私有**,以及从Digital Content Protection LLC接收到的相应标识符。该标识符是分配给设备的**选择向量(KSV)。KSV是一个40位的二进制值。HDCP身份验证协议可分为三部分。第一部分建立两个HDCP设备之间的共享值,如果两个设备都有来自Digital Content Protection LLC的有效设备**集。第二部分允许HDCP转发器报告附加的HDCP接收器的ksv。第三部分发生在启用加密的每个帧之前的垂直下料间隔期间,并为HDCP密码提供初始化状态,以便加密该帧中的HDCP内容。

协议内容

认证协议的第一部分

图2-1说明了身份验证交换的第一部分。HDCP发送器(设备A)可以在任何时候启动身份验证,甚至在以前的身份验证交换完成之前。HDCP发送器发起的身份验证是发送一个启动消息包含KSV (Aksv)和一个64位伪随机值(一个),通过HDCP密码函数hdcpRngCipher(4.5节)发送给HDCP接收器(设备B)。HDCP接收器会发送一个响应消息,其中包含接收器的KSV (Bksv)和中继位,这个中继位用来表明接收器是一个HDCP中继器与否。HDCP发送器验证HDCP接收器的KSV没有被撤销(第5节),并且接收到的KSV包含20个1和20个0。

display:HDCP协议简述

 此时,如果两个HDCP设备都有来自Digital Content Protection LLC的有效的秘密设备**数组和相应的KSV,那么它们可以各自计算一个56位共享秘密值Km(或视频接收器中的Km’)。每个设备通过添加由另一个设备的KSV描述的私有设备**的选择来计算Km(或Km'),使用56位二进制加法(即无符号加法256)。选择加在一起的秘密设备**由对应于KSV二进制表示的所有1位的位索引的**组成。

例如,假设Bksv等于0x5A3。对于0x5A3的二进制表示,位位置0、1、5、7、8和10是1,其他所有位位置都是0。因此,设备A将在数组索引0、1、5、7、8和10处同时添加自己的秘密设备**,以计算共享的秘密值Km。设备B将使用自己的私钥阵列和设备A的KSV进行类比计算,得到Km’。如果任一设备拥有无效的秘密设备**集或相应的KSV,则Km将不等于Km'。

然后使用HDCP密码函数hdcpBlockCipher(章节4.5)计算三个值:Ks、M0和R0。此计算的密码初始值为Km(或Km'),以及中继器的65位级联。HDCP接收器的状态位中继器表明HDCP接收器支持将HDCP内容重新传输到其他HDCP接收器。会话**Ks是用于HDCP密码的56位**。M0是认证协议第二部分中使用的一个64位秘密值,作为HDCP密码初始化值的补充。R0'是一个16位的响应值,视频接收器将该值返回给HDCP发射机,以指示身份验证交换是否成功。R0'必须在HDCP发送器完成向视频接收器写入Aksv后的100毫秒内可用,以供HDCP发送器读取。HDCP发送器写入Aksv后,R0'值的读取时间不能早于100ms。

如果身份验证成功,则R0'将等于R0。如果身份验证失败,那么R0'和R0在大多数情况下是不同的。在身份验证协议的第三部分期间生成的未来Ri'值将显示,如果R0值错误地指示身份验证成功,则身份验证失败。

当身份验证协议的第一部分成功完成时,HDCP发送器启用HDCP加密。

 

认证协议的第二部分

如果HDCP接收器是HDCP转发器,则需要验证协议的第二部分(图2-2)。HDCP发射器只在设置中继器位时执行协议的第二部分,表明所附加的HDCP接收器是HDCP中继器。协议的这一部分通过允许的连接树将所有连接到HDCP中继器的下游ksv列表组装起来,从而支持上游的撤销。

display:HDCP协议简述

HDCP中继器将所有附加的下游HDCP接收器的列表组装起来,作为HDCP中继器受HDCP保护的下游接口端口,使用附加的HDCP接收器完成认证协议。该列表由一组连续的字节表示,每个KSV占用5个字节,按小端字节顺序存储。KSV列表的总长度是附加的和活动的下游HDCP设备(包括下游HDCP中继器)总数的五倍。没有附加活动设备的hdcp保护接口端口不会向列表添加任何内容。此外,HDCP中继器本身在任何级别的KSV都不包括在它自己的KSV列表中。连接到非HDCP中继器的HDCP接收器的受HDCP保护的接口端口将附加的HDCP接收器的Bksv添加到列表中。带有HDCP中继器的受HDCP保护的接口端口添加从附加的下游HDCP中继器读取的KSV列表,加上附加的下游HDCP中继器本身的Bksv。为了添加附加的HDCP中继器的KSV列表,HDCP中继器需要通过计算V来验证列表的完整性,并根据附加的HDCP中继器接收到的V'检查这个值。如果V不等于V',则下游KSV列表完整性检查失败,而上游HDCP中继器不能断言其就绪状态。上游HDCP发射器将在HDCP发射器中设置的看门狗定时器到期之前检测到此故障。 

 当HDCP中继器组装完附加的HDCP设备的KSV的完整列表后,它计算验证值v并将其附加到该列表中。该值是KSV列表、Bstatus和秘密值M0的连接的SHA-1散列。在构建SHA-1输入的字串时,KSV列表采用相同的小端字节顺序,在链路上传输它,Bstatus以小端字节顺序追加,M0也以小端字节顺序追加。(见表A-24和A-25)。当KSV列表和V都可用时,HDCP中继器断言其就绪状态指示器。

HDCP发送器确定在协议中较早读取的中继器位已被设置,然后设置一个五秒的watchdog定时器并轮询HDCP中继器的就绪状态位。当准备就绪时,HDCP发射机从HDCP中继器读取KSV列表和V。如果KSV列表的大小超过HDCP发送器的容量,则身份验证协议将中止。HDCP发送器通过计算SHA-1散列值V并将该值与V'比较来验证KSV列表的完整性。如果V不等于V',则身份验证协议终止。

如果在5秒的最大允许时间内没有接收到断言的就绪状态,则HDCP中继器的身份验证将失败。出现此故障后,HDCP发送器放弃使用HDCP中继器的身份验证协议。可以通过传输新值An和Aksv重新尝试身份验证。

除了组装KSV列表外,HDCP中继器还通过连接树向上传播拓扑信息到HDCP发送器。HDCP中继器报告拓扑状态变量DEVICE_COUNT和深度。HDCP中继器的DEVICE_COUNT等于附加的下游HDCP接收器和HDCP中继器的总数。该值计算为附加的下游HDCP接收器和HDCP中继器数量的总和,加上从所有附加的HDCP中继器读取的DEVICE_COUNT的总和。HDCP中继器的深度状态等于以下任何受HDCP保护的下游接口端口的最大连接级别数。该值计算为下游HDCP中继器报告的最大深度加上1(包括所附的下游HDCP中继器)。例如,一个下游HDCP设备为0的HDCP中继器报告深度和DEVICE_COUNT的值都为0。带有四个下游HDCP接收器(不是HDCP中继器)的HDCP中继器报告深度为1,DEVICE_COUNT为4。如果HDCP中继器的计算DEVICE_COUNT超过127或KSV FIFO的大小支持的最大设备数,则HDCP中继器必须断言max_devs_status位。如果HDCP中继器的计算深度超过7,则HDCP中继器必须断言max_cascade_exceed状态位。当HDCP中继器从下游HDCP中继器接收到max_devs_exceed或max_cascade_exceed状态时,需要向上游HDCP发送器断言相应的状态位。如果设置了max_cascade_exceed或max_devs_exceed状态位,则中继器可能设置就绪位,或者可能不设置就绪位,而只是让HDCP发送器发生超时。

对于双链路中继器,中继器将两个链路的拓扑信息合并到一个从主链路KSV FIFO读取的单个KSV列表中。它可以自行删除列表中重复的KSV信息。重复的KSV值可能导致下游的双链路HDCP设备在两个链路上具有相同的KSV。如果超过拓扑最大值,则身份验证失败。*HDCP发送器检查是否在当前的撤销列表中找到任何附加设备的KSV,如果存在,则验证失败。HDCP发送器使用数字内容保护有限责任公司的公钥,通过检查系统可更新消息(SRM)的签名来验证当前撤销列表的完整性。此完整性检查失败将构成身份验证失败。

display:HDCP协议简述

 

display:HDCP协议简述

 

第三部分验证协议

认证协议的第三部分,如图2-4所示,发生在它所适用的帧之前的垂直下料间隔期间。两个HDCP设备分别计算新的密码初始值Ki和Mi,以及第三个值Ri。索引i表示帧号,从完成第一部分认证协议后启用加密的第一个视频帧的值1开始,在加密的帧或每帧上递增,取决于是否启用ADVANCE_CIPHER模式(参见下面的内容)。但是,当HDCP设备处于HDMI AVMUTE状态时,帧计数器不会前进,并且在HDMI AVMUTE状态之后直到第一个加密帧才会继续前进。Ki是一个56位的**,用于初始化HDCP密码以对HDCP内容进行加密或解密。Mi是HDCP密码的一个新的64位初始值。Ri是一个16位的值,用于链路完整性验证,每128帧计数器增量更新一次,从128帧开始。HDCP发射器根据自己的计算来验证Ri',以确保视频接收器仍然能够正确地解密信息。这种验证至少每两秒进行一次。每次Ri更改时(每128thframe)同步读取Ri也可以代替异步轮询。(在Ri更新之前和更新1毫秒后不久的帧同步读取还提供了一种检测HDCP发射器和HDCP接收器之间的帧计数器不匹配的方法,而这两个设备都不支持增强的链路验证)。它要求从HDCP发送器开始的时间起1毫秒内完成Ri'读操作。由于任何原因导致HDCP发送器认为HDCP接收器未经验证。

 为了增强对加密同步丢失的检测,HDCP发射机和接收机可以选择性地支持增强的链路验证,在此过程中,当处理特定的视频像素时,执行有助于验证加密同步的计算。对于每16帧计数器增量,使用XOR操作将第一个像素的通道零的解密值与最不重要的字节Rj组合在一起,结果在Pj端口上可用。如果HDCP接收器支持此功能,则设置Bcaps第1.1_FEATURES并始终更新Pj '端口。HDCP发送器可选地支持根据内部生成的Pj值读取和验证Pj '值。但是,除非出现至少三个连续的稳定值不匹配,否则这将被视为像素传输错误,而不是身份验证或同步错误。此外,不匹配的Pj值必须以与Ri值相同的方式进行多次采样。注意,如果ADVANCE_CIPHER模式(见下文)被启用,那么帧计数器可能会在未加密的帧上前进,在这种情况下,每16帧捕获最不重要的字节Rj和像素数据。但是,如果未启用ADVANCE_CIPHER,则在每16个加密帧上更新这些值。

ADVANCE_CIPHER模式是一种可选模式,其中对于DVI模式下的每一帧,或者对于HDMI模式下非AVMUTE状态下的每一帧,无论是否启用或禁用加密,密码状态和帧计数器都是高级的。HDCP接收器通过设置1.1_FEATURES Bcaps位来表示此功能,而HDCP发送器通过在Ainfo字节中设置ENABLE_1.1_FEATURES位来启用此功能。在验证之后发送或接收第一个ENC_EN时,首先将帧计数器更新为1,然后对每一帧进行递增,直到设置SET_AVMUTE(在HDMI模式下)。如果HDMI模式AV_MUTE是活动的,并且在HDMI CLEAR_AVMUTE之后继续前进到第一个ENC_EN帧,那么密码状态就不是高级的。

注意:一个HDMI-capable HDCP发射机,使得交流(通过编写1 ENABLE_1.1_FEATURES点AInfo)可能需要重新发送一个AVMUTE HDCP接收器之后,自从HDCP接收机可能忽略了HDMI一般控制包包含Set_AVMUTE命令,造成的损失HDCP密码同步。

HDCP2.2 

HDCP 2.2规范应用了最新的加密标准,例如RSA和AES,并将它们分别用于身份验证和加密,这使其比以前的HDCP1.X协议更加安全。

HDCP 2.2协议分三个阶段工作:第一阶段,身份验证,用于验证接收器是真实的并有权接收数字内容。在第二阶段,即加密,发送方可以开始将加密的数据发送给接收方,然后接收方将使用在身份验证步骤中交换的**对数据进行解密。如果合法设备遭到破坏,则第三阶段(可更新性)允许HDCP发射机识别此类受到破坏的设备并阻止HDCP内容的传输。

HDCP2.2认证协议

在发送视听内容之前,发送者必须使用身份验证协议确保接收者是真实的并有权接收受保护的内容。

身份验证协议包括:
1.身份验证和**交换(AKE):检查接收方是否包含有效的未撤销公共**证书。
2.位置检查:检查以确保将接收器放置在附近并限制传输到某个地方。
3.会话**交换(SKE):交换公共共享会话**,该**将用于加密数据本身。
4.使用中继器[并不是最终的显示设备]进行身份验证:当接收器是中继器时,这是一个可选步骤,即可以连接后续接收器设备。发送器检查拓扑中的所有接收器均未被授权。

https://blogs.synopsys.com/vip-central/2015/04/21/hdmi-hdcp/

https://www.digital-cp.com/sites/default/files/specifications/HDCP%20Specification%20Rev1_4_Secure.pdf