鄧志 伍衛(wèi)中 楊育文 李孟杰

（廣州羊城通有限公司 廣東省廣州市 510080）

1 概述

自交通運輸部印發(fā)《交通運輸部關(guān)于促進(jìn)交通一卡通健康發(fā)展加快實現(xiàn)互聯(lián)互通的指導(dǎo)意見》[1]以來，全國各省市在“統(tǒng)籌規(guī)劃、分步實施、標(biāo)準(zhǔn)先行”的建設(shè)原則指導(dǎo)下，運用先進(jìn)、成熟的計算機(jī)技術(shù)和IC 卡技術(shù)，建設(shè)高效、安全的一卡通應(yīng)用服務(wù)平臺，將一卡通全面應(yīng)用于公共汽車、地鐵、城際軌道、輪渡、長途客運、公共自行車、停車場、城市小額消費等領(lǐng)域，逐步全面推廣交通一卡通，實現(xiàn)跨區(qū)（市）域、跨交通方式互聯(lián)互通。

然而，在一卡通運營企業(yè)進(jìn)行全國交通一卡通票卡發(fā)行系統(tǒng)開發(fā)過程中，面臨如下幾個問題：

（1）各個票卡廠商有各自的票卡個人化指令規(guī)范[2]，在開發(fā)票卡發(fā)行系統(tǒng)時需要分別適配，導(dǎo)致開發(fā)成本高、時間長；

（2）各個票卡廠商有各自的個人化流程，導(dǎo)致不同廠商的票卡所使用的發(fā)行時間不一致，在安排人力資源與硬件資源時容易造成混亂；

（3）在開發(fā)票卡發(fā)行系統(tǒng)時，不能制定統(tǒng)一的代碼結(jié)構(gòu)，需要根據(jù)不同的廠家進(jìn)行針對性開發(fā)。

因此，迫切需要一套統(tǒng)一的個人化指令與發(fā)行流程的個人化規(guī)范方案來指導(dǎo)全國交通一卡通票卡個人化開發(fā)。

1.1 解析常規(guī)票卡個人化方案分析

CPU 票卡個人化分析。原羊城通省標(biāo)CPU 卡與捷德、握奇、天喻、復(fù)旦等10 多個廠家進(jìn)行票卡開發(fā)合作，每個廠家有各自定義的票卡個人化規(guī)范，與每個票卡廠家進(jìn)行對接開發(fā)，都需要按以下流程步驟進(jìn)行開發(fā)：

（1）學(xué)習(xí)票卡廠家提供的票卡COS 開發(fā)手冊，熟悉個人化指令，包括文件新建、刪除、修改，密鑰新建、刪除、修改等。

（2）根據(jù)票卡卡結(jié)構(gòu)，結(jié)合票卡COS 開發(fā)手冊，開發(fā)票卡個人化腳本。

（3）將腳本導(dǎo)入票卡發(fā)行數(shù)據(jù)庫。

（4）修改票卡發(fā)行后臺程序代碼，兼容票卡廠家CPU 卡個人化指令。

（5）聯(lián)合票卡廠家進(jìn)行票卡發(fā)行調(diào)試，查找發(fā)行過程中出現(xiàn)的錯誤，修改錯誤后反復(fù)調(diào)試。

（6）票卡發(fā)行后對票卡進(jìn)行基礎(chǔ)功能測試與終端兼容性測試。票卡發(fā)行流程圖如圖1 所示。

1.2 引入STORE DATA的CPU設(shè)計方案，提高一卡通票卡個人化效率

圖1：票卡發(fā)行流程圖

票卡發(fā)行的優(yōu)點主要有兩方面，第一方面是，個人化指令通過密文+MAC 的方式傳輸，保證個人化數(shù)據(jù)的安全。另外一方面是，每條個人化指令都需要取卡片隨機(jī)數(shù)參與運算，從而有效增強(qiáng)個人化數(shù)據(jù)破解難度。同時它的缺點也很明顯，首先，每個廠家有各自的APDU 指令規(guī)范，每次接入新廠家都需要重復(fù)修改票卡發(fā)行平臺，新增該廠家的票卡發(fā)行功能。另外個人化指令腳本數(shù)量太多，并且無法壓縮，造成終端在發(fā)行票卡時，需要與后臺發(fā)送與接收200 多個來回的個人化數(shù)據(jù)，導(dǎo)致每張票卡的發(fā)行時間為30 秒，發(fā)卡效率較低。為此通過引入STORE DATA 的CPU 設(shè)計方案，實現(xiàn)票卡發(fā)行功能的統(tǒng)一，不但可以有效提高票卡發(fā)行的開發(fā)效率與票卡發(fā)行效率，而且還能增加資源的重復(fù)利用和減少浪費。既優(yōu)化了操作人員的票卡發(fā)行體驗，又降低票卡出貨時間。

