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，可下载条件接收系统有什么不同。从计算来说，传统终端系统就固定死了，可下载的条件系统在终端是可以实施密钥的安全基础。这是最大的不同，还有一个安全信息扩散管理。这两个不同导致了一些功能上和结构上的不同，以前系统的机顶盒是绑定的，彼此不可分离。现在不是这样，现在可以非常方便地从前端下载一个非常薄、非常小的小程序，下载以后就能够实现同样一个硬件机顶盒在保持不变的情况下就进行切换，比如说从A厂商到B厂商的信息化，实现这样一个不同。从表现形态上面，CA在终端层面上的要求是智能卡，也有不采用智能卡的方案。我们知道智能卡是以卡的形式把一个安全芯片包装起来，也有的方案据我所知，目前深圳就产生这样一个解决方案，把智能卡的安全芯片贴在机顶盒主板上面，整体要求是智能卡或者芯片的情况，主要是和终端是绑定的。江苏有线号称1800万用户的网络公司，在招标的时候很难达到超过100万的，原因就是各地的CA分割，造成格局网络终端条块分割比较严重，就是不能实现终端的水平化市场。

       可下载条件接收系统刚才说了，实际上就是公钥方面做了手脚，别的没变。现在整体架构来说，比如说授权控制管理系统等等机制完全不变，只是说终端的安全芯片里面预先埋的不是一个公密钥，而是能够接收公密钥的机制。可下载条件系统在前端上面来说，基本上应该说原有的都保留了，唯有在前端也有一个和终端实时生成密钥的小部件。也就是说，全程的条件接收系统在前端通过升级就能够实现同时对传统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，好在还是有一点基础，总局支持了五个厂家来做具有高安全属性的五个芯片，来支持做具有高安全属性的终端解码芯片。现在据我所知有三四家，能够生产出具有高安全属性的解码器。把这个具有高级安全属性的芯片做下来以后，我们今天上午还在进行沟通，从工信部联合进行支持，上周我还和北京市经信委的领导沟通，从计划层面，国家支持民主产业发展。目前中间件的标准还没有出来，目前我们系统实验做了三款中间件，包括NDS、同洲和数码视讯。有三个机顶盒，目前也是有两个芯片，包括Broadcom为和CT，整机有三个大品牌，长虹、同洲和创维。下一步我们也在加大力度支持，下周我们还会到工信部开会，推进产业化。这两天也一直和江苏、上海、杭州、深圳的一些大运营商进行沟通，推进这件事情。

       我的汇报大致就到这里，谢谢大家！