如何结合NGB下载CA技术规范开发独立的智能卡CA应用

txca

       泰信推出的T1智能数字机顶盒有一个智能卡的读卡器，可以支持传统的有线电视智能卡，但需要对应的APK应用。可参考2012年3月国家广电总局发布的NGB下载CA标准(《GY/T 255-2012 可下载条件接收系统技术规范》)，智能卡操作部分我们结合标准在DTVOS中做了完善和扩展(详见泰信官方网站)。

智能卡CA应用的工作的流程和下载CA应用没有本质的区别(见下图)，希望对智能卡厂家和第三方开发者有所帮助。

智能卡CA应用的开发主要包括几个方面：

1 接口：

应用开发使用的接口主要包括以下几个部分：

API名称	包名称
终端软件平台上层API	org.ngb.net.cas.module
应用扩展API	org.ngb.net.cas.event
解扰器/终端安全芯片API	org.ngb.net.cas.controller
网络API	java.net
Section过滤API	org.davic.mpeg.sections
永久性存储API	java.io
可分离安全设备API	org.ngb.net.cas.detachable
Class Loader API	java.lang

接口的原型及使用说明请参考下载CA标准及泰信官方网站。

2 实现：

智能卡CA应用的实现主要包含以下内容：CA应用的框架、ECM数据的接收处理、EMM数据的接收处理、CW的设置等。

1)      CA应用框架：

Android平台下，CA采用service组件功能来代替Xlet。每个CA是一个单独的应用，即一个APK文件，并且自己拥有界面。CA采用android应用基本组件service来管理自己的生命周期。CA应用通过监听“android.intent.action.BOOT_COMPLETED”广播，并在广播后启动自身的service，在service启动中完成如startXlet相同的功能：完成自身的初始化，解扰服务可用后，完成向CASModuleManager的注册。CA应用采用Android的Activity来实现其图形化的管理功能，像授权信息显示，电视邮件显示、阅读、删除等。另外CA应用、平台和其他应用通过Android提供的Binder跨进程通讯机制实现交互。

2)ECM数据的接收处理：

根据ECM的属性此处建议使用SimpleSectionFilter接收ECM数据，详细原因请参照davic接口的使用。ECM数据的接收始于public void startDescrambling(CASSession  casSession,CAServiceComponentInfo casci[])接口被调用，设置filter接收数据用到的TransportStream来自于参数casSession，CA system id及ECM pid的信息来自于参数casci. ECM数据被接收后，送往智能卡中解析处理得到加密的控制字CW。

3)EMM数据的接收处理：

单向情况下EMM数据的接收根据各CA的特点使用不同的filter类型，此处建议使用RingSectionFilter，大小根据实际情况设定。EMM数据的接收始于接收到CAT数据，并解析到对应的CA描述符，为此标准中给出了public void catUpdate(CADescriptor desc, org.davic.net.tuning.NetworkInterface ni);的接口，但为处理方便，我们建议上层CA应用自己申请CAT，自己把握申请CAT的时机，接收到CAT解析出EMM PID后，设置EMM的filter接收EMM数据。双向环境下可创建socket或者http(s)客户端定时向服务器申请授权信息的CA数据。接收到EMM数据后，根据各CA的情况解析得到授权、反授权等信息。

4)CW的设置：

标准中提供的设置CW的接口为：loadCW，其接口原型为：

public void loadCW(int VendorID, CWKey cwKey, Key[] levelKeys, int schemeId) throws CADriverException；将智能卡解出的CW通过这个接口设置到底层，这个周期的节目就可以正常解扰播放了。循环上述的ECM接收处理和CW设置的过程就可以完成节目的正常播放了。

txca

3 界面
CA应用同时需要UI提供一定接口用于智能卡信息显示、授权信息显示、电视邮件显示、阅读、删除等。Android平台下建议该界面及相应交互由CA应用采用Android自带的Activity来实现。

4 和下载CA应用的区别
我们知道NGB下载CA标准中规定的下载CA是无卡设计，所以智能卡CA应用同下载CA应用开发最大的区别是智能卡通讯部分，包括智能卡的复位、初始化、CA信息的获取以及ECM、EMM数据的解密处理以及机卡配对功能等，泰信DTVOS在NGB标准接口的基础上扩展了智能卡设备的接口，通过设备接口结合各CA的具体通讯协议，比如采用什么样的协议T0、T1、T14？各指令的格式是什么，如何打包，收到指令后智能卡多长时间回应，回应的格式是什么，要不要校验，要不要解密，如何解析等，就可以在CA应用中完成传统CA库中同智能卡通讯部分的功能。

    智能卡CA应用同下载CA应用的另一个区别是在刚才提到的CW设置上，由于下载CA采用了层级密钥机制，所以在设置CW时候设置的是加密的CW，同时又设置了各加密的层级密钥，而目前的智能卡CA由于不具备这个机制所以设置时有所区别，结合标准中提供的设置CW的接口：loadCW，其接口原型为：

public void loadCW(int VendorID, CWKey cwKey, Key[] levelKeys, int schemeId) throws CADriverException；

本方法用于通知终端软件平台向解扰器装入控制字，并向终端安全芯片装入所需密钥。

其中@param cwKey 控制字，如果控制字是明文，levelKeys参数被忽略，如果cwKey为null,，即CA应用没有提供有效的控制字。

    @param levelKeys 用于置入终端安全芯片的多级密钥.密钥数组的索引等于终端安全芯片中的绝对位置，在数组中特定元素值为Null表明终端安全芯片中相应位置不应装入密钥.

@param schemeId 本schemeId用于指定终端安全芯片的加密算法(例如，AES，TDES)

@ChipController接口中定义了方式（scheme）值的列表。如果控制器只支持一种方式，则该值被忽略。

如果不考虑高级安全的环境，智能卡解出CW后设置的CW将是提到的控制字是明文的情况，参考CWKey的定义。

public class CWKey extends Key

{

public static final int PARITY_EVEN = 0;

public static final int PARITY_ODD = 1;
/*

* @param value 密钥的值
* @param真值标识密钥是加密的，假值表示密钥未加密.
* @param 奇偶值，表明控制字的奇偶性.

*/

public CWKey(byte[] value, boolean encrypted, int parity)

/**
* 本方法返回控制字的奇偶性.
* @return 控制字的奇偶性.
*/

public int getParity()

}


假定偶奇CW数组分别是：evencw、oddcw，对应CWKey是ECW[0]、ECW[1]，那么

  ECW[0] = new CWKey(evencw, false, 0);

  ECW[1] = new CWKey(oddcw, false, 1);

设置CW的代码为：

try {

          descramblerContext.loadCW(0x1234, ECW [0], null,  ChipController.SCHEME_3DES);

            } catch (CADriverException ex) {

}

try {

          descramblerContext.loadCW(0x1234, ECW [1], null,  ChipController.SCHEME_3DES);

            } catch (CADriverException ex) {

}

结合这几点开发一个独立的智能卡CA应用的难度应该就不大了。

ysj113

看来泰信已经做足了在智能卡过渡到下载ca方面的技术储备，希望广电终端智能化、产业化能真正到来！

GreenDream

终端智能化、产业化是一大幸事，希望这一天别等的太久!

到此一游

嗯，今年CCBN在泰信的展台听他们的人讲过，不知道现在什么情况了？

496361700

不错呀