2 基于STORE DATA的CPU票卡個人化方案設(shè)計及關(guān)鍵技術(shù)

2.1 NATIVE卡與JAVA卡

“NATIVE”與“JAVA”是針對加載在卡片上的應(yīng)用的開發(fā)環(huán)境而言的。NATIVE 卡應(yīng)用使用與NATIVE 平臺同樣的語言進(jìn)行開發(fā)，比如C,匯編等;JAVA 卡應(yīng)用是使用JAVA 語言開發(fā)的，而JAVA 平臺本身可以認(rèn)為是一個特殊的NATIVE 應(yīng)用。

NATIVE平臺通過統(tǒng)一卡片操作系統(tǒng)(COS)來實現(xiàn)所有的功能，所有功能接口都基于COS 來實現(xiàn)，并且需前期進(jìn)行開發(fā)，二次開發(fā)的難度非常大，并且功能少。而JAVA 平臺分為兩層結(jié)構(gòu)，底層為按照J(rèn)AVACARD 規(guī)范來實現(xiàn)，向上提供規(guī)范定義的接口（API），通常支持GP API。上層為按照應(yīng)用需求開發(fā)的APPLET，相當(dāng)于NAVTIVE 卡片上的ADF?？梢愿鶕?jù)不同類型的應(yīng)用，開發(fā)多個APPLET。這些APPLET 相互獨立，通過AID 來選擇。

前期羊城通票卡發(fā)行項目基于NATIVE 平臺實現(xiàn)，期間遇到眾多難題，例如二次開發(fā)的資源投入率高、票卡發(fā)行效率低等。由于JAVA 卡的接口規(guī)范多樣性以及應(yīng)用二次開發(fā)的方便性，本研究項目基于JAVA 平臺實現(xiàn)。

圖2：寫文件TAG 低2 字節(jié)定義

圖3：寫密鑰TAG 低字節(jié)定義

2.2 GP技術(shù)簡介

GlobalPlatform 是一家由支付和通信業(yè)的領(lǐng)先廠商、政府相關(guān)部門以及供應(yīng)商社區(qū)共同建立的一個組織，并率先提出了一個跨行業(yè)的智能卡全局基礎(chǔ)架構(gòu)及其實現(xiàn)，其目標(biāo)是為了減少隱藏在快速增長的跨行業(yè)、多應(yīng)用的智能卡背后的障礙，使得發(fā)卡商在各種各樣的卡片、終端和后臺系統(tǒng)前，繼續(xù)享有選擇的自由[3]。

對于Java 卡：GP 規(guī)范是Java 卡上的一套Java 應(yīng)用代碼管理機(jī)制，負(fù)責(zé)Java 應(yīng)用的安全管理，通過安全信道、安全域、密鑰權(quán)限等安全因素實現(xiàn)對Java 應(yīng)用的加載、安裝、刪除等動態(tài)管理。

安全域：卡片管理器作為GlobalPlatform 架構(gòu)中的首要組件起到了GlobalPlatform 卡片中心管理者的作用，特定的密鑰和安全管理應(yīng)用被稱作安全域，負(fù)責(zé)確保發(fā)卡方和其他安全域提供者之間的密鑰的完全隔離。安全域負(fù)責(zé)提供各類安全服務(wù)，包括密鑰管理、加密解密、針對其提供者（發(fā)卡方、應(yīng)用提供方、授權(quán)管理者）的應(yīng)用進(jìn)行數(shù)字簽名的生成與驗證。

2.3 STORE DATA+DGI

STORE DATA 命令是GP 規(guī)范定義用于將數(shù)據(jù)傳輸至應(yīng)用程序或者安全域的指令。安全域根據(jù)接收到的命令數(shù)據(jù)來確定該命令是用于自身還是用于應(yīng)用程序。STORE DATA 命令基于GP 規(guī)范制定的安全機(jī)制與規(guī)則，用于保證數(shù)據(jù)的完整性與安全性。

DGI：DGI（Data Grouping Identifier）格式是GP 規(guī)范定義的在兩個字節(jié)上進(jìn)行編碼的二進(jìn)制格式，其后需接長度標(biāo)識和數(shù)據(jù)域。

