運營商發(fā)展國密UIM卡技術(shù)探討

郭建昌++姜奎

【摘 要】闡述了運營商發(fā)展國密UIM卡產(chǎn)品的必要性，介紹了國密卡產(chǎn)品的實現(xiàn)方法，對不同的實現(xiàn)方式進行了對比，并結(jié)合目前的產(chǎn)品推廣現(xiàn)狀提出了實現(xiàn)方案建議。

【關(guān)鍵詞】國密 運營商 移動支付 UIM 藍牙

doi：10.3969/j.issn.1006-1010.2017.02.015 中圖分類號：TN918.91 文獻標志碼：A 文章編號：1006-1010（2017）02-0074-05

引用格式：郭建昌，姜奎. 運營商發(fā)展國密UIM卡技術(shù)探討[J]. 移動通信， 2017，41（2）： 74-78.

1 引言

一場始于美國東部的大規(guī)?；ヂ?lián)網(wǎng)癱瘓于2016年21日席卷全美，美國公共服務、社交平臺、民眾網(wǎng)絡服務器等遭到空前網(wǎng)絡攻擊，半個國家的網(wǎng)絡幾乎陷入癱瘓。本次網(wǎng)絡癱瘓不僅規(guī)模驚人，而且對民眾生活產(chǎn)生了嚴重影響，帶來的損失超過數(shù)千萬美元。近期類似的信息安全事件引發(fā)了大眾的廣泛關(guān)注，隨著科技的發(fā)展和社會的進步，各行各業(yè)對于信息安全的需求越來越緊迫，信息安全已成為國家的重點戰(zhàn)略。

智能卡作為接入運營商網(wǎng)絡的鑒權(quán)工具以及承載各種應用、數(shù)據(jù)的安全載體，已經(jīng)成為信息安全技術(shù)發(fā)展的重要組成部分，在智能卡領(lǐng)域保障信息安全的關(guān)鍵技術(shù)就是采用各種密碼算法對數(shù)據(jù)進行加密存儲及運算。一直以來，我國長期沿用國際通用的密碼算法（如DES、3DES、RSA、SHA-1等）體系及相關(guān)標準，近年來國家密碼管理局先后發(fā)布了一系列由我國自主研發(fā)的國產(chǎn)商用密碼算法（包括SM2、SM3、SM4等）體系及相關(guān)標準，并在相關(guān)領(lǐng)域進行試點推廣。

近日，全國信息安全標準化技術(shù)委員會發(fā)布了24項與信息安全相關(guān)的國家標準，其中《信息安全技術(shù)具有中央處理器的IC卡嵌入式軟件安全技術(shù)要求》[1]、《信息安全技術(shù)具有中央處理器的IC卡芯片安全技術(shù)要求》[2]、《信息安全技術(shù)SM2橢圓曲線公鑰密碼算法》[3]、《信息安全技術(shù)SM3密碼雜湊算法》[4]、《信息安全技術(shù)SM4分組密碼算法》[5]等多項標準與智能卡行業(yè)有密切關(guān)聯(lián)。

隨著“互聯(lián)網(wǎng)+”戰(zhàn)略的逐步落地，各行各業(yè)之間的融合也日益加深，目前運營商均在推動利用手機終端和UIM卡在移動支付領(lǐng)域的發(fā)展，包括金融支付類、身份識別類、門禁考勤類、公交一卡通類、醫(yī)療衛(wèi)生類、社保健康卡、EID等，這與國密算法的應用領(lǐng)域不謀而合。運營商基于現(xiàn)有UIM卡產(chǎn)品實現(xiàn)國密算法，既減少對國際算法的依賴性，抵御現(xiàn)有的國際算法攻擊風險，可提供更加安全可靠的產(chǎn)品，又符合國家針對信息安全相關(guān)政策的要求，提高行業(yè)自主可控能力，更加有利于占領(lǐng)市場先機。

本文介紹了運營商實現(xiàn)國密UIM卡產(chǎn)品的實現(xiàn)方法，對不同的實現(xiàn)方式進行了對比驗證，并結(jié)合目前的產(chǎn)品推廣現(xiàn)狀提出了實現(xiàn)方案建議。

2 原理

