王同洋,趙 磊
華中科技大學,湖北武漢 430074
智能卡(Smartcard)在包括電信、銀行、公交、醫(yī)療、身份證件、數(shù)字電視、安全認證等與普通消費者息息相關的領域均獲得了廣泛的應用。在未來移動支付、信用卡等更加普及、對個人信息安全有更高訴求的時代,智能卡仍將發(fā)揮不可替代的重要作用。
傳統(tǒng)的Native卡存在先天缺陷,概括為如下3點:
1)應用開發(fā)的難度大、周期長、成本高:native卡以匯編或C語言進行開發(fā),缺乏通用開發(fā)平臺,開發(fā)、調(diào)試困難,要求開發(fā)人員對硬件的底層細節(jié)熟悉;
2)不能很好的支持跨行業(yè)應用和一卡多用,而一卡多用是智能卡發(fā)展的趨勢;
3)應用在卡發(fā)行時便已經(jīng)固定下來,無法實現(xiàn)應用的更新或升級,無法滿足客戶個性化的需求,也使供應商在增值服務方面無法有所作為;
Native卡在互操作性和多功能應用上的不足,在應用開發(fā)時的高難度、高成本已經(jīng)成為限制智能卡進一步發(fā)展的最大障礙。在探索如何解決這些矛盾的過程中,以Sun為代表的公司開始嘗試將更通用和安全的Java平臺引入智能卡行業(yè),Java卡便應運而生。
Java卡是一種可以運行Java程序的微處理器智能卡,在卡中運行的程序叫Java Card Applet。Applet可以由用戶動態(tài)裝載到卡上。Java卡是Java體系中最小的一個平臺,Applet可以在任何符合Java卡規(guī)范的卡上運行,主要規(guī)范包括:Java卡虛擬機規(guī)范(JCVM),編程接口規(guī)范(API)和運行時環(huán)境規(guī)范(JCRE),目前最新的規(guī)范是3.0版本。
1.1.1 Java卡體系結(jié)構(gòu)
Java卡的內(nèi)部結(jié)構(gòu)由 COS、Native Functions、Java VM、Java Framework 以及架構(gòu)在此上的應用程序Applet所構(gòu)成,Java卡內(nèi)部結(jié)構(gòu)如圖1所示:
圖1 Java卡體系結(jié)構(gòu)
1.1.2 Java卡虛擬機結(jié)構(gòu)
與Java平臺相同,Java卡實現(xiàn)跨平臺和高安全的關鍵是虛擬機,同樣受限與硬件資源,Java卡虛擬機(JCVM)和普通Java虛擬機(JVM)的最重要的區(qū)別就在于JCVM是一個分離的結(jié)構(gòu)——卡外和卡內(nèi)虛擬機:
圖2 Java卡虛擬機分離模型
如圖2所示:卡外虛擬機部分主要包括一個converter,它運行在PC或者工作站,主要用來裝載和預處理輸入的class文件,并將其轉(zhuǎn)化輸出為一種Java卡字節(jié)碼文件(即CAP,Converted Applet);卡內(nèi)虛擬機部分包括Java卡字節(jié)碼解釋器Interpreter,用來解釋執(zhí)行Java卡字節(jié)碼文件。兩者結(jié)合,就構(gòu)成了完整的Java卡虛擬機,它們在卡外安裝程序和卡上安裝器的共同工作下,完成CAP文件下載、安裝過程,如圖3所示:
圖3 CAP文件下載安裝過程
1.1.3 Java卡優(yōu)點
Java卡的優(yōu)點可以概括如下:
1)平臺無關性和互操作性:通過Java卡虛擬機技術實現(xiàn)了跨平臺和互操作的能力;
2)支持一卡多用,應用的動態(tài)下載及管理;
3)通用和開放:Java卡不但兼容了現(xiàn)有的智能卡行業(yè)標準,它還提供了一整套標準的API,使智能卡應用開發(fā)回到主流的面向?qū)ο缶幊?,開發(fā)人員無需了解復雜的智能卡硬件和專用技術;
4)安全:Java卡繼承了Java語言的安全特性,包括原子事務、應用防火墻等,從而提供了一個安全高效的執(zhí)行環(huán)境。
1.2.1 Java卡內(nèi)存管理模型和對象類型
作為低端嵌入式設備的Java卡,內(nèi)存是最寶貴的資源。通常在Java卡內(nèi)有3種存儲體:
1)ROM:通常存儲有Java卡虛擬機、API類庫、卡內(nèi)操作系統(tǒng)和卡商預先裝入的applet等,并在發(fā)卡前將它們掩膜到ROM中;
2)RAM:斷電后數(shù)據(jù)丟失,因此用來存儲暫態(tài)數(shù)據(jù),包括局部變量、方法參數(shù)、中間運算結(jié)果等;
3)EEPROM:用來存儲持久數(shù)據(jù),包括下載到卡中的applet class和創(chuàng)建的持久對象。
目前在Java卡中執(zhí)行應用時,Java卡虛擬機調(diào)用new指令創(chuàng)建對象,并默認存儲于EEPROM中。對象包括兩類:
1)暫態(tài)對象(Transient Object),它分為兩種類型:CLEAR_ ON_RESET和CLEAR_ON_DESELECT。通過調(diào)用Java卡API來創(chuàng)建,并存儲在RAM中,斷電后對象的字段(field)值、字段類型等數(shù)據(jù)自動丟失。CLEAR_ON_RESET類型的對象在一次會話期間或進行applet選擇切換時會保存下來,但進行復位操作時被復位為默認值;而CLEAR_ON_DESELECT類型的對象無論是復位操作還是applet選擇切換,都無法保存。對暫態(tài)對象的操作不是原子的;
2)持久對象(Persistent Object):由new操作符創(chuàng)建,并默認存儲在EEPROM中,它在卡被拔出后依然存在。對持久對象數(shù)據(jù)的操作必須是原子的,即更新操作要么全部完成,要么中斷更新并回滾恢復到原來的狀態(tài);
無論是暫態(tài)對象還是持久對象,當沒有其他任何對象引用它時,該對象就不再可以訪問,也就成為垃圾,但它們所占據(jù)的空間只有被回收后才能再次利用。
1.2.2 現(xiàn)有模型的性能問題
在字節(jié)碼文件下載解析過程中,以及虛擬機執(zhí)行應用的過程中都遭遇了性能問題,而其中消耗絕大部分執(zhí)行時間的是EEPROM寫操作,原因總結(jié)如下:
1)為了支持持久對象的原子性操作,保證數(shù)據(jù)的完整性,Java卡在EEPROM中開辟了一塊特殊的存儲區(qū)域來存儲原有的數(shù)據(jù),以執(zhí)行數(shù)據(jù)的回滾。將舊有數(shù)據(jù)寫入Transaction-Buffer的次數(shù)占據(jù)了所有EEPROM寫操作的75%~80%,而寫EEPROM的時間為3ms~10ms,比RAM慢1 000倍;
2)寫EEPROM操作采用了機制,即先將數(shù)據(jù)寫入Page-Buffer,然后再寫入EEPROM,清除Page-Buffer后再重復下一次的寫過程。這種寫入—刪除—再寫入的機制在大量寫操作時是十分緩慢的;
3)在下載CAP文件時,對常量池等組件的解析過程在EEPROM中完成。同樣的,虛擬機在執(zhí)行applet實例的時候,大部分對象的創(chuàng)建也是在EEPROM中完成,兩者都產(chǎn)生了大量的EEPROM寫操作。
為了解決Java卡的性能問題,研究人員提出了一些典型優(yōu)化方法,分析歸納如下:
1)在Java卡虛擬機分離模型的基礎上,采用分離模式的CAP文件解析優(yōu)化方案,即將靜態(tài)解析過程放在卡外執(zhí)行,該過程只訪問CAP文件,而無需訪問卡內(nèi)資源。將動態(tài)解析過程留在卡內(nèi)進行,該過程必須獲得卡內(nèi)資源才能完成解析。最后設計一種偽指令集來銜接優(yōu)化后的解析執(zhí)行過程 ;
2) 改 進Java卡 已 有 的 事 務(transaction) 機 制,將Transaction-Buffer分配在RAM中,并將事務開始后的新數(shù)據(jù)寫入這個Buffer。如果事務順利完成,則將其中的數(shù)據(jù)寫入EEPROM并替換舊數(shù)據(jù);如果事務中斷,比如卡被拔出等,由于RAM的易失性,Buffer中的數(shù)據(jù)自然消失,而EEPROM中原始的數(shù)據(jù)也并沒有被更改,也就保證了數(shù)據(jù)的完整性。該方法大大減少了對EEPROM的寫操作,很好的提高了應用的執(zhí)行性能。不足之處是加大了對本就稀有的RAM資源的開銷;
3)引入cache策略,改進傳統(tǒng)的寫EEPROM機制。這個方法的基礎是Java卡在執(zhí)行應用期間,寫操作的數(shù)據(jù)擁有高度的局部相似特性(即cache擁有較高的命中率),基于這個特性,在傳統(tǒng)的Page-buffer的基礎上在RAM中增加一個Object-buffer,并通過引入cache策略,從而在大量寫操作發(fā)生的時候可以大幅度提高性能;
4)改進對象模型,將applet實例和靜態(tài)數(shù)據(jù)成員之外的大部分對象都存儲在RAM中,而非傳統(tǒng)的EEPROM中。該方法需要在編寫applet時考慮到數(shù)據(jù)的持久性要求,如事務平衡值,并將這些數(shù)據(jù)成員的類型設為static,從而將其保存在永久性的EEPROM中。需要指出的是該方法對RAM空間有較高的要求[5];
5)采用壓縮算法對字節(jié)碼文件進行優(yōu)化或?qū)ψ止?jié)碼文件中的Method組件的指令碼進行折疊優(yōu)化。但這些方法對有標準格式要求的字節(jié)碼而言,優(yōu)化的空間有限且往往會產(chǎn)生優(yōu)化的負效應[6]。
2.2.1 優(yōu)化的目標
1)提高應用的下載、安裝速度:減少CAP解析過程對EEPROM的寫操作次數(shù),從而提高Java卡對CAP文件的下載解析速度;
2)提高應用的執(zhí)行性能:減少applet生命周期過程中對EEPROM的寫操作次數(shù),提高applet的執(zhí)行性能;
3)提高內(nèi)存使用率:減少內(nèi)存碎片和提高空間回收效率,從而更加高效的利用寶貴的Java卡內(nèi)存資源。
2.2.2 可行的技術方案
1)實現(xiàn)新的對象模型和新的堆存儲區(qū)模型,保證有一種合理的算法實現(xiàn)對EEPROM(或Flash)和RAM堆空間的高效管理;
2)優(yōu)化傳統(tǒng)的事務機制,在保證持久對象的原子性和一部分敏感暫態(tài)數(shù)據(jù)的安全性的同時,減少事務機制帶來的性能負效應;
3)探索一種能用于智能卡的合理高效的cache算法,配合寫入策略(Normal Write & Tear-Proof Write)來優(yōu)化現(xiàn)有的EEPROM寫入機制;
4)圍繞對象模型,對現(xiàn)有的Java卡堆棧操作指令,以及涉及對象管理和事務機制的API進行分析,對其中實現(xiàn)效率不高的進行優(yōu)化、合并或擴展,或直接在底層用native代碼實現(xiàn),從字節(jié)碼指令層提高應用的執(zhí)行性能;
5)設計一種新的CAP文件解析策略,結(jié)合RAM空間的使用,減少在CAP文件下載和安裝過程中對EEPROM的寫操作,提高下載和解析的速度。
2.2.3 技術方案的評估
在設計新的算法或方案對Java卡平臺進行優(yōu)化之后,需要有一個合理的評估方案實現(xiàn)對優(yōu)化結(jié)果的測評以考察其有效性[7]。性能評估從兩個方面進行:
1)Java卡正常使用(事務正常完成)的應用執(zhí)行性能,需對如下幾個方面進行測評:
(1)內(nèi)存管理:包括對象創(chuàng)建和數(shù)據(jù)更新時的堆棧讀寫等;
(2)指令的派遣和執(zhí)行。
2)整個平臺的性能,包括平臺特性和在非正常情況下Java卡的性能表現(xiàn)(即事務中斷),可以細分為對如下幾個環(huán)節(jié)的測評:
(1)應用的下載和安裝速度;
(2)內(nèi)存回收策略:包括對象刪除和垃圾回收等的效率;
(3)JCRE:事務中斷,即發(fā)生數(shù)據(jù)回滾時的性能表現(xiàn);
(4)API:Java卡API方法的執(zhí)行效率。
Java卡分離的虛擬機結(jié)構(gòu)和有限的內(nèi)存資源決定了Java卡應用的執(zhí)行性能無法與Native卡相比。隨著Java卡應用領域的不斷拓展(如在3.0規(guī)范中推出的基于Java卡的Web Server應用),對Java卡的性能提出了更高的要求。隨著Java卡處理器性能的提升和內(nèi)存資源的豐富,在壓縮字節(jié)碼、優(yōu)化內(nèi)存管理算法等傳統(tǒng)優(yōu)化途徑之外,在卡中實現(xiàn)垃圾收集器和數(shù)據(jù)庫管理系統(tǒng)(DBMS)也都將成為合理的優(yōu)化手段,以不斷提高Java卡的性能。
[1]ZhiqunChen,JavaCardTechnologyforSmar tCards:ArchitectureandProgrammer’sGuide,Addison-Wesley,2000.
[2]M.Oest reicher,K.Ksheeradbhi,ObjectLi fetimesinJavaCard,Proc.UsenixWork-shopSmar tCardTechnology,UsenixAssoc.,Berkeley,Calif.,1999:129-137.
[3]常青,靳偉,李春龍,張其善.JCVM解析優(yōu)化設計與實現(xiàn)[N].北京航空航天大學學報,2004,30(12).
[4]Min-SikJin,Won-HoChoi,Yoon-SimYang,Min-SooJung,AStudyonFastJCVMwithNewTransactionMechanismandCaching-BufferBasedonJavaCardObjectswithaHighLocality,InternationalFederationforInformationProcess(IFIP),2005.
[5]Min-SikJin,Min-SooJung,AStudyonFastJCVMbymovingobjectfromEEPROMtoRAM,Proceedingofthe11thIEEEInternationalConferenceonRTCSA,2005.
[6]ClausenL.R.,SchultzU.P.,ConselC.,JavaBytecodeCompressionLow-EndforEmbeddedSystem,InACMTransactionsonProgrammingLanguagesandSystems,2000,22(3).
[7]PierreParadinas,SamiaBouzefrane,JulienCordry,HowtomeasuretheperformanceofJavaCardPlatforms,CEDRICLab.CNAM(Paris),2007.