基于3G網(wǎng)絡(luò)的綁定式智能卡系統(tǒng)模型

文章出處：http://56733.cn 作者：周允強(qiáng)，李代平，劉志武，黃健，梅小虎，郭鴻志   人氣： 發(fā)表時(shí)間：2011年10月08日

    1 概述

    隨著 3G 網(wǎng)絡(luò)的發(fā)展以及微電子技術(shù)的進(jìn)步，智能卡硬件資源越來(lái)越豐富，使開(kāi)發(fā)一套適應(yīng)3G 網(wǎng)絡(luò)，能在智能卡中實(shí)現(xiàn)的芯片操作系統(tǒng)(Chip Operating System, COS)成為可能。同時(shí)，為滿足3G 用戶存儲(chǔ)大容量信息的需求，高端智能卡芯片也在頻繁更換，使兼容各大廠家芯片COS 的研發(fā)成為智能卡技術(shù)的發(fā)展趨勢(shì)。

    2 單晶片操作系統(tǒng)技術(shù)分析

    智能卡由硬件資源(智能卡芯片)與COS 組成，COS 是智能卡的核心。而針對(duì)某一種特定芯片開(kāi)發(fā)的COS，簡(jiǎn)稱為單晶片操作系統(tǒng)(Mini_COS)。

    2.1 3G 網(wǎng)絡(luò)UICC 平臺(tái)

    通用集成電路卡(Universe Integrated Circuit Card, UICC)是用在3G 網(wǎng)絡(luò)系統(tǒng)移動(dòng)終端的智能卡物理載體。同時(shí)，智能卡應(yīng)用功能的實(shí)現(xiàn)在3G 網(wǎng)絡(luò)下都需要UICC平臺(tái)的物理支撐。UICC 內(nèi)部集成電路一般由多個(gè)硬件構(gòu)成，但是每間公司的芯片設(shè)計(jì)和市場(chǎng)定位不一，導(dǎo)致各廠家的UICC 內(nèi)部結(jié)構(gòu)不一定相同，出現(xiàn)了一套COS 只能適合一種特定芯片的瓶頸問(wèn)題。

    2.2 Mini_COS 層次調(diào)用技術(shù)分析

    ISO7816 系列規(guī)范對(duì)智能卡的物理電氣特性、文件系統(tǒng)結(jié)構(gòu)、通信協(xié)議進(jìn)行了規(guī)定。傳統(tǒng)智能卡的COS 離不開(kāi)四大功能模塊與硬件底層的設(shè)計(jì)和開(kāi)發(fā)。Mini_COS 的層次調(diào)用模型如圖1 所示。

    Mini_COS 層次模型從整體上分為功能模塊層和微內(nèi)核層。功能模塊層主要實(shí)現(xiàn)COS 的應(yīng)用邏輯處理功能，并調(diào)用微內(nèi)核層中的底層驅(qū)動(dòng)模塊實(shí)現(xiàn)對(duì)硬件的操作，該層主要包含通信管理模塊、安全管理模塊、命令處理模塊及文件管理模塊。微內(nèi)核層主要對(duì)功能層的邏輯處理提供硬件支持，并直接實(shí)現(xiàn)對(duì)UICC 硬件的具體操作，如flash, DES, RNG,TIMER 等硬件的讀寫(xiě)程序。 

