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
評論
查看更多