Java智能卡平臺及其優化技術展望

王同洋，趙 磊

華中科技大學，湖北武漢 430074

0 引言

智能卡（Smartcard）在包括電信、銀行、公交、醫療、身份證件、數字電視、安全認證等與普通消費者息息相關的領域均獲得了廣泛的應用。在未來移動支付、信用卡等更加普及、對個人信息安全有更高訴求的時代，智能卡仍將發揮不可替代的重要作用。

傳統的Native卡存在先天缺陷，概括為如下3點：

1）應用開發的難度大、周期長、成本高：native卡以匯編或C語言進行開發，缺乏通用開發平臺，開發、調試困難，要求開發人員對硬件的底層細節熟悉；

2）不能很好的支持跨行業應用和一卡多用，而一卡多用是智能卡發展的趨勢；

3）應用在卡發行時便已經固定下來，無法實現應用的更新或升級，無法滿足客戶個性化的需求，也使供應商在增值服務方面無法有所作為；

Native卡在互操作性和多功能應用上的不足，在應用開發時的高難度、高成本已經成為限制智能卡進一步發展的最大障礙。在探索如何解決這些矛盾的過程中，以Sun為代表的公司開始嘗試將更通用和安全的Java平臺引入智能卡行業，Java卡便應運而生。

1 Java智能卡平臺

Java卡是一種可以運行Java程序的微處理器智能卡，在卡中運行的程序叫Java Card Applet。Applet可以由用戶動態裝載到卡上。Java卡是Java體系中最小的一個平臺，Applet可以在任何符合Java卡規范的卡上運行，主要規范包括：Java卡虛擬機規范（JCVM），編程接口規范（API）和運行時環境規范（JCRE），目前最新的規范是3.0版本。

1.1 Java卡體系結構及優點

1.1.1 Java卡體系結構

Java卡的內部結構由 COS、Native Functions、Java VM、Java Framework 以及架構在此上的應用程序Applet所構成，Java卡內部結構如圖1所示：

圖1 Java卡體系結構

1.1.2 Java卡虛擬機結構

與Java平臺相同，Java卡實現跨平臺和高安全的關鍵是虛擬機，同樣受限與硬件資源，Java卡虛擬機（JCVM）和普通Java虛擬機（JVM）的最重要的區別就在于JCVM是一個分離的結構——卡外和卡內虛擬機：

圖2 Java卡虛擬機分離模型

如圖2所示：卡外虛擬機部分主要包括一個converter，它運行在PC或者工作站，主要用來裝載和預處理輸入的class文件，并將其轉化輸出為一種Java卡字節碼文件（即CAP，Converted Applet）；卡內虛擬機部分包括Java卡字節碼解釋器Interpreter，用來解釋執行Java卡字節碼文件。兩者結合，就構成了完整的Java卡虛擬機，它們在卡外安裝程序和卡上安裝器的共同工作下，完成CAP文件下載、安裝過程，如圖3所示：

圖3 CAP文件下載安裝過程

1.1.3 Java卡優點

Java卡的優點可以概括如下：

1）平臺無關性和互操作性：通過Java卡虛擬機技術實現了跨平臺和互操作的能力；

2）支持一卡多用，應用的動態下載及管理；

3）通用和開放：Java卡不但兼容了現有的智能卡行業標準，它還提供了一整套標準的API，使智能卡應用開發回到主流的面向對象編程，開發人員無需了解復雜的智能卡硬件和專用技術；

4）安全：Java卡繼承了Java語言的安全特性，包括原子事務、應用防火墻等，從而提供了一個安全高效的執行環境。

1.2 Java智能卡內存管理和對象管理

1.2.1 Java卡內存管理模型和對象類型

作為低端嵌入式設備的Java卡，內存是最寶貴的資源。通常在Java卡內有3種存儲體：

1）ROM：通常存儲有Java卡虛擬機、API類庫、卡內操作系統和卡商預先裝入的applet等，并在發卡前將它們掩膜到ROM中；

2）RAM：斷電后數據丟失，因此用來存儲暫態數據，包括局部變量、方法參數、中間運算結果等；

3）EEPROM：用來存儲持久數據，包括下載到卡中的applet class和創建的持久對象。

目前在Java卡中執行應用時，Java卡虛擬機調用new指令創建對象，并默認存儲于EEPROM中。對象包括兩類：

1）暫態對象（Transient Object），它分為兩種類型：CLEAR_ ON_RESET和CLEAR_ON_DESELECT。通過調用Java卡API來創建，并存儲在RAM中，斷電后對象的字段（field）值、字段類型等數據自動丟失。CLEAR_ON_RESET類型的對象在一次會話期間或進行applet選擇切換時會保存下來，但進行復位操作時被復位為默認值；而CLEAR_ON_DESELECT類型的對象無論是復位操作還是applet選擇切換，都無法保存。對暫態對象的操作不是原子的；

2）持久對象（Persistent Object）：由new操作符創建，并默認存儲在EEPROM中，它在卡被拔出后依然存在。對持久對象數據的操作必須是原子的，即更新操作要么全部完成，要么中斷更新并回滾恢復到原來的狀態；

無論是暫態對象還是持久對象，當沒有其他任何對象引用它時，該對象就不再可以訪問，也就成為垃圾，但它們所占據的空間只有被回收后才能再次利用。

1.2.2 現有模型的性能問題

在字節碼文件下載解析過程中，以及虛擬機執行應用的過程中都遭遇了性能問題，而其中消耗絕大部分執行時間的是EEPROM寫操作，原因總結如下：

