一種JavaCard庫包后下載的方法

作者/ 許晶1,2 王于波1,2 張彥杰1,2 袁艷芳1,2 付青琴1,2

　　1.北京智芯微電子科技有限公司 國家電網(wǎng)公司重點(diǎn)實(shí)驗(yàn)室 電力芯片設(shè)計(jì)分析實(shí)驗(yàn)室(北京100192)

　　2.北京智芯微電子科技有限公司 北京市電力高可靠性集成電路設(shè)計(jì)工程技術(shù)研究中心(北京100192)

摘要: JavaCard將標(biāo)準(zhǔn)API的定義引入了嵌入式開發(fā)，這帶來了平臺和應(yīng)用開發(fā)的分離，使得開發(fā)更為便利。而當(dāng)發(fā)行后的平臺有新增功能的需求時，需要考慮在平臺還是應(yīng)用層來進(jìn)行實(shí)現(xiàn)。如需在每個應(yīng)用中進(jìn)行實(shí)現(xiàn)，代碼會冗余、空間占用會增大;如采用傳統(tǒng)的補(bǔ)丁方式，實(shí)現(xiàn)又有較多限制。在避免重新掩膜的情況下，本文提出一種后下載庫包的方法，將新增功能定義為庫包，庫包的實(shí)現(xiàn)采用Java包的方式，在平臺上先下載實(shí)現(xiàn)好的庫包，再下載調(diào)用庫包的應(yīng)用。驗(yàn)證表明，該方法具有節(jié)省空間、方便實(shí)現(xiàn)以及節(jié)省成本等優(yōu)點(diǎn)。

引言

　　由于具有靈活性和安全性，JAVA卡在智能卡領(lǐng)域的應(yīng)用越來越多。當(dāng)一張JAVA卡發(fā)行后，如果多個應(yīng)用需要調(diào)用同一個功能模塊，現(xiàn)有的辦法是在每個應(yīng)用(JavaCard Applet)中實(shí)現(xiàn)此功能。這將導(dǎo)致空間占用的增加，在存儲資源有限的情況下，會使得JAVA卡上支持的應(yīng)用個數(shù)減少。如果使用補(bǔ)丁機(jī)制將此功能模塊做成智能卡的補(bǔ)丁，開發(fā)一個完整的功能模塊會受到補(bǔ)丁機(jī)制的靈活性限制。如要重新進(jìn)行卡片掩膜，又將涉及到成本的增加。

　　本文將有類似需求的功能模塊作為JAVA卡的一個外部庫包，每個應(yīng)用不需要單獨(dú)實(shí)現(xiàn)這些功能，而采用調(diào)用新增的庫包的方式，減少了空間的占用。庫包實(shí)現(xiàn)方式靈活，便于快速開發(fā)。在ROM掩膜的平臺上，也免除了重新掩膜的成本。試驗(yàn)結(jié)果證明，此方法能具有很好的靈活性和安全性，并節(jié)省了智能卡的空間。

1 JAVA卡平臺和應(yīng)用開發(fā)模式

　　1.1 傳統(tǒng)的智能卡平臺應(yīng)用開發(fā)模式

　　傳統(tǒng)智能卡COS開發(fā)時，平臺和應(yīng)用通常是由一個廠商開發(fā)的^[1]。平臺負(fù)責(zé)實(shí)現(xiàn)底層芯片驅(qū)動、算法模塊及文件系統(tǒng)等功能。應(yīng)用實(shí)現(xiàn)滿足行業(yè)規(guī)范的開卡、交易流程及安全機(jī)制等，比如裝載密鑰、內(nèi)部認(rèn)證、加解密等功能。如圖1所示，各行業(yè)發(fā)布規(guī)范，各智能卡廠商根據(jù)規(guī)范開發(fā)出多款產(chǎn)品，每一款產(chǎn)品都有單獨(dú)的平臺和行業(yè)應(yīng)用，以提供給不同的行業(yè)進(jìn)行商用。

　　1.2 JAVA卡平臺應(yīng)用開發(fā)模式

　　隨著越來越多的行業(yè)開始使用智能卡，人們對一張卡上集成多個應(yīng)用的需求也隨之增長^[2]。90年代開始，多應(yīng)用芯片卡開放系統(tǒng)陸續(xù)出現(xiàn)。其中使用最為廣泛的就是JavaCard平臺^[3]。JAVA卡的平臺和應(yīng)用完全分離。一張搭載JAVA卡平臺的卡片，能夠在平臺發(fā)行后再下載應(yīng)用，這是JAVA卡比使用本地語言如C語言的Native卡有著更為便利的優(yōu)勢，一張JAVA卡能夠適應(yīng)不同的應(yīng)用場景，而不需要開發(fā)多個版本的COS(Chip Operation System，片上操作系統(tǒng))^[4]。

