HDCP简介
HDCP(High -bandwidth Digital Content Protection):高带宽数字内容保护技术。HDTV(高清电视)时代即将来临,为了适应高清电视的高带宽,出现了HDMI。HDMI是一种高清数字接口标准,它可以提供很高的带宽,无损地传输数字视频和音频信号。为了保证HDMI或者DVI传输的高清晰信号不会被非法录制,就出现了高带宽数字内容保护技术,即HDCP技术。HDCP技术规范由Intel领头完成。当用户进行非法复制时,该技术会进行干扰,降低复制出来的影像的质量,从而对内容进行保护。
HDCP技术
在电脑平台上受到HDCP技术(简称DP)保护的数据内容在输出时会由操作系统中的COPP驱动(认证输出保护协议)首先验证显卡,只有合法的显卡才能实现内容输出,随后要认证显示设备的密钥,只有符合HDCP要求的设备才可以最终显示显卡传送来的内容。HDCP传输过程中,发送端和接受端都存储一个可用密钥集,这些密钥都是秘密存储,发送端和接受端都根据密钥进行加密解密运算,这样的运算中还要加入一个特别的值KSV(视频加密密钥)。同时HDCP的每个设备会有一个唯一的KSV序列号,发送端和接受端的密码处理单元会核对对方的KSV值,以确保连接是合法的。HDCP的加密过程。
软硬件设备
前面说到,HDCP需要软硬件共同支持,凡是参与内容传输的设备缺一不可。微软在新一代操作系统Vista中将集成“保护性内容输出管理协议(OPM)”,用来在输出内容前确认显示设备的性能及HDCP支持情况。同时作为高清视频的主要载体,蓝光和HD-DVD也会执行HDCP标准。
而视频源播放以及显示终端设备将通过内置转换芯片实现信号的二次编/解码,涉及产品包括显示卡、影碟机、电视、显示器、投影仪等。HDCP通过数字接口DVI-D或新型HDMI实现,其中后者应用较为普遍,兼具音/视频传输,几乎成为支持HDCP的标志。不过HDMI+HDCP目前似乎只在家电领域声望较高,几乎成为新产品的标准配置,远远超前于实际应用,但迫于日后兼容性以及上游协议制定者的压力,设备生产商不敢怠慢。而在PC领域,尽管微软一直“警告”Vista只能支持HDCP协议的显示卡及对应驱动,但一次次的跳票给了配件厂商更多的理由。HDCP协议是用来防止视频内容在传输的过程被完整的复制下来。这种技术并不是让数字讯号无法被不合法的录制下来,而是将数字讯号进行加密,让不合法的录制方法,无法达到原有的高分辨率画质。要支持HDCP协议,必须使用DVI、HDMI等数字视频接口,传统的VGA等模拟信号接口无法支持HDCP协议。但是并不是带DVI接口的液晶显示器都支持HDCP协议,必须经过带有相应硬件芯片,通过认证的显示器才行。
HDCP技术工作原理
通俗的话来说,HDCP技术实际上就是一种加密技术,和普通的加密技术不同,HDCP可以说在纵向和横向两方面对视频进行加密,首先我们来看看纵向,那就是计算机硬件要支持HDCP技术,这就需要显示器,显卡,和光驱这三部分。蓝光和HD DVD光驱都加入了对HDCP的支持,用于保护光盘中的视频内容无法正常复制出来在其它地方播放。
在HDCP运作的具体过程中,发送端和接受端都存储一个可用密钥集,这些密钥都是秘密存储,发送端和接受端都根据密钥进行加密解密运算,这样的运算中还要加入一个特别的值KS(视频加密密钥)。同时HDCP的每个设备会有一个唯一的序列号:KSV,由20个“1”和20个“0”组成。发送端和接受端的密码处理单元会核对对方的KSV值,以确保连接是合法的。
HDCP的加密过程会对每个象素进行处理,使得画面变得毫无规律、无法识别,只有确认同步后的发送端和接受端才可能进行逆向处理,完成数据的还原。在解密过程中,HDCP系统会每2秒中进行一次连接确认,同时每128帧画面进行一次发送端和接受端同步识别码,确保连接的同步。
由于HDCP的理念是非完全的防止复制而是不允许复制“高清”内容。所以如果显示设备不具有此功能也不是完全无法欣赏到“蓝光”和“HD DVD”的内容,只是得不到“高清”的效果。事实上,“蓝光”和“HD DVD”允许通过模拟接口输出经过压缩了的画面,这样的画面达不到“高清”的显示效果。一代微软视窗操作系统Windows Vista也采用相似的机制,进行数字内容的版权保护。
HDCP加密过程
HDCP会对每个像素进行处理,使得画面变得毫无规律、无法识别,只有确认同步后的发送端和接受端才可能进行逆向处理,完成数据的还原。在解密过程中,HDCP系统会每2秒中进行一次连接确认,同时每128帧画面进行一次发送端和接受端同步识别码,确保连接的同步。为了应对密钥泄漏的情况,HDCP特别建立了“撤销密钥”机制。每个设备的密钥集KSV值都是唯一的,HDCP系统会在收到KSV值后在撤销列表中进行比较和查找,出现在列表中的KSV将被认做非法,导致认证过程的失败。这里的撤销密钥列表将包含在HDCP对应的多媒体数据中并将自动更新。
HDCP 组成部分解析和烧录方式介绍
第一部分是鉴定协议,确认接收者的合法性。发送方与接收方进行信息交换,接收方将KEY 传给发送方,发送方验证并用此产生公共密钥,通过公共密钥作为均衡KEY 混入授权证实序列中,用于加密内容的解密,授权确认完成 出于保密原因,密钥不能从IC 里读出 (要透过 Scaler HDCP Engine 去 get)
第二一旦确认,发送方将加密内容以双方都知道的解密方式传给接收方;
第三当非授权设备接收时,通过发送方的检测,将中断内容传送。
H DCP 具体工作过程:首先由主机发送密钥选择导引序列(AKSV)和64bit 伪随机序列(An)到接收方,接收方回传密钥选择导引序列(BKSV)
和转发器位(REPEAT-bit)(如是转发器用以表示身份) ,发送方确认BKSV 是否已被废除和是否包含20个1和20个0;如果双方的设备密钥和KSV 有效,则计算产生一个56bit 的公共密钥Km 和Km`,然后可产生KS 、KS`(传输密钥) 、M0、MO`(64bit后续验证用追加初始序列) 、RO 、R0`(16bit指示验证成功,它必须在AKSV 发送后100ms 内传回发送方;验证成功后R01和R0相等;每128帧修正一次,每2s 回传一次) 。因此当DVI 接口中断传输2s 以上,或是非授权设备接收时,主机将停止传输内容,以达到保护传输内容的目的。
1. 如果要指定 HDCP Key 的 Counter 你可以在档案最后两个 Bytes 修改 然后 save 一次,再 close H DCP Writer 程序 然后 再 Run 一次HDCP Writer 程序 ,你可以看到 4a380 , 4a381 = 0x0308 (十六进制)= 776 (十进制) 代表现在烧到 776 组
2. 用序号的方式 要考虑到
1. 不同的 Model 会有相同的序号
2. 相同的 Model , 序号也会有相同的可能性 (y ww) 不同 序号相同
3. 每一千组为一档案 那序号应该索引那一个 File ?
4. 烧 HDCP Key时 如何得到 S/N 数据 ? 还需要 Bar Code Reader 吗 ?
5. 那 S/N 格式每家格式都不同 维护有其困难(要针对 Model)
3. HDCP Key 的掌控要完善必须 all models 联机管理 But ,工程耗大
4. I can write a tool to skip the address of 0x1f000 ~0x1ffff for update BIOS ,But the speed is very slow , I do not know why ?
5. Any Comments , call me B/R HH
HDCP KEY功能我有以下疑问:
按目前来说。
1. 每次在烧录密码只能在TOOL 里烧录时递进场(+1),如果有一个号码(998)因主板坏了, 更换主板。 要第二次烧录此号码。 需要从1烧起再来一直烧录到998号码。--》这样真的很麻烦。 如果这个号码不要了。 又是浪费。
2. 如因其它问题, 需要重新Update BIOS时, 虽然在烧录BIOS 的Tool 中设置(如下:
将F-》变为E. 可以不复掉此原来的号码。 但这如果来给产线作业者又是一大的难关。
2.1:作业员漏记做更改。--》号码被改掉。
2.2:作业内容增加。--》没有防呆。
是否在烧录密码时, 可否能采用烧S/N方法进行。 如能这样的话, 一切问题都将能解决。。 以上为个人观点。。。
我补充一下 HDCP Key 的概念
公司买了 10 万组的 Key , 暂且称为 Original Source Key ,这些 Key 不能直接拿来烧到 EEPROM or 程序 ROM ,每家 scaler 厂商都有提供 其加秘的程序 所以要将 Original Source Key 输入到加秘的程序 产生的 Key 才能烧到 EEPROM or 程序 ROM 不能用 Genesis 的 加秘程序 产生的 Key 烧到 Master 的 Projects ,反之也是 , 目前我的做法是 把加秘过的 Key 以 1000 组为一个 档案
example : Mstart_Key_0000_0999.bin (代表 Key 000 ~ 999)每次烧完一组 HDCP Key , 程序自动 加 1 , 等到 Operator 关掉 烧录程序 Counter 就会被 save 到档案(Mstart_Key_0000_0999.bin ) 所以 next time , open file Counter 就会被自动加载
My Suggestion如果 10 万组的 Key 是否画分成
0 ~ 3万组 For Genesis
评论
查看更多