java card 技術（一）

2019-11-17 04:05:29

字體：大中小

來源：轉載

供稿：網友

簡介

　　java Card 技術適用于 Java 平臺，可應用于環境高度專用化、內存和處理約束比 J2ME 設備更苛刻的智能卡和其他設備。

　　智能卡在個人安全領域發揮著舉足輕重的作用。它們可以用于添加身份驗證，并對安全級別很高的信息系統提供安全訪問。存儲在智能卡中的信息是可移植的。借助 Java Card 技術，您可以攜帶有價值且敏感的個人信息，例如病歷、信用卡號或者存儲在壓縮但非常安全的介質中的電子現金余額。

　　什么是智能卡？

　　智能卡不是什么新鮮事物。早在 20 年前，歐洲就以（非智能形式）內存卡的形式引入了智能卡的概念，使用它保存重要的電話信息，其作用是減少盜打付費電話的可能。

　　智能卡技術由一項國際標準組織（ISO）和國際電工委員會（IEC）組成的聯合技術委員會（JTC1）定義并管理的工業標準。1987年推出的ISO/IEC 7816國際標準系列在2003年推出了它的最新的升級版本，界定了智能卡的方方面面，包括物理特性、物理接觸界面、電子信號和傳輸協議、命令、安全體系、應用程序標識符和公用數據元素等。

　　智能卡是一個含有嵌入式集成電路（IC）的塑料卡片。類似于一張信用卡。當用作 SIM 卡時，這個塑料卡片很小，但大小剛好能插入手機中。智能卡從設計上保證高度安全性，竄改一點點內容都會導致毀壞它所包含的信息。

　　在智能卡使用的某些領域中，它們僅僅提供受保護的非易失性存儲。更高級的智能卡還有用于安全處理和存儲的微處理器和內存，可以用于使用公鑰或共享密鑰算法的安全應用程序。智能卡上的非易失性存儲是最寶貴的資源，可以用于保存安全密鑰和數字證書。一些智能卡有單獨的加密協處理器，支持象 RSA、AEC 和 (3)DES 這樣的算法。

　　智能卡不含電池，只有在和智能卡讀取器相連時才被激活。當被連接時，在執行完一段復位序列后，智能卡仍保持被動狀態，等待接受從客戶機（主機）應用程序發來的命令請求。

　　智能卡可以是接觸式的或者非接觸式的。正如其名稱所暗示的，接觸式智能卡通過介于智能卡讀取器與智能卡 8 觸點之間的物理接觸進行通信并工作；而非可接觸式智能卡依靠在小于 2 英尺的一般距離之內的射頻信號進行通信。非接觸式智能卡的射頻通信基于類似于用于保存反盜竊和記錄清單的無線射頻識別（Radio Frequency ID，RFID）標記技術。圖 1 描述了接觸式和非接觸式智能卡：

圖 1a.接觸式智能卡

圖 1b.非接觸式智能卡

　　Java Card 技術也存在不同于智能卡的外形規格，例如智能按鈕和 USB 令牌（如圖 2 所示）。它們可以同智能卡一樣驗證用戶或傳送敏感信息。智能按鈕包括一塊電池而且是基于可接觸模式，而 USB 令牌則可以直接插入到個人計算機的 USB 端口，而無需使用接觸式或非接觸式讀取器。這兩種類型的 Java Card 均提供與智能卡相同的編程功能，并具有防篡改特性。

圖 2a.帶有 Java 功能的智能按鈕

圖 2b.帶有 Java 功能的 USB 令牌

Java Card 規范

　　多年以前，Sun Microsystem 就實現了智能卡和類似的資源約束設備的潛能，并為 Java 技術的子集定義一套規范，以便為 Java Card applet 創建應用程序。支持這些規范的設備簡稱 Java Card 平臺。在 Java Card 平臺上，來自不同供應商的多個應用程序可以安全地共存。

　　一臺典型的 Java Card 設備有一個運行于 3.7MHz 的 8 位或 16 位 CPU ，帶有 1K 的 RAM 和多于 16K 的非易失內存（EEPROM 或閃存）。高性能的智能卡帶有單獨的處理器、加密芯片和內存加密，某些智能卡還帶有 32 位 CPU。

　　Java Card 技術規范的最新版本為 2.2，由三部分組成：

　　Java Card 虛擬機規范，定義了用于智能卡的 Java 程序編程語言的一個子集和虛擬機。

　　Java Card 運行時環境規范，詳細定義了基于 Java 的智能卡的運行時行為。

