李浩亮，刘永飞

（郑州大学 信息工程学院，郑州 450001）

引 言

CAS（Conditional Access System，条件接收系统）是一种加密系统方法总称，通过这个系统可以实现网络控制、收费、加密、管理等诸多功能，广泛应用于视频点播、电子银行、网上超市、远程教育等诸多环境。其与数字广播系统独立，但对商业的数字广播系统来说，是其成功运营的基础、增值服务的命脉，CAS系统须保证未授权用户不能收看加密节目，而授权的用户可以收看加密节目，同时可以对单用户进行识别、控制，消除传统网路电视的盲目性，是我国数字网络改造的核心部分。CAS系统由两部分组成：前端加扰管理系统和终端解扰子系统。机顶盒属于终端设备，本文介绍的CAS系统属于终端解扰子系统。

任何一款复杂电子设备，都离不开一款强大的操作系统支持，而Android系统起初是Google公司为移动设备开发的一套操作系统，但由于其开源、拥有OHA联盟强大的后盾，而且具有独特的系统架构以及Linux内核底层的稳定支撑，很快有许多其他产品厂商都纷纷开发出Android平台，使其成为目前在大型嵌入式设备上最流行的操作系统。目前华为、中兴等为代表的机顶盒厂商都在纷纷推出基于Android平台的机顶盒。本文详细介绍了机顶盒CAS终端子系统的设计过程和移植到Android平台上的过程。

1 终端解扰子系统解扰过程

数字电视节目都是通过介质（地面、电缆、卫星）以TS流的形式传播的。TS流依据 MPEG－2协议被分成长度188字节的ES包，每一个ES包都有自身识别的PID号，根据PID号的不同分成各种功能不同的表，其中对CAS系统有用的是ECM表和EMM表。EMM（Entitle Manager Message）表为授权管理信息表，里面主要包含每个用户授权的节目数和对应的SK（Service Key）业务密钥信息。ECM（Entitle Control Message）表为授权控制信息表，里面含有对解扰最重要的CW（Control Word）控制字，取得对应节目的CW之后，就可以交给安全模块解扰，解扰后的明文CW就可以用来解扰加密节目，整个解密过程也就完成了。

CA解扰的过程如图1所示。

2 终端子系统设计

图1 CA解扰的过程

考虑到应用设计与底层硬件智能卡进行交互，且Android系统提供有NDK套件工具，使得底层的其他语言的API与Android应用层JAVA语言无缝对接，所以可以把CAS以库的形式存放到Android中间层，供Android上层GUI调用。CAS系统的设计用到上述的ECM表和EMM表，但EMM表和ECM表要从PSI中的PMT、CAT表获得其PID号。图2、图3是用专用工具截取的一段PMT和CAT表里面的CA信息。

图2 CAT表中的ECM表

图3 PMT表中的EMM表

从图2可以看出此TS流中的CAT表中含有ca＿descriptor描述符，并可以得出ECM的ca＿pid为0x0562。而从图3中可以看出，PMT表中含有的EMM表的ca＿pid为0x0ffe。此时就可以设置操作demod来分配filter通道，过滤出 EMM、ECM 表的section＿descriptor＿table，来取得CA有关的信息。如果用户要流畅地播放节目，机顶盒（Set－Top Box，STB）就要不断地获得密文CW送入智能卡中，从整个解码过程中可以把整个CAS终端子系统分为3个模块：EMM解析模块、ECM解析模块、智能卡任务模块。Android系统采用的是Linux内核，保留了posix的pthread、message、memory pool等通用的 API，所以在设计3个模块时，可以使用pthread＿create（）创建任务模块；使用msgget（）创建消息，实现3个任务模块的通信与同步。

2.1 EMM任务模块

由图1可知，TS流经tuner调谐，把高频载波去掉，再经过demod解调，就可以根据PES包的PID号和TABLE＿ID号设置其里面的filter。一般来说一个demod含有多个filter，在系统启动开始就会分配PAT表的filter，有PAT表的setction＿descriptor的描述就可以得到PMT表的PID，此时同样分配PMT表的filter。如果此节目是加密节目，在其段描述符中就会含有EMM表的PID号，一旦找到EMM的PID号，就可以为EMM表分配filter。如果EMM里面的CA信息版本号和智能卡存储的CA信息版本号一致，就舍弃此EMM；如果不一致，就重新改写智能卡里面的CA用户的信息。EMM任务模块流程如图4所示。

