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

    1 概述

    随着 3G 网络的发展以及微电子技术的进步，智能卡硬件资源越来越丰富，使开发一套适应3G 网络，能在智能卡中实现的芯片操作系统(Chip Operating System, COS)成为可能。同时，为满足3G 用户存储大容量信息的需求，高端智能卡芯片也在频繁更换，使兼容各大厂家芯片COS 的研发成为智能卡技术的发展趋势。

    2 单晶片操作系统技术分析

    智能卡由硬件资源(智能卡芯片)与COS 组成，COS 是智能卡的核心。而针对某一种特定芯片开发的COS，简称为单晶片操作系统(Mini_COS)。

    2.1 3G 网络UICC 平台

    通用集成电路卡(Universe Integrated Circuit Card, UICC)是用在3G 网络系统移动终端的智能卡物理载体。同时，智能卡应用功能的实现在3G 网络下都需要UICC平台的物理支撑。UICC 内部集成电路一般由多个硬件构成，但是每间公司的芯片设计和市场定位不一，导致各厂家的UICC 内部结构不一定相同，出现了一套COS 只能适合一种特定芯片的瓶颈问题。

    2.2 Mini_COS 层次调用技术分析

    ISO7816 系列规范对智能卡的物理电气特性、文件系统结构、通信协议进行了规定。传统智能卡的COS 离不开四大功能模块与硬件底层的设计和开发。Mini_COS 的层次调用模型如图1 所示。

    Mini_COS 层次模型从整体上分为功能模块层和微内核层。功能模块层主要实现COS 的应用逻辑处理功能，并调用微内核层中的底层驱动模块实现对硬件的操作，该层主要包含通信管理模块、安全管理模块、命令处理模块及文件管理模块。微内核层主要对功能层的逻辑处理提供硬件支持，并直接实现对UICC 硬件的具体操作，如flash, DES, RNG,TIMER 等硬件的读写程序。 

图 1 Mini_COS 层次调用模型

    从图 1 模型的层次调用关系来看，在读写设备采用应用协议数据单元(Application Protocol Data Unit, APDU)[2]直接与功能模块层进行通信后，APDU 命令使数据在智能卡层与层之间发生调用关系。与传统COS 调用方式相比，Mini_COS具有更高的效率，主要体现在对安全管理模块的设置上。在Mini_COS 系统中并没有对所有文件系统中存储和读取数据进行安全管理，例如与网络鉴权中，连续访问同一文件时，不需要重复进行安全处理，而是根据命令的类别需要来进行适当的处理，比如部分文件数据的加密等。而传统COS 中所有与外界通信的数据都需经过安全处理。

    2.3 Mini_COS 存在的问题

    虽然 Mini_COS 比传统COS 在数据传输效率上有明显的改善，但其针对某一种特定芯片底层来开发，产生如下问题：

    (1)在COS 支持的上层应用不变的情况下，当更换不同的UICC 硬件时，需要重新了解新硬件COS 的开发环境及底层技术细节，移植工作量非常巨大，不低于重新编写一次COS。

    (2)使用自然语言开发的COS，大多采用层次结构，开发效率较低，编写的代码量较大，增加了硬件的效率成本和存储成本。

    (3)不同厂家开发各自芯片时，需要研发适合自身芯片的操作系统和数据服务，造成操作系统、同类指令处理逻辑的重复开发及利用。为了增强 Mini_COS 上层逻辑在不同芯片上的适应性，减小上层逻辑在不同UICC 上移植的难度，采用模型改进的策略提高COS 开发效率。

    3 绑定式多晶片操作系统模型

    针对目前大多数芯片的 COS 和多种UICC 硬件的不同结构，提出绑定式多晶片COS 模型，简称多晶片操作系统(Bind_Max_COS)模型。

    3.1 Bind_Max_COS 模型技术问题分析

    Bind_Max_COS 模型是一个覆盖模型，同时也是一个抽象模型，它并不是一个可以单独编译运行的系统，简单地说只是一种组件的管理概念。因此，直接掩模到具体UICC 芯片上的是在Bind_Max_COS 基础上进行建立、裁剪、抽象出来的符合用户需求的Mini_COS，简称Bind_Mini_COS。从Bind_Max_COS 演化为Bind_Mini_COS 的核心技术问题如下： 

    (1)需要对不同底层硬件UICC 进行分析，抽取其中相同或兼容硬件驱动部分，记录到驱动库中。

    (2)建立COS 适配器，针对特定芯片不同的硬件需求将覆盖模型裁剪编译成特定的COS 掩模灌装到智能卡芯片中。 

    (3)如何为不同的UICC 底层硬件驱动在覆盖模型中建立正确的地址映射。

    针对上述问题，下文给出一个绑定式多晶片 COS 模型。

    3.2 Bind_Max_COS 模型整体结构 

    模型的设计原则遵从 IS07816 相关规范，以便提高不同芯片的兼容性。模型结构如图2 所示。 

图 2 Bind_Max_COS 模型结构

    硬件库表示多个芯片 UICC 硬件驱动程序的集合，不同的UICC 可以由不同的硬件属性Pi 构成，属性Pi 有FLASH,DES, RNG, I/O, CPU 等硬件电路模块，同时每一种属性只能与驱动库中的一种驱动Di 相对应。另外，硬件库采用设备管理表(Driver Manage Table, DMT)对UICC 属性进行检索管理。驱动库表示硬件库中所有硬件属性 Pi 对应的驱动Di 的集合，一般硬件属性Pi 的总量上限大于或等于驱动Di 的总量上限，并且Di 与Pi 的对应关系为一对一或一对多。驱动库是从硬件库中抽象出来的，不同的UICC 对FLASH的擦除模式、DES 的运算模式等都可以具有通用性，也就是说一个Di 属性至少可以同时兼容2 种以上不同芯片的Pi 属性。

    驱动管理器是微内核设计的核心部分之一，主要实现对下层驱动库程序的管理，并且为上层接口层提供正确的驱动程序映射。管理器通过设置驱动控制表(Driver Control Table,DCT)实现对底层驱动的管理。DCT 中每一项可以代表一种具体硬件属性的驱动，但实际上存储的是硬件属性对应的在驱动库中放置的驱动映射地址，DCT 只是一种管理机制。