　　Java Card API 規范，定義了用于智能卡應用程序的核心框架和擴展 Java 軟件包和類。

　　Sun 還提供了 Java Card 開發工具（JCDK），其中包括 Java Card RE 和 Java Card VM 的參考實現以及其他幫助開發的 Java Card applet 。本文第二部分將介紹詳細 JCDK。

　　Java Card 技術和 J2ME 平臺

　　讓我們比較一下 Java Card 和 J2ME 平臺技術：

圖 3 Java Card 技術和 J2ME 平臺

　　CDC 和 CLDC 配置以及相關配置文件都是 J2ME 平臺的組成部分，而 Java Card 是一個為智能卡環境而專門創建的單獨平臺專門。

　　Java Card 應用程序的元素

　　完整的 Java Card 應用程序由一個后端應用程序、系統、一個主機（卡片外部）應用程序、一個接口設備（卡片讀取器）和卡片內部 applet、用戶證書和支持軟件組成。所有這些元素一起構成了一個安全的端到端應用程序：

圖 4. Java Card 應用程序的架構

　　一個典型的 Java Card 應用程序并不是獨立的，而是包含卡片端、讀取器端和后端元素。下面詳細介紹一下每個元素。

　　后端應用程序和系統

　　后端應用程序提供支持卡片內 Java applet 的服務。例如，一個后端應用程序能提供與安全系統和卡上證書的連接，并提供強大的安全性。在電子支付系統中，后端應用程序可以提供到信用卡和其他付款信息的訪問。

　　讀取器端主機應用程序

　　主機應用程序存在于一個像個人計算機這樣的臺式機或者終端、電子付款終端、手機或者一個安全子系統中。

　　主機應用程序處理用戶、Java Card applet 和提供器的后端應用程序之間的通信。

　　傳統的讀取器端應用程序用 C 語言編寫。近來 J2ME 技術的廣泛普及有望使用 Java 實現主機應用程序；例如，它可以在一臺支持 MIDP 和安全性和信任服務應用編程接口（Security and Trust Services API）的手機上運行。

　　智能卡供應商通常不僅提供開發工具箱，還提供 API 以便支持讀取器端應用程序以及 Java Card applet。這方面的示例包括基于 Java 的 API 集合的 OpenCard Framework，其中隱藏了與不同卡片供應商提供的卡片讀取器進行交互的一些細節，還有兩個將在本文后邊討論的 Java Card 遠程方法調用（Java Card Remote Method Invocation，JCRMI）分布式對象模型和安全性和信任服務應用編程接口（SATSA）。

　　讀取器端卡片接入設備

　　卡片接入設備（Card Acceptance Device，CAD）是一個位于主機應用程序和 Java Card 設備之間的接口設備。CAD 為卡片提供電源以及與之進行的電子的或 RF 通信。CAD 可能是使用串行端口與臺式計算機相連的卡片讀取器，也可能被集成為一個終端。例如飯店或者加油站內的電子付款終端。接口設備從主機應用程向卡片轉發應用協議數據單元（application Protocol Data Unit，APDU）命令（稍后加以討論），再將卡片發出的響應傳遞給主機應用程序。一些 CAD 有用于輸入 PIN 入口點的鍵盤，有的可能還有顯示屏。

　　卡片端 Applet 和環境

　　Java Card 平臺是一個多應用程序環境。如圖 4 所示，卡片上可能存在一個或多個 Java Card applet，與支持軟件 —— 卡片操作系統和 Java Card 運行時環境（JCRE）一起存儲在卡片上。JCRE 由 Java Card VM、Java Card Framework 和 API 以及一些擴展 API 組成。

　　所有的 Java Card applet 擴展 Applet 基類，且必須實現 install() 和 process() 方法；當 JCRE 安裝 applet 時，調用 install()，每當為 applet 傳入 APDU 時，JCRE 都會調用 process()。

　　當 Java Card applet 被加載時進行實例化，并且電源被切斷時仍保持激活狀態。卡片 applet 起到服務器的作用，是被動的。當卡片接上電源，每個 applet 一直處于未激活狀態直到進行初始化時被選中。當向 applet 發送 APDU 時它才被激活。Applet 如何變為激活狀態（被選中）的詳細內容在 Java Card Applet 的生命周期一節中進行了描述。

與 Java Card Applet 之間的通信（訪問智能卡）