图4 EMM任务模块流程

在EMM任务模块中，通过CAS＿EMM＿TASK（）函数创建任务，在CAS＿EMM＿TASK（）中调用CAS＿EMM＿ReceiveMessage（）函数来接收EMM filter发送过来的CA信息。在没有EMM流时，EMM任务一直挂起，而一旦filter发现EMM表，就会把EMM的CA信息发送到EMM任务中，同时关掉filter，避免其未处理完此EMM，而又接收新的EMM。此时EMM任务从挂起进入就绪态，从而处理来自filter的EMM信息，处理完之后，再次分配EMM的filter。

2.2 ECM任务模块

通过解读CAT表可知，此节目表是否加密，如果加密则设置相应ECM的filter过滤出对应的ECM表，此时结合智能卡中存储的EMM的CA信息，就可以判断出用户是否对此节目授权，若授权则取出智能卡中的SK业务密钥，找出对应的奇偶控制字（CW），送入到智能卡中，通过智能卡系统解密出CW，送入到STB中实现数据、视频、音频的解码。整个过程如图5所示。

图5 ECM任务模块流程

在ECM任务模块中，通过CAS＿ECM＿TASK（）创建线程任务，在其内部调用CAS＿ECM＿ReceiveMessage（）函数接收来自ECM的filter过滤出的CA信息；此时通过CAS＿CARD＿ReadMessage（）读取智能卡内部用户授权信息，来判断ECM是否有效且取出对应的密文的CW；而用CAS＿ECM＿SendToCard（）函数把密文CW送入到智能卡中解密，解密出明文CW；用CAS＿CW＿SendToSTB（）函数送入到机顶盒，此时解复用模块接收到明文CW就可以得到解码加密流了。

2.3 智能卡任务模块

智能卡的通信标准有T0和T1两种，T0按字节传送，T1按块传送，而在设计过程中通常支持两种协议。一般采用I2C总线通信，而智能卡内部一般没有上拉电阻，所以在电路设计过程中，SCL和SDA的引脚处必须加上拉电阻，否则无法正常通信。根据通信协议，如果要对智能卡数据读写操作，首先要发送5字节的命令字，这5字节命令字依次为CLA、INS、P1、P2、P3，其中CLA为指令类型，INS为命令符，P1、P2为操作文件位置，P3为后续字符数。智能卡接收到命令符就可以根据命令种类对其后续数据进行操作，同时智能卡就可以发出两个字节W1、W2的应答符。如果成功，W1、W2分别为0x90、0x00；如果不成功则会返回相应的代码，以便给开发者提供调试。因为智能卡内部十分复杂，篇幅有限，所以想深入了解原理的话可以参考智能卡标准，这里仅介绍机顶盒操作智能卡过程的设计。

如图6所示，在智能卡任务模块中，在系统启动之初，未进入文件系统之前，就要对智能卡进行初始化，分配内存池，强制为智能卡复位，从而选择通信类型（T0或T1），全部完成之后就可以进入文件系统。通过CAS＿CARD＿TASK（）为智能卡建立线程，在其线程内部使用CAS＿CARD＿ReceiveMessage（）接收来自EMM或者ECM的命令字。如果合法，通过CAS＿CARD＿SendMessage（）可以把应答字给其两个模块，同时通知其他两个模块发送操作数，若是EMM则到此结束，若为ECM则智能卡会把解密的CW 通过CAS＿CARD＿SendMessage（）发送给机顶盒。

图6 智能卡任务模块流程

2.4 其他细节设计

CAS系统除了最重要的解扰以外，还有其他重要的附属功能，如邮件、在线付费、在线充值、节目点播、区域限制、用户管理。这些信息都存储在EMM表中，所以EMM和ECM表的解析也是一个十分重要的步骤，只有正确地提取出EMM中的CA信息，才能顺利地进行下一步的操作。根据MPEG－2标准和PSI／SI协议，以及智能卡厂商的提供功能表，就能设计出EMM和ECM的解析函数。

表1列出了一个通用CA的描述符。

