基於HCE移動支付研究報告

標籤：

　1. 概念

　　HCE(host-based card emulation)，即基於主機的卡類比。在一部配備NFC功能的手機實現卡類比，目前有兩種方式：一種是基於硬體的，稱為虛擬卡模式(Virtual Card Mode);一種是基於軟體的，被稱為主機卡模式(Host Card Mode)，即本文要討論的方式。

　　在虛擬卡模式下，需要提供安全模組SE(Secure Elemen)，SE提供對敏感資訊的安全儲存和對交易事務提供一個安全的執行環境。NFC晶片作為非接觸通訊前端，將從外部讀寫器接收到的命令轉寄到SE，然後由SE處理，並通過NFC控制器回複。

　　而在主機卡模式下，不需要提供SE，而是由在手機中啟動並執行一個應用或雲端的伺服器完成SE的功能，此時NFC晶片接收到的資料由作業系統或發送至手機中的應用，或通過移動網路發送至雲端的伺服器來完成互動。兩種方式的特點都是繞過了手機內建的SE的限制。

　　2.NFC技術簡介

　　近距離無線通訊(Near Field Communication,NFC)是一種短距高頻的無線電技術，由非接觸式射頻識別(RFID)演變而來。NFC工作頻率為13.56Hz，有效範圍為20cm以內，其傳輸速度有106 Kbit/秒、212 Kbit/秒或者424 Kbit/秒三種。NFC有3種工作模式：讀卡機模式、點對點模式、卡類比模式。在讀卡機模式時，NFC裝置產生射頻場從外部採用相同標準的NFC標籤中讀寫資料。在點對點模式中，NFC可以與其他的NFC裝置通訊，進行點對點的資料轉送。卡類比模式中，讀卡機是主動裝置，產生射頻場;NFC裝置為被動裝置，類比一張符合NFC標準的非接觸式卡片與讀卡機進行互動。其中本文所討論的HCE技術主要是用於卡類比的模式。

　　傳統的NFC終端主要包括非接觸性前端CLF(也叫NFC控制器)、天線(Antenna)、安全模組(Secure Element,SE)三個主要組件。在CLF中提供了識讀介面、P2P介面、卡類比介面，分別對應上面所說的三種工作模式。

　　安全模組SE主要功能是實現應用和資料的安全儲存，對外提供安全運算服務，它是卡類比的核心。安全模組還通過非接前端與外部讀寫裝置進行通訊，實現資料存放區及交易過程的安全性。

　　非接觸性前端也稱為NFC控制器，其功能包括射頻訊號的調製解調，非接觸通訊的協議處理。非接觸前端一方面串連射頻天線，實現13.56MHz訊號的發送與接收，另一方面與安全模組通訊。

　　天線整合在終端內部，與非接前端相連，實現13.56MHz射頻訊號的發送與接收。

　　NFC的實現方案中，一般非接前端、天線都整合在手機終端中，而安全模組可根據情況存放在不同的位置。根據安全模組存放的位置不同，NFC可分為不同的實現方案。

　　3.基於安全模組的卡類比

　　圖1 基於安全模組的卡類比

　　當使用安全模組(SE)來提供卡類比時，安全模組通過NFC晶片中的非接觸前端與外部讀寫裝置進行通訊，資料的儲存和處理都在安全模組中。使用者將手機放入NFC終端的識別範圍，NFC控制器將從外部讀寫器接收到的所有資料直接轉寄到手機內部的安全模組，由安全模組處理，然後再通過NFC控制器將響應資料發送給外部讀寫終端，整個事務過程中手機上的應用程式完全沒有參與其中。待事務過程完成後手機端的Android應用程式可以查詢安全模組的事務狀態然後通知客戶。圖1描述了這個過程。

　　基於安全模組的卡類比主要有三種解決方案，分別是NFC全終端方案、eNFC技術方案和NFC-SD技術方案。