　　您可以使用兩種模式中的任意一種完成主機應用程序和 Java Card applet 之間的通信。第一種模式是基本的消息傳遞模式，第二種模式基于 Java 遠程方法調用（Java RMI）和 J2SE RMI 分布式對象模型的子集。此外，通過基于通用連接框架（Generic Connection Framework,GCF）API 的一個更抽象的 API，SATSA 使您能夠使用消息傳遞或 JCRMI 訪問智能卡。

　　消息傳遞模型

　　在圖 5 中說明的消息傳遞模型為所有 Java Card 通信提供基礎。其核心是與 CAD 和 Java Card Framework 之間交換的邏輯數據包 —— 應用協議數據單元（APDU）。Java Card Framework 接收任何由 CAD 發送的 APDU 并轉發給適當的 applet。Applet 處理 APDU 命令并返回一個 APDU 響應。APDU 遵循國際標準 ISO/IEC 7816-3 和 7816-4。

圖 5 使用消息傳遞模型進行通信

　　讀取器和卡片之間的通信通常建立在兩項鏈接協議基礎上，面向字節的 T=0 或面向塊的 T=1。可選協議簡稱 T=USB，且可能會采用 T=RF。JCRE APDU 類隱藏了來自應用程序的協議細節，但并非全部，因為 T=0 協議相當復雜。

　　1. APDU 命令

　　APDU 命令的結構由第一個字節的值控制，大多數情況下，類似于：

圖 6. APDU 命令

　　APDU 命令有一個必須有的標題和可選的主體，其中包括：

　　CLA （1 字節）：這個必需的字段識別指令的一個特定于應用程序類。有效的 CLA 值在 ISO 7816-4 規范中做了界定：

　　表 1. ISO 7816 CLA 值

CLA 值  指令類
0x0n，0x1n  ISO 7816-4 卡片指令，例如用于文件存取和安全操作
20 to 0x7F  保留
0x8n 或者 0x9n  您可以使用特定于應用程序指令的 ISO/IEC 7816-4 格式，根據標準解釋 'X'。
0xAn  特定于應用程序的指令或供應商指定的指令
從 B0 到 CF  您可以使用特定于應用程序指令的 ISO/IEC 7816-4 格式
從 D0 到 FE  特定于應用程序的指令或供應商指定的指令
FF  為協議類型選項所做的保留

　　從理論上講，可以使用所有的 CLA 值 0x80 或更高值來用于特定于應用程序的指令，但是實際上在當前許多的 Java Card 實現中，只有以黑體顯示的指令是實際認可的。

　　INS （1 字節）：這個必需的字段說明在指令類中由 CLA 字段識別的特定指令。ISO 7816-4 標準指定了當卡片根據標準所定義的卡片內部文件系統接收到指令時，用于訪問卡片內部數據的基本指令。在標準中的其它地方還指定了一些附加功能，其中包括安全功能。要了解 ISO 7816 部分指令的列表，參見表 2。只有當使用適當的 CLA 字節值時，根據標準規定才可以定義自己的應用程序指定的 INS 值。

　　表 2. 當 CLA = 0X 時的 ISO 7816-4 INS 值

INS 值  命令描述
0E  刪除二進制
20  驗證
70  管理通道
82  外部身份驗證
84  質詢
88  內部身份驗證
A4  選擇文件
B0  讀取二進制
B2  讀取記錄
C0  獲取響應
C2  信封
CA  獲取數據
D0  編寫二進制碼
D2  編寫記錄
D6  更新二進制碼
DA  輸入數據
DC  更新記錄
E2  附加記錄

　　P1 （1 字節）：這個必需的字段定義指令參數 1。可以使用該字段限定 INS 字段，或者用于輸入數據。

　　P2 （1 字節）：這個必需的字段定義指令參數 2。可以使用該字段限定 INS 字段，或者用于輸入數據。

　　Lc （1 字節）：這個可選字段是命令的數據字段中的字節數。

　　Data 字段（變量，字節的 Lc 數）：這個可選字段保存命令數據。

　　Le （1 字節）：這個可選字段指定在期望響應的數據字段中的字節最大數。

　　根據所出現的命令數據和是否需要響應，為 APDU 命令配置了四個變量。只有使用協議 T=0 的情況下才有必要關注這些變量。

圖 7. APDU 命令的四種可能結構

　　典型的應用程序使用帶有不同結構的各種 APDU 命令。

2. APDU 響應

　　APDU 響應的格式很簡單的：

圖 8 APDU 響應

　　響應 APDU 與命令 APDU 類似，都具有可供選擇的必需字段：

