智能卡標準
智能卡應(yīng)用程序開發(fā)中容易使人迷惑的一點是標準協(xié)議問題。在我們的例子中基本上是應(yīng)用程序與閱讀器通信，然后由閱讀器以一種標準協(xié)議與智能卡通信。而這種標準是國際標準化組織的7816協(xié)議。 

 

 

　　象其它許多新技術(shù)一樣，關(guān)于智能卡有許許多多令人眼花繚亂的技術(shù)標準。對于下面這些標準形成初步的了解之后，你就會大體上掌握智能卡應(yīng)用程序設(shè)計的基本技術(shù)要點。當(dāng)然對于一些系統(tǒng)的特殊標準還須另外掌握。我把這一向、整套標準分成“橫向的”和“縱向的”兩個部分：橫向的標準可以被所有的應(yīng)用程序所用，而縱向的標準僅僅適用于特定的系統(tǒng)。 

 

　　橫向的標準 

 

　　ISO7816－－描述到智能卡底層接口標準。這種標準定義智能卡閱讀器和智能卡之間如何傳遞字節(jié)流。 

 

　　PC/SC－－定義運行Win3.1/Win95/NT的機器與智能卡之間通信的標準。 

 

　　OCF－－定義從Java應(yīng)用環(huán)境和智能卡之間的通信標準，該標準完全是Java接口。（很快，OCF 將允許開發(fā)者向OCF輸出，并執(zhí)行轉(zhuǎn)換，這樣開發(fā)者再無必要使用PC/SC了。） 

 

　　JavaCard－－描述JavaCard和它所支持的標準。

 

　　縱向的標準 

 

　　Mondex－－以智能卡形式實現(xiàn)的數(shù)據(jù)現(xiàn)金。Mondex不允許存在于卡片之外的現(xiàn)金。 

 

　　VisaCash－－這種借貸卡可以用于跟蹤服務(wù)器上的卡。 

 

　　Proton－－另外一種形式的電子貨幣卡 

 

　　MPCOS-EMV－－這是一種通用的智能卡，它允許你實現(xiàn)自己的貨幣或是令牌。

我自己常常感覺到疑惑不解：對于這樣一塊小小的塑料卡片，為什么會有如此之多的文檔描述其標準，而且開發(fā)者又要掌握大量的知識才能去開發(fā)它？ 

 

　　因為進行智能卡的開發(fā)要求高度的專業(yè)知識，所以市場上需要支持Beans的產(chǎn)品，這種產(chǎn)品應(yīng)該用橫向的標準去實現(xiàn)縱向標準的。這意味著你可以使用各式各樣的橫向標準組合開發(fā)出Beans產(chǎn)品來，就象OpenCard一樣，為了實現(xiàn)特定的一個應(yīng)用程序而采用其它幾家商用標準或是其它的應(yīng)用程序。 

 

　　Java小應(yīng)用或是Java應(yīng)用程序與智能卡之間的通信

 

　　你知道了如何將所有硬件連接在一起�，F(xiàn)在我們需要如何使用一些API，這些API可以從應(yīng)用程序向智能卡閱讀器發(fā)出命令。（閱讀器然后與智能卡打交道，作為一個應(yīng)用程序到智能卡之間的信息傳遞媒介。）智能卡閱讀器移動其與智能卡接觸的金屬尖端傳遞數(shù)據(jù)。智能卡對數(shù)據(jù)做出處理之后反還給閱讀器，而閱讀器再將之傳會應(yīng)用程序。下面的問題是，在這些數(shù)據(jù)從應(yīng)用程序流向智能卡之時，它們究竟處于何處？ 

 

　　正如前所述，應(yīng)用程序與閱讀器通信，而閱讀器將使用上面介紹的標準再與智能卡通信�；�本上，隨著智能卡技術(shù)的發(fā)展，ISO推出了一套智能卡標準。該標準定義了智能卡的機械和電器特性以及與智能卡通信的標準。與ISO該標準相關(guān)的文檔列在參考資料當(dāng)中。不幸的是，ISO沒有能夠提供與閱讀器相互通信的標準。因此，為了向智能卡發(fā)出一條命令，首先你要找出智能卡支持的命令集合，將該命令用ISO命令包封裝，然后將這個包再以適合于閱讀器的格式封裝。下面的例程正是完成所有這些瑣事。 

 

　　Application Procotols Data Units(APDUs) 

 

　　與智能卡交換信息的基本單元就是APDU包。從應(yīng)用程序?qū)觽鞒龅拿�令消息，加上從智能卡返回到�?yīng)用程序的回應(yīng)消息均稱為ApplicationProcotolsDataUnits(APDU)。與智能卡和閱讀器的通信以APDU形式實現(xiàn)。一個APDU包可以看作包含完整指令或是回應(yīng)的數(shù)據(jù)包。為了提供這樣的功能，在ISO7816規(guī)范家族里有一部分為APDU定義了一個良好的結(jié)構(gòu)。 

 

　　APDU包含如下域： 

 