表1 一个通用CA的描述符

由于每个智能卡厂商的填充数据不一样，所以必须根据厂商的定义再去提取数据、处理数据。由于笔者参与设计的是某公司提供的智能卡，所以数据的格式也都以它为标准。最终设计包括12个源文件、5个头文件。

3 CAS子系统Android的移植

CAS终端子系统起初设计由于涉及到与底层交互，采用的是C语言。如果想要使上层的JAVA环境调用其API，就要遵循JNI规范添加新的头文件，使其应用层能够方便地调用。同时Google在设计Android之初就提供了NDK套件，有着独有的交叉编译器，使得原有的许多C语言编写的驱动、应用程序可十分方便地移植到Android系统中。

3.1 搭建Android的NDK开发环境

由于是在 Windows下进行开发，所以要在 Windows下模拟Linux的开发环境，需要下载cygwin工具，下载地址为 http：／／www.cygwin.com／setup.exe。安装方法请参考相关文档，这里就不赘述了。同样也需要Android的NDK套件，下载地址为 http：／／developer.android.com／sdk／ndk／index.html；可以选择最新的版本下载，下载完毕，直接解压到同一路径下。然后在cygwin的安装目录home／Administrator下的.／bash＿profile文件添加 NDK的路径，就可以使用NDK下的ndk－build命令了，进入samples／hello－jni。在cygwin中调用ndk－build，如果出现如图7所示的结果，则NDK的环境已经搭建成功。

3.2 编写CAS子系统的makefile

笔者使用的是android－ndk－r7b版本，也是目前最新版本，其交叉编译器位于其toolchains／arm－linux－androideabi－4.4.3／prebuilt／windows／arm－linux－android／bin中，库的头文件位于／platforms／android－xx／arch－arm／usr／include中，库位于 platform／android－xx／arch－arm／usr／lib中。知道了编译器和C库的头文件，就可以容易地编写出makefile。在编写makefile时需要注意，若用到了posix的pthread库，则需要添加“LDFLAGS＋＝－lpthread”，否则在执行链接的时候会出现错误。编译完成之后如图8所示。

图7 搭建成功后的显示内容

图8 编译完成后的显示结果

3.3 实现CAS子系统的JNI接口函数

因为CAS子系统提供给外部使用的API达20多个，这里以CASTB＿GetVersion（）函数为例，其他都是如此实现。新建一个文件夹，命名为STBCA，在文件下建立两个文件夹分别命名为JNI和SRC。JNI存放为CAS的JNI本地 API，源文件为castb＿api＿jni.c；SRC存放的是上层JAVA应用程序，根据JNI标准则需把CASTB＿GetVersion（）定义为“Java＿com＿jpf＿stbca＿STBCA＿CASTB＿Get－Version（）；”。只要调用3.2小节的中libCAS.a库中的源函数就实现了对原函数的包装，在同一目录下添加android.mk，内容如下所示：

通过3.1小节的步骤就可以生成cas＿jni.so库，上层如果要调用cas＿jni.so库中的函数只要在JAVA文件中声明 public native CASTB＿GetVersion（）函数，且使用“static｛system.loadlibrary（"cas＿jni"）；｝”把动态库加载到连接器中，就完成了全部的设计。通过实践，负责上层软件编写的同时能够无缝地实现CAS系统API的调用。

结 语

本文详细阐述了CAS子系统的开发过程和Android系统移植。在Android机顶盒的开发过程中，使用的是华为的H3716C平台，笔者承担了CAS系统和PSI／SI节目表解析的开发与移植。使用此CAS子系统播放加密节目，持续稳定地播放一周而且没有出现马赛克或卡现象，说明此CAS子系统比较稳定。但CAS是一套功能完整的独立系统，而笔者只是重点探讨解密的过程，许多其他功能未有涉及，若想深入了解CAS系统，请参考CAS系统标准。

［1］ANSI ISO／IEC 13818－1－2000信息技术.移动画面和相关音频信息的通用编码系统［S］.

［2］Download the Android NDK［OL］.［2012－03］.http：／／developer.android.com／sdk／ndk／index.html.

［3］韩超，梁泉.Android系统原理及开发要点详解［M］.北京：电子工业出版社，2010.