通過自定義票卡結(jié)構(gòu)里文件的DGI 標(biāo)簽，包括電子錢包文件、電子現(xiàn)金文件、普通二進(jìn)制文件、循環(huán)或變長記錄文件、密鑰文件、擴(kuò)展應(yīng)用文件等，并形成自定義規(guī)范標(biāo)準(zhǔn)，統(tǒng)一票卡個人化的腳本指令。同時，使用STORE DATA 指令來傳輸自定義指令，運用密文+CMAC 的方式來保護(hù)傳輸數(shù)據(jù)的完整性與安全性。

2.4 密文+CMAC

票卡個人化腳本在傳輸過程中，根據(jù)GP 規(guī)范定義的方式，對傳輸?shù)臄?shù)據(jù)使用卡片密鑰進(jìn)行數(shù)據(jù)加密，得到傳輸數(shù)據(jù)密文，并計算數(shù)據(jù)的CMAC 值。卡片在接收到數(shù)據(jù)后，使用相應(yīng)的密鑰，用相同的算法對傳輸數(shù)據(jù)進(jìn)行解密，獲取傳輸數(shù)據(jù)明文，并計劃CMAC 值，對比接收的CMAC 值，判斷數(shù)據(jù)是否一致。

表1：NATIVE 卡與JAVA 卡各項細(xì)節(jié)對

圖4：校驗密鑰TAG 低字節(jié)定義

票卡個人化數(shù)據(jù)從票卡發(fā)行系統(tǒng)加密，到票卡進(jìn)行解密，數(shù)據(jù)在傳輸過程中處理加密狀態(tài)，確保數(shù)據(jù)在中間傳輸過程不被破解。

2.5 密鑰安全保障機(jī)制

票卡從生產(chǎn)到發(fā)行，需采用必要的安全機(jī)制來保障數(shù)據(jù)發(fā)行安全：

（1）應(yīng)用預(yù)個人化流程，票卡生產(chǎn)廠家需提前獲取票卡發(fā)行方的基礎(chǔ)安全密鑰。

（2）票卡生產(chǎn)廠家需安裝票卡發(fā)行方的基礎(chǔ)安全密鑰至票卡中，并生成KMC。

（3）票卡發(fā)行方在票卡個人化時需對票卡KMC 密鑰進(jìn)行替換。

票卡安全域密鑰KMC 的安裝與使用，由票卡發(fā)行方來定義。KMC 密鑰通過母卡的方式提供給票卡生產(chǎn)商。票卡生產(chǎn)商在安裝Java 平臺時，需對票卡進(jìn)行預(yù)個人化處理，即從母卡中導(dǎo)出初始密鑰并安裝至票卡中，此時票卡的安全域KMC 被修改為票卡發(fā)行方的密鑰。

2.6 數(shù)據(jù)格式與定義

制卡數(shù)據(jù)類型編碼規(guī)范：Tag 占2/3 字節(jié)，高字節(jié)為0x7F（01111111），即bit7-8 采取Application Class。

寫文件Tag 由3 字節(jié)構(gòu)成，其低2 字節(jié)定義如圖2 所示。

寫密鑰Tag 由2 字節(jié)構(gòu)成，其低字節(jié)定義如圖3 所示。

校驗密鑰Tag 由2 字節(jié)構(gòu)成，其低字節(jié)定義如圖4 所示。

預(yù)充值（錢包信用額度）Tag 由2 字節(jié)構(gòu)成，其低字節(jié)定義如圖5 所示。

NATIVE 卡與JAVA 卡各項細(xì)節(jié)對比，如表1 所示。

通過定制的JAVA 卡對比NATIVE 卡，具有以下優(yōu)點：

（1）統(tǒng)一一套票卡個人化腳本指令，每個廠家根據(jù)票卡規(guī)范進(jìn)行COS 開發(fā)，二次開發(fā)難度大大減少。

（2）出廠前預(yù)置票卡結(jié)構(gòu)，并做好預(yù)個人化。

（3）提前初始化票卡文件內(nèi)容，設(shè)置為普通值0 或F，而關(guān)鍵數(shù)據(jù)包括文件密鑰、卡片信息、證書信息等在個人化時才寫入，即保證數(shù)據(jù)安全，又節(jié)省個人化時間。

（4）只需一次獲取卡片隨機(jī)數(shù)，后面每條個人化指令都根據(jù)上次指令計算卡片隨機(jī)數(shù)參與運算，既減少個人化指令計算次數(shù)，又有效增強(qiáng)個人化數(shù)據(jù)破解難度。

（5）個人化腳本最多只需72 條，最少可以縮減至49 條，大幅提高個人化效率。