　　Data 字段（變量長度，由 APDU 命令中的 Le 確定）：該可選字段包含由 applet 所返回的數據。

　　SW1 （1 字節）：這個必需的字段是狀態字 1。

　　SW2 （1 字節）：這個必需的字段是狀態字 2。

　　在 ISO 7816-4 規范中定義了狀態字的值：

圖 9. 響應狀態代碼

　　在 Java Card Framework API 中的 ISO7816 Java 接口中定義了許多常量以便實施返回錯誤代碼的規范。

　　3. 處理 APDU

　　每當為所選的 applet 提供傳入的 APDU 時，JCRE 都會調用 applet 的 process() 方法，把傳入的 APDU 作為參數來傳遞。Applet 必須解析 APDU 命令，處理數據，生成響應 APDU，然后把控制權返回給JCRE。

　　您會在本文的第二部分“ process() 方法 —— 與 APDU 協同工作”中找到關于 APDU 命令和響應的更多信息。

　　Java Card RMI（JCRMI）

　　第二種通信模型基于 J2SE RMI 分布式對象模型的子集。

　　在 RMI 模型中，服務器應用程序創建并訪問遠程對象，且客戶機應用程序獲得對遠程對象的遠程引用，然后為這些對象調用遠程方法。在 JCRMI 中，Java Card applet 為服務器，主機應用程序為客戶機。

　　在擴展軟件包 javacardx.rmi 中由類 RMIService 提供 JCRMI。JCRMI 消息被封裝到傳入的 RMIService 方法的 APDU 對象中。換句話說，JCRMI 提供了一個熟練運用基于 APDU 消息傳遞模型的分布式對象模型的機制，借助該機制，服務器和客戶機進行通信，往復傳遞方法信息、參數、并返回值。

　　安全性和信任服務應用編程接口（SATSA）

　　在 JSR 177 中所定義的 SATSA 指定了為 J2ME 提供安全性和信任服務 API 的可選軟件包。該客戶機 API 提供了對各種服務的訪問，這些服務由安全存儲、敏感信息的檢索以及加密和身份驗證服務等安全元素（例如智能卡）提供。

　　SATSA 采用有限連接設備配置（Connected Limited Device Configuration，CLDC）的版本 1.0 中所定義的通用連接框架（Generic Connection Framework，GCF) 以便向消息傳遞和 JCRMI 通信模型提供更抽象的接口。為了支持消息傳遞，SATSA 定義了 apdu：URL 方案和 APDUConnection，為了支持 JCRMI，它還定義了 jcrmi：方案和 JavaCardRMIConnection。

　　SATSA 由下列軟件包組成：

　　java.rmi 定義了 Java 2 標準版 java.rmi 軟件包的子集，以及專門定義的 Remote 和 RemoteException。

　　javacard.framework 定義了遠程方法可能引發的標準 Java Card API 異常：CardRuntimeException、ISOException、APDUException、CardException、PINException、SystemException、TransactionException 和 UserException。

　　javacard.framework.service 定義了遠程方法可能引發的標準 Java Card API 服務異常：ServiceException。

　　javacard.security —— 定義了遠程方法會引發的標準 Java Card API 加密相關異常。CryptoException。

　　javax.microedition.io 定義了兩種連接接口，用于基于 APDU 協議而進行智能卡訪問的 APDUConnection 和用于 Java Card RMI 協議的 JavaCardRMIConnection。

　　javax.microedition.jcrmi 定義了樁模塊所使用的類和接口，該樁模塊由 Java Card RMI 樁模塊編譯器生成。

　　javax.microedition.pki 定義了用于用戶證書基礎管理的類。

　　javax.microedition.securityservice 定義了生成應用程序級數字簽名的類。

　Java Card VM

　　Java Card 虛擬機（JCVM）規范定義了用于智能卡的 Java 編程語言和 Java 可兼容的 VM，包括二進制數據表示和文件格式以及 JCVM 指令集。

　　用于 Java Card 平臺的 VM 分兩部分實現，一部分在卡片外部，另一部分在卡片上運行。卡片內部的 Java Card VM 解釋字節碼、管理類和對象等等。外部 Java VM 部分是一個開發工具，通常簡稱 Java Card 轉換工具，加載、驗證進而為卡片內部指令執行進一步準備卡片 applet 中的 Java 類。轉換工具的輸出是一個 Converted Applet（CAP）文件，保護所有可加載、可執行的二進制表示中的 Java 軟件包。轉換程序驗證類是否遵循 Java Card 規范。

