類似的視頻數(shù)據(jù)的不同幀之間分辨。在測試之后，發(fā)現(xiàn)在幀數(shù)據(jù)的前64字節(jié)上使用CRC-64實現(xiàn)好的結(jié)果。因為幀可以容易地跨越1000分組并且出于性能原因明顯地不期望散列全幀。發(fā)現(xiàn)64字節(jié)的散列給出好的分辨。
[0024]以該方式，過程可以指定修理作為散列、來自MPEG開始代碼的字節(jié)偏移以及5字節(jié)覆寫的組合。這被實驗上示出以在有代表性的電影剪輯中通過唯一性，并且還在其中散列不是唯一的情況下，可以僅通過在具有唯一的散列值的幀中定位修理來在MT時間處實施唯一性。
[0025]密鑰交換部件32與播放器40相關(guān)聯(lián)。播放器40加載內(nèi)容代碼36和原生內(nèi)容代碼38，其與圖形處理單元(GPU)42協(xié)商會話密鑰、惟一地保護該密鑰并且與第三部件，修理部件34，共享該密鑰。
[0026]密鑰交換部件密鑰交換庫。密鑰交換部件32與每個播放器40相關(guān)聯(lián)、是每播放器唯一的并且基于與內(nèi)容一起提供的數(shù)據(jù)被參數(shù)化。密鑰交換部件34包含用于到圖形處理單元(即GPU)端點的視頻數(shù)據(jù)的加密的密鑰的安全建立的庫功能。密鑰交換庫44支持四個不同的GPU密鑰交換協(xié)議:GPU-CP、AMD/ATI UVD (統(tǒng)一視頻解碼器)、Nvidia VP2以及Intel PAVP。盡管協(xié)議可能不同，但是針對每個媒體路徑的一般技術(shù)方案是相同的。意圖是提供用于將被發(fā)送到GPU端點的加密視頻的安全路徑。密鑰交換協(xié)議中的每個具有產(chǎn)生安全加密密鑰的不同步驟，但每個到達相同的結(jié)論，即到GPU的用于加密的安全密鑰。對全部四個協(xié)議的支持給予技術(shù)方案在操作系統(tǒng)變化上(即Win 8、Win7、Vista, WinXP)和GPU供應(yīng)商變化(Nvidia、AMD/AT1、Intel)上最廣范圍的支持。注意到技術(shù)方案不限于這些系統(tǒng)和GPU，但容易地擴展到其他操作系統(tǒng)和GPU，支持密鑰交換協(xié)議和基于硬件的解密。
[0027]密鑰交換庫44是建立可以被用來對視頻流加密的AES對稱密鑰需要的0S和GPU特定協(xié)議的封裝。AES密鑰連同保護密鑰的數(shù)據(jù)變換(US6594761)被建立、目的在于AES加密例程的白盒實現(xiàn)(在US7464269、US7971064中被描述)。將信息在密鑰交換庫和白盒AES實現(xiàn)之間以從未暴露密鑰的方式既不靜態(tài)地也不動態(tài)地安全傳遞。更進一步地，被加密的視頻數(shù)據(jù)還可以包含被糾正的某些腐蝕，如在下一部分中描述的那樣。
[0028]參考圖4和5，圖示了形式修理部件的客戶側(cè)媒體處理。取決于修理部件34正在運行的環(huán)境，其可以是兩個形式中的一個。
[0029]在圖4中，圖示了修理部件34的第一形式42。修理形式42在調(diào)用時唯一地修理流，同時將該操作混合到目的為GPU的AES (先進加密標(biāo)準(zhǔn))加密46的第一輪中。AES操作的密鑰從未在操作期間的任何點處被暴露。
[0030]在圖5中，圖示了修理部件34的第二形式60。按照[W02013/033807國際專利申請，Andrew Szczeszynski等]，修理形式60在調(diào)用時唯一地修理流，同時將該操作混合到再腐蝕操作62中以便在頻域中貫穿其處理地保護視頻數(shù)據(jù)。
[0031]在圖6中，圖示了修理部件34的第三形式##0按照[W02013/033807國際專利申請，Andrew Szczeszynski等]，修理形式##在調(diào)用時唯一地修理流，同時將該操作混合到可變長度的解碼操作##中以便在壓縮域中貫穿其處理地保護視頻數(shù)據(jù)。
[0032]修理部件的第一形式一一白盒AES/修理混合
每內(nèi)容36唯一地準(zhǔn)備修理部件34的第一形式42并且將其與內(nèi)容一起分發(fā)。通過媒體播放器40加載原生內(nèi)容代碼38來唯一地回放媒體內(nèi)容。
[0033]因為播放器40遇到具有可用的混合特征的容器20，所以播放器40在初始化期間首先加載與容器20相關(guān)聯(lián)的內(nèi)容代碼36。然后，密鑰交換部件32協(xié)商用于加密的密鑰。然后，以受保護的形式將該密鑰連同用于加密類型的配置參數(shù)從密鑰交換部件32傳遞到修理部件42。最后，修理部件42的原生內(nèi)容代碼38執(zhí)行混合的白盒AES加密和直接目的為GPU的視頻數(shù)據(jù)的修理。
[0034]在圖4中描繪了 AES加密的細(xì)節(jié)，其中原生內(nèi)容代碼38做出針對端點GPU的完全混合加密。受保護的視頻塊48連同描述變換的數(shù)據(jù)進入內(nèi)容代碼。將變換的明文50連同被腐蝕的塊傳遞到AES實現(xiàn)46，其遵循較早描述的對齊約束的集合。這些約束提供允許在AES實現(xiàn)內(nèi)的有效率的處理的框架。
[0035]針對變換的情況，過程執(zhí)行對預(yù)子密碼(pre-subcipher) 54、回合密鑰(roundkey)56以及變換的明文50的字節(jié)計算異或52的操作，其中明文具有40位混合的布爾算術(shù)變換(進一步在 Yongxin Zhou、Alec Main、Yuan Xiang Gu、Harold JohnsonInformat1nHiding in Software with Mixed Boolean-Arithmetic Transforms，，，Lecture inComputer Science Volume 4867，2007，pp61_75中被描述)。其他輸入可以或可以不被變換；然而輸出是未變換的。完成這點以確保在GPU端點上的回放。
[0036]操作的變換的40位異或集合使用在密鑰調(diào)度的最后回合中的字節(jié)方式到字方式轉(zhuǎn)換和在AES算法中的最后子字節(jié)步驟之后的類似轉(zhuǎn)換來執(zhí)行對預(yù)子密碼和回合密鑰的必要計算。
[0037]針對計算中的其他字節(jié)，用于這些字節(jié)的明文未被變換，但預(yù)子密碼和回合密鑰兩者可以被變換。存在可以由適當(dāng)大小的操作的集合處理的字節(jié)的兩個組。這意味著針對密鑰調(diào)度的最后回合和最后的子字節(jié)步驟，存在兩個其他字節(jié)方式到字方式變換。通過包括描述塊內(nèi)的組的分解的系數(shù)來創(chuàng)建處理整個塊的操作的單個集合。未變換的情況不是與變換的情況不同的情況，因為甚至在變換的情況下，明文字節(jié)的大部分未被變換。
[0038]以標(biāo)準(zhǔn)方式變換密鑰和初始化矢量兩者。在AES CTR模式加密中，僅在極最后的步驟處使用明文，其中所述明文與通過對計數(shù)器加密導(dǎo)出的子密碼異或。因此，針對當(dāng)前的情況，幾乎整個WBAES實現(xiàn)與申請人的現(xiàn)有的動態(tài)密鑰實現(xiàn)中的一個相同，因為大小和性能兩者是重要的考慮。
[0039]在存在預(yù)子密碼時對在最后的子字節(jié)步驟之后的實現(xiàn)分割。在該點處，剩余的步驟是:
1.最后的AddRoundKey以產(chǎn)生子密碼。
[0040]2.使子密碼與明文異或以產(chǎn)生密文58。
[0041]修理部件的第二形式一一運行時失真/修理混合
在圖5中示出了修理部件34的第二形式60。在第二形式60中，包括與運行時失真操作62的混合，代替加密操作。這是支持代替直接在GPU上的在軟件中執(zhí)行的視頻解碼操作的情況。該方法的優(yōu)勢是本系統(tǒng)一般更適用于不同的回放系統(tǒng)。然而，系統(tǒng)的CPU必須滿足視頻比特率需要的性能。
[0042]運行時失真操作62被定義為如在[W02013/033807國際專利申請，AndrewSzczeszynski等]中詳細(xì)描述的頻域失真和相應(yīng)的空間域修理器的插入。
[0043]視頻內(nèi)容48的失真一般發(fā)生在客戶端代碼中。這可以是播放器的部分或與內(nèi)容一起被動態(tài)加載。被動態(tài)加載的客戶端代碼的示例是原生內(nèi)容代碼，其是與內(nèi)容相關(guān)聯(lián)且一起分發(fā)的部件。動態(tài)加載的原生內(nèi)容代碼是最好的模式，因為其提供可更新的保護機制和多樣性的安全能力。多樣性意味著可以使得原生內(nèi)容按照分布的內(nèi)容而不同，使得差分攻擊更困難。
[0044]頻域失真并且產(chǎn)生兩個輸出:
1.失真的視頻內(nèi)容64，以及
2.可以被用來修復(fù)內(nèi)容的‘修理器’參數(shù)數(shù)據(jù)66的集合。
[0045]失真的