前言

Java語言具有的跨平台特性，如果它能被使用在Smart Card的世界中，那它將可以建立一個統一Smart Card開發標準並增加更多可攜性，以及藉著下載applets的方式來達到動態功能更新的目的。利用Java來做為開發Smart Card的語言是否可行？或者這只是個夢？這一切如果要成為事實，那必須有賴一個詳細的實作規格的建立，而不只是喊喊口號而已。

什麼是Java Card？

Java Card就像是一般的Smart Card一樣，它符合所有Smart Card的標準，因此，對於目前一些Smart Card-aware的應用方面來說，它也可以支援Java Card而不需要做任何改變。那為何這種card叫做「Java Card」而不稱為Smart Card？主要原因是Java Card的實作語言是以Java的開發環境為主，所以Java Card的code是種bytecode。它也是需要JVM (Java Virtual Machine，Java虛擬機器)來做為執行的工具。

在Java Card中，它的JVM (Java Virtual Machine)是實作在它的唯讀記憶體(ROM)中，因為這種Java Card的獨特性質，使它和一般Smart Card不同。因為Java Card內建了JVM，所以JVM的各種元件(component)可以存取所有Smart Card的一切資源(例如記憶體與I/O)，並且可提供了一般Smart Card的作業系統(OS)所提供的一般性服務。除此之外，Java Card也利用Java的bytecode來執行對外界的通訊行為(例如:簽證、登入等)。其架構如(圖一)所示：

《圖一　Java Card的架構》

Java Card的發展觀念約在1996年便已經開始，那時是由一個Smart Card的製造商-Schlumberger所展示這發展的可能性。不過在那時候的構想上還有許多問題尚待克服，其中有兩個主要缺點存在。第一、那時候Java的應用程式所能用於存取系統功能的函數不多，所以無法利用Java去建立一個完善的Smart Card系統；第二、Java Card必須使用它自己的card上的檔案系統去下載Java相關資源，以及常常要對資料做確認與儲存的工作，這種運作方法對物件導向的作業環境來說顯然是不適合的。

那使用Java Card和使用Smart Card有何不同？這些不同其實是很明顯的，那就是Java Card可以讓程式寫作具有跨平台特性，不因card的架構不同而必須重新撰寫程式，這種優點比一般Smart Card多了可攜性。所以各位也許會想，那既然Java Card有這個好處，為何現在還不全面使用？剛剛前面說的就是原因之一，而另一個主要原因是安全方面的考量。不過隨著時間的流逝，現在廠商已經將這些Java Card的功能更加以延伸了，它不但更具有安全性，且在網路存取時，Java Card可以為您的銀行帳戶做到更好的保密。

雖然到目前為止，我們還不清楚這種跨平台的Java Card會長的什麼樣子。不過Sun Micro- systems在1996年率先發佈第一個Java Card的規格出來，而它所根據的就是那時Schlumberger的實驗方式。不過和他們不同的是規格中限制了Java Card的一般性目的與架構，但它仍提供一般Java語言方面的支援能力，並提供Smart Card專用的編碼函數。

1997年的Java Card論壇中，制定了Java Card 2.0規格。在這個2.0規格中，它含有更具體的API規格(例如：編/解碼的函數實作)與一個比JVM更小巧的JCVM (Java Card Java Virtual Machine)。不過在不同Java Card 的Java code之間與可攜性方面還有問題存在，這些不相容的問題有些甚至存在於source code層次上面。舉例來說，Java Card檔案系統的API規格並未普及化，這對那些享有Java Card檔案系統專利技術的廠商來說，還是會有不相容的情形出現。除此之外，編碼的函數的缺乏與對不同國家的轉換通融性方面，Java Card都還有待改良。所以，因為API方面的實作規格不夠詳細，導致較複雜的Java Card應用程式函數無法在不同Java Card之間流傳應用。

新的Java Card規格

1998年的4月，VISA發表了一個VISA OpenPlatform (VOP)的Smart Card規格，這個規格是為了因應Smart Card的多程式時代的來臨所制定。1999年VISA公開VOP的標準，並將它改名為開放式平台2.0(OpenPlatform 2.0, OP)。因為OP標準的開放，促使了ETSI標準化會議選擇用OP來當作GSM行動電話之SIM卡的管理標準。OP之所以被重視，是因為Sun或是Java Card論壇，他們都沒有為applet建立一個安全的下載標準，而VISA的OP是第一個真實標準的建立者。不過這不意味它對Java Card而言是完備的，因為它也沒有為Java Card的應用程式之程式碼檔案格式或是指令集(instruction set)下一個定義。這兩個東西在1998年的Java Card相關會議裡面，是一個重要的討論議題所在。

有關OP安全方面的概念是著重在對那些多程式卡的軟體提供者的角色上面，包含卡的作業系統提供者、製造者、發行者與applet提供者。它必須能確保一旦Smart Card離開製造者之後，只有發行者可以控制Smart Card的內容與使用。OP對於這點，它引入了一種「CardDomain」的觀念，它可以讓發行者以編碼的方法來控制card的存取功能，並決定是否可以下載新的applets。

OP允許不同的applet提供者能在同一張card內運作，除此之外，在OP中還有一個管理安全方面功能，稱為「Security-Domain」。這個SecurityDomain和前面說的CardDomain是有點不一樣的，連發行者都不知道SecurityDomain的applet code，SecurityDomain可視為一種獨立單位。