　　NFC全終端方案是指將安全模組整合到手機終端的NFC方案，支援多安全域、多應用安全模組架構以及相應的管理技術，可在安全模組上劃分不同的安全域以承載來自不同應用提供者的不同安全要求的各類應用，而且能保證各應用之間資料獨立與資料安全。NFC全終端方案優勢是其標準成熟，得到眾多終端廠商的認可與支援。此方案中由於安全模組與手機整合，有效避免了機卡介面和機卡相容性的問題。缺點是安全晶片無法與手機終端分離，業務初始化、個人化、業務更新和管理不方便，使用者更新手機時，所有業務需要重新轉移到新手機，成本高，流程長。Google錢包就是基於NFC全終端方案的一個典型業務。

　　eNFC技術方案是使用SIM/UIM卡作為安全模組的NFC技術方案，又被稱為SWP(單線通訊協定)方案或NFC-SIM方案。用SIM/UIM卡作為安全模組，儲存使用者支付賬戶、密鑰等敏感性資料，運行支付應用，手機中的NFC控制器通過SWP(Single Wire Protocol)協議與SIM/UIM卡通訊。由於SIM/UIM卡是移動使用者必不可少的身份識別模組，使用者對SIM卡作為安全模組較容易接受，同時卡片和應用的發行及服務可以藉助電信電訊廠商的受理渠道，容易進行業務的推廣。此外，SIM卡與終端分離，使用者更換手機不會影響移動支付業務的繼續使用，靈活性更高。由於eNFC方案的諸多優勢，國內外的電信電訊廠商多選用eNFC方案，因此eNFC是業界認為最可能的移動近場支付技術方向。但是eNFC方案還面臨諸多困難，如專利、規範等，更重要的是，支援eNFC的手機終端很少，eNFC的產業鏈不成熟，該技術的商用還有較大障礙，目前還沒有比較典型的商用案例。

　　NFC-SD技術方案是使用移動終端智能SD卡作為安全模組的NFC技術。其方案與eNFC方案類似，智能SD卡與NFC控制器晶片之間也採用SWP協議串連，可實現卡類比、讀卡機和點對點通訊三種工作模式。採用NFC-SD方案服務提供者(Service Provider，SP)可以自行發行SD卡，這樣就能獨立於電信電訊廠商發展NFC業務，因此金融機構做主導時更願意採用這種方式。但是SD卡方案需要支援SWP-SD方案的手機支援，而市面上相關款式的機型太少。另外一張SD卡一般只能支援一個SP的服務，如果使用者希望能使用多種服務的話，還必須在不同的SD卡中間切換，切換過程繁瑣且成本偏高。儘管NFC-SD方案被中國銀聯定為其移動現場支付標準，但NFC-SD卡方案被證明是比較難於實施的。

　　採用全終端解決方案和eNFC技術方案，儘管解決了多應用的服務的問題，但是SE的控制權卻被手機製造商和行動電信業者鬧鬧掌控，第三方的SP要部署的自己的服務必須和SE的發行者們溝通，而這已經被證明是複雜和耗時的。而如果採用NFC-SD方案，儘管服務提供者可以自己控制SE，但是這種方案得不到手機廠商和行動電信業者的支援，而且對於使用者來講，要使用多種服務就必須切換SD卡。這些因素都限制了NFC技術在移動支付領域的應用。而通過以上分析我們不難得出，問題的核心就在於通向“手機錢包”的一扇門-SE的控制權上。

　　2013年10月31日，Google發布了最新的Android4.4系統，這其中提到了一個NFC的新技術，即HCE(Host Card Emulation)。自誕生之初，HCE就引起了極大的關注，不僅僅在於這項令人耳目一新的新技術本身，更在於它讓業界的所有人看到了一種脫離安全載體(SE)而部署NFC的可能性。HCE技術對第三方的服務提供者(SP)意義重大，它使得SP們可以將自己的服務在更短時間內以更低的開發成本推向市場，而使用者也可以更方便的使用多個SP提供的服務。

　　4.基於主機的卡類比(HCE)

　　圖2 基於主機的卡類比

