基于3G网络的绑定式智能卡系统模型

图 3 DCT 和DMT 表工作流程

    DMT 表记录了某个UICCk 硬件中的CPU, FLASH, I/O,DES, TRNG 等模块信息，以地址值标识该模块驱动程序在内存中的存储位置。DCT 表针对DMT 表的所有UICC 硬件中某个同类模块的信息进行记录，例如，DCT 中的FLASH 表示目前DMT 表中所有UICC 具有FLASH存储模块这一共性，其中包括DCT_FLASH1, DCT_FLASHi, DCT_FLASHk 等不同特征的子属性，也就是说，不同UICC 的FLASH 控制方式不一样，比如FLASH 容量大小不一、擦写模式不统一等，这些都可能导致不同UICC 具有不同的驱动程序等。从理论上来说，FLASH 所有属性数量不应大于DMT 表中UICC 的总数量，而且每一个属性与DMT 表中同类属性存在一对一或一对多的关系，也就是说DCT_FLASHi 可以适合UICC1中的DMT_FLASH，或者同时适合UICC1 和UICCk 中的DMT_FLASH。DCT 表中的其余硬件模块类似。

    假设要往两表添加 UICCk 的新FLASHk 属性，首先通过驱动管理器的驱动匹配处理，从DCT 表FLASH 模块中寻找是否存在与新FLASHk 硬件模块相匹配的子属性，若有匹配的子属性 DCT_FLASHi，就采用当前DCT_FLASHi 作为新FLASH 的驱动。若不存在，则往DMT 表相应位置添加新FLASHk 属性，然后把新FLASHk 属性存储信息添加到DCT表的FLASH 模块中，并且采用属性DCT_FLASHk 作为新FLASH 的驱动。

    4 模型可行性分析及评估

    4.1 可行性分析

    Bind_Max_COS 模型的实现是以Mini_COS 模型为基础，通过对各厂家的芯片进行分析，把芯片的不同硬件属性及驱动程序记录入库，根据用户的需求，对Bind_Max_COS 进行裁剪，抽象到符合用户需求的Bind_Mini_COS。其生成模型如图4 所示。 

图 4 Bind_Mini_COS 生成模型

     Bind_Max_COS 模型只是一个覆盖模型，不能单独编译生成COS 脚本并掩模到智能卡芯片中，而掩模到芯片中的只能是Mini_COS 或Bind_Mini_COS。因此，Bind_Max_COS中的硬件适配部分可以采用软件形式在PC 机上实现，用户通过选择界面选择适合的硬件设备及型号，并通过COS 适配器生成具有绑定用户需求功能的COS 脚本，利用读卡器把COS 脚本直接灌装到智能卡芯片中，在芯片中运行的系统就是Bind_Mini_COS。另外，Bind_Max_COS 可以不被智能卡的代码存储空间和运行时间效率因素所限制，硬件各模块不同类型的驱动程序可以存储在PC 机上，根据用户的需求来调用。

    基于本绑定式智能卡系统模型的实现，通过对芯片进行硬件底层技术分析，根据不同用户需求，对模型中的驱动库和硬件库进行动态部署，实现了将一套智能卡COS 应用到不同芯片上，证明了方案的可行性。

    4.2 模型评估

    Mini_COS 模型主要针对的是上层应用逻辑设计和某个具体芯片的底层设计，主要解决上层逻辑应用问题，相比传统的COS，该模型在安全鉴别及文件数据处理上有较高的效率。Bind_Max_COS 模型针对的是对多个芯片底层的设计，主要解决在多个芯片上的驱动共享和移植问题， 相比Mini_COS，该模型能够支持更多的芯片，提高了COS 的适应性。Bind_Mini_COS 模型是在Bind_Max_COS 模型基础上，根据用户的需求，进行裁剪、抽象而成，除了继承Mini_COS和Bind_Max_COS 两大模型的优点外，具有很好的延展性，方便日后在单张智能卡上实现多应用功能。

    基于商业理由，大多数厂商对自己的芯片技术都是保密的，在一定程度上阻碍了绑定式智能卡模型的推广。因此，在技术实现共享，对绝大部分厂家芯片技术进行覆盖后，才能真正证明模型的有效性和实用性。

    5 结束语

    本文针对传统开发的智能卡COS 不能有效移植到不同芯片上的问题，提出了绑定式多晶片智能卡系统模型，在一定程度上解决了智能卡系统中功能模块与UICC 硬件底层不相兼容的难题，为日后COS 的“一次开发，到处运行”奠定了基础。另外，对于如何有效判断已有的驱动能否适合新硬件的问题还没作深入研究，该方向将成为下一步研究的重点。