（6）個人化指令通過密文+CMAC 的方式傳輸，保證個人化數(shù)據(jù)的安全。

（7）在票卡發(fā)行過程中，發(fā)行終端與發(fā)行后臺的連接次數(shù)，最低可以壓縮至17 次，有效減輕了后臺壓力。

（8）單張交通部二合一卡發(fā)行時間為8 秒/張。

（9）定制的個人化指令配合定制的重復(fù)寫卡機(jī)制，可以直接對異常卡進(jìn)行重新寫卡，不再需要進(jìn)行7 卡步驟。

2.7 新票卡發(fā)行的創(chuàng)新和難點分析

新票卡發(fā)行的流程圖，如圖6 所示。

2.7.1 設(shè)計與開發(fā)過程中所遇問題總結(jié)與難點突破

由于此套方案基于不同的技術(shù)與不同的平臺，因此在設(shè)計開發(fā)過程中遇到很多問題，現(xiàn)總結(jié)如下：

（1）在設(shè)計個人化指令時，沒有充分考慮各文件之間的關(guān)系，導(dǎo)致某些個人化指令出現(xiàn)歧義，一條指令無法定位文件位置，后經(jīng)測試反復(fù)重現(xiàn)問題，并重新設(shè)計三字節(jié)標(biāo)簽來解決此問題。

（2）在計算票卡指令CMAC 時，由于算法較復(fù)雜，相關(guān)聯(lián)的字段較多，出現(xiàn)計算錯誤的情況，后經(jīng)廠家指導(dǎo)，順利完成CMAC計算。

（3）在票卡COS 開發(fā)過程中，有的廠家缺少三個應(yīng)用錢包共享的設(shè)計，導(dǎo)致在開發(fā)完成后再發(fā)現(xiàn)問題并重復(fù)修改。后重新與廠家討論技術(shù)細(xì)節(jié)，并提供相關(guān)技術(shù)文檔，確保廠家按我們的需求完成開發(fā)。

（4）由于對電子現(xiàn)金的認(rèn)識不足，導(dǎo)致開發(fā)發(fā)行平臺的時間延長，在對票卡電子現(xiàn)金進(jìn)行測試時，缺少部分測試項。后經(jīng)廠家技術(shù)指導(dǎo)后，完成開發(fā)與測試。

（5）在票卡測試過程中，沒能及時收集全國各地的終端與PSAM 卡類型進(jìn)行測試，導(dǎo)致少部分票卡的發(fā)行參數(shù)與部分地區(qū)的標(biāo)志不符，后經(jīng)修改參數(shù)加以解決。

2.7.2 創(chuàng)新點

圖5：預(yù)充值低字節(jié)定義

圖6：新票卡發(fā)行流程圖

在對原票卡發(fā)行系統(tǒng)運營管理多年的基礎(chǔ)上，發(fā)現(xiàn)系統(tǒng)在新票卡開發(fā)、票卡發(fā)行時間、發(fā)行流程、維護(hù)成本等環(huán)節(jié)上問題較多，如何有效優(yōu)化流程以及如何設(shè)計方案成為核心突破點。根據(jù)現(xiàn)在流行的JAVA 平臺票卡發(fā)行思維，結(jié)合GP 規(guī)范定義的標(biāo)準(zhǔn)接口與API，再運用成熟的DGI 標(biāo)簽格式，設(shè)計出一套完善可靠安全的個人化指令標(biāo)準(zhǔn)。此規(guī)范標(biāo)準(zhǔn)適用于所有開發(fā)廠家，廠家根據(jù)我們定義的規(guī)范標(biāo)準(zhǔn)開發(fā)完成并通過我們測試后，適用于我們的交通部二合一票卡發(fā)行。新標(biāo)準(zhǔn)解決了原系統(tǒng)的眾多問題，包括新票卡開發(fā)時，不再需要重新學(xué)習(xí)開發(fā)腳本與指令；票卡發(fā)行時間從30 秒/張縮短至8 秒/張；發(fā)行流程簡化，不再需要重復(fù)洗卡；二次開發(fā)更方便快捷。

3 總結(jié)

本套方案通過自定義DGI 腳本，規(guī)范各種不同類型的個人化指令，實現(xiàn)票卡發(fā)行功能的統(tǒng)一，不但可以有效提高票卡發(fā)行的開發(fā)效率與票卡發(fā)行效率，而且還能減少資源的重復(fù)利用與浪費。既優(yōu)化了操作人員的票卡發(fā)行體驗，又降低票卡出貨時間，該方案將成為票卡行業(yè)發(fā)展的重要手段和未來票卡發(fā)行的引路方向。