　　使用基於主機的卡類比時(HCE)，NFC控制器從外部讀寫終端接收到的資料將直接被發送到主機系統上，而不是安全模組。圖2描述了這個過程。

　　4.1支援的NFC卡和協議

　　NFC標準對很多智慧卡協議提供了支援，Android4.4系統也支援包括金融支付卡在內的很多非接觸智慧卡協議，因此使用手機可以類比出不同類型的智慧卡。同樣市場上很多NFC讀卡機也支援這些協議，包括一部支援NFC的Android裝置作為讀卡機本身。這樣通過HCE技術我們只用Android裝置就可以部署一個端對端的NFC解決方案。

　　Android4.4系統使用NFC論壇制定的的ISO-DEP標準協議(基於ISO/IEC 14443-4(ISO-DEP)標準)進行資料轉送，傳輸的資料單元被稱為應用協議資料單元(APDUs)。另外，在數字協議方面(相當於MAC層協議)，Android系統只要求對頂層的NFC-A(ISO/IEC 14443-3 Type A)技術提供支援，而對NFC-B技術的(ISO/IEC 14443-3 Type B)的支援則是可選的，這些技術提供了包括初始化、衝突檢測等解決方案。Android系統的HCE協議棧3所示。

　　圖3 Android HCE協議棧

　　4.2 HCE服務

　　Android系統上的HCE技術是通過系統服務實現的(HCE服務)。使用服務的一大優勢是它可以一直在後台運行而不需要有使用者介面。這個特點就使得HCE技術非常適合像會員卡、交通卡、門禁卡這類的交易，當使用者使用時無需開啟程式，只需要將手機放到NFC讀卡機的識別範圍內，交易就會在後台進行。當然如果有必要的話，使用者也可以開啟UI介面。這時的手機和普通的智慧卡片已經沒有區別了。

　　在上面的交易中我們有一個問題沒有解決，當使用者將手機放到NFC讀卡機的識別範圍時,Android系統需要知道讀卡機真正想要和哪個HCE服務互動，這樣它才能將接收到的資料發送至相應的服務。ISO/IEC 7816-4規範正是解決服務選擇的問題，它定義了一種通過應用程式ID(AID)來選擇相應服務的方法。一個AID佔16位，如果手機類比的是一個已經存在的NFC讀卡設施，那麼這些NFC讀卡設施會去尋找那些經公用註冊而廣為人知的AID(類似於連接埠號碼)。像Visa卡和萬事達卡等這些智慧卡可以註冊AID號作為他們專用的識別標誌。反之，如果要為自己的新的讀卡設施部署NFC應用，你就需要註冊自己的AID。AID註冊過程在ISO/IEC 7816-5規格中定義，為防止和其他的Android程式衝突，Google建議AID號按此規格中推薦的註冊。

　　4.2.1 AID組

　　在某些情況下，為實現一個應用，HCE服務需要註冊多個AID號，我們需要確保這些AID號的處理請求都會送到這個應用，而不是組中的某個AID號的請求被送到了其他的應用中。

　　一個AID組中的所有AID號應該被系統看作是一個整體，對於這些AID號，作業系統肯定會保證以下中一點：

　　AID組中的所有AID號都被路由到某個HCE服務;

　　AID組中沒有一個AID號被路由到某個HCE服務;

　　換言之，絕對不會存在中間狀態，組中某個AID被路由到一個HCE服務，而另外一個被路由到其他的HCE服務中。

　　4.2.2 AID組合和交易類型

　　對於使用者而言，他們不會去關注AID號及AID組，他們只會關注現在進行中的是什麼交易，所以Android4.4定義了Category。每個AID組對應一個Category，這樣系統就可以按類型對HCE服務進行組織。

