| JavaCard |
Native |
|
| 功能特性 |
||
| 開發語言 |
l 純面向對象的Java語言的子集。 Java語言先進靈活，開發調試速度快，實現靈活。 l Java沒有指針，並且有內部安全機制可以有效的避免越界訪問造成的程序的錯誤和崩潰。 l 所有的變量在Java中創建時，都會被自動進行初始化。 |
l 匯編和標准C，面向過程的語言。 l 匯編語言作為機器語言，比較晦澀，開發速度慢，使現有局限，但是運行速度快，效率高。 l C語言有指針，可以靈活的實現各種內存操作，但容易因為越界訪問造成錯誤和崩潰。 l C中的變量需要手工初始化，容易因為忽略造成錯誤。 |
| 體系構架 |
分為兩層結構。 l 底層為按照JavaCard規范實現的JavaCard平台，向上提供規范定義的接口（API），通常支持JavaCard API和GP API。 l 上層為按照應用需求開發的Applet，相當於Native卡片上的ADF。可以根據不同類型的應用，開發多個Applet。這些Applet相互獨立，通過AID來選擇。 |
統一通過卡片操作系統（COS）來實現所有的功能。 l COS內部也按照功能的不同，分為多個層次，包括應用層具體交易APDU的實現，通訊協議層的實現，以及和芯片的具體交互等等。 l 通常通過創建不同的ADF文件的方式，來區分不同的應用。 |
| 應用(ADF)選擇 |
l JavaCard規范定義，只支持通過AID選擇應用（ADF）。 l 在應用內部，可以通過程序實現，用AID或者DFID選擇ADF。 |
l 可以通過AID或者DFID選擇應用(ADF)。 |
| 個人化流程 |
JavaCard規范推薦統一的通用個人化流程(CPS)，在創建安全通道后，通過統一的Store Data命令完成卡片的個人化。 |
不同廠家定義完全不同的個人化流程，采用完全不同的個人化指令，紛繁復雜，不便於掌握，也不便於統一。 |
| 卡片鎖定 |
卡片鎖定后，再向卡片發送指令，由卡片上的JavaCard平台按照規范定義統一處理，不受具體應用(Applet)的控制。 |
卡片鎖定后，在向卡片發送指令，仍然由卡片操作系統（COS）處理，應用指令通過程序內部予以屏蔽。 |
| RSA密鑰長度支持 |
按照JavaCardAPI接口V2.2.1，支持512，736，768，896，1024，1280，1536，1984，2048位長度的密鑰。 |
可以支持芯片所能支持的按8字節或者4字節長度遞增的密鑰長度。 |
| 協作開發 |
l 可以開發一種特殊的Applet，作為可以被其他應用Applet調用的通用的功能模塊(Library)，以便於統一提供一些功能的實現。 l 可以通過Shareable Interface安全的調用其他Applet授權可以訪問的方法。 |
源代碼級別上的協作開發，通過代碼的重用，實現功能上的協作。 |
| 安全性 |
||
| 規范定義 |
l JavaCard規范，目前普遍支持2.2.1版本。 l GP規范，目前普遍支持2.1.1版本。 l 安全性由這些規范定義和保證，並經過SUN的權威認證。 |
沒有統一的國際性規范。 安全性由各卡片COS生產廠家，通過管理和測試進行保證。 |
| 安全控制機制 |
多種安全機制的參與，包括Applet之間的防火牆，安全域和安全通道的控制。 |
主要通過狀態機來實現。特殊指令使狀態機跳轉，訪問文件時判斷狀態機是否滿足條件。 |
| 應用數據獨立性 |
不同應用之間的數據直接訪問是嚴格禁止的，由JavaCard平台實現的防火牆實現物理隔離。 |
將不同應用的數據組織為不同的ADF文件，靠的是卡片存儲空間上的邊界來區分。 |
| 數據訪問 |
存儲在RAM上的緩存數據，可以在應用失去選擇，或者卡片Reset之后自動清除，無法再次訪問，確保臨時數據不會泄密。 |
存儲在RAM上的緩存數據，在卡片Reset之后自動清除，無法再次訪問，確保臨時數據不會泄密。 |
| 數據存儲 |
數據存儲分為文件和內部數據對象兩種方式。 l 對於像密鑰一類的敏感數據，采用JavaCard規范定義的內部數據對象存儲，該對象由JavaCard平台實現，對這些敏感數據進行特殊保護。 l 其他的普通存儲數據，以文件形式組織，便於訪問和管理。 |
數據統一按照文件的形式組織和存儲。 l 不論是密鑰還是數據，不論是敏感數據還是普通數據，都存放在文件中。 l 對密鑰等敏感數據可能采取加密存儲的方式，或者存放在特殊訪問權限的文件中。 |
| 功能的修改和增/刪 |
||
| 修改APDU指令 |
l 對相應的Applet源代碼進行單獨的修改，不影響其他應用的實現和穩定性，不影響底層的JavaCard平台的實現和穩定性。 l 只需要對修改的Applet進行測試和認證。 |
l 對卡片操作系統（COS）進行修改，可能會影響其他應用的指令的實現和穩定性。 l 需要重新進行整體的測試和認證。 |
| 添加全新的指令 |
l 對相應的Applet源代碼進行單獨的修改，不影響其他應用的實現和穩定性，不影響底層的JavaCard平台的實現和穩定性。 l 只需要對修改的Applet進行測試和認證。 |
l 對卡片操作系統（COS）進行修改，可能會影響其他應用的指令的實現和穩定性。 l 需要重新進行整體的測試和認證。 |
| 不同應用下，相同的指令支持不同功能 |
l 分別對不同應用對應的Applet進行單獨修改，互不影響，也不會造成沖突。 l 實現簡單，安全。 |
l 對卡片操作系統（COS）進行修改，因為對相同的指令要有不同的解釋，所以可能會有沖突。 l 需要通過轉義表的方式，判斷當前在哪一個應用對應的ADF文件下，來進行何種解釋。 l 實現起來比較復雜，有一定風險。 |
| 添加全新的應用和交易 |
l 開發一個全新的Applet應用。不影響其他應用的實現和穩定性，不影響底層的JavaCard平台的實現和穩定性。 l 只需要對新增的Applet進行測試和認證。 |
l 對卡片操作系統（COS）進行修改，增加新的應用和交易。可能會影響其他應用的指令的實現和穩定性。 l 需要重新進行整體的測試和認證。 |
| 刪除對某種應用的支持 |
直接將應用對應的Applet從卡片中刪除即可。 |
對卡片操作系統（COS）進行修改，刪除對應的應用的交易和指令。 |
| 應用和案例 |
||
| 主要應用范圍 |
l EMV2000借貸記應用(VSDC, MChip, PBOC2.0 DC)， l 積分， l ED/EP， l NFC等新業務應用領域， l 復合應用，例如金融應用+積分應用，NFC應用+電信應用， l 電信SIM卡。 |
l EMV 96，PBOC1.0 ED/EP， l PBOC2.0 DC， l 社保， l PSAM或者ESAM， l Key卡， l USBKey。
|
| 案例數量 |
數量逐步增加，突出表現在借貸記應用領域、新業務領域和復合應用領域 |
已經廣泛的在應用在一些傳統的領域，或者有一定歷史的項目中。 |
| 容量和價格 |
||
| EEPROM空間大小 |
通常為20K，36K，72K或者更大，便於對於多應用的支持 |
通常為8K,16K或者32K,36K，便於節約成本，大批量展開。 |
| 芯片平台 |
l 通常采用高端芯片平台， l 通常支持RSA和雙界面， l 芯片頻率高，處理速度快。 |
l 采用中高低端各種芯片平台， l 可選支持RSA和雙界面。 |
| 卡片價格 |
l 由於卡片EEPROM空間通常比較大，芯片平台比較高端，所以價格比較高。 l 還存在JavaCard授權的問題，可能需要向SUN支付授權費用，這個費用包含在卡片費用中，由卡片生產廠家支付。 |
由於卡片EEPROM空間通常小一些，所以價格相對比較便宜。 |