　　而平臺和應(yīng)用的分離是通過統(tǒng)一的API來實(shí)現(xiàn)的。JAVA卡API是JAVA卡運(yùn)行環(huán)境的重要組成部分之一^[5]，它提供了一套統(tǒng)一的、基于國際標(biāo)準(zhǔn)的、用于應(yīng)用開發(fā)的編程接口，包括I/O接口、異常管理、安全管理等接口^[6]。JAVA卡平臺實(shí)現(xiàn)API接口，JAVA卡應(yīng)用可以通過調(diào)用API接口來進(jìn)行編程，生成可下載文件。

　　在JAVA卡發(fā)行之后，還能夠進(jìn)行應(yīng)用的下載、安裝、刪除等管理^[5]。不同的應(yīng)用開發(fā)商開發(fā)的JAVA卡應(yīng)用，也可以下載到不同平臺開發(fā)商開發(fā)的、支持同一API版本的JAVA卡平臺上。如圖2所示。

　　應(yīng)用開發(fā)時，引用JAVA卡API庫包進(jìn)行編譯，生成可下載文件CAP包。應(yīng)用下載到平臺后，對平臺庫包API的調(diào)用采用動態(tài)鏈接機(jī)制，通過平臺編譯的Token值索引，找到調(diào)用的JAVA包、類和方法，完成相應(yīng)功能的實(shí)現(xiàn)^[8]。

2 通用的JAVA卡新增功能實(shí)現(xiàn)方式及問題

　　本文將實(shí)現(xiàn)了具體功能的API包稱為庫包。常見的JAVA卡標(biāo)準(zhǔn)庫包包括java.io、java.lang、javacard.framework、javacard.security、javacardx. crypto等^[6]。庫包java.io和java.lang定義了一些常見的異常(Exception)，javacard.framework定義了JAVA卡平臺運(yùn)行環(huán)境的各種操作接口，javacard.security和javacardx. crypto定義了國際算法和密碼相關(guān)的安全接口。

　　在一張JAVA卡發(fā)行后，如果不同的應(yīng)用需要平臺新增實(shí)現(xiàn)相同的功能，傳統(tǒng)的實(shí)現(xiàn)方法，第一種是每個應(yīng)用都實(shí)現(xiàn)一套相同的功能函數(shù);第二種方法是采用JAVA卡傳統(tǒng)的補(bǔ)丁方式，將功能實(shí)現(xiàn)增加到平臺中;第三種方法是重新開發(fā)平臺，如果為ROM掩膜的卡片，還需要重新進(jìn)行平臺掩膜。

　　現(xiàn)有的新增通用功能的方法都有各自的問題：

　　1)第一種方法，每個應(yīng)用內(nèi)部實(shí)現(xiàn)一套功能函數(shù)，這樣導(dǎo)致代碼量的冗余，在智能卡有限的空間中，如果單個應(yīng)用的代碼量增大，會導(dǎo)致可加載應(yīng)用的個數(shù)減少;

　　2)第二種方法，JAVA卡傳統(tǒng)的補(bǔ)丁方式，一般是在JAVA卡運(yùn)行環(huán)境中，在調(diào)用方法的時候進(jìn)行補(bǔ)丁函數(shù)的判斷，如果該方法有補(bǔ)丁函數(shù)，則運(yùn)行補(bǔ)丁函數(shù);如果沒有補(bǔ)丁函數(shù)，則運(yùn)行現(xiàn)有的函數(shù)，這種方法增加了判斷的時間，使得卡運(yùn)行效率降低，而且補(bǔ)丁函數(shù)的開發(fā)有較多的限制;

　　3)第三種方法，重新開發(fā)一版新平臺，這種方法不僅導(dǎo)致芯片可能有重新掩膜的成本，而且增加了多個版本的維護(hù)工作。

3 JAVA卡庫包后下載的方法

　　本文將后下載的庫包分為兩個模塊，庫實(shí)現(xiàn)包模塊和庫接口包模塊，此處的庫，指的是Java卡外部庫，非標(biāo)準(zhǔn)庫，即卡內(nèi)未預(yù)置的庫，需要新增功能的庫包。

　　實(shí)現(xiàn)時，首先實(shí)現(xiàn)一個庫實(shí)現(xiàn)包，庫實(shí)現(xiàn)包作為一個JAVA卡的包(Package)，基于JAVA卡標(biāo)準(zhǔn)庫包進(jìn)行開發(fā)，包中包含了新增庫的功能函數(shù)(Java文件)。Java文件通過javac編譯器引用Java API，生成庫實(shí)現(xiàn)Java可裝載文件(Class文件)，然后，通過JavaCard編譯器converter引用JavaCard和GP(Global Platform，應(yīng)用安全管理平臺)的API^[9]，將Class文件生成庫實(shí)現(xiàn)Java卡可裝載文件(CAP文件)，如圖3所示。