　　Android4.4定義了兩個類型：CATEGORY_PAYMENT(用於符合工業標準的支付應用)和CATEGORY_OTHER(其他的HCE應用)。在應用程式的設定檔中我們可以聲明應用的類型。值得注意的是在CATEGORY_PAYMENT類型中，只有一個AID組應用可以在任何時候處於可用狀態，這個AID組所代表的應用一般是能夠讀懂大部分的銀行卡支付協議並能夠在任何一個支付商家處使用。對於像儲值卡這類只能在某個商家處使用的閉環支付應用，我們應該使用CATEGORY_OTHER。這個類型裡的AID組可以一直保持啟用狀態，如有必要在AID選擇的時候可以被NFC讀卡機賦予優先順序。

　　4.3實現HCE服務

　　在手機上用HCE技術實現NFC卡類比，首先要建立一個處理交易事務的HCE服務。我們可以通過檢查FEATURE_NFC_HOST_CARD_EMULATION特性來檢查手機是否支援HCE技術，然後在設定檔manifest中的標籤中聲名本程式使用HCE技術。

　　Android4.4為HCE服務提供了一個非常方便的基類HostApduService，我們可以通過繼承HostApduService來實現自己的HCE服務。

　　public class MyHostApduService extends HostApduService {

　　@Override

　　Public byte[] processCommandApdu(byte[] apdu, Bundle extras){

　　...

　　}

　　@Override

　　public void onDeactivated(int reason){

　　...

　　}

　　}

　　HostApduService中聲明了兩個我們需要重寫並實現的抽象方法。

　　任何時候，NFC讀卡機向手機服務發送應用協議資料單元(APDU)的時候processCommandApdu()方法都會被調用。APDUs被定義在ISO/IEC 7816-4規範中，作為一個應用程式層的協議包，APDUs被用於HCE服務和NFC讀卡機之間的資料交換。並且此應用程式層協議是半雙工的：NFC讀卡機向手機發送一個命令APDU，然後等待手機回複一個APDU包。

　　正如前面提到的，Android系統通過AID來決定使用哪個HCE服務與NFC讀卡機互動。所以一般情況下，NFC讀卡機發送的第一個APDU是"SELECT　AID"APDU，這個APDU包含NFC讀卡機想要對話的服務的AID號。Android系統提取出協議包裡的AID號，將其發送至相應的HCE服務，並將其後的APDU都發送至那個HCE服務。

　　我們可以通過在processCommandApdu中返回位元數組來發送一個回複APDU。由於processCommandApdu方法會在主線程中被調用，所以不能被阻塞。當在程式中無法立即計算出結果並回複時，我們應該立即返回NULL。然後在其他的線程中做相應的工作，待計算結果完成後用在HostApduService中定義的 sendResponseApdu()方法發送回複。

　　Android系統會將從NFC讀卡機接收到的APDU都發送至已選擇的那個HCE服務，直到遇到以下兩種情況：

　　1.NFC讀卡機發送另外一個"SELECT AID"APDU命令，作業系統會重新選擇一個其他的HCE服務。

　　2.NFC讀卡機和手機之間的串連中斷。

　　以上任何一種情況發生時，onDeactivated()方法會被調用，它的參數(reason)則指明發生了哪種情況。

　　如果要開發已存在的NFC系統，我們只需要在HCE服務中實現NFC讀卡機期望的應用程式層協議。反之如果要開發自己的新的NFC系統，我們就需要定義自己的協議和APDU序列。一般而言我們應該保證資料交換時使用很少的APDU包數量和很小的資料量，這樣使用者就不必花很長時間將手機放在NFC讀卡機上。一個明智的選擇是交換的資料量不超過1KB，這樣一次通訊通常只需300ms。

　　4.4 AID衝突的解決方式

　　在手機中我們可以安裝多個HCE服務，同一個AID號可能會被很多個HCE服務所註冊。Android系統對於不同的Category裡的AID衝突解決方式不同。例如，對於CATEGORY_PAYMENT(支付類)，使用者可以在系統的設定菜單“tap & pay”選項中設定這類支付的預設支付應用，當衝突時將會執行預設的HCE服務。而對於CATEGORY_OTHER類的衝突，手機會彈出對話方塊讓使用者選擇要執行的應用。通過isDefaultServiceForCategory()介面可以查看本HCE服務是否是預設的服務。