　　JCVM 只支持 Java 編程語言的有限子集，但是保留了許多熟悉的特性，包括對象、繼承、軟件包、動態對象創建、虛擬方法、接口和異常。JCVM 規范放棄支持使用過多智能卡有限內存的語言元素。

　　表 3. Java Card 語言限制匯總

語言特性  不支持動態類加載、安全管理器（java.lang.SecurityManager）、線程、對象克隆和軟件包訪問控制的某些方面。
關鍵詞  不支持 native、synchronized、transient、volatile、strictfp。
類型  不支持 char, double, float 和 long 或多維數組。對 int 的支持是可選的。
類和接口  除 Object 和 Throwable 之外，不支持 Java 核心 API 類和接口（java.io, java.lang, java.util），絕大多數 Object 和 Throwable 方法不可用。
異常  一些 Exception 和 Error 子類被忽略，因為這些封裝的異常和錯誤在 Java Card 平臺中不出現。

　　還存在編程模型的限制。例如，一個被加載的庫類再也不會在卡片中被擴展；它被隱式地結束。

　　按照內存約束，JCVM 規范另外定義了許多程序屬性的約束。表 4 總結 JCVM 資源約束。請注意許多約束通常對 Java Card 開發人員通常是透明的。

　　表 4. Java Card VM 約束的摘要信息

軟件包  一個軟件包可以引用多達 128 個其他的軟件包。
完全合格的軟件包名稱限定為 255 字節。請注意字符大小取決于字符編碼。
一個軟件包能夠具備多至 255 個類。
類  一個類可以直接或間接實現多達 15 個接口。
一個接口可以從多達 14 個接口繼承。
如果一個軟件包含有 applet（一個 applet 軟件包）它可以有多達 256 個靜態方法，如果包不含有 applet（庫軟件包），它可以有 255 個靜態方法。
一個類可以實現 128 個公共的或受保護的實例方法，以及帶有軟件包可見性的 128 個公共的或受保護的實例方法。

　　同 J2SE VM 中的類文件一樣，在 Java Card VM 中的類文件是核心，但是 JCVM 規范定義了深化平臺獨立性的兩個其他文件格式 Converted Applet （CAP）和導出格式，二者在本系列文章第二部分的“開發 Java Card 應用程序”一節中加以描述。

　　Java Card API

　　Java Card API 規范定義了傳統 Java 編程語言 API 的小型子集 —— 甚至比 J2ME 的 CLDC 子集還要小。它不支持 Strings 或多線程。在這個子集中存在像 Boolean 和 Integer 這樣的包裝類，不存在 Class 或 System 類。

　　除了熟悉的 Java 核心類的小型子集外，Java Card Framework 定義了自己的核心類子集以便專門支持 Java Card 應用程序。這些子集被包含在下列軟件包內：

　　java.io 定義了一個異常類，基 IOException 類，以便完成 RMI 異常層級結構。除此之外，不包含其它傳統的 java.io 類。

　　java.lang 定義了 Object 和 Throwable 類，但是沒有 J2SE 中那么多方法。它還定義了許多異常類：Exception 基類、各種運行時異常和 CardException。除此之外，不包含其它傳統的 java.lang 類。

　　java.rmi 定義了 Remote 接口和 RemoteException 類。除此之外，不包含其它傳統的 java.rmi 類。其中包含對遠程方法調用（Remote Method Invocation，RMI）的支持，以便簡化與使用 Java Card 技術的設備之間的遷移和與之的集成。

　　javacard.framework 定義了構成核心 Java Card Framework 的接口、類和異常。它還定義了像個人識別號碼（Personal Identification Number，PIN）、應用程序數據單元（Application Protocol Data Unit，APDU）、Java Card applet（Applet）、Java Card System（JCSystem）和實用類這樣的重要概念。它還定義了各種 ISO7816 常量和各種特定于 Java Card 的異常。表 5 總結了這個軟件包的內容：

　　表 5. Java Card v2.2 javacard.framework