　　命令A(yù)PDU格式 

 

CLA INS P1 P2 Lc Data Le  

　　

 

　　回應(yīng)APDU格式 

 

Data SW1 SW2  

 

 

　　下面是一些支持APDU傳輸?shù)念惣捌涔δ苊枋觯?nbsp;

 

　　Command－－封裝命令A(yù)PDU 

 

　　Response－－封裝回應(yīng)APDU 

 

　　ISOCardReader－－規(guī)定一個接口。每一種設(shè)備必須實現(xiàn)該接口 

 

　　ISOCommand－－構(gòu)成一個ISOCommand并從ISOCardReader接口執(zhí)行該命令

與智能卡通信 

 

　　Sun開發(fā)了JavaElectronicCommerceFramework(JECF)，這是對核心Java平臺的擴展，它允許開發(fā)者輕松快速的開發(fā)商用電子應(yīng)用程序。JECF提供幾種與智能卡通信的類。 

 

　　我們這里討論的智能卡分別有一條讀取數(shù)據(jù)和寫入數(shù)據(jù)的命令。它是由GemPlus提供的名為GFM卡。你也可以使用其它類型的智能卡，只要它們支持ISO7816標準并且你了解它們的APDU命令格式。當(dāng)然還要做一點程序工作。GFM卡的內(nèi)存是以64個比特或是8個字節(jié)為單位的。你必須用模8的算法讀寫數(shù)據(jù)。換句話說，你不能向GFM卡做一次長度為1k連續(xù)的寫入。我們這里提供的Java代碼完成這項功能。一些新的智能卡支持更大單位的讀寫單位。因此，為了寫入字符串“0123456789”，你必須發(fā)出兩條適當(dāng)編址的命令。（是的，智能卡就是這樣難于編程。）當(dāng)存儲型卡和處理器型卡相互融合時，這種限制也許會消失。 

 

　　為了讀取上面那條字符串，你應(yīng)該發(fā)出“read”命令。這兩種命令按照APDU的術(shù)語被格式化的寫在了下面。在我們的例子中利用了Java讀寫智能卡。下面表中的值示出如何組成一個APDU。在GCM編程指南中定義了APDU的結(jié)構(gòu)。 

 

Location of data Upper Lower

256 0x00 0x00 

1023 0x00 0x00

3093 0x00 0x00 

 

　　“upper”和“lower”是地址的高位和低位字節(jié)。舉幾個例子可能會有助于明晰概念。這張 表的upper和lower值提供了存儲數(shù)據(jù)的確定地址。我們討論過的向GPM896智能卡通信的兩 種方法是： 

 

ISOCommand(0,0xD0,0,upper,lower,8);//Write 8 bytes to the address 

ISOCommand(0,0xB0,0,upper,lower,8);//Read 8 bytes from the address  

 

　　瀏覽器與智能卡之間的通信 

 

　　三個本地接口的存在表明對主要的開發(fā)者集團缺乏了解，沒有能夠充分考慮如何向處 于Java開發(fā)環(huán)境的開發(fā)者們提供簡單易于記憶的API。如果所有的銷售商均支持JNI，至少 接口可保持一致，你不必化大量的時間去把接口綁定。當(dāng)然你必須書寫少量的本地代碼，但 擁有統(tǒng)一的接口還是有價值的。我嘗試了所有三種API，最終發(fā)現(xiàn)JNI要比其它的更為一致，并且也最為簡單、易于實現(xiàn)。聯(lián)合HotJava一塊使用是最佳的，這樣你可以對與串口通信的 類簽名，然后安全的使用它們，比起另外兩種瀏覽器來講麻煩要少的多。Sun最近還宣布幫 助瀏覽器公司實現(xiàn)新版JDK/JVM的建議。 

 

　　前面的討論圍繞如何與一個不支持JDK的硬件設(shè)備通信。在下面的幾篇文章里我們將不再使用“本地接口”，而是使用一個工業(yè)標準與智能卡通信。我所選擇的這項標準就是帶有PC/SC橋的OpenCard標準。我將用OpenCard而不是PC/SC書寫應(yīng)用程序，為什么呢？ 

 

　　作為開發(fā)者，你擁有多種選擇。通常來講這是一件好事，但這也可能導(dǎo)致成本升高和功 能的不一致性，尤其是當(dāng)你選擇的API并不被多種平臺所支持時。例如，你決定用PC/SC標準 書寫支持Win32系列平臺的智能卡應(yīng)用程序。如果你的應(yīng)用程序是一個顧客使用的應(yīng)用并 且將用在WebTV之上，你的選擇就是完全錯誤的。顯示器上將會閃動一條信息：“等待WebTV 的Pentium版本。”智能卡是用在Win32桌面和CE單元以外的市場之上的。那么你應(yīng)該如何呢 ？使用OpenCard標準，拋棄缺乏一致JNI綁定的Internet Explorer。事實上，我認為將所有API 抽象至單一平臺是一個極為明智的選擇。