　　4.5與傳統的SE卡相容

　　Android系統使用HCE技術類比卡與其他的類比卡技術是相容的，即其他的基於SE的類比卡技術可以在使用HCE技術的Android手機上使用，反之亦可，只要系統支援HCE技術。

　　這種相容是建立在這樣一個AID路由原則之上的：NFC控制器內部儲存一個路由表，表項由AID和目標地址組成，目標地址既可以是主機(應用程式啟動並執行地方)，也可以是與之相連的安全模組(SE)。

　　當NFC讀卡機發送了一個”SELECT AID”的APDU時，NFC控制器解析出其中的AID並在路由表中檢索，路由表中有相應匹配時將此APDU送至相應的目標地址，並且其後的APDU都將會送至同一個目標地址，直到遇到下一個”SELECT AID”的APDU或者串連中斷。

　　圖4 同時具有HCE和SE卡類比的系統

　　如果在路由表中沒有檢索到匹配項，則NFC控制器通常會將其送至預設的目標地址。從Android4.4開始預設的目標地址都是主機，這就意味著NFC控制器的路由表只需要包含所有路由到的SE模組的AID。

　　當使用者升級完Android4.4系統之後，若想繼續使用其已存在的SE實現就必須在NFC控制器的路由表中重新註冊，這意味著使用者有可能要到櫃檯等地方去重新做一次升級。

　　5.HCE的安全性探討

　　HCE技術只是實現了將NFC讀卡機的資料送至作業系統的HCE服務或者將回複資料返回給NFC讀卡機，而對於資料的處理和敏感資訊的儲存則沒有具體實現細，所以說到底HCE技術是類比NFC和SE通訊的協議和實現。但是HCE並沒有實現SE，只是用NFC與SE通訊的方式告訴NFC讀卡機後面有SE的支援，從而以虛擬SE的方式完成NFC業務的安全保證。既然沒有SE，那麼HCE用什麼來充當SE呢，解決方案要麼是本地軟體的類比，要麼是雲端伺服器的類比。

　　對於本地軟體類比SE的方案，使用者敏感資訊及交易資料存放在本地。交易過程和資料存放區由作業系統管理，這提供了一種基本的安全保障機制(如作業系統可以將每個程式運行在一個沙箱(sandbox)裡，這樣可以防止一個應用程式訪問其他應用的資料)。但是Android系統的安全性本來就很差，所以這種安全保證是非常脆弱的。當一部Android手機被Root之後，使用者可以取得系統的最高許可權，這樣基本上就可以為所欲為了。

　　相較於傳統的基於SE的NFC方案，HCE技術可能面臨以下的風險：

　　1. 使用者可以對終端進行Root操作，通過Root使用者可以取得所有儲存在應用中的資訊，包括類似於支付憑證之類的敏感性資料,這些都是服務提供者所不願看到的，因為這也給了惡意軟體擷取敏感資訊的可乘之機。從統計數量上來說，只有很少一部分的安卓終端進行了Root操作，但是這仍然意味著數百萬層級的終端數量。

　　2. 惡意軟體可以自行Root作業系統。對於前期安卓系統來說，由於存在著一些漏洞，導致不少的惡意軟體可以直接Root系統。雖然這些漏洞看起來影響範圍不是特別的大(比如如果使用者不安裝未知來源的安卓軟體就不會有這個問題)，但是這仍然是一個需要考慮的問題。安卓系統的一個已知漏洞的彌補是很難的，這是因為安卓系統冗長的更新過程，需要花費很長的時間才能使得市面上的大部分終端都更新到最新的系統版本。如果在支援HCE的系統版本中也出現了缺陷，也需要花費足夠長的時間去解決現有終端上的缺陷問題。

　　3. 如果手機丟失或者被盜取，一個惡意使用者可以Root終端或者通過其它方式訪問終端的儲存系統，並且擷取各種儲存於應用中的資訊。這可能帶來致命的問題，比如惡意使用者可以使用這些敏感性資料去完成一些偽卡的交易。

