智能卡操作系统的补丁机制研究
文章出处：http://www.singbon.com 作者：张李静, 张秋燕 人气： 发表时间：2011年09月30日
随着科学技术的不断进步，智能卡的应用已涉及到人类生活的各个领域，如商业、医疗、保险、交通、社会公共事业等多种领域。同时，用户手里的智能卡数量也越来越多，特别是同种类的卡由于要升级卡片信息往往需要换一张新卡。 所以，如何高效利用智能卡，即如何设计智能卡的补丁机制，以实现发卡后更新卡片应用程序或者修改卡片操作系统BUG是十分重要的课题。
1 智能卡操作系统概述
智能卡操作系统，简称COS。COS一般是紧紧围绕着它所服务的智能卡的特点而开发的。与那些常见的微机上的操作系统相比较而言， COS在本质上更加接近于监控程序。智能卡和终端进行通信是以命令的形式进行的。根据规范要求,系统所采用的都是命令应答对的方式，由读写设备发出命令，智能卡则接收命令，进行处理,处理完毕后送出相应的应答。所以，COS所需要解决的最根本问题是对外部的命令如何进行处理、响应的问题。
整个COS是通过文件来实现存储和管理数据的，文件结构系统类似于DOS的目录管理方式,可以实现多级目录，每个目录下面可以创建多种类型文件。文件系统是由专有文件DF (Dedicated File)和基本文件EF (Elementary File)组成的. 根目录的DF称为MF，任何一个文件组织均是以MF开头的结构.所有的其余文件(DF、EF)均是MF的分支， DF下可以创建DF和EF分支， EF是末端，不能在EF下创建文件，文件系统结构如图1所示。
图1 智能卡操作系统的文件结构
Fig. 1 File structures of COS
智能卡操作系统COS在设计主函数时比较通用的方式是设计成一个循环的方式. 循环实现智能卡接收命令, 进行处理, 处理完毕后送出相应的应答。
主程序在接收到终端发来的指令会经过传输管理模块,首先判断是什么样的指令,以及要对那些文件进行操作,操作后再返回主程序进行处理,返回相应的数据和执行结果. 智能卡和终端的交互过程是通过对卡内文件的连续操作进行的。
2 智能卡操作系统补丁机制的应用背景
2. 1 补丁在智能卡操作系统中的使用
通常,智能卡操作系统COS的下载方式是由芯片提供商决定的. 在下载COS之前,卡片的状态为BootLoader状态. 卡片BootLoader有一套自己的操作指令. 本文中的补丁机制研究以51系列智能卡为例， 实际操作时,采用的编译器是Keil编译器,程序编译后会产生一个. hex文件. 下载程序时把. hex文件中地址信息和对应的数据信息解析出来,然后用BootLoader的下载指令即可。
一般情况下,在下载完COS后,如果发现COS中有程序错误或者需要增加新的功能而需要修改某些函或文件,最简单的办法就是重新发卡,即回收卡片,重新下载COS. 但是当卡片已经在用户手中，这时，不仅要回收卡片,还要经历COS下载、个人化等阶段. 这就显的非常麻烦。 所以,我们在设计卡操作系统时最好能给出一个补丁( PATCH)的接口,这样的话,当卡片需要增加新的功能或是修改BUG时,只需将补丁程序下载到卡片这一个步骤。
2. 2 补丁的实现方式
传统的补丁设计方法是直接在程序中预留一段或者多段代码. 这样,当需要下载补丁时,只需将补丁程序写到预留的地址中去即可. 但是,由于在预留代码时一般不能确定未来下载补丁的大小和个数，所以，这种实现方法有一定的局限性，而且，在需要下载的补丁较大或者较多时,比较容易出现代码重叠的情况,使COS在执行过程中出现异常错误。
基于以上问题,下面结合51系列智能卡研究出一套补丁机制,这种方案适合任意的51系列智能卡的补丁下载. 该方法通过建立PATCH函数表和在操作系统主程序中设计调用补丁的接口来实现补丁的下载和管理，可以根据不同的补丁分类索引进行补丁下载，而且不再受补丁大小的限制，同时支持多个补丁的下载。
3 智能卡操作系统补丁机制方案设计
3. 1 实现机制
本文中智能卡操作系统的补丁机制采用地址映射表的方式实现. 即在EEPROM /FLASH ( ram)放置一个PATCH函数表(或者创建一个内部管理文件存储). 数据记录格式如表1所示. 其中, Patch ID值为自定义或运营商定义. Patch属性字节定义如表2所示。
3. 2 实现方式
1)在卡片中的系统数据区预先创建Patch索引表,预留足够的表空间。
2)在固化程序中预留可能会调用补丁的接口。
调用方式举例:
Judge_Patch函数位于固化程序中,它可以解析Patch索引表,根据Patch ID来确定是否有Patch需要执行,及获得Patch程序首地址. Judge_Patch函数中会自动将补丁程序的首地址赋给一个全局函数指针,所以如果存在Patch程序,可以直接调用函数指针实现对补丁函数的调用. 如果Judge_Patch函数返回0,表示没有找到相关的补丁函数,则继续执行原来的处理流程。
3)执行补丁程序, COS直接转到获得的Patch程序首地址开始执行. 补丁程序执行之前内部实现保护目前的程序地址和寄存器等。
4 实例分析
若智能卡操作系统的两个补丁函数为: AP I_FindDfEf_patch,即找到当前DF文件下的EF文件;Update_Record_Patch,即更新记录文件，下面给出具体进行补丁函数下载时的详细步骤:
1)编写补丁函数,并将这段代码下载到芯片的代码区空余位置(可以从COS编译后生成的文件中获取地址) ,并记录下载的首地址。
2)为当前补丁设置在补丁索引表中的位置和相关属性，如表4所示。
3)卡片复位,重新上电后，COS会通过Judge _Patch函数进行对判断是否要执行补丁函数以及执行哪个补丁，根据属性字节可知要执行的补丁是第一个补丁,即找到当前DF文件下的EF文件，Judge_Patch会送出补丁的起始地址,在接下来补丁程序，实现如下:
4)是补丁功能验证，卡片复位,执行选择DF下某EF文件指令。 因为该指令内部是通过前面下载的补丁来实现的。 所以,从指令的执行结果就能观察出本文中下载补丁的正确与否， 本例中，卡片返回正确的状态码以及所选EF的相关信息。
5 结 论
本文首先介绍智能卡操作系统的基本概念，其次结合接触式51系列智能卡芯片说明补丁下载在智能卡操作系统中的应用背景。并针对当前补丁下载方法的不足,提出了一种补丁管理机制。文中给出具体的实例，并进行分析，给出实现方法和步骤,同时验证了此补丁下载方法的可行性，本文中提出的补丁管理机制适合任意的51系列智能卡的补丁下载，而且不再受补丁大小的限制，并可根据不同的补丁分类索引进行补丁下载，因此，该方案具用很好的应用价值。
(文/天津理工大学计算机与通信工程学院, 张李静, 张秋燕)
