目前從全球來看，第一波的EMV遷移進(jìn)程已經(jīng)接近尾聲，現(xiàn)在人們關(guān)注的是如何從SDA(靜態(tài)數(shù)據(jù)認(rèn)證)進(jìn)一步升級到DDA（動態(tài)數(shù)據(jù)認(rèn)證）或者CDA（關(guān)于SDA、DDA、CDA的定義參見EMV規(guī)范），從而進(jìn)一步增強(qiáng)卡片的防欺詐能力。

    反觀國內(nèi)市場，EMV遷移幾乎還停留在起步階段，只有為數(shù)不多的幾家銀行發(fā)行了少量的EMV卡。更多的銀行還在熱火朝天地推廣普通的磁條信用卡，五花八門的促銷手段和普天蓋地的廣告，讓人目不暇接。國內(nèi)各家銀行會同威士、萬事達(dá)、JCB、美國運(yùn)通發(fā)行的各種雙幣種信用卡，不僅讓普通的消費(fèi)者無所適從，也讓國內(nèi)銀行間交易處理業(yè)務(wù)的中國銀聯(lián)感到了市場的嚴(yán)峻，所以中國銀聯(lián)采取各種策略，希望國內(nèi)的銀行能夠發(fā)行銀聯(lián)卡，并且不遺余力地推廣PBOC借貸記和小額支付規(guī)范的應(yīng)用，這樣從市場上為PBOC借貸記和小額支付的大量普及消除了阻力。

    PBOC規(guī)范和EMV規(guī)范

    在EMV2000芯片卡規(guī)范頒布之后，各個主要的銀行卡組織都根據(jù)自身的需要對EMV規(guī)范進(jìn)行了細(xì)化和修訂，其中包括威士推出的VSDC，萬事達(dá)推出的 Mchip以及JCB推出的Jsmart等。通過各個銀行卡組織的細(xì)化，進(jìn)一步明確了在EMV規(guī)范中一些籠統(tǒng)的定義，并且把一些發(fā)卡行可以靈活定義的選項作了明確的約定，這樣可以保證同一個銀行卡品牌在全球各地的成員銀行進(jìn)行EMV芯片遷移的時候可以做到一致，更好地實現(xiàn)互操作性，當(dāng)然這也為眾多的智能卡廠商在產(chǎn)品開發(fā)方面提供了必要的參考依據(jù)。

    PBOC規(guī)范可以說是中國人民銀行針對EMV規(guī)范的本地化版本，在EMV規(guī)范的整體框架內(nèi)，根據(jù)中國的銀行卡實際進(jìn)行了適當(dāng)?shù)男抻啠钥ㄆ灰椎牧鞒桃约皞€人化指南方面和EMV規(guī)范幾乎完全一致。

    PBOC規(guī)范和Java卡以及GP規(guī)范

    我們都知道Java卡是SUN公司推出的面向智能卡的一種Java體系結(jié)構(gòu)，利用Java卡可以加快應(yīng)用開發(fā)的進(jìn)度，避免開發(fā)者苦苦鉆研具體的智能卡芯片底層結(jié)構(gòu)，能夠以更靈活的方式支持卡片多應(yīng)用以及卡片發(fā)行后的應(yīng)用添加和刪除。不同應(yīng)用之間具有防火墻，可用通過安全通道的方式實現(xiàn)卡片和終端之間的保密通訊。

    當(dāng)然如果僅僅從功能上來看，Java卡的各種功能也都可以在Native卡上實現(xiàn)，不過Native卡實現(xiàn)上述功能的方法在不同廠商之間會存在很大的差別，增加了用戶在個人化、應(yīng)用開發(fā)方面的困難。

    對于Java卡在應(yīng)用的下載、刪除、個人化、卡片生命周期管理等方面都有明確的定義，這就是GP（Global Platform）規(guī)范的內(nèi)容。很多智能卡廠商、芯片廠商、銀行卡組織和電信運(yùn)營商都是GP的成員，而GP規(guī)范最早是威士開發(fā)的Open Platform，所以在EMV卡的個人化方面參照GP規(guī)范也就不足為奇了。 

    PBOC規(guī)范在第10部分《中國金融集成電路（IC）卡借記貸記應(yīng)用個人化指南》中所定義的命令和流程以及EMV卡的個人化流程也是一致的，也就是說同樣符合GP規(guī)范。

    因此如果采用Java卡進(jìn)行PBOC借貸記應(yīng)用開發(fā)的話，在個人化方面很容易滿足個人化指南的要求。但是對于Native卡而言，如果要達(dá)到同樣的結(jié)果不僅所需要的開發(fā)周期長，而且開發(fā)難度也大。

    所以從規(guī)范的角度看，雖然PBOC規(guī)范沒有像威士那樣明確定義Open Platform，但是從內(nèi)容上看和Java卡以及GP規(guī)范都是一致的，在PBOC規(guī)范中也同樣定義了如何利用INITIALIZE UPDATE，EXTERNAL AUTHENTICATE，STORE DATA（詳情參見GP規(guī)范）等命令進(jìn)行數(shù)據(jù)和密鑰的個人化。

    國內(nèi)的Java卡和Native卡應(yīng)用

    雖然支持GP規(guī)范的Java卡在全球市場已經(jīng)得到了廣泛普及，但國內(nèi)市場的一些項目主要還是Native卡占據(jù)主導(dǎo)地位。其中的原因除了成本考慮外，還有其它幾方面的因素：

    ◆ 國內(nèi)各個不同應(yīng)用部門機(jī)構(gòu)之間利益分割嚴(yán)重，難以達(dá)成統(tǒng)一的多應(yīng)用平臺，缺少Java卡的應(yīng)用環(huán)境，使得Java卡的多應(yīng)用優(yōu)勢難以有效發(fā)揮；
    ◆ 因為開發(fā)Java卡需要向SUN公司支付一定的技術(shù)轉(zhuǎn)讓費(fèi)用，所以國內(nèi)一些卡商寧可投入大量的人力物力，開發(fā)屬于自己的Native卡，也不愿意開發(fā)Java卡，這樣從技術(shù)上缺少相應(yīng)的儲備；
    ◆ 進(jìn)入國內(nèi)市場的一些國外廠商雖然有很好的Java卡產(chǎn)品，但是在國內(nèi)的應(yīng)用環(huán)境中絲毫發(fā)揮不了Java卡的優(yōu)勢，比如電信領(lǐng)域的OTA應(yīng)用，在Java卡中都有很好的實現(xiàn)，可惜不論是中國移動還是中國聯(lián)通都撇開成熟的技術(shù)不用，另起爐灶開發(fā)自己的OTA系統(tǒng)，把眾多的卡商弄的無所適從；
    ◆ 開發(fā)國內(nèi)銀行IC卡電子錢包應(yīng)用和社保應(yīng)用的一些系統(tǒng)集成商已經(jīng)熟悉了廣泛應(yīng)用于Native卡的那套密鑰傳遞、管理機(jī)制和文件建立的流程，對于Java卡缺少了解。

    但是我們也看到相關(guān)的單位和部門在智能卡多應(yīng)用方面已經(jīng)有所行動，比如去年成立的國家金卡工程多功能卡應(yīng)用聯(lián)盟，號召各個應(yīng)用部門之間協(xié)調(diào)合作，力推一卡多用。而Java卡是得到全球用戶廣泛認(rèn)可的多應(yīng)用產(chǎn)品，在未來中國的多功能卡應(yīng)用中也同樣會發(fā)揮其獨(dú)特的作用。

    部分國內(nèi)銀行開始選擇Java卡

    隨著PBOC借貸記卡項目的逐步啟動，一些銀行在卡片選型方面已經(jīng)往Java卡方面傾斜。銀行之所以選擇Java卡，主要看中的就是Java卡所支持的GP規(guī)范，為銀行開發(fā)自己的增值應(yīng)用提供了可能。

    從國外EMV遷移的經(jīng)驗來看，在項目啟動初期大家都急于尋找一個商業(yè)模式，以便能夠平衡EMV遷移帶來的投入，雖然其中包含減少欺詐損失的因素，但是銀行還是希望能夠在這個功能強(qiáng)大的芯片卡上面挖掘更多的潛能。于是人們自然會把注意力放在芯片卡的多應(yīng)用方面，銀行也會根據(jù)不同的客戶群開發(fā)不同的增值應(yīng)用，既防止客戶流失，也帶來了增值收入。

    比如國內(nèi)部分商業(yè)銀行正在進(jìn)行的一些項目預(yù)測試，就希望采用具備一定存儲空間的Java卡，這樣才能夠把自己開發(fā)的一些應(yīng)用下載到Java卡上，而且可以利用自己的發(fā)卡商權(quán)限更好地管理各種應(yīng)用。

    另外，中國銀聯(lián)也起草了支持非接觸交易的PBOC以及小額支付的規(guī)范，于是商業(yè)銀行在PBOC卡片的發(fā)行方面就會有自己不同的應(yīng)用組合模式，Java卡在應(yīng)用下載、安裝、刪除方面的通用性和靈活性無疑將會成為最佳選擇。

    Java卡在PBOC借貸記和小額支付應(yīng)用中的優(yōu)勢

    ◆ 能夠滿足不同的市場需求：因為國內(nèi)PBOC借貸記項目以及小額支付項目剛剛開始啟動，而且對于項目中如何取舍PBOC規(guī)范沒有明確定義的數(shù)據(jù)項，各個商業(yè)銀行之間也可能存在一些差異，那么在這個時候如果采用完全固化到芯片中的Native卡則很難具備應(yīng)有的靈活性。但是Java卡因為應(yīng)用程序本身可以靈活下載，所以可以更好地適應(yīng)多變的市場；
    ◆ 具備快速進(jìn)入市場的能力：因為多數(shù)銀行應(yīng)用的Native卡都需要進(jìn)行COS的掩模，而且這一過程通常需要2-3個月的周期，無疑延緩了產(chǎn)品上市的時間。而Java卡在應(yīng)用程序開發(fā)完成之后，就可以對外銷售，相當(dāng)于節(jié)省了掩模的時間，對于瞬息萬變的市場而言，這2-3個月顯得彌足珍貴；
    ◆ 可以簡化產(chǎn)品開發(fā)過程：如果采用Native卡開發(fā)PBOC借貸記和小額支付應(yīng)用，需要從底層一點一滴做起，包括通訊協(xié)議、加密算法、內(nèi)存管理、數(shù)據(jù)存儲等，任何環(huán)節(jié)出現(xiàn)錯誤都會導(dǎo)致整個項目的崩潰。而利用Java卡進(jìn)行開發(fā)的話，則只需要關(guān)注應(yīng)用本身，只要理清整個交易流程很快就能夠開發(fā)出滿足規(guī)范的產(chǎn)品，前面提到的那些底層開發(fā)工作已經(jīng)都包含在Java卡的API里面了，使得開發(fā)工作變得簡單而容易；
    ◆ 項目初期整體成本低：一般來說單張Java卡的成本比Native卡略高，但是Native卡的成本優(yōu)勢只有在大規(guī)模應(yīng)用的時候才能夠體現(xiàn)出來，因為芯片廠商都會收取一筆不菲的掩模費(fèi)。對于初期的PBOC借貸記和小額支付項目應(yīng)用而言，一般試點規(guī)模都是以數(shù)萬張為限，所以Java卡反而具備更好的成本優(yōu)勢。

    總結(jié)

    目前，Java卡在國內(nèi)的市場雖然所占的份額還很小，但是我們看到未來的趨勢正朝著有利于Java卡的方向發(fā)展。而且國內(nèi)一些具有前瞻性的卡商也開始著手進(jìn)行Java卡的開發(fā)，在GP成員的名單中也有了中國公司的身影。這都說明Java卡得以普及的內(nèi)部和外部環(huán)境都在逐步改善，我們相信伴隨著未來幾年國內(nèi)商業(yè)銀行針對PBOC借貸記、小額支付以及qPBOC芯片卡項目的逐步啟動，以及NFC移動支付業(yè)務(wù)的發(fā)展，Java卡的前景也會越來越樂觀。

    附：本文提到的相關(guān)規(guī)范可以瀏覽以下鏈接獲得詳情：

    1．EMV規(guī)范：http://www.emvco.com/specifications.asp
    2．Java卡規(guī)范：http://java.sun.com/javacard/specs.html
    3．GP規(guī)范：http://www.globalplatform.org/showpage.asp?code=specifications

    關(guān)于SDA和DDA：

    脫機(jī)數(shù)據(jù)認(rèn)證是PBOC2.0中的重要部分的，是驗證金融IC卡的有效手段。未來，消費(fèi)者在使用符合PBOC2.0要求的金融IC卡進(jìn)行持卡消費(fèi)的時候，布置在商家的POS系統(tǒng)會與IC卡交互完成脫機(jī)數(shù)據(jù)認(rèn)證工作，判斷該卡是否被惡意篡改過或非法復(fù)制。在PBOC2.0中定義了兩種脫機(jī)數(shù)據(jù)認(rèn)證的方式，即靜態(tài)數(shù)據(jù)認(rèn)證和動態(tài)數(shù)據(jù)認(rèn)證。

    靜態(tài)數(shù)據(jù)認(rèn)證（簡稱SDA），由終端驗證IC卡中的數(shù)字簽名來完成。其目的是確認(rèn)存放在IC卡中關(guān)鍵的靜態(tài)數(shù)據(jù)的合法性，以及可以發(fā)現(xiàn)在卡片個人化以后，對卡內(nèi)的發(fā)卡行數(shù)據(jù)未經(jīng)授權(quán)的改動，不僅能有效地檢測IC卡內(nèi)關(guān)鍵靜態(tài)數(shù)據(jù)的真實性，而且防止卡片的非法復(fù)制和偽造。

    動態(tài)數(shù)據(jù)認(rèn)證（簡稱DDA）。在動態(tài)數(shù)據(jù)認(rèn)證過程中，終端驗證卡片上的靜態(tài)數(shù)據(jù)以及卡片產(chǎn)生的交易相關(guān)信息的簽名，DDA能確認(rèn)卡片上的發(fā)卡行應(yīng)用數(shù)據(jù)自卡片個人化后沒有被非法篡改。DDA還能確認(rèn)卡片的真實性，防止卡片的非法復(fù)制。

    DDA可以是標(biāo)準(zhǔn)動態(tài)數(shù)據(jù)認(rèn)證或復(fù)合動態(tài)數(shù)據(jù)認(rèn)證/應(yīng)用密文生成（CDA）。

    關(guān)于Native卡：

    Native卡是和Java卡相對應(yīng)的概念，通常所說的Native卡是指卡片的COS和硬件平臺緊密相關(guān)，卡片不具有通用性和二次開發(fā)的API接口，應(yīng)用的開發(fā)和底層COS密不可分，而且多數(shù)的Native卡僅支持單一應(yīng)用，即便是支持多應(yīng)用也是事先固化在芯片里的多應(yīng)用，不能夠像Java卡那樣支持多應(yīng)用的動態(tài)下載。