運營商現(xiàn)有移動支付UIM卡是一種復合型電信智能卡?？ㄆ訳ICC多應用平臺為基礎進行構(gòu)建，引入了Java Card虛擬機（JCVM）[6]、Java Card運行時環(huán)境（JCRE）[7]、Global Platform運行環(huán)境（OPEN）[8]、非接觸框架（Contactless Framework）等多類應用的運行環(huán)境，從而實現(xiàn)了多個維度的“一卡多應用”。具體來說，運營商現(xiàn)有移動支付UIM卡可以在一張UICC上同時支持接觸式應用、非接觸應用、電信應用（NAA，如UIM、USIM）、非電信應用（如安全域、金融支付類應用、身份識別類應用、門禁考勤類應用、公交一卡通類應用、醫(yī)療衛(wèi)生類應用、社保健康卡應用等），實現(xiàn)多類應用并存的業(yè)務需求，所有應用均采用Java Applet方式實現(xiàn)，是一種可以應用于跨領(lǐng)域業(yè)務的電信智能卡。

運營商現(xiàn)有移動支付UIM卡架構(gòu)如圖1所示，主要由底層架構(gòu)和應用層組成，其中底層架構(gòu)主要由四部分組成：

（1）硬件層：UIM卡用于同外部設備進行通信的物理接口，包括ISO7816接口[9]、SWP接口[10]、藍牙接口等。

（2）COS層：提供內(nèi)存和文件等基礎管理，實現(xiàn)虛擬機和安全機制，實現(xiàn)底層傳輸協(xié)議及命令分發(fā)、APDU指令處理，并實現(xiàn)多個應用間防火墻等，為上層提供基礎的邏輯處理機制。

（3）應用基礎能力層：負責為UIM卡應用層的各種卡應用程序提供在卡內(nèi)容下載、安裝、刪除的管理和存儲等服務，并實現(xiàn)用戶卡與外部設備通信的指令報文，以及包含鑒權(quán)和加密機制的安全信道會話機制。實現(xiàn)GP應用管理、空間管理、生命周期管理，為UIM卡提供了與終端進行交互的應用工具箱能力（包括Setup Menu（菜單顯示）、Display（信息顯示）、Get Input（信息輸入）、Send Short Message（發(fā)送短信）、Set Up Call（撥打電話）等）。

（4）應用API層：為UIM卡應用層的各種卡應用程序提供基本調(diào)用接口，包括Java Card API、UICC/USIM API、GP API、HCI API等。

應用層則包括基礎功能需求應用（電信應用、CRS、CREL、JCPM等）、安全域（為安全隔離發(fā)卡方和應用提供方而創(chuàng)建的具有密鑰和卡內(nèi)容管理功能的特殊應用）以及各類可動態(tài)加載或預置的具有復雜處理邏輯的用戶卡應用（如金融支付類應用、身份識別類應用、門禁考勤類應用、公交一卡通類應用、醫(yī)療衛(wèi)生類應用、社保健康卡應用、EID應用等）。

本文提到的國密UIM卡產(chǎn)品實現(xiàn)方法，主要是針對COS底層架構(gòu)中的應用API層進行改造，實現(xiàn)國密算法API供應用層調(diào)用。

3 國密UIM卡產(chǎn)品實現(xiàn)方式

目前國密UIM卡產(chǎn)品主要有如下幾種實現(xiàn)方式：

（1）在現(xiàn)有的移動支付UIM卡上加載國密芯片；

（2）在現(xiàn)有的移動支付UIM卡上加載國密芯片和藍牙芯片；

（3）將現(xiàn)有移動支付UIM卡采用芯片替換為國密芯片；

（4）將現(xiàn)有移動支付UIM卡采用芯片替換為國密芯片，同時增加藍牙芯片。

3.1 現(xiàn)有移動支付UIM卡上加載國密芯片

該方案主要是為了解決運營商現(xiàn)有移動支付UIM卡產(chǎn)品不支持國密算法的問題，基于現(xiàn)有移動支付UIM卡增加國密芯片?，F(xiàn)有移動支付UIM卡底層COS調(diào)用國密芯片提供的國密算法接口，提供給應用層供Java Applet使用，這樣加載在移動支付UIM卡上金融支付類、身份識別類、門禁考勤類、公交一卡通類、醫(yī)療衛(wèi)生類、社保健康卡等領(lǐng)域的Java Applet應用就可以支持國密算法。

