基于3G網絡的綁定式智能卡系統模型
文章出處：http://5052h112.com 作者：周允強，李代平，劉志武，黃健，梅小虎，郭鴻志 人氣： 發表時間：2011年10月08日
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 只是一種管理機制。
上層接口層表示微內核與上層功能模塊通信的接口。該層設計的好壞直接影響到上層邏輯應用到不同的UICC 時，對上層代碼修改工作量的大小。因此，進行COS 設計時必須考慮底層接口對上層應用邏輯的通用性，盡量使用不同UICC均支持的函數接口。
本模型將 UICC 硬件底層的設計與上層功能模塊的設計進行分離，使得底層硬件驅動的動態部署成為可能。模型中的微內核層由四大部件構成，其中硬件庫集成了不同UICC屬性的驅動，通過抽象的對比與篩選，把不同芯片的等價驅動采用驅動控制表(DCT)記錄入驅動庫中，大大減少了驅動程序代碼量。而且在上層功能模塊不變的情況下，相對Mini_COS 模型，Bind_Max_COS 模型解決了更換硬件時不需重新移植的問題，實現了重新選擇相應硬件的驅動組件編譯構成新COS 的功能，做到了“一次開發，到處運行”。另外，采用了模型改進的策略，提高了COS 的運行效率等。
3.3 DCT 和DMT 表建立工作流程
DCT 和DMT 表分別表示對硬件庫和驅動庫中硬件屬性驅動程序在庫中放置的映射地址的記錄，實質是一種管理機制，在庫中驅動代碼散列放置，采用上述管理機制來實現對驅動代碼的檢索和管理。工作流程如圖3 所示。
圖 3 DCT 和DMT 表工作流程
DMT 表記錄了某個UICCk 硬件中的CPU, FLASH, I/O,DES, TRNG 等模塊信息，以地址值標識該模塊驅動程序在內存中的存儲位置。DCT 表針對DMT 表的所有UICC 硬件中某個同類模塊的信息進行記錄，例如，DCT 中的FLASH 表示目前DMT 表中所有UICC 具有FLASH存儲模塊這一共性，其中包括DCT_FLASH1, DCT_FLASHi, DCT_FLASHk 等不同特征的子屬性，也就是說，不同UICC 的FLASH 控制方式不一樣，比如FLASH 容量大小不一、擦寫模式不統一等，這些都可能導致不同UICC 具有不同的驅動程序等。從理論上來說，FLASH 所有屬性數量不應大于DMT 表中UICC 的總數量，而且每一個屬性與DMT 表中同類屬性存在一對一或一對多的關系，也就是說DCT_FLASHi 可以適合UICC1中的DMT_FLASH，或者同時適合UICC1 和UICCk 中的DMT_FLASH。DCT 表中的其余硬件模塊類似。
假設要往兩表添加 UICCk 的新FLASHk 屬性，首先通過驅動管理器的驅動匹配處理，從DCT 表FLASH 模塊中尋找是否存在與新FLASHk 硬件模塊相匹配的子屬性，若有匹配的子屬性 DCT_FLASHi，就采用當前DCT_FLASHi 作為新FLASH 的驅動。若不存在，則往DMT 表相應位置添加新FLASHk 屬性，然后把新FLASHk 屬性存儲信息添加到DCT表的FLASH 模塊中，并且采用屬性DCT_FLASHk 作為新FLASH 的驅動。
4 模型可行性分析及評估
4.1 可行性分析
Bind_Max_COS 模型的實現是以Mini_COS 模型為基礎，通過對各廠家的芯片進行分析，把芯片的不同硬件屬性及驅動程序記錄入庫，根據用戶的需求，對Bind_Max_COS 進行裁剪，抽象到符合用戶需求的Bind_Mini_COS。其生成模型如圖4 所示。
圖 4 Bind_Mini_COS 生成模型
Bind_Max_COS 模型只是一個覆蓋模型，不能單獨編譯生成COS 腳本并掩模到智能卡芯片中，而掩模到芯片中的只能是Mini_COS 或Bind_Mini_COS。因此，Bind_Max_COS中的硬件適配部分可以采用軟件形式在PC 機上實現，用戶通過選擇界面選擇適合的硬件設備及型號，并通過COS 適配器生成具有綁定用戶需求功能的COS 腳本，利用讀卡器把COS 腳本直接灌裝到智能卡芯片中，在芯片中運行的系統就是Bind_Mini_COS。另外，Bind_Max_COS 可以不被智能卡的代碼存儲空間和運行時間效率因素所限制，硬件各模塊不同類型的驅動程序可以存儲在PC 機上，根據用戶的需求來調用。
基于本綁定式智能卡系統模型的實現，通過對芯片進行硬件底層技術分析，根據不同用戶需求，對模型中的驅動庫和硬件庫進行動態部署，實現了將一套智能卡COS 應用到不同芯片上，證明了方案的可行性。
4.2 模型評估
Mini_COS 模型主要針對的是上層應用邏輯設計和某個具體芯片的底層設計，主要解決上層邏輯應用問題，相比傳統的COS，該模型在安全鑒別及文件數據處理上有較高的效率。Bind_Max_COS 模型針對的是對多個芯片底層的設計，主要解決在多個芯片上的驅動共享和移植問題， 相比Mini_COS，該模型能夠支持更多的芯片，提高了COS 的適應性。Bind_Mini_COS 模型是在Bind_Max_COS 模型基礎上，根據用戶的需求，進行裁剪、抽象而成，除了繼承Mini_COS和Bind_Max_COS 兩大模型的優點外，具有很好的延展性，方便日后在單張智能卡上實現多應用功能。
基于商業理由，大多數廠商對自己的芯片技術都是保密的，在一定程度上阻礙了綁定式智能卡模型的推廣。因此，在技術實現共享，對絕大部分廠家芯片技術進行覆蓋后，才能真正證明模型的有效性和實用性。
5 結束語
本文針對傳統開發的智能卡COS 不能有效移植到不同芯片上的問題，提出了綁定式多晶片智能卡系統模型，在一定程度上解決了智能卡系統中功能模塊與UICC 硬件底層不相兼容的難題，為日后COS 的“一次開發，到處運行”奠定了基礎。另外，對于如何有效判斷已有的驅動能否適合新硬件的問題還沒作深入研究，該方向將成為下一步研究的重點。