　　由此可見Android系統提供的安全保障機制非常有限，一旦被Root這種機制就蕩然無存。提高HCE技術的安全性可以從兩個方面來考慮，一個是提供一個更安全的儲存敏感資訊的位置，另外一個就是提供更安全的機制來保證這個位置的資訊的安全性。

　　5.1敏感資訊的儲存位置

　　HCE服務雖然運行在Android系統上，但SP可以要求將敏感資訊儲存和處理放在在一個更安全的位置。這裡有四個可以選擇位置，他們都在安全性和使用代價之間有不同的平衡。圖5描述了這四個不同的選擇。

　　圖5 HCE服務儲存敏感資訊的位置

　　5.1.1主機

　　這是最簡單但是安全性最差的實現方式，即直接將資料的儲存和處理放在主機的應用上進行。除了作業系統提供的非常基本的安全機制外，沒有其他附加的保護。實現起來也最容易，但是對於Root的系統沒有任何防範。

　　5.1.2雲端SE

　　使用這種方式時，HCE服務將請求通過移動網路發送至雲端，敏感資訊的儲存和處理都在雲端伺服器。安全性方面比直接在主機的應用上處理和儲存要高，但是此時移動網路就變得更加重要了。網路覆蓋和網路延時都會成為很大的問題，在網路沒有覆蓋或訊號差的地方這種方式就無法使用了。一次移動支付交易的時間都在一秒以內，雲端SE的方案在速度上並不能保證這點。另外雲端SE還有一個認證的問題，如果將裝置到雲端SE的認證認證放在HCE服務裡，那麼雲端SE方案的安全性就大打折扣了。這個問題可以通過使用者去完成(如登陸)認證，但是使用者體驗就很差了。或者用一個單獨的硬體SE去處理認證問題。目前來看，對於安全性較高的移動支付服務，這個方案還是最適合的。

　　5.1.3可信執行環境(TEE)

　　圖6 可信執行環境

　　可信執行環境(TEE)是指獨立於作業系統的一個執行環境，專門用於提供安全服務。TEE有自己獨立的軟體和硬體資源，對外提供安全服務介面，使用者敏感資訊的儲存和處理都在這個環境裡進行。由於TEE運行自己獨立的系統，所以Android主系統被Root不會影響到自己。TEE提供的安全性總體上要比雲端SE高，但是還是沒有達到SE提供的安全性，因為它沒有SE的反篡改機制。TEE方案很像傳統的基於SE的方案，所以其實現起來要更複雜，另外其標準也沒有敲定。

　　5.1.4 UICC或嵌入式SE

　　這種方式提供最進階別的安全保證，將敏感資訊的儲存和處理放在一塊單獨的安全模組上(SE)。但是這樣做HCE技術與傳統的基於SE的卡類比方案相比就毫無優越性可言，甚至增加了實現的複雜度(傳統的方法是直達SE，現在是經過作業系統再到達SE)。

　　5.2安全的機制

　　有很多方法機制來保證應用程式的安全性，原則上這些方法都可以用在上面這四種方案中來實現更安全的HCE支付方案。當然使用這些機制會增加使用者使用的複雜度，同樣也會增加開發人員的實現難度。我們必須在安全性、使用者使用的方便性和成本之間做一個權衡，來選擇合適的機制。

　　5.2.1.使用者驗證

　　在支付交易中使用使用者驗證機制可以顯著提高交易的安全性。典型的驗證機制有：

　　根據使用者知道的資訊驗證：如使用者名稱，密碼，數字 PIN 碼等;

　　根據使用者的行為驗證：最典型的是關於異地使用拒絕，如果一次支付在某地完成後很快又在很遠的其他地方進行，則這樣的支付請求可以拒絕;

　　根據生物測定驗證：如指紋識別，聲音識別，臉部辨識和虹膜掃描識別等，這些生物驗證機制現在已經引起了極大的關注，而且已經在某些手機上實現了。

　　5.2.2交易限制