基于該方案現(xiàn)有移動支付UIM卡需進行如下改造：

（1）卡片需重新設計封裝；

（2）現(xiàn)有移動支付UIM卡COS底層需修改，增加與國密芯片交互接口，同時增加對外提供給Java Applet的國密算法接口。

該方案的優(yōu)缺點：

（1）原有移動支付UIM卡COS成熟度較高，對原有移動支付UIM卡COS底層改造較小，COS開發(fā)和測試難度較小；

（2）現(xiàn)有移動支付UIM卡COS底層與國密芯片交互為私有接口，存在一定的安全隱患，且性能比直接調(diào)用國密芯片底層算法接口慢；

（3）卡片重新設計封裝額外增加成本，且周期較長；

（4）未解決目前不支持Open Mobile API終端無法通過客戶端訪問UIM卡上的Java Applet問題。

3.2 現(xiàn)有移動支付UIM卡上加載國密芯片和藍牙

芯片

該方案基于3.1節(jié)的方案額外增加藍牙芯片，為了解決部分終端不支持Open Mobile API，無法通過客戶端訪問移動支付UIM卡上的Java Applet的問題。增加藍牙芯片后，手機終端可通過藍牙接口與移動支付UIM卡進行通信。

基于該方案現(xiàn)有移動支付UIM卡需進行如下改造：

（1）卡片需重新設計封裝；

（2）現(xiàn)有移動支付UIM卡COS底層需修改，增加與國密芯片交互接口，同時增加對外提供給Java Applet的國密算法接口。

該方案的優(yōu)缺點：

（1）原有移動支付UIM卡COS成熟度較高，對于原有移動支付UIM卡COS底層改造較小，COS開發(fā)和測試難度較小；

（2）現(xiàn)有移動支付UIM卡COS底層與國密芯片交互為私有接口，存在一定的安全隱患，且性能比直接調(diào)用國密芯片底層算法接口慢；

（3）卡片重新設計封裝，額外增加成本，且周期較長；

（4）增加兩顆芯片后卡片封裝受限，無法封裝成Mini-UICC（4FF）形態(tài)，在目前卡槽設計為Mini-UICC形態(tài)的終端上無法使用；

（5）終端與UIM卡進行藍牙交互目前暫無標準協(xié)議接口，且目前終端與卡片進行藍牙交互成熟度不高，可能存在兼容性問題。

3.3 現(xiàn)有移動支付UIM卡芯片替換為國密芯片

該方案主要是將現(xiàn)有移動支付UIM卡采用的國外芯片替換為國密芯片，UIM卡底層COS可以直接調(diào)用國密芯片提供的國密算法接口，提供國密算法API給應用層供Java Applet使用，這樣加載在移動支付UIM卡上的金融支付類、身份識別類、門禁考勤類、公交一卡通類、醫(yī)療衛(wèi)生類、社保健康卡等領(lǐng)域的Java Applet應用就可以支持國密算法。

基于該方案，現(xiàn)有移動支付UIM卡需進行如下改造：

需基于國密芯片實現(xiàn)原移動支付UIM卡產(chǎn)品所有功能，同時將國密芯片提供的國密算法接口改造成可供應用層調(diào)用的國密算法API接口，其中國密算法API調(diào)用流程如圖2所示。

安全應用調(diào)用國密算法API的流程說明如下：

（1）獲得移動支付UIM卡算法能力：調(diào)用安全應用的客戶端軟件使用移動支付UIM卡的基本命令，獲取移動支付UIM卡上的算法能力，該命令和移動支付UIM卡上的安全應用無關(guān)。

（2）返回算法標識：移動支付UIM卡操作系統(tǒng)通過算法標識返回移動支付UIM卡支持的算法能力。如果載體不支持國密算法，流程結(jié)束；如果支持國密算法，轉(zhuǎn)步驟（3）。