雖然OP對Java Card的發展工具影響不大，對程式而言，設計師還是必須經由標準的Smart Card終端機，將Java Card CAP (Cardlet Package)檔案轉換成為Smart Card通訊命令序列，也就是應用程式資料協定單位(application data protocol units，ADPU)。當CardDomain接受資料之後，它就會載入並連結新的applet到card中。

在1999年3月，Java Card 2.1(JC21)的規格被制定出來，它為Java Card的bytecode提供一種稱為「code signing」的認證機制，這種認證機制可以被使用在下載方面的安全上。除此之外，Java Card它還引入一種新的觀念，那就是「軟體防火牆機制」。所謂軟體防火牆機制就是說，Java Card的物件可以利用他們的applets相互聯繫，而每一個物件在另一物件上面的存取權都必須經過JVM的核對，利用這種方式可以增加Java Card安全上面的保障與減少非法存取的可能性。到了1999年的11月做左右，許多新的規格都已經紛紛出籠，例如

●Java Card 2.1 API規格

●Java Card 2.1 Runtime Environment (JCRE)規格

●Java Card 2.1 Virtual Machine (JCVM)規格。

●Java Card 2.1 規格的發行注意事項。

這些都可以在http://java.sun. com/products/JavaCard/找到。

Java card 2.1的延伸功能

JCRE定義了applet執行的相關環境方面的細節問題。

Java card 2.1的虛擬機器規格定義了binary的可攜性標準，這標準包含了Java card語法的子集合、JCVM規格與在Java card程式中的binary表示法。

Java card 2.1 API規格主要是修正自Java card 2.0 API規格，它保留了一些基本Java card 2.0的API函數，並且加入了一些新的應用函數(例如︰新的Java Card. security與JavaCardx.crypto套件)，以加強Java card的安全保密與可攜性功能。這些API函數與指令參考都可以在上述網站找到。而要為Java Card發展應用程式的方法有許多，一個是自己用一般Java開發工具來撰寫函數，另一個方法便是使用Java CardTM 2.1 Development Kit來直接呼叫JC21的API函數。有關這Java CardTM 2.1 Development Kit，各位可以去Java.Sun.Com的網站下載。

Java Card的架構簡化

一般比較便宜的Smart Card所含有一些晶片，可能是一個256Bytes的隨機存取記憶體(RAM)，與16KBytes的唯讀記憶體(ROM)以及4~8KBytes的可抹寫、可程式化記憶體(EEPROM)。不過這規格不是統一的，例如Rolls Royce的Smart Card硬體架構是一個4KBytes的RAM，一個64KBytes的ROM與一個64 KBytes的EEPROM。雖然他們的的架構上面有所不同，但是在編碼上面大都採用DES式或是RSA的編碼方法。

這些Smart Card的架構成本關係到Java Card的設計。為了減少成本，許多廠商與Java Card論壇將Smart Card的某些硬體架構，定位在較便宜的晶片可負擔的情況下。因為這種因素，導致Java Card必須不能有太多複雜的資料結構。對Java Card而言，浮點數(float)、雙精確數(double)與長整數(long)的資料型態將不再被支援。不過還好這些限制，並不會對Java Card的程式寫作有太大影響。

Java Card的運作和一般Smart Card是沒有什麼不同的，也就是說，Smart Card讀取器可以對Java Card送出命令，而Java Card會在處理這個命令之後傳回結果，就如同一般使用Smart Card一樣。不過為了和目前的Smart Card應用程式相容，Java Card目前只能一次處理一個命令。Java Card applets的實作可以用各種不同的Java發展環境來完成，例如JDK(Java Developer's Kit)、VisualCafe、JavaBuilder、Visual Age等等。完成之後的applets程式碼可以在一般JVM機器上面執行，但是存取動作只限於Smart Card特定界面才可以。

Java Card轉換的最佳化

因為JVM的執行效率比一般原生碼來得慢，因此要改善Java Card的byte code轉換效率，可以基本上有兩個技術：

將指令集最佳化

如果單純只改變標準JAVA指令集，可能還達不到我們所要求的效率，不過這卻是改良Java Card系統效能上一個可行的方法。作法就是：

1.移除不支援的資料格式指令：將移除之後的剩下指令當作是Java Card的opcodes (operation codes)，這樣可以讓Java Card的JCVM實作上更有效率。

2.Java Card內定只支援短整數運算，因此你可以將Java內的整數集合重新定義，只留下短整數型態。

將資料格式最佳化

要定義Java Card的檔案格式，便避免不了面對複雜的資料結構與訊息連結的安排工作。將這種資料結構重新定義的一個最大用處，就是希望能將Java Card使用到的記憶體單元減到最小以及讓存取時間變短。Java Card的時間存取瓶頸諸要是出現在經由緩慢的Smart Card連結上面去下載資料時，而記憶體的瓶頸主要出現在下載的Java Card的CAP對隨機存取記憶體之需求與那些需要儲存在EEPROM-based的applet執行訊息上面。因此要將Java Card做最佳化的改良，便可以從時間與記憶體需求減少方面著手。

結語

到目前為止，Java Card的夢想雖然尚未實現。不過許多討論依舊在Java Card論壇(http://www. JavaCardforum.org)上面熱烈展開，他們還在考慮許多有關Java標準實作的各種觀念。雖然Java Card還未真正出現在市面上，但我相信Java Card的出現只是時間問題。