智能卡操作系統(tǒng)的補丁機制研究
文章出處：http://botanicstilllife.com 作者：張李靜, 張秋燕 人氣： 發(fā)表時間：2011年09月30日
隨著科學(xué)技術(shù)的不斷進步，智能卡的應(yīng)用已涉及到人類生活的各個領(lǐng)域，如商業(yè)、醫(yī)療、保險、交通、社會公共事業(yè)等多種領(lǐng)域。同時，用戶手里的智能卡數(shù)量也越來越多，特別是同種類的卡由于要升級卡片信息往往需要換一張新卡。 所以，如何高效利用智能卡，即如何設(shè)計智能卡的補丁機制，以實現(xiàn)發(fā)卡后更新卡片應(yīng)用程序或者修改卡片操作系統(tǒng)BUG是十分重要的課題。
1 智能卡操作系統(tǒng)概述
智能卡操作系統(tǒng)，簡稱COS。COS一般是緊緊圍繞著它所服務(wù)的智能卡的特點而開發(fā)的。與那些常見的微機上的操作系統(tǒng)相比較而言， COS在本質(zhì)上更加接近于監(jiān)控程序。智能卡和終端進行通信是以命令的形式進行的。根據(jù)規(guī)范要求,系統(tǒng)所采用的都是命令應(yīng)答對的方式，由讀寫設(shè)備發(fā)出命令，智能卡則接收命令，進行處理,處理完畢后送出相應(yīng)的應(yīng)答。所以，COS所需要解決的最根本問題是對外部的命令如何進行處理、響應(yīng)的問題。
整個COS是通過文件來實現(xiàn)存儲和管理數(shù)據(jù)的，文件結(jié)構(gòu)系統(tǒng)類似于DOS的目錄管理方式,可以實現(xiàn)多級目錄，每個目錄下面可以創(chuàng)建多種類型文件。文件系統(tǒng)是由專有文件DF (Dedicated File)和基本文件EF (Elementary File)組成的. 根目錄的DF稱為MF，任何一個文件組織均是以MF開頭的結(jié)構(gòu).所有的其余文件(DF、EF)均是MF的分支， DF下可以創(chuàng)建DF和EF分支， EF是末端，不能在EF下創(chuàng)建文件，文件系統(tǒng)結(jié)構(gòu)如圖1所示。
圖1 智能卡操作系統(tǒng)的文件結(jié)構(gòu)
Fig. 1 File structures of COS
智能卡操作系統(tǒng)COS在設(shè)計主函數(shù)時比較通用的方式是設(shè)計成一個循環(huán)的方式. 循環(huán)實現(xiàn)智能卡接收命令, 進行處理, 處理完畢后送出相應(yīng)的應(yīng)答。
主程序在接收到終端發(fā)來的指令會經(jīng)過傳輸管理模塊,首先判斷是什么樣的指令,以及要對那些文件進行操作,操作后再返回主程序進行處理,返回相應(yīng)的數(shù)據(jù)和執(zhí)行結(jié)果. 智能卡和終端的交互過程是通過對卡內(nèi)文件的連續(xù)操作進行的。
2 智能卡操作系統(tǒng)補丁機制的應(yīng)用背景
2. 1 補丁在智能卡操作系統(tǒng)中的使用
通常,智能卡操作系統(tǒng)COS的下載方式是由芯片提供商決定的. 在下載COS之前,卡片的狀態(tài)為BootLoader狀態(tài). 卡片BootLoader有一套自己的操作指令. 本文中的補丁機制研究以51系列智能卡為例， 實際操作時,采用的編譯器是Keil編譯器,程序編譯后會產(chǎn)生一個. hex文件. 下載程序時把. hex文件中地址信息和對應(yīng)的數(shù)據(jù)信息解析出來,然后用BootLoader的下載指令即可。
一般情況下,在下載完COS后,如果發(fā)現(xiàn)COS中有程序錯誤或者需要增加新的功能而需要修改某些函或文件,最簡單的辦法就是重新發(fā)卡,即回收卡片,重新下載COS. 但是當(dāng)卡片已經(jīng)在用戶手中，這時，不僅要回收卡片,還要經(jīng)歷COS下載、個人化等階段. 這就顯的非常麻煩。 所以,我們在設(shè)計卡操作系統(tǒng)時最好能給出一個補丁( PATCH)的接口,這樣的話,當(dāng)卡片需要增加新的功能或是修改BUG時,只需將補丁程序下載到卡片這一個步驟。
2. 2 補丁的實現(xiàn)方式
傳統(tǒng)的補丁設(shè)計方法是直接在程序中預(yù)留一段或者多段代碼. 這樣,當(dāng)需要下載補丁時,只需將補丁程序?qū)懙筋A(yù)留的地址中去即可. 但是,由于在預(yù)留代碼時一般不能確定未來下載補丁的大小和個數(shù)，所以，這種實現(xiàn)方法有一定的局限性，而且，在需要下載的補丁較大或者較多時,比較容易出現(xiàn)代碼重疊的情況,使COS在執(zhí)行過程中出現(xiàn)異常錯誤。
基于以上問題,下面結(jié)合51系列智能卡研究出一套補丁機制,這種方案適合任意的51系列智能卡的補丁下載. 該方法通過建立PATCH函數(shù)表和在操作系統(tǒng)主程序中設(shè)計調(diào)用補丁的接口來實現(xiàn)補丁的下載和管理，可以根據(jù)不同的補丁分類索引進行補丁下載，而且不再受補丁大小的限制，同時支持多個補丁的下載。
3 智能卡操作系統(tǒng)補丁機制方案設(shè)計
3. 1 實現(xiàn)機制
本文中智能卡操作系統(tǒng)的補丁機制采用地址映射表的方式實現(xiàn). 即在EEPROM /FLASH ( ram)放置一個PATCH函數(shù)表(或者創(chuàng)建一個內(nèi)部管理文件存儲). 數(shù)據(jù)記錄格式如表1所示. 其中, Patch ID值為自定義或運營商定義. Patch屬性字節(jié)定義如表2所示。
3. 2 實現(xiàn)方式
1)在卡片中的系統(tǒng)數(shù)據(jù)區(qū)預(yù)先創(chuàng)建Patch索引表,預(yù)留足夠的表空間。
2)在固化程序中預(yù)留可能會調(diào)用補丁的接口。
調(diào)用方式舉例:
Judge_Patch函數(shù)位于固化程序中,它可以解析Patch索引表,根據(jù)Patch ID來確定是否有Patch需要執(zhí)行,及獲得Patch程序首地址. Judge_Patch函數(shù)中會自動將補丁程序的首地址賦給一個全局函數(shù)指針,所以如果存在Patch程序,可以直接調(diào)用函數(shù)指針實現(xiàn)對補丁函數(shù)的調(diào)用. 如果Judge_Patch函數(shù)返回0,表示沒有找到相關(guān)的補丁函數(shù),則繼續(xù)執(zhí)行原來的處理流程。
3)執(zhí)行補丁程序, COS直接轉(zhuǎn)到獲得的Patch程序首地址開始執(zhí)行. 補丁程序執(zhí)行之前內(nèi)部實現(xiàn)保護目前的程序地址和寄存器等。
4 實例分析
若智能卡操作系統(tǒng)的兩個補丁函數(shù)為: AP I_FindDfEf_patch,即找到當(dāng)前DF文件下的EF文件;Update_Record_Patch,即更新記錄文件，下面給出具體進行補丁函數(shù)下載時的詳細步驟:
1)編寫補丁函數(shù),并將這段代碼下載到芯片的代碼區(qū)空余位置(可以從COS編譯后生成的文件中獲取地址) ,并記錄下載的首地址。
2)為當(dāng)前補丁設(shè)置在補丁索引表中的位置和相關(guān)屬性，如表4所示。
3)卡片復(fù)位,重新上電后，COS會通過Judge _Patch函數(shù)進行對判斷是否要執(zhí)行補丁函數(shù)以及執(zhí)行哪個補丁，根據(jù)屬性字節(jié)可知要執(zhí)行的補丁是第一個補丁,即找到當(dāng)前DF文件下的EF文件，Judge_Patch會送出補丁的起始地址,在接下來補丁程序，實現(xiàn)如下:
4)是補丁功能驗證，卡片復(fù)位,執(zhí)行選擇DF下某EF文件指令。 因為該指令內(nèi)部是通過前面下載的補丁來實現(xiàn)的。 所以,從指令的執(zhí)行結(jié)果就能觀察出本文中下載補丁的正確與否， 本例中，卡片返回正確的狀態(tài)碼以及所選EF的相關(guān)信息。
5 結(jié) 論
本文首先介紹智能卡操作系統(tǒng)的基本概念，其次結(jié)合接觸式51系列智能卡芯片說明補丁下載在智能卡操作系統(tǒng)中的應(yīng)用背景。并針對當(dāng)前補丁下載方法的不足,提出了一種補丁管理機制。文中給出具體的實例，并進行分析，給出實現(xiàn)方法和步驟,同時驗證了此補丁下載方法的可行性，本文中提出的補丁管理機制適合任意的51系列智能卡的補丁下載，而且不再受補丁大小的限制，并可根據(jù)不同的補丁分類索引進行補丁下載，因此，該方案具用很好的應(yīng)用價值。
(文/天津理工大學(xué)計算機與通信工程學(xué)院, 張李靜, 張秋燕)