接口  ISO7816 定義了與 ISO 7816-3 和 ISO 7816-4 相關的常量。
MultiSelectable 識別可以支持并發選項的 applet。
PIN 表示用于安全目的（身份驗證）的個人識別號碼。
Shareable 識別共享對象。那些能通過 applet 防火墻的對象必須實現這個接口。
類  AID 定義了遵循 ISO7816-5 標準并且與應用程序提供器相關的應用程序標識符，還定義了 applet 的強制屬性。
APDU 定義了遵循 ISO7816-4 標準的應用程序協議數據單元（APDU），它是 applet（卡片內部）和主機應用程序（卡片外部）之間使用的通信格式。
Applet 定義了一個 Java Card 應用程序。所有的 applet 必需擴展這個抽象類。
JCSystem 提供了控制 applet 生命周期、資源和事務管理以及 applet 內部對象共享和對象刪除的方法。
OwnerPIN 是 PIN 接口的一個實現。
Util 提供了數組和短型變量操作的使用方法，包括 arrayCompare()、arrayCopy()、arrayCopyNonAtomic()、 arrayFillNonAtomic()、getShort()、makeShort() 和 setShort()。
異常  以下為所定義的 Java Card VM 異常類：APDUException、CardException、CardRuntimeException、ISOException、PINException、SystemException、TransactionException 和 UserException。

　　javacard.framework.service 定義了用于各種服務的接口、類和異常。服務處理以 APDU 的格式傳入的命令。表 6 總結了框架服務 API：

　　表 6. javacard.framework.service

接口  Service 是基本的服務接口，定義 processCommand()、 processDataIn() 和 processDataOut() 等方法。
RemoteService 是一個通用服務，給出對卡內部服務訪問的遠程進程。
SecurityService 擴展了 Service 基接口，并提供方法以便查詢包括 isAuthenticated()、isChannelSecure() 和 isCommandSecure() 在內的當前安全狀態。
類  BasicService 是一個服務的默認實現；它提供了輔助方法以便處理 APDU 和服務協作。
Dispatcher 維護服務的注冊表。如果希望將 APDU 的處理委托給幾個服務，請使用分發程序。分發程序可以使用 process() 方法完整處理 APDU，或者使用 dispatch() 方法通過幾項服務將其分發進行處理。
異常  ServiceException 是一個與服務相關的異常。

　　javacard.security 定義用于 Java Card 安全框架的類和接口。Java Card 規范定義了一個健壯的安全 API，其中包括各種類型的私人密鑰和公共密鑰及其算法、計算循環冗余碼校驗（CRC）的各種方法、消息摘要和簽名：

　　表 7. javacard.security

接口  通用基接口 Key、PrivateKey、PublicKey 和 SecretKey 以及表示各種類型的安全密鑰和算法的子接口：AESKey、DESKey、DSAKey、DSAPrivateKey、DSAPublicKey、ECKey、ECPrivateKey、ECPublicKey、RSAPrivateCrtKey、RSAPrivateKey 和 RSAPublicKey。
類  Checksum：一個用于 CRC 算法的抽象基類
KeyAgreement：一個用于密鑰協議算法的基類
KeyBuilder：密鑰對象廠
KeyPair：一個存儲密鑰對（一個是私人密鑰，一個是公共密鑰）的容器
MessageDigest：用于散列算法的基類
RandomData：用于隨機數生成器的基類
Signature：一個用于簽名算法的基抽象類
異常  CryptoException：與加密相關的異常，例如不支持的算法或未初始化的密鑰。

　　javacardx.crypto 是一個定義接口 KeyEncryption 和類 Cypher 的擴展軟件包，其中接口和類在各自的軟件包中，可以輕松實現導出控制。使用 KeyEncryption 來解密一個使用加密算法的輸入密鑰。Cypher 是所有加密器必須實現的基抽象類。

　　javacardx.rmi 是一個定義 Java Card RMI 類的擴展軟件包。它定義了兩個類，CardRemoteObject 和 RMIService。CardRemoteObject 定義了兩種方法，export() 和 unexport()，用于啟用和禁用對來自卡片外部對象的遠程訪問。RMIService 擴展 BasicService 并實現 RemoteService 以便處理 RMI 請求。

Java Card 運行時

　　JCRE 規范定義了 Java Card VM 的生命周期、applet 的生命周期、applet 被選擇和與其它 applet 隔離的方式、事務、對象持久性和共享。JCRE 提供一個由卡片操作系統所提供服務的平臺獨立接口。該接口由 Java Card Virtual Machine、Java Card AP 和供應商指定的擴展組成：

圖 10. Java Card 架構和運行時環境

　　Java Card VM 的生命周期