圖 1 Mini_COS 層次調(diào)用模型

    從圖 1 模型的層次調(diào)用關(guān)系來(lái)看，在讀寫(xiě)設(shè)備采用應(yīng)用協(xié)議數(shù)據(jù)單元(Application Protocol Data Unit, APDU)[2]直接與功能模塊層進(jìn)行通信后，APDU 命令使數(shù)據(jù)在智能卡層與層之間發(fā)生調(diào)用關(guān)系。與傳統(tǒng)COS 調(diào)用方式相比，Mini_COS具有更高的效率，主要體現(xiàn)在對(duì)安全管理模塊的設(shè)置上。在Mini_COS 系統(tǒng)中并沒(méi)有對(duì)所有文件系統(tǒng)中存儲(chǔ)和讀取數(shù)據(jù)進(jìn)行安全管理，例如與網(wǎng)絡(luò)鑒權(quán)中，連續(xù)訪問(wèn)同一文件時(shí)，不需要重復(fù)進(jìn)行安全處理，而是根據(jù)命令的類別需要來(lái)進(jìn)行適當(dāng)?shù)奶幚恚热绮糠治募?shù)據(jù)的加密等。而傳統(tǒng)COS 中所有與外界通信的數(shù)據(jù)都需經(jīng)過(guò)安全處理。

    2.3 Mini_COS 存在的問(wèn)題

    雖然 Mini_COS 比傳統(tǒng)COS 在數(shù)據(jù)傳輸效率上有明顯的改善，但其針對(duì)某一種特定芯片底層來(lái)開(kāi)發(fā)，產(chǎn)生如下問(wèn)題：

    (1)在COS 支持的上層應(yīng)用不變的情況下，當(dāng)更換不同的UICC 硬件時(shí)，需要重新了解新硬件COS 的開(kāi)發(fā)環(huán)境及底層技術(shù)細(xì)節(jié)，移植工作量非常巨大，不低于重新編寫(xiě)一次COS。

    (2)使用自然語(yǔ)言開(kāi)發(fā)的COS，大多采用層次結(jié)構(gòu)，開(kāi)發(fā)效率較低，編寫(xiě)的代碼量較大，增加了硬件的效率成本和存儲(chǔ)成本。

    (3)不同廠家開(kāi)發(fā)各自芯片時(shí)，需要研發(fā)適合自身芯片的操作系統(tǒng)和數(shù)據(jù)服務(wù)，造成操作系統(tǒng)、同類指令處理邏輯的重復(fù)開(kāi)發(fā)及利用。為了增強(qiáng) Mini_COS 上層邏輯在不同芯片上的適應(yīng)性，減小上層邏輯在不同UICC 上移植的難度，采用模型改進(jìn)的策略提高COS 開(kāi)發(fā)效率。

    3 綁定式多晶片操作系統(tǒng)模型

    針對(duì)目前大多數(shù)芯片的 COS 和多種UICC 硬件的不同結(jié)構(gòu)，提出綁定式多晶片COS 模型，簡(jiǎn)稱多晶片操作系統(tǒng)(Bind_Max_COS)模型。

    3.1 Bind_Max_COS 模型技術(shù)問(wèn)題分析

    Bind_Max_COS 模型是一個(gè)覆蓋模型，同時(shí)也是一個(gè)抽象模型，它并不是一個(gè)可以單獨(dú)編譯運(yùn)行的系統(tǒng)，簡(jiǎn)單地說(shuō)只是一種組件的管理概念。因此，直接掩模到具體UICC 芯片上的是在Bind_Max_COS 基礎(chǔ)上進(jìn)行建立、裁剪、抽象出來(lái)的符合用戶需求的Mini_COS，簡(jiǎn)稱Bind_Mini_COS。從Bind_Max_COS 演化為Bind_Mini_COS 的核心技術(shù)問(wèn)題如下： 

    (1)需要對(duì)不同底層硬件UICC 進(jìn)行分析，抽取其中相同或兼容硬件驅(qū)動(dòng)部分，記錄到驅(qū)動(dòng)庫(kù)中。

    (2)建立COS 適配器，針對(duì)特定芯片不同的硬件需求將覆蓋模型裁剪編譯成特定的COS 掩模灌裝到智能卡芯片中。 

    (3)如何為不同的UICC 底層硬件驅(qū)動(dòng)在覆蓋模型中建立正確的地址映射。

    針對(duì)上述問(wèn)題，下文給出一個(gè)綁定式多晶片 COS 模型。

    3.2 Bind_Max_COS 模型整體結(jié)構(gòu) 

    模型的設(shè)計(jì)原則遵從 IS07816 相關(guān)規(guī)范，以便提高不同芯片的兼容性。模型結(jié)構(gòu)如圖2 所示。 