　　然后，用庫實(shí)現(xiàn)源文件生成庫接口源文件，只保留方法的聲明。如果希望庫接口包中含有最少的函數(shù)聲明，可以將需要提供的接口所在的類和函數(shù)都放在最前位置編譯。由于converter中JAVA卡外部類按照字母順序來生成排序的類Token值^[8]，需要將提供接口的類排列在包的最前位置。接口文件的實(shí)現(xiàn)，保證了實(shí)現(xiàn)的代碼不會被泄露。應(yīng)用需要獲取庫接口文件JAVA卡庫文件，通過javac編譯器生成應(yīng)用Java可裝載文件后，使用converter工具，除了引用JavaCard和GP API外，還需引用庫接口JAR包，生成應(yīng)用的JAVA卡可裝載文件。

　　最后，完成應(yīng)用的裝載安裝過程。在應(yīng)用裝載前，需要寫在現(xiàn)有的標(biāo)準(zhǔn)JAVA卡上，通過JavaCardLoader(下載器)先將庫實(shí)現(xiàn)JAVA卡可裝載文件安裝進(jìn)JAVA卡，然后，再通過JavaCard Loader和Installer(安裝器)將應(yīng)用的Java卡可裝載文件下載并安裝進(jìn)JAVA卡中，完成應(yīng)用的下載和安裝。如圖4所示。

4 結(jié)論

　　將本文的方法與傳統(tǒng)的方法相比較。相比第一種方法，在應(yīng)用中實(shí)現(xiàn)庫包的功能，減少了代碼量。如果庫功能實(shí)現(xiàn)的代碼量為n Kbytes，應(yīng)用實(shí)現(xiàn)的代碼量是m Kbytes，當(dāng)一張卡上有i個應(yīng)用需要調(diào)到該庫的功能時，第一種方法需要的代碼量是i*(n+m)Kbytes，而本方法需要的代碼量是n+i*m Kbytes，減少了(i-1)*n Kbytes的代碼量。代碼量的減少，可以在芯片選型時，選擇空間較小，成本較低的芯片。

　　與第二種方法相比，縮短了開發(fā)時間，降低了開發(fā)難度，并提高了運(yùn)行效率。依靠傳統(tǒng)的補(bǔ)丁方式實(shí)現(xiàn)功能庫函數(shù)時，需要在設(shè)計(jì)時就考慮到有可能出現(xiàn)的問題，設(shè)計(jì)好補(bǔ)丁入口。在實(shí)現(xiàn)時，有較多開發(fā)上的限制。采用JAVA卡包來實(shí)現(xiàn)新增功能的庫函數(shù)，能縮短開發(fā)時間，降低開發(fā)難度。運(yùn)行時，傳統(tǒng)的補(bǔ)丁需要在函數(shù)調(diào)用時判斷是否具有補(bǔ)丁函數(shù)，在每個方法調(diào)用前都增加了運(yùn)行時間成本，本方法提高了運(yùn)行效率。

　　與第三種方法相比，減少了版本維護(hù)，如果在ROM掩膜的芯片上，還節(jié)約了芯片掩膜成本。此方法在功能函數(shù)缺失或需要新增的時候，只需將Java庫實(shí)現(xiàn)包下載進(jìn)JAVA卡，并提供相應(yīng)的庫接口包給應(yīng)用開發(fā)的用戶，無需重新開發(fā)一版COS，減少了COS的版本。在ROM掩膜的芯片上，無需再次進(jìn)行芯片掩膜，直接將功能庫進(jìn)行下載，大大節(jié)約了多次掩膜的成本。

　　綜上所述，相比傳統(tǒng)方法，本文提出的JAVA卡庫包后下載的方法具有節(jié)省卡片空間、便于開發(fā)、節(jié)約成本的優(yōu)點(diǎn)。

參考文獻(xiàn)：

　　[1]王愛英.智能卡技術(shù)[M].北京:清華大學(xué)出版社, 2009.

　　[2]馬多賀.Java智能卡開發(fā)及應(yīng)用技術(shù)研究[M].哈爾濱工業(yè)大學(xué),2006.

　　[3]Michael Baentsch, Peter Buhler, etc.IEEE Concurrency, Oct.-Dec.1999,JavaCard-From Hype to Reality, 1999.

　　[4]張旭.基于JavaCard的智能存儲卡多行業(yè)應(yīng)用研究[M].北京郵電大學(xué),2008.

　　[5]Runtime Environment Specification, JavaCardTM Platform, Version 2.2.2, March 2006.

　　[6] Application Programming Interface, JavaCardTMPlatform, Version 2.2.2, March 2006.

　　[7] Virtual Machine Specification, JavaCardTM Platform, Version 2.2.2, March 2006.

　　[8] Development Kit User’s Guide, For the Source Release. Java CardTM Platform, Version 2.2.2, 2006

　　[9]GlobalPlatform Card Specification, Card Specification, Version2.2, March 2006.

本文來源于中國科技期刊《電子產(chǎn)品世界》2016年第10期第47頁，歡迎您寫論文時引用，并注明出處。