　　這是通過對交易設定一些限制來減小潛在的安全風險，例如只允許小額支付，每日交易額不超過一定量，不允許境外支付等。使用者可以修改這些限制，但必須輸入密碼，這樣即使手機被盜也可以將損失減少。

　　5.2.3 Android系統檢查

　　Android應用程式可以檢查到系統是否被Root。可以將Root與風險聯絡起來，一旦HCE程式檢測到系統被Root，我們可以執行相應的措施。

　　5.2.4 資料加密

　　可以將敏感性資料加密然後存放在HCE程式中，這樣即使惡意使用者和應用獲得了這些資料也無法解析。但是這麼做的話也會增加應用程式的複雜性和成本。

　　6.HCE技術展望

　　不可否認的一點是，HCE技術提供了一種安全性稍差但是部署起來非常方便的NFC服務解決方案。HCE技術對服務提供者而言至關重要，無需SE，剪除了不少NFC支付利益方糾葛，因此他們會是HCE技術的堅決支援者。據最新的訊息，萬事達卡(MasterCard)已正式宣布將推出適用於HCE技術的NFC規範，而Visa則將在Visa Ready Program中加入HCE支付應用的支援特色。而NFC論壇也表態力挺HCE技術，其旗下多種標準已支援HCE技術，包括NFC控制器介面(NCI)規範，該標準結合國際標準組織(ISO)14443及日本工業標準(JIS)X 6319-4等。NFC論壇指出，現在多個產業團體陸續啟動NFC服務，而HCE技術將十分有希望成為加速整體NFC市場成長的潛在因素，因此NFC論壇將持續追蹤HCE技術新的開發動態並持續透過標準開發工作回應市場需求。Google公司也是大力推動HCE技術的重要角色，在其最新的Nexus 5智能手機當中，已經應用HCE技術到Google錢包中，搭配安卓4.4系統，無需SE防護晶片就可以進行PayPass交易。

　　HCE技術面臨的最大難題還是其安全性問題。無論是本地軟體還是雲端SE的方案，都沒有硬體層級的安全性高。對於金融層級的移動支付，HCE技術最可行的解決方案還是雲端式端SE的方法，將支付資料存放區在雲端並且採用一些技術(如Token或者非對稱金鑰等)確保從HCE Host到雲端伺服器的資料轉送通道是安全的，HCE的安全性是可以得到提高和增強。所以在金融業務方面，HCE技術能否登堂入室，首先要看Visa、Master、銀聯等金融機構是否能夠解決本地軟體、遠程雲端SE的安全問題。目前，國內有個別電訊廠商和銀行在小規模試用類似HCE的技術手段，希望推動移動支付的發展，但是否能夠成為標準，形成規模，還需要時間考驗。

　　雖然在金融層級的移動支付方面前景還不太明朗，但是對於像會員卡、優惠券、電子票等低價值的閉環支付方面HCE技術還是有很大的發揮餘地的。這些類型的NFC應用安全要求不像賬戶中有大量資金的銀行類支付業務，雖然需要對使用者身份、憑證的安全性做出確認，避免假冒和偽造，但還未上升到金融業務的高度，因此如何在安全、便利和業務發展之間尋求平衡十分重要。GoogleHCE的出現為這些非金融支付類的O2O業務開啟了一扇門，在一定程度上提供安全的類比手段，經濟的解決SE的問題，為業務的蓬勃發展大有助力。服務供應商須評估、決定儲存安全憑據最好的方式，並清楚在不同的使用情境下不同的解決方案將各有優缺點，安全風險(Security Risk)與便利性間須有所取捨。

　　總之，HCE技術帶來的是一次變革，為NFC的發展和普及帶來了價值，同樣也帶來了一定的安全風險。移動支付中的安全問題至關重要，解決這個問題需要金融服務提供者、通訊電訊廠商和Google等方面建立起完備的安全機制。另外HCE的出現，對於傳統的卡廠、電訊廠商來說都產生了一定的威脅和挑戰，能否實現產業的共贏，亦是產業各方需要去權衡和考慮的。

基於HCE移動支付研究報告