（3）調(diào)用安全應用接口：如果移動支付UIM卡支持國密算法，調(diào)用安全應用的客戶端軟件調(diào)用移動支付UIM卡安全應用的命令接口。移動支付UIM卡安全應用收到調(diào)用命令后，根據(jù)命令進行處理。

（4）調(diào)用國密算法API：如果該命令的處理需要使用國密算法，通過移動支付UIM卡操作系統(tǒng)的商用密碼算法API進行調(diào)用。

（5）返回算法調(diào)用結(jié)果：國密算法API被調(diào)用后，進行算法處理并向移動支付UIM卡上的安全應用返回算法處理結(jié)果。

（6）返回應用調(diào)用結(jié)果：移動支付UIM卡上的安全應用處理算法結(jié)束后，向客戶端返回調(diào)用結(jié)果，流程結(jié)束。

該方案的優(yōu)缺點：

（1）COS開發(fā)測試難度較大，需在新的芯片平臺進行功能移植（包含移動支付UIM卡架構(gòu)中所有功能）以及完整的產(chǎn)品化測試；

（2）卡片無需重新設計封裝；

（3）未解決目前不支持Open Mobile API終端無法通過客戶端訪問UIM卡上的Java Applet問題。

3.4 現(xiàn)有移動支付UIM卡采用芯片替換為國密芯

片，同時增加藍牙芯片

該方案基于3.3節(jié)方案增加藍牙芯片，手機終端可通過藍牙接口與移動支付UIM卡進行通信。

基于該方案現(xiàn)有移動支付UIM卡需進行如下改造：

（1）需基于國密芯片實現(xiàn)原移動支付UIM卡產(chǎn)品所有功能；

（2）卡片需重新設計封裝。

該方案的優(yōu)缺點：

（1）COS開發(fā)測試難度較大，需在新的芯片平臺進行功能移植、功能及產(chǎn)品化完整測試；

（2）卡片重新設計封裝，額外增加成本，且周期較長；

（3）終端與UIM卡進行藍牙交互目前暫無標準協(xié)議接口，且目前終端與卡片進行藍牙交互成熟度不高，可能存在兼容性問題。

4 國密UIM卡產(chǎn)品實現(xiàn)方式對照

目前國密UIM卡產(chǎn)品實現(xiàn)方式對照結(jié)果如表1所示。

5 結(jié)束語

運營商發(fā)展國密UIM卡產(chǎn)品需根據(jù)實際需求，綜合考慮實現(xiàn)方式。在目前終端與UIM卡交互成熟度不高的情況下，建議采用方案三，將現(xiàn)有移動支付UIM卡芯片替換為國密芯片。

參考文獻：

[1] 全國信息安全標準化技術(shù)委員會. GB/T 20276-2016 信息安全技術(shù)具有中央處理器的IC卡嵌入式軟件安全技術(shù)要求[S]. 2016.

[2] 全國信息安全標準化技術(shù)委員會. GB/T 22186-2016 信息安全技術(shù)具有中央處理器的IC卡芯片安全技術(shù)要求[S]. 2016.

[3] 全國信息安全標準化技術(shù)委員會. GB/T 32918-2016 信息安全技術(shù)SM2橢圓曲線公鑰密碼算法[S]. 2016.

[4] 全國信息安全標準化技術(shù)委員會. GB/T 32905-2016 信息安全技術(shù)SM3密碼雜湊算法[S]. 2016.

[5] 全國信息安全標準化技術(shù)委員會. GB/T 32907-2016 信息安全技術(shù)SM4分組密碼算法[S]. 2016.

[6] Oracle. E25256-01 Java Card 3 Platform Virtual Machine Specification， Classic Edition Version 3.0.4[S]. 2011.

[7] Oracle. E18985-01 Java Card 3 Platform Runtime Environment Specification， Classic Edition Version 3.0.4[S]. 2011.

[8] Global Platform. GPC_SPE_034 Card Specification Version 2.2.1[S]. 2011.

[9] ISO/IEC. Identification cards—Integrated circuit cards—Part 4： Organization， security and commands for interchange[S]. 2005.

[10] ETSI TS 102. 613. Smart Cards； UICC-Contactless Front-end （CLF） Interface； Part 1： Physical and data link layer characteristics[S]. 2012.★