2012年3月20日至23日，第20屆中國國際廣播電視信息網絡展覽會（CCBN2012）在北京中國國際展覽中心舉行，搜狐IT作為“CCBN”的官方指定合作伙伴，對展會現場進行全程圖文報道。在NGB可下載CA技術規范宣貫會上，科技司科技與標準管理處處長盛志凡介紹了標準管理情況和技術內容。以下為盛志凡發言實錄：
盛志凡：各位領導、各位專家、各位來賓，大家下午好！
今天我為各位匯報的題目是可下載條件接受系統，繼續規范主要的內容。由于當時機制和機理的原因，造成各家網絡公司被條件接收限制。如果說一個終端從某個網絡挪到另一個網絡，比如長沙市的網絡挪到徐州市的網絡，如果條件接收不一樣的話，這個終端是不能用的，硬件和軟件都可以換完以后才能用，這個情況實際上也是造成我們有線電視網絡互聯互通不能形成規模效應的一個很重大的原因。
在這樣一個背景下，當時我們就想怎么解決這個問題。實際上這個命題的提出不是輕易提出來的，在整個產業界也有一些想法。當時在我們之前有一個大卡方案，這個思路就是把所有和條件接收相關的東西都做到一張大卡里面，終端就有條件接收，這就是我們做的大卡方案。在美國叫做Cable Card，被美國強制要求在機頂盒上實施。當時我記得是2008年或者2009年FCC下了一個文，就是說在2010年5月份或者6月份，一定要全部實施完畢。實際上到2010年初和2009年年底的時候，FCC又下了另外一個法令，以前的強制要求終端采用大卡的法令取消，現在FCC只能說我以前要求你做的事情你沒做。標志著以大卡為標志的路線產業時代。FCC曾經就說我不要求，在這種情況下，我們有多年來全球的命題，或者是很大的一個難題和挑戰要解決，以大卡的方式探索沒有行得通。2010年的時候，03年的時候就提過可下載方案，當時的思路是往可下載做，后來因為實現方法還不夠好，也被放棄了。2010年之后我們看到這樣一個挑戰，我們看到大卡對于產業化推進來說行不通，我們就面對著DCAS這樣一個思路，在這樣的背景下產生的。
在這種情況下也集思廣益想了很多方法解決這個事情，經過很多年的積累、修正和探索，我們基本上到條件成熟之后，能夠收斂出一些想法，我們開始了這個工作，由科技司牽頭，電視臺、廣電，還有一些我們典型的網絡公司參與了這個工作。從思路來說很簡單，以前分析下來，解決造成分割很大的原因在于終端的安全芯片的一些安全方面的機制化處理各家不同。最主要的一個不同處理方式就是各家會發一個智能卡，智能卡里面的公密鑰，最頂層的密鑰是要預先預置到條件接收智能卡里面的安全芯片。按照原來的機制，每一個顆芯片里面都會預置一個不同的公密鑰，而且是各個廠家自己規定的。也就是說，各個廠家都不同，當然也絕不可能相同。一相同的話安全性就沒有保證了，絕不可能共享?；谶@樣一個原因，這個安全底層的機制是造成這個條件檢索系統多方面條塊分割局面很重要的原因。
當時我們想是不是提取一種思路，大家不預置一個公密鑰，不是預置各個廠家不同的，每個芯片不同的個性化的密鑰，能不能大家少一些框框，能夠產生實時形成公密鑰的機制，當然這個首先就是安全。同時要求是公正的。這個安全機制是要為所有的廠商供應的，我們找到這樣一個機制，再構建這樣一個系統，終端不是拿一個密鑰進去，而是拿一個函數進去，用這個函數產生不同的密鑰。很簡單，在這種時候，因為考慮到所有的廠家要用同樣的函數，最后安全出了問題，還是條件接收廠家要承擔。條件接收廠家必須要唯一地確定自己的安全性。針對這個問題，我們也在想，信息安全秘密分散的一部分。以前密鑰是一個安全廠家自己決定的，針對這樣一個大家共用的函數和機制產生公密鑰的方式，我們就是說是不是由多方共同來決定這個公密鑰的產生，必然要運行公密鑰的共行模塊的機制，共同分散管理安全信息，由安全管理平臺管理。銀行的保險柜必須是三把鑰匙同時到場，才能利用這把鎖打開門。這樣的機制下其實想想很簡單，圍繞這個思路，大致給大家介紹一個背景和基本大層面的想法，下面稍微具體介紹一下可下載具體的內容。
傳統條件接收系統與我們現在可下載條件接收系統有什么不同，大致介紹一下這個系統是什么樣，由大致介紹的原理再稍微深入介紹一下這個原理怎么樣，最后會稍微介紹一下，因為我們廣電行業來說一個技術出來以后，還要交叉使用起來。在新的系統下面是怎么應用起來的，怎么實現的，這一方面我們也稍微梳理一下，包括系統也去參與，包括流程。最后給大家匯報一下產業化的情況，并且進行分析。
傳統CAS與NGB，可下載條件接收系統有什么不同。從計算來說，傳統終端系統就固定死了，可下載的條件系統在終端是可以實施密鑰的安全基礎。這是最大的不同，還有一個安全信息擴散管理。這兩個不同導致了一些功能上和結構上的不同，以前系統的機頂盒是綁定的，彼此不可分離?，F在不是這樣，現在可以非常方便地從前端下載一個非常薄、非常小的小程序，下載以后就能夠實現同樣一個硬件機頂盒在保持不變的情況下就進行切換，比如說從A廠商到B廠商的信息化，實現這樣一個不同。從表現形態上面，CA在終端層面上的要求是智能卡，也有不采用智能卡的方案。我們知道智能卡是以卡的形式把一個安全芯片包裝起來，也有的方案據我所知，目前深圳就產生這樣一個解決方案，把智能卡的安全芯片貼在機頂盒主板上面，整體要求是智能卡或者芯片的情況，主要是和終端是綁定的。江蘇有線號稱1800萬用戶的網絡公司，在招標的時候很難達到超過100萬的，原因就是各地的CA分割，造成格局網絡終端條塊分割比較嚴重，就是不能實現終端的水平化市場。
可下載條件接收系統剛才說了，實際上就是公鑰方面做了手腳，別的沒變。現在整體架構來說，比如說授權控制管理系統等等機制完全不變，只是說終端的安全芯片里面預先埋的不是一個公密鑰，而是能夠接收公密鑰的機制?？上螺d條件系統在前端上面來說，基本上應該說原有的都保留了，唯有在前端也有一個和終端實時生成密鑰的小部件。也就是說，全程的條件接收系統在前端通過升級就能夠實現同時對傳統CA和可下載CA的支持。剛才說了，我們采用了信息分散管理，我們還引入了一些新的概念，比如說安全下載管理平臺，需要建立一個組，作為可下載CA很重要的一部分參與了安全的管理和可下載的條件接收系統。整體來說，可下載的條件接收系統是能夠兼容的。當然，這里面為了提高授權效率，因為可下載的條件接收系統我們目前采用的是有雙向要求，我們也充分利用了雙向的通道來提高我們授權管理信息，就是EMM信息發射的效率，也就是提高我們對于終端授權的效率，所以我們采用了雙向通道。也就是說全程的CA傳輸都是完全通過廣播信道傳輸。在可下載CA和DCAS這個系統里面，傳輸既可以利用原有的廣播信道進行傳輸，大大提高了數據效率。嚴格來說這個系統也不是新的，無非就是前端加終端，這個系統圖把終端稍微分解一下，我們在這里看到有一個安全芯片，所有的條件接收，目前我們定義的安全機制全部都放在安全芯片里面，為了實現在終端形成不同條件系統的切換，為了實現這個，我們有一個小軟件，叫做DCAS用戶端軟件，是非常薄的。同時，為了能夠方便地下載和承載，對同樣一個品牌承載不同的DCAS軟件，我們引用了中間件的概念。實際上DCAS的用戶端軟件是一個小的應用件，是建立于中間件之上的一個小軟件。還有相關的我們看到有DCAS應用程序接口，在中間件我們也用了DCAS應用接口。
下面這個圖是要管理密鑰的形成，要進行一些計算，來提供一些信息，實現對每一顆芯片的安全性。還有安全密鑰的生產和管理，這個是在生產線上面生產之前，機頂盒生產線上面對安全芯片進行密鑰的預置。大家知道，密鑰都是要預置一些信息進去的。通常我們使用Black Box的技術。嚴格來說，和我們已有的系統沒有什么不同，這是從大的模塊上面來說，功能上面集成一些功能。有前端，還有終端，還有終端安全芯片等等。
我大致介紹一下原理，實際上我剛才也解釋了，在DCAS的原理里面，全程的條件接收和程序密鑰的原理，加上一個公鑰的生成機制，有兩個方面，一方面要預置在終端，前端也算，為了安全性，實際上是可以預先算出來，但是我們為了加強安全性，前面也有一個模塊來算。我計算公密鑰的時候是給一個數字，采用安全信息分散管理的原理，我們由三方進行來計算，條件接收本身、終端安全芯片廠家提出算法，然后是安全系統管理平臺，三家進行的機制。除了這個以外，其他的對于授權信息的產生，程序的密鑰機制是完全一樣的。這也是為什么說我們DCAS系統能夠和條件接收系統完全兼容的原因，就是能夠兼容現有的條件接收系統。可以說，在實施上面，在想法上面，因為機制變了，終端不是買一個公密鑰，而是買一個生成公密鑰的安全機制，這個大的機制上變了，應該說DCAS是一個革命性的想法。但是實施起來，革命性的想法也是我們的基礎網絡不方便進入的。目前我們做的是把安全芯片和解碼芯片完全的放在一起，實際上我們并不要求完全集成，只是我們采用這個方式，實際上是最簡單的方式。如果我們要把安全芯片放在解碼芯片之外，我們考慮安全芯片和解碼芯片之間。為了趕上我們的要求，第一步我們還是直接定義了這樣的形態，就是說安全芯片這是一個最簡單的方式。接下來加上安全芯片以外怎么辦？嚴格來說，看運營商從標準角度來說是什么樣的狀態。不僅成本節省了，同時用戶報障率下降了1/3。
剛才我們說到，終端是同樣產生公密鑰的機制，還要下載一個小軟件，從A廠家變成B廠家。這個時候如何保證安全性？前端和終端如何統一起來？三者之間如何把安全性聯系起來？為了保證安全性，在標準里面要求要實現一致，這就是我們為什么要提出雙向的論證。握手論證目前標準里面提的就是在第一次安裝的時候要求實現終端安全芯片的安全機制和DCAS小的軟件和前端系統三個之間要握手，保證都是同一家的。大家不能說一個講浙江話，一個講廣東話，這是從安全性方面來考慮的。一個盒子從A條件接收廠家到B接收廠家的時候，條件接收廠家之間切換的時候要求有一個過程，這是標準的強制要求。除此以外，更多的握手要求沒有做更多的規范。有的運營商要求安全性增高，也可以說一周或者一個月，實際上也可能單向的網絡，在下載的時候，我們為了安全性的保證，實現安全鏈的一個保護機制。比如說是安全芯片的密鑰來進行嵌入保護，保證是真的，同時用Boot Loader技術，跟中間件下載的DCAS進行保護。通過這樣一個信任鏈的機制建立，我們能夠確保下載DCAS軟件是安全的，是真實的，這個其實也是對于其他應用軟件的要求。一旦我們建立中間件的平臺以后，不管是下載條件接收應用以外，還需要其他的應用，這個安全性也是有要求的，這個要求在很多領域都是存在的，在這里也沒有例外。
具體到安全芯片領域，每一個都有一個風險要寫進去，Black Box我們安全芯片管理模塊是一個要工作的對象。公鑰就不多說了，關鍵是想法比較奇妙。我們看層級密鑰，我們完完全全不用多說了。我們剛才介紹的主要還是原理，具體的要求請大家看行業標準，可下載條件接收系統技術規范。這個技術規范是一個系統，我們對DCAS的前端、終端的DCAS軟件、安全芯片等等，包括安全生產管理平臺都有一些具體的技術要求，管理芯片方面也就不展開了。
這里給出一個終端的圖，標準上面也有，從上面可以明顯地看出來，一共有幾個方面。有程序密鑰，還有解擾、解碼，還有碼流處理。目前這個安全芯片實際上是包含在一個解碼芯片里，我們下一步很快會增加一項，就是把安全芯片這一塊給出相關的名稱。中間件就不多說了，別的廠在做。順便給大家公告，中間件這個標準也是做了兩年多了，應該在6月份之前我們有信心推出來。在中間件里面，API接口里面與DCAS用戶端軟件的接口方面有兩個組，是DCAS組和NGB的中間件組進行了充分的協調和溝通。所以未來DCAS支持用戶端軟件的API是協同一致的，這里可以看出來很簡單，不用多說。
關于密鑰的管理，完完全全是由條件接收廠家決定的，對于DCAS實際上不同。剛才說到，我們為了使條件接收廠家能夠放心、安全的使用同樣一個能夠生成公密鑰的機制，大家有同樣的生成公密鑰的機制。所以我們采用了安全信息分散管理的原則，引入了安全信息管理的概念。這時候我們也有一套流程和方法，保證安全，這時候密鑰的管理就不是條件接收廠家一家的事了。未來一開始密鑰的管理會保證，條件接收廠家有這個機制。安全數字管理平臺對很多項目有統一的管理，比如說芯片的密鑰和加密的密鑰，SCK就是加密的安全芯片密鑰，目的是產生條件接收廠家的加密公鑰，是要由安全信息管理平臺統一管理。既然是新的東西，下面我們有專門的講解，這個是由廣科院電子所的所長來介紹。我就不多介紹了，現在我就大致引入這個概念。
加密信息分散管理，銀行的保險柜是三把鑰匙，在DCAS下面，所有的廣播電視內容如果裝在一個銀行的保險柜里面的話，條件接收系統銀行的保險柜，開這個柜的鑰匙就是密鑰，我們要求三方同時掌握才能生成一個鑰匙。這三方就是條件接收廠家、層級密鑰數字管理平臺和芯片廠家。任何兩家信息泄漏了，也不會被終端打開。通過這個，既提高了安全性，同時也確保了條件接收廠家自己安全。這樣的話達到了既增加安全性，也平衡了多方利益和安全的要求。
運營方面來說，條件接收系統用了以后，我們不是想制作一個好看的東西，還是要能用。主要是針對現有的流程，通過現有的流程大家看得出來，這個系統是可做的，可以在現有的條件接收系統，有線電視網絡運營商在現有的體系、管理流程和技術流程下面，基本上相同的復雜度，能夠實現對DCAS的運營和管理。比如說描述了一種可能的流程，芯片廠家向安全數據平臺申請一定數量的Chip ID和ESCK，芯片廠家完成此批芯片的生產后通知安全數據平臺。安全數據平臺向所有的CA廠商發布消息，通知新的芯片將進入DCAS系統。這個發布可以是定向的，比如說上海說我要新招標一百萬臺盒子，他也決定采用某一個廠家安全芯片的話，這個盒子完全都是在上海，可以全面推開。同時，CA廠家獲取芯片數據，還要從安全數據平臺獲取Chip ID和ESCK，再和芯片廠商獲取Seedv。CA廠商根據SCKV和Seedv計算根密鑰K3，CA廠商將新的一批K3更新到各地前端服務器。一段時間后，使用新芯片的終端被消費者購買，在某個運營商網絡中開機運行，CA通過雙向握手認證得知新芯片進入系統，CA使用已經保存的根密鑰K3加密K2，使用K2加密K1，使用K1加密控制字CW，而且相關的規范也是現有的條件接收廠家所處理的一些情況，CA下發加密后的K2、K1、CW。系統參與角色就不多說了，剛才基本上已經講到了，有安全系統管理平臺、安全芯片廠家、CA提供商、中間件和終端廠家，這里最重要的還有我們的運營商，最后所有的工作都是為我們有線電視網絡運營商服務的。
下面給大家匯報一下標準和產業化的情況。DCAS標準我們叫做條件接收系統規范，我們規定了條件接收的系統標準，我們談一下系統結構、主要模塊和接口以及對功能塊的要求做定義。同時在這里面因為是一個新的機制，所以我們對支撐實現DCAS這樣一個系統的機理也做了一些定義和規范。應該說包括一些重要的環節，都需要安全芯片，在以前是沒有的，我們都做了要求。
產業化的情況，這里面講一個小故事，安全芯片終端的要求，ETSI、TS103、162標準，我們這個工作是在TS103、162標準，是在2010年11月份到12月份左右發布的，我們是想在2012年2月份開始，4、5月份啟動，下面就是繼續完善，把它能夠操作系統。嚴格來說，我們在2010年8、9月份就能發布，我們想盤沒有了，大家用同樣一個機制，所有的廠家在終端要用同樣一個安全機制來生成自己的密鑰，這個安全機制的安全性、公正性如何來證明是很頭疼的事。我們當時布置得慢了一點，因為參加的廠家也有國外的廠家，在歐洲我們是做了貢獻，但是某種程度上我們吃了虧。但是實際上我們也占了便宜，一旦歐洲這個標準發布以后，我要證明這個機制是合理、公正和安全的，這個時候我們就開始大力做研發，把系統進行實現。我說的意思就是，咱們的想法實際上是具有世界性的，而且也是機制上可行的。當然我們這個標準是超越了ETSI、TS103、162，我們是一個系統發展的新產品，不僅僅是把終端的機制公密鑰開始一致搞定，同時還對系統怎么來實現，應該說世界上第一個比較完整的系統DCAS標準實現是我們的目標。
產業化的情況怎么樣？會后請大家看會場邊上的電視。目前我們有三個機頂盒，長虹、同洲、創維實現的。終端的芯片目前有Broadcom、ST、NXP、Realtek，好在還是有一點基礎，總局支持了五個廠家來做具有高安全屬性的五個芯片，來支持做具有高安全屬性的終端解碼芯片?，F在據我所知有三四家，能夠生產出具有高安全屬性的解碼器。把這個具有高級安全屬性的芯片做下來以后，我們今天上午還在進行溝通，從工信部聯合進行支持，上周我還和北京市經信委的領導溝通，從計劃層面，國家支持民主產業發展。目前中間件的標準還沒有出來，目前我們系統實驗做了三款中間件，包括NDS、同洲和數碼視訊。有三個機頂盒，目前也是有兩個芯片，包括Broadcom為和CT，整機有三個大品牌，長虹、同洲和創維。下一步我們也在加大力度支持，下周我們還會到工信部開會，推進產業化。這兩天也一直和江蘇、上海、杭州、深圳的一些大運營商進行溝通，推進這件事情。
我的匯報大致就到這里，謝謝大家！
魯公網安備 37010102000429號