圖 2 Bind_Max_COS 模型結(jié)構(gòu)

    硬件庫(kù)表示多個(gè)芯片 UICC 硬件驅(qū)動(dòng)程序的集合，不同的UICC 可以由不同的硬件屬性Pi 構(gòu)成，屬性Pi 有FLASH,DES, RNG, I/O, CPU 等硬件電路模塊，同時(shí)每一種屬性只能與驅(qū)動(dòng)庫(kù)中的一種驅(qū)動(dòng)Di 相對(duì)應(yīng)。另外，硬件庫(kù)采用設(shè)備管理表(Driver Manage Table, DMT)對(duì)UICC 屬性進(jìn)行檢索管理。驅(qū)動(dòng)庫(kù)表示硬件庫(kù)中所有硬件屬性 Pi 對(duì)應(yīng)的驅(qū)動(dòng)Di 的集合，一般硬件屬性Pi 的總量上限大于或等于驅(qū)動(dòng)Di 的總量上限，并且Di 與Pi 的對(duì)應(yīng)關(guān)系為一對(duì)一或一對(duì)多。驅(qū)動(dòng)庫(kù)是從硬件庫(kù)中抽象出來(lái)的，不同的UICC 對(duì)FLASH的擦除模式、DES 的運(yùn)算模式等都可以具有通用性，也就是說(shuō)一個(gè)Di 屬性至少可以同時(shí)兼容2 種以上不同芯片的Pi 屬性。

    驅(qū)動(dòng)管理器是微內(nèi)核設(shè)計(jì)的核心部分之一，主要實(shí)現(xiàn)對(duì)下層驅(qū)動(dòng)庫(kù)程序的管理，并且為上層接口層提供正確的驅(qū)動(dòng)程序映射。管理器通過(guò)設(shè)置驅(qū)動(dòng)控制表(Driver Control Table,DCT)實(shí)現(xiàn)對(duì)底層驅(qū)動(dòng)的管理。DCT 中每一項(xiàng)可以代表一種具體硬件屬性的驅(qū)動(dòng)，但實(shí)際上存儲(chǔ)的是硬件屬性對(duì)應(yīng)的在驅(qū)動(dòng)庫(kù)中放置的驅(qū)動(dòng)映射地址，DCT 只是一種管理機(jī)制。 

    上層接口層表示微內(nèi)核與上層功能模塊通信的接口。該層設(shè)計(jì)的好壞直接影響到上層邏輯應(yīng)用到不同的UICC 時(shí)，對(duì)上層代碼修改工作量的大小。因此，進(jìn)行COS 設(shè)計(jì)時(shí)必須考慮底層接口對(duì)上層應(yīng)用邏輯的通用性，盡量使用不同UICC均支持的函數(shù)接口。

    本模型將 UICC 硬件底層的設(shè)計(jì)與上層功能模塊的設(shè)計(jì)進(jìn)行分離，使得底層硬件驅(qū)動(dòng)的動(dòng)態(tài)部署成為可能。模型中的微內(nèi)核層由四大部件構(gòu)成，其中硬件庫(kù)集成了不同UICC屬性的驅(qū)動(dòng)，通過(guò)抽象的對(duì)比與篩選，把不同芯片的等價(jià)驅(qū)動(dòng)采用驅(qū)動(dòng)控制表(DCT)記錄入驅(qū)動(dòng)庫(kù)中，大大減少了驅(qū)動(dòng)程序代碼量。而且在上層功能模塊不變的情況下，相對(duì)Mini_COS 模型，Bind_Max_COS 模型解決了更換硬件時(shí)不需重新移植的問(wèn)題，實(shí)現(xiàn)了重新選擇相應(yīng)硬件的驅(qū)動(dòng)組件編譯構(gòu)成新COS 的功能，做到了“一次開(kāi)發(fā)，到處運(yùn)行”。另外，采用了模型改進(jìn)的策略，提高了COS 的運(yùn)行效率等。

    3.3 DCT 和DMT 表建立工作流程

    DCT 和DMT 表分別表示對(duì)硬件庫(kù)和驅(qū)動(dòng)庫(kù)中硬件屬性驅(qū)動(dòng)程序在庫(kù)中放置的映射地址的記錄，實(shí)質(zhì)是一種管理機(jī)制，在庫(kù)中驅(qū)動(dòng)代碼散列放置，采用上述管理機(jī)制來(lái)實(shí)現(xiàn)對(duì)驅(qū)動(dòng)代碼的檢索和管理。工作流程如圖3 所示。 

圖 3 DCT 和DMT 表工作流程

    DMT 表記錄了某個(gè)UICCk 硬件中的CPU, FLASH, I/O,DES, TRNG 等模塊信息，以地址值標(biāo)識(shí)該模塊驅(qū)動(dòng)程序在內(nèi)存中的存儲(chǔ)位置。DCT 表針對(duì)DMT 表的所有UICC 硬件中某個(gè)同類模塊的信息進(jìn)行記錄，例如，DCT 中的FLASH 表示目前DMT 表中所有UICC 具有FLASH存儲(chǔ)模塊這一共性，其中包括DCT_FLASH1, DCT_FLASHi, DCT_FLASHk 等不同特征的子屬性，也就是說(shuō)，不同UICC 的FLASH 控制方式不一樣，比如FLASH 容量大小不一、擦寫(xiě)模式不統(tǒng)一等，這些都可能導(dǎo)致不同UICC 具有不同的驅(qū)動(dòng)程序等。從理論上來(lái)說(shuō)，F(xiàn)LASH 所有屬性數(shù)量不應(yīng)大于DMT 表中UICC 的總數(shù)量，而且每一個(gè)屬性與DMT 表中同類屬性存在一對(duì)一或一對(duì)多的關(guān)系，也就是說(shuō)DCT_FLASHi 可以適合UICC1中的DMT_FLASH，或者同時(shí)適合UICC1 和UICCk 中的DMT_FLASH。DCT 表中的其余硬件模塊類似。

    假設(shè)要往兩表添加 UICCk 的新FLASHk 屬性，首先通過(guò)驅(qū)動(dòng)管理器的驅(qū)動(dòng)匹配處理，從DCT 表FLASH 模塊中尋找是否存在與新FLASHk 硬件模塊相匹配的子屬性，若有匹配的子屬性 DCT_FLASHi，就采用當(dāng)前DCT_FLASHi 作為新FLASH 的驅(qū)動(dòng)。若不存在，則往DMT 表相應(yīng)位置添加新FLASHk 屬性，然后把新FLASHk 屬性存儲(chǔ)信息添加到DCT表的FLASH 模塊中，并且采用屬性DCT_FLASHk 作為新FLASH 的驅(qū)動(dòng)。

    4 模型可行性分析及評(píng)估

    4.1 可行性分析

    Bind_Max_COS 模型的實(shí)現(xiàn)是以Mini_COS 模型為基礎(chǔ)，通過(guò)對(duì)各廠家的芯片進(jìn)行分析，把芯片的不同硬件屬性及驅(qū)動(dòng)程序記錄入庫(kù)，根據(jù)用戶的需求，對(duì)Bind_Max_COS 進(jìn)行裁剪，抽象到符合用戶需求的Bind_Mini_COS。其生成模型如圖4 所示。 