1）為了支持持久對象的原子性操作，保證數據的完整性，Java卡在EEPROM中開辟了一塊特殊的存儲區域來存儲原有的數據，以執行數據的回滾。將舊有數據寫入Transaction-Buffer的次數占據了所有EEPROM寫操作的75%～80%，而寫EEPROM的時間為3ms～10ms，比RAM慢1 000倍；

2）寫EEPROM操作采用了機制，即先將數據寫入Page-Buffer，然后再寫入EEPROM，清除Page-Buffer后再重復下一次的寫過程。這種寫入—刪除—再寫入的機制在大量寫操作時是十分緩慢的；

3）在下載CAP文件時，對常量池等組件的解析過程在EEPROM中完成。同樣的，虛擬機在執行applet實例的時候，大部分對象的創建也是在EEPROM中完成，兩者都產生了大量的EEPROM寫操作。

2 優化技術的探討

2.1 已有的典型優化技術

為了解決Java卡的性能問題，研究人員提出了一些典型優化方法，分析歸納如下：

1）在Java卡虛擬機分離模型的基礎上，采用分離模式的CAP文件解析優化方案，即將靜態解析過程放在卡外執行，該過程只訪問CAP文件，而無需訪問卡內資源。將動態解析過程留在卡內進行，該過程必須獲得卡內資源才能完成解析。最后設計一種偽指令集來銜接優化后的解析執行過程 ；

2） 改 進Java卡 已 有 的 事 務（transaction） 機 制，將Transaction-Buffer分配在RAM中，并將事務開始后的新數據寫入這個Buffer。如果事務順利完成，則將其中的數據寫入EEPROM并替換舊數據；如果事務中斷，比如卡被拔出等，由于RAM的易失性，Buffer中的數據自然消失，而EEPROM中原始的數據也并沒有被更改，也就保證了數據的完整性。該方法大大減少了對EEPROM的寫操作，很好的提高了應用的執行性能。不足之處是加大了對本就稀有的RAM資源的開銷；

3）引入cache策略，改進傳統的寫EEPROM機制。這個方法的基礎是Java卡在執行應用期間，寫操作的數據擁有高度的局部相似特性（即cache擁有較高的命中率），基于這個特性，在傳統的Page-buffer的基礎上在RAM中增加一個Object-buffer，并通過引入cache策略，從而在大量寫操作發生的時候可以大幅度提高性能；

4）改進對象模型，將applet實例和靜態數據成員之外的大部分對象都存儲在RAM中，而非傳統的EEPROM中。該方法需要在編寫applet時考慮到數據的持久性要求，如事務平衡值，并將這些數據成員的類型設為static，從而將其保存在永久性的EEPROM中。需要指出的是該方法對RAM空間有較高的要求[5]；

5）采用壓縮算法對字節碼文件進行優化或對字節碼文件中的Method組件的指令碼進行折疊優化。但這些方法對有標準格式要求的字節碼而言，優化的空間有限且往往會產生優化的負效應[6]。

2.2 優化方向的探索

2.2.1 優化的目標

1）提高應用的下載、安裝速度：減少CAP解析過程對EEPROM的寫操作次數，從而提高Java卡對CAP文件的下載解析速度；

2）提高應用的執行性能：減少applet生命周期過程中對EEPROM的寫操作次數，提高applet的執行性能；

3）提高內存使用率：減少內存碎片和提高空間回收效率，從而更加高效的利用寶貴的Java卡內存資源。

2.2.2 可行的技術方案

1）實現新的對象模型和新的堆存儲區模型，保證有一種合理的算法實現對EEPROM（或Flash）和RAM堆空間的高效管理；

2）優化傳統的事務機制，在保證持久對象的原子性和一部分敏感暫態數據的安全性的同時，減少事務機制帶來的性能負效應；

3）探索一種能用于智能卡的合理高效的cache算法，配合寫入策略（Normal Write & Tear-Proof Write）來優化現有的EEPROM寫入機制；

4）圍繞對象模型，對現有的Java卡堆棧操作指令，以及涉及對象管理和事務機制的API進行分析，對其中實現效率不高的進行優化、合并或擴展，或直接在底層用native代碼實現，從字節碼指令層提高應用的執行性能；

5）設計一種新的CAP文件解析策略，結合RAM空間的使用，減少在CAP文件下載和安裝過程中對EEPROM的寫操作，提高下載和解析的速度。

2.2.3 技術方案的評估

在設計新的算法或方案對Java卡平臺進行優化之后，需要有一個合理的評估方案實現對優化結果的測評以考察其有效性[7]。性能評估從兩個方面進行：

1）Java卡正常使用（事務正常完成）的應用執行性能，需對如下幾個方面進行測評：

（1）內存管理：包括對象創建和數據更新時的堆棧讀寫等；

（2）指令的派遣和執行。

2）整個平臺的性能，包括平臺特性和在非正常情況下Java卡的性能表現（即事務中斷），可以細分為對如下幾個環節的測評：

（1）應用的下載和安裝速度；

（2）內存回收策略：包括對象刪除和垃圾回收等的效率；

（3）JCRE：事務中斷，即發生數據回滾時的性能表現；

（4）API：Java卡API方法的執行效率。

3 結論

Java卡分離的虛擬機結構和有限的內存資源決定了Java卡應用的執行性能無法與Native卡相比。隨著Java卡應用領域的不斷拓展（如在3.0規范中推出的基于Java卡的Web Server應用），對Java卡的性能提出了更高的要求。隨著Java卡處理器性能的提升和內存資源的豐富，在壓縮字節碼、優化內存管理算法等傳統優化途徑之外，在卡中實現垃圾收集器和數據庫管理系統（DBMS）也都將成為合理的優化手段，以不斷提高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解析優化設計與實現[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.