基于3G網(wǎng)絡(luò)的綁定式智能卡系統(tǒng)模型
文章出處:http://www.luckydriving.com 作者:周允強,李代平,劉志武,黃健,梅小虎,郭鴻志 人氣: 發(fā)表時間:2011年10月08日
1 概述
隨著 3G 網(wǎng)絡(luò)的發(fā)展以及微電子技術(shù)的進步,智能卡硬件資源越來越豐富,使開發(fā)一套適應(yīng)3G 網(wǎng)絡(luò),能在智能卡中實現(xiàn)的芯片操作系統(tǒng)(Chip Operating System, COS)成為可能。同時,為滿足3G 用戶存儲大容量信息的需求,高端智能卡芯片也在頻繁更換,使兼容各大廠家芯片COS 的研發(fā)成為智能卡技術(shù)的發(fā)展趨勢。
2 單晶片操作系統(tǒng)技術(shù)分析
智能卡由硬件資源(智能卡芯片)與COS 組成,COS 是智能卡的核心。而針對某一種特定芯片開發(fā)的COS,簡稱為單晶片操作系統(tǒng)(Mini_COS)。
2.1 3G 網(wǎng)絡(luò)UICC 平臺
通用集成電路卡(Universe Integrated Circuit Card, UICC)是用在3G 網(wǎng)絡(luò)系統(tǒng)移動終端的智能卡物理載體。同時,智能卡應(yīng)用功能的實現(xiàn)在3G 網(wǎng)絡(luò)下都需要UICC平臺的物理支撐。UICC 內(nèi)部集成電路一般由多個硬件構(gòu)成,但是每間公司的芯片設(shè)計和市場定位不一,導致各廠家的UICC 內(nèi)部結(jié)構(gòu)不一定相同,出現(xiàn)了一套COS 只能適合一種特定芯片的瓶頸問題。
2.2 Mini_COS 層次調(diào)用技術(shù)分析
ISO7816 系列規(guī)范對智能卡的物理電氣特性、文件系統(tǒng)結(jié)構(gòu)、通信協(xié)議進行了規(guī)定。傳統(tǒng)智能卡的COS 離不開四大功能模塊與硬件底層的設(shè)計和開發(fā)。Mini_COS 的層次調(diào)用模型如圖1 所示。
Mini_COS 層次模型從整體上分為功能模塊層和微內(nèi)核層。功能模塊層主要實現(xiàn)COS 的應(yīng)用邏輯處理功能,并調(diào)用微內(nèi)核層中的底層驅(qū)動模塊實現(xiàn)對硬件的操作,該層主要包含通信管理模塊、安全管理模塊、命令處理模塊及文件管理模塊。微內(nèi)核層主要對功能層的邏輯處理提供硬件支持,并直接實現(xiàn)對UICC 硬件的具體操作,如flash, DES, RNG,TIMER 等硬件的讀寫程序。
圖 1 Mini_COS 層次調(diào)用模型
從圖 1 模型的層次調(diào)用關(guān)系來看,在讀寫設(shè)備采用應(yīng)用協(xié)議數(shù)據(jù)單元(Application Protocol Data Unit, APDU)[2]直接與功能模塊層進行通信后,APDU 命令使數(shù)據(jù)在智能卡層與層之間發(fā)生調(diào)用關(guān)系。與傳統(tǒng)COS 調(diào)用方式相比,Mini_COS具有更高的效率,主要體現(xiàn)在對安全管理模塊的設(shè)置上。在Mini_COS 系統(tǒng)中并沒有對所有文件系統(tǒng)中存儲和讀取數(shù)據(jù)進行安全管理,例如與網(wǎng)絡(luò)鑒權(quán)中,連續(xù)訪問同一文件時,不需要重復進行安全處理,而是根據(jù)命令的類別需要來進行適當?shù)奶幚?,比如部分文件?shù)據(jù)的加密等。而傳統(tǒng)COS 中所有與外界通信的數(shù)據(jù)都需經(jīng)過安全處理。
2.3 Mini_COS 存在的問題
雖然 Mini_COS 比傳統(tǒng)COS 在數(shù)據(jù)傳輸效率上有明顯的改善,但其針對某一種特定芯片底層來開發(fā),產(chǎn)生如下問題:
(1)在COS 支持的上層應(yīng)用不變的情況下,當更換不同的UICC 硬件時,需要重新了解新硬件COS 的開發(fā)環(huán)境及底層技術(shù)細節(jié),移植工作量非常巨大,不低于重新編寫一次COS。
(2)使用自然語言開發(fā)的COS,大多采用層次結(jié)構(gòu),開發(fā)效率較低,編寫的代碼量較大,增加了硬件的效率成本和存儲成本。
(3)不同廠家開發(fā)各自芯片時,需要研發(fā)適合自身芯片的操作系統(tǒng)和數(shù)據(jù)服務(wù),造成操作系統(tǒng)、同類指令處理邏輯的重復開發(fā)及利用。為了增強 Mini_COS 上層邏輯在不同芯片上的適應(yīng)性,減小上層邏輯在不同UICC 上移植的難度,采用模型改進的策略提高COS 開發(fā)效率。
3 綁定式多晶片操作系統(tǒng)模型
針對目前大多數(shù)芯片的 COS 和多種UICC 硬件的不同結(jié)構(gòu),提出綁定式多晶片COS 模型,簡稱多晶片操作系統(tǒng)(Bind_Max_COS)模型。
3.1 Bind_Max_COS 模型技術(shù)問題分析
Bind_Max_COS 模型是一個覆蓋模型,同時也是一個抽象模型,它并不是一個可以單獨編譯運行的系統(tǒng),簡單地說只是一種組件的管理概念。因此,直接掩模到具體UICC 芯片上的是在Bind_Max_COS 基礎(chǔ)上進行建立、裁剪、抽象出來的符合用戶需求的Mini_COS,簡稱Bind_Mini_COS。從Bind_Max_COS 演化為Bind_Mini_COS 的核心技術(shù)問題如下:
(1)需要對不同底層硬件UICC 進行分析,抽取其中相同或兼容硬件驅(qū)動部分,記錄到驅(qū)動庫中。
(2)建立COS 適配器,針對特定芯片不同的硬件需求將覆蓋模型裁剪編譯成特定的COS 掩模灌裝到智能卡芯片中。
(3)如何為不同的UICC 底層硬件驅(qū)動在覆蓋模型中建立正確的地址映射。
針對上述問題,下文給出一個綁定式多晶片 COS 模型。
3.2 Bind_Max_COS 模型整體結(jié)構(gòu)
模型的設(shè)計原則遵從 IS07816 相關(guān)規(guī)范,以便提高不同芯片的兼容性。模型結(jié)構(gòu)如圖2 所示。
圖 2 Bind_Max_COS 模型結(jié)構(gòu)
硬件庫表示多個芯片 UICC 硬件驅(qū)動程序的集合,不同的UICC 可以由不同的硬件屬性Pi 構(gòu)成,屬性Pi 有FLASH,DES, RNG, I/O, CPU 等硬件電路模塊,同時每一種屬性只能與驅(qū)動庫中的一種驅(qū)動Di 相對應(yīng)。另外,硬件庫采用設(shè)備管理表(Driver Manage Table, DMT)對UICC 屬性進行檢索管理。驅(qū)動庫表示硬件庫中所有硬件屬性 Pi 對應(yīng)的驅(qū)動Di 的集合,一般硬件屬性Pi 的總量上限大于或等于驅(qū)動Di 的總量上限,并且Di 與Pi 的對應(yīng)關(guān)系為一對一或一對多。驅(qū)動庫是從硬件庫中抽象出來的,不同的UICC 對FLASH的擦除模式、DES 的運算模式等都可以具有通用性,也就是說一個Di 屬性至少可以同時兼容2 種以上不同芯片的Pi 屬性。
驅(qū)動管理器是微內(nèi)核設(shè)計的核心部分之一,主要實現(xiàn)對下層驅(qū)動庫程序的管理,并且為上層接口層提供正確的驅(qū)動程序映射。管理器通過設(shè)置驅(qū)動控制表(Driver Control Table,DCT)實現(xiàn)對底層驅(qū)動的管理。DCT 中每一項可以代表一種具體硬件屬性的驅(qū)動,但實際上存儲的是硬件屬性對應(yīng)的在驅(qū)動庫中放置的驅(qū)動映射地址,DCT 只是一種管理機制。
上層接口層表示微內(nèi)核與上層功能模塊通信的接口。該層設(shè)計的好壞直接影響到上層邏輯應(yīng)用到不同的UICC 時,對上層代碼修改工作量的大小。因此,進行COS 設(shè)計時必須考慮底層接口對上層應(yīng)用邏輯的通用性,盡量使用不同UICC均支持的函數(shù)接口。
本模型將 UICC 硬件底層的設(shè)計與上層功能模塊的設(shè)計進行分離,使得底層硬件驅(qū)動的動態(tài)部署成為可能。模型中的微內(nèi)核層由四大部件構(gòu)成,其中硬件庫集成了不同UICC屬性的驅(qū)動,通過抽象的對比與篩選,把不同芯片的等價驅(qū)動采用驅(qū)動控制表(DCT)記錄入驅(qū)動庫中,大大減少了驅(qū)動程序代碼量。而且在上層功能模塊不變的情況下,相對Mini_COS 模型,Bind_Max_COS 模型解決了更換硬件時不需重新移植的問題,實現(xiàn)了重新選擇相應(yīng)硬件的驅(qū)動組件編譯構(gòu)成新COS 的功能,做到了“一次開發(fā),到處運行”。另外,采用了模型改進的策略,提高了COS 的運行效率等。
3.3 DCT 和DMT 表建立工作流程
DCT 和DMT 表分別表示對硬件庫和驅(qū)動庫中硬件屬性驅(qū)動程序在庫中放置的映射地址的記錄,實質(zhì)是一種管理機制,在庫中驅(qū)動代碼散列放置,采用上述管理機制來實現(xiàn)對驅(qū)動代碼的檢索和管理。工作流程如圖3 所示。
圖 3 DCT 和DMT 表工作流程
DMT 表記錄了某個UICCk 硬件中的CPU, FLASH, I/O,DES, TRNG 等模塊信息,以地址值標識該模塊驅(qū)動程序在內(nèi)存中的存儲位置。DCT 表針對DMT 表的所有UICC 硬件中某個同類模塊的信息進行記錄,例如,DCT 中的FLASH 表示目前DMT 表中所有UICC 具有FLASH存儲模塊這一共性,其中包括DCT_FLASH1, DCT_FLASHi, DCT_FLASHk 等不同特征的子屬性,也就是說,不同UICC 的FLASH 控制方式不一樣,比如FLASH 容量大小不一、擦寫模式不統(tǒng)一等,這些都可能導致不同UICC 具有不同的驅(qū)動程序等。從理論上來說,F(xiàn)LASH 所有屬性數(shù)量不應(yīng)大于DMT 表中UICC 的總數(shù)量,而且每一個屬性與DMT 表中同類屬性存在一對一或一對多的關(guān)系,也就是說DCT_FLASHi 可以適合UICC1中的DMT_FLASH,或者同時適合UICC1 和UICCk 中的DMT_FLASH。DCT 表中的其余硬件模塊類似。
假設(shè)要往兩表添加 UICCk 的新FLASHk 屬性,首先通過驅(qū)動管理器的驅(qū)動匹配處理,從DCT 表FLASH 模塊中尋找是否存在與新FLASHk 硬件模塊相匹配的子屬性,若有匹配的子屬性 DCT_FLASHi,就采用當前DCT_FLASHi 作為新FLASH 的驅(qū)動。若不存在,則往DMT 表相應(yīng)位置添加新FLASHk 屬性,然后把新FLASHk 屬性存儲信息添加到DCT表的FLASH 模塊中,并且采用屬性DCT_FLASHk 作為新FLASH 的驅(qū)動。
4 模型可行性分析及評估
4.1 可行性分析
Bind_Max_COS 模型的實現(xiàn)是以Mini_COS 模型為基礎(chǔ),通過對各廠家的芯片進行分析,把芯片的不同硬件屬性及驅(qū)動程序記錄入庫,根據(jù)用戶的需求,對Bind_Max_COS 進行裁剪,抽象到符合用戶需求的Bind_Mini_COS。其生成模型如圖4 所示。
圖 4 Bind_Mini_COS 生成模型
Bind_Max_COS 模型只是一個覆蓋模型,不能單獨編譯生成COS 腳本并掩模到智能卡芯片中,而掩模到芯片中的只能是Mini_COS 或Bind_Mini_COS。因此,Bind_Max_COS中的硬件適配部分可以采用軟件形式在PC 機上實現(xiàn),用戶通過選擇界面選擇適合的硬件設(shè)備及型號,并通過COS 適配器生成具有綁定用戶需求功能的COS 腳本,利用讀卡器把COS 腳本直接灌裝到智能卡芯片中,在芯片中運行的系統(tǒng)就是Bind_Mini_COS。另外,Bind_Max_COS 可以不被智能卡的代碼存儲空間和運行時間效率因素所限制,硬件各模塊不同類型的驅(qū)動程序可以存儲在PC 機上,根據(jù)用戶的需求來調(diào)用。
基于本綁定式智能卡系統(tǒng)模型的實現(xiàn),通過對芯片進行硬件底層技術(shù)分析,根據(jù)不同用戶需求,對模型中的驅(qū)動庫和硬件庫進行動態(tài)部署,實現(xiàn)了將一套智能卡COS 應(yīng)用到不同芯片上,證明了方案的可行性。
4.2 模型評估
Mini_COS 模型主要針對的是上層應(yīng)用邏輯設(shè)計和某個具體芯片的底層設(shè)計,主要解決上層邏輯應(yīng)用問題,相比傳統(tǒng)的COS,該模型在安全鑒別及文件數(shù)據(jù)處理上有較高的效率。Bind_Max_COS 模型針對的是對多個芯片底層的設(shè)計,主要解決在多個芯片上的驅(qū)動共享和移植問題, 相比Mini_COS,該模型能夠支持更多的芯片,提高了COS 的適應(yīng)性。Bind_Mini_COS 模型是在Bind_Max_COS 模型基礎(chǔ)上,根據(jù)用戶的需求,進行裁剪、抽象而成,除了繼承Mini_COS和Bind_Max_COS 兩大模型的優(yōu)點外,具有很好的延展性,方便日后在單張智能卡上實現(xiàn)多應(yīng)用功能。
基于商業(yè)理由,大多數(shù)廠商對自己的芯片技術(shù)都是保密的,在一定程度上阻礙了綁定式智能卡模型的推廣。因此,在技術(shù)實現(xiàn)共享,對絕大部分廠家芯片技術(shù)進行覆蓋后,才能真正證明模型的有效性和實用性。
5 結(jié)束語
本文針對傳統(tǒng)開發(fā)的智能卡COS 不能有效移植到不同芯片上的問題,提出了綁定式多晶片智能卡系統(tǒng)模型,在一定程度上解決了智能卡系統(tǒng)中功能模塊與UICC 硬件底層不相兼容的難題,為日后COS 的“一次開發(fā),到處運行”奠定了基礎(chǔ)。另外,對于如何有效判斷已有的驅(qū)動能否適合新硬件的問題還沒作深入研究,該方向?qū)⒊蔀橄乱徊窖芯康闹攸c。