圖 4 Bind_Mini_COS 生成模型

     Bind_Max_COS 模型只是一個(gè)覆蓋模型，不能單獨(dú)編譯生成COS 腳本并掩模到智能卡芯片中，而掩模到芯片中的只能是Mini_COS 或Bind_Mini_COS。因此，Bind_Max_COS中的硬件適配部分可以采用軟件形式在PC 機(jī)上實(shí)現(xiàn)，用戶通過(guò)選擇界面選擇適合的硬件設(shè)備及型號(hào)，并通過(guò)COS 適配器生成具有綁定用戶需求功能的COS 腳本，利用讀卡器把COS 腳本直接灌裝到智能卡芯片中，在芯片中運(yùn)行的系統(tǒng)就是Bind_Mini_COS。另外，Bind_Max_COS 可以不被智能卡的代碼存儲(chǔ)空間和運(yùn)行時(shí)間效率因素所限制，硬件各模塊不同類型的驅(qū)動(dòng)程序可以存儲(chǔ)在PC 機(jī)上，根據(jù)用戶的需求來(lái)調(diào)用。

    基于本綁定式智能卡系統(tǒng)模型的實(shí)現(xiàn)，通過(guò)對(duì)芯片進(jìn)行硬件底層技術(shù)分析，根據(jù)不同用戶需求，對(duì)模型中的驅(qū)動(dòng)庫(kù)和硬件庫(kù)進(jìn)行動(dòng)態(tài)部署，實(shí)現(xiàn)了將一套智能卡COS 應(yīng)用到不同芯片上，證明了方案的可行性。

    4.2 模型評(píng)估

    Mini_COS 模型主要針對(duì)的是上層應(yīng)用邏輯設(shè)計(jì)和某個(gè)具體芯片的底層設(shè)計(jì)，主要解決上層邏輯應(yīng)用問(wèn)題，相比傳統(tǒng)的COS，該模型在安全鑒別及文件數(shù)據(jù)處理上有較高的效率。Bind_Max_COS 模型針對(duì)的是對(duì)多個(gè)芯片底層的設(shè)計(jì)，主要解決在多個(gè)芯片上的驅(qū)動(dòng)共享和移植問(wèn)題， 相比Mini_COS，該模型能夠支持更多的芯片，提高了COS 的適應(yīng)性。Bind_Mini_COS 模型是在Bind_Max_COS 模型基礎(chǔ)上，根據(jù)用戶的需求，進(jìn)行裁剪、抽象而成，除了繼承Mini_COS和Bind_Max_COS 兩大模型的優(yōu)點(diǎn)外，具有很好的延展性，方便日后在單張智能卡上實(shí)現(xiàn)多應(yīng)用功能。

    基于商業(yè)理由，大多數(shù)廠商對(duì)自己的芯片技術(shù)都是保密的，在一定程度上阻礙了綁定式智能卡模型的推廣。因此，在技術(shù)實(shí)現(xiàn)共享，對(duì)絕大部分廠家芯片技術(shù)進(jìn)行覆蓋后，才能真正證明模型的有效性和實(shí)用性。

    5 結(jié)束語(yǔ)

    本文針對(duì)傳統(tǒng)開(kāi)發(fā)的智能卡COS 不能有效移植到不同芯片上的問(wèn)題，提出了綁定式多晶片智能卡系統(tǒng)模型，在一定程度上解決了智能卡系統(tǒng)中功能模塊與UICC 硬件底層不相兼容的難題，為日后COS 的“一次開(kāi)發(fā)，到處運(yùn)行”奠定了基礎(chǔ)。另外，對(duì)于如何有效判斷已有的驅(qū)動(dòng)能否適合新硬件的問(wèn)題還沒(méi)作深入研究，該方向?qū)⒊蔀橄乱徊窖芯康闹攸c(diǎn)。