　　JCVM 的生命周期與卡片本身的生命周期一致：JCVM 的生命周期從卡片被制造并測試后且發行給卡片持有人前的某一時刻開始，在卡片被廢棄或損壞之時結束。當接到卡片上的電源去掉時，JCVM 并不停止運行，因為其狀態在卡的非易失內存中仍被保留下來。啟動 JCVM 需要初始化 JCRE 并創建所有在 JCVM 整個生命周期中都處于激發狀態的 JCRE 框架對象。在 JCVM 啟動之后，所有與卡片的交互原則上受卡片中某個 applet 控制。當電源從卡片上移走時，所有包含在 RAM 中的數據全部丟失，但是存儲在非易失內存中的狀態仍然被保留下來。當電源重新供應時，VM 再一次被激發，此時 VM 的狀態和對象的狀態被存儲，執行恢復，等待新的輸入。

　　Java Card Applet 的生命周期

　　卡片上的 applet 由應用程序 ID （AID）惟一識別。AID 在 ISO 7816-5 中定義，是一個介于 5 個字節和 16 個字節的序列。所有 applet 必須擴展這個定義 JCRE 使用方法的 Applet 抽象基類，以便控制 applet 的生命周期，總結內容如圖 10 所示：

圖 11. Java Card Applet 的生命周期方法

　　Applet 的生命周期始于 applet 被下載到卡片上且 JCRE 調用 applet 的靜態 Applet.install() 方法，以及 applet 通過使用 JCRE 調用 Applet.register() 進行自我注冊之時。一旦 applet 被安裝和注冊，它便處于未被選中的狀態，可以用于選擇并進行 APDU 處理。圖 11 Applet 方法操作的總結

圖 12 使用 Java Card Applet 方法

　　當 applet 處于未被選中的狀態時，它是無效的。當主機應用程序請求 JCRE 選擇卡片中特定的 applet 時（通過向卡片讀取器發出指令 SELECT APDU 或 MANAGE CHANNEL APDU 完成），applet 被選中用于 APDU 處理。要通知 applet 已經被主機應用程序選中，JCRE 會調用 select() 方法；applet 通常執行適當的初始化過程，準備用于 APDU 處理。

　　一旦完成選擇 applet，JCRE 將傳入的 APDU 命令傳遞給 applet，通過調用 process() 方法進行處理。JCRE 可以捕捉任何 applet 捕捉失敗的異常。

　　當主機應用程序告訴 JCRE 選擇另一個 applet 的時候，當前正在使用的 applet 被取消選中。通過調用通常執行清除邏輯并返回 applet 為無效、未被選中狀態的 deselect() 方法，JCRE 通知處于激活狀態的 applet 已經被取消選中。

　Java Card 會話和邏輯通道

　　當卡片接通電源并與卡片讀取器進行 APDU 交換期間，卡片進行會話。

　　Java Card 2.2 支持邏輯通道概念，允許卡片一次打開多至 16 個的應用程序會話，一個會話占用一個邏輯通道。由于卡片內的 APDU 處理過程不能被中斷，每個 APDU 包含了對邏輯通道（以 CLA 字節的形式）的引用，替換的 APDU 可以不同時訪問卡片中的許多 applet。您還可以設計 applet 為多項選擇的；也就是一次可以在多于一個的邏輯通道上進行通信。多項選擇的 applet 必須實現 javacard.framework.MultiSelectable 接口和相應的方法。

　　在一些卡片部署中，默認的 applet 可以在卡片復位后被定義為自動選擇，以便在基邏輯通道上（通道 0）進行通信。Java Card 2.2 許可定義默認的 applet，但是沒有指定定義默認 applet 的方式；此種機制是由供應商指定的。

　　Applet 的隔離和對象共享

　　Java Card 平臺是一個安全的多應用程序環境 —— 許多不同供應商生產的不同 applet 可以在同一張卡片上安全地共存。每個 applet 被分配給一個執行上下文，用于控制所分配對象的訪問。在兩個擴展上下文之間的邊界通常被稱作 applet 防火墻。它是沙箱的 Java 安全概念的 Java Card 運行時增強，結合了類加載器功能、java.ClassLoader 訪問控制器和 java.accessController。Java Card 防火墻創建了虛擬堆，這樣，一個對象只能訪問在相同防火墻內的（公共的）方法和這些對象的數據。防火墻可能包含許多 applet 和其他對象，例如常見的安全密鑰。Java Card 當前執行的上下文在軟件包范圍內。當每個對象被創建時，為對象分配調用程序的執行上下文。

　　Java Card 平臺支持跨越防火墻的安全對象共享。圖 12 描述 applet 隔離和對象共享：

圖 13. Applet 防火墻和對象共享

　　在圖 12 中描述了典型的流程，如圖所示：

　　Appleta 通過調用系統的 JCSystem.getAppletShareableInterfaceObject() 方法請求訪問 Appletc 的可共享接口。

　　為了表示 Appleta，JCRE 通過調用 applet 的 getShareableInterfaceObject() 方法請求 Appletc 的可共享接口。

　　如果 Appletc 允許共享，Appleta 將獲得對一個 Appletc 共享對象的引用。Appleta 現在就可以訪問 Appletc 了。Appleta 將擁有自己創建的任意對象，即使這些對象是在 Appletc 中定義的。

　　在同一個執行上下文中的 Applet 在默認情況下能夠互相訪問，因此，Appleta 和 Appletb 不需要遵循這一程序來共享對象。

　　管理內存和對象

　　在 Java Card 設備上，內存是最有價值的資源。在某些 Java Card 實現中，垃圾收集器有可能不可用。當一個對象被創建時，對象及其內容被保存在非易失內存中，使得這些內容在會話過程中可用。在某些情況下，應用程序數據不需要是持久性的 —— 它可以是臨時性的或者是瞬態的。要減少對智能卡持久性內存的損壞，因此要最大限度地增加此類內存的生命周期，盡可能將經常被更新的數據作為瞬態類型的數據處理。

　　Java Card 技術不支持瞬態關鍵字。Java Card API（javacard.framework.JCSystem）而是定義了使您能夠在運行時創建瞬態數據的三種方法，以及使您能檢查對象是否為瞬態的第四種方法。

　　static byte[] makeTransientByteArray(short length, byte event)

　　static Object makeTransientObjectArray(short length, byte event)

　　static short[] makeTransientShortArray(short length, byte event)

　　static byte isTransient(java.lang.Object theObj)

　　還可以創建 byte 或 short 的基本數據類型的瞬態數組，或者創建一個瞬態的對象。但是請記住，下列行為可用于瞬態數據：

　　瞬態對象的狀態在會話過程中不是持久的。請注意其內容（不是對象本身）是瞬態的。對于任意其他 Java 語言對象，只要引用瞬態對象，它就會一直存在。

　　當發生卡片復位或 applet 取消選中時，瞬態對象的內容可能會被復位為字段的默認值（零，false 或 null）。

　　出于安全原因，瞬態對象的字段不在持久內存中儲存。

　　瞬態對象字段的更新不是原子的，且不受事務的影響。

　　在 Java Card 環境中，數組和基本類型在對象聲明位置被聲明，為了有利于對象的重用，應該最大限度減少對象實例化。在 applet 生命周期內只對對象進行一次實例化，最好是在 applet 初始化時通過在生命周期內惟一調用一次 install() 方法進行實例化。

　　為了利于重用，對象保留在原有位置或在生命周期內被引用，且這些對象的狀態（成員變量的值）在重用前適當復位。由于垃圾收集器并不是總是可用的，應用程序可能不再回收分配給超出范圍的對象的存儲空間。

　　持久性事務

　　JCRE 支持原子事務安全地更新一個或多個持久性對象。即使發生斷電或程序錯誤，事務也要確保數據完整性。事務通過下列方法得到系統級支持：

　　JCSystem.beginTransaction()

　　JCSystem.commitTransaction()

　　JCSystem.abortTransaction()

　　在許多事務模型常見的模型中，Java Card 事務從調用 beginTransaction() 開始，并從調用 commitTransaction() 或 abortTransaction() 結束。讓我們看一看使用這些 API 的代碼片斷：

...
private short balance;
...
JCSystem.beginTransaction();
balance = (short)(balance + creditAmount);
JCSystem.commitTransaction();
...

　　務必確保實例變量余額的更新操作為原子操作。如果發生程序錯誤或電源重置，確保事務會恢復余額的前值。

　　JCRE 不支持嵌套事務。

　　結束語

　　本系列文章的第一部分介紹了相當廣泛的內容：使用智能卡存儲敏感信息和安全處理事務，Java Card 技術的方方面面 —— Java Card VM、運行時環境、相關的 API 和 Java Card applet 的行為。系列文章的第二部分將介紹 Java Card 技術的開發部分。

　　使用 Java Card 技術的智能卡具備最佳的可移植性，并且是攜帶數字個人信息計算功能的安全方式；在當今的數字世界中，它是一項強大的必備技術。

上一篇：Java Card 技術(二)

下一篇：java第8天代碼（集合類）-list