HCE(Host-based Card Emulation)，即基於主機的卡模擬。
基本介紹
- 中文名：基於主機的卡模擬
- 外文名：Host-based Card Emulation
在一部配備NFC功能的手機實現卡模擬，目前有兩種方式：一種是基於硬體的，稱為虛擬卡模式(Virtual Card Mode);一種是基於軟體的，被稱為主機卡模式(Host Card Mode)。
在虛擬卡模式下，需要提供安全模組SE(Secure Element)，SE提供對敏感信息的安全存儲和對交易事務提供一個安全的執行環境。NFC晶片作為非接觸通訊前端，將從外部讀寫器接收到的命令轉發到SE，然後由SE處理，並通過NFC控制器回復。
在主機卡模式下，不需要提供SE，而是由在手機中運行的一個套用或雲端的伺服器完成SE的功能，此時NFC晶片接收到的數據由作業系統或傳送至手機中的套用，或通過行動網路傳送至雲端的伺服器來完成互動。兩種方式的特點都是繞過了手機內置的SE的限制。這一標準的妙處在於，它不需要整個行業為了控制安全元件而爭鬥。
使用基於主機的卡模擬時(HCE)，NFC 控制器從外部讀寫終端接收到的數據將直接被傳送到主機系統上，而不是安全模組。上圖描述了這個過程。
HCE技術的關鍵大事記
2012/09/19,SimplyTapp在Android第三方CyanogenMod固件中實現主機卡模擬技術HCE;
2013/12/13,美國連鎖咖啡TimHortons在北美4000多家門店推出基於HCE的NFC支付套用;
2014/02/17,西班牙銀行Bankinter發布基於HCE技術的虛擬卡手機錢包;
2014/02/20,全球智慧卡製造商ABnote與SimplyTapp合作，將HCE技術加入到其TSM（空中發卡技術）平台中。
NFC標準對Android支持
NFC標準對很多智慧卡通訊協定提供了支持，而Android4.4系統也支持包括主流智慧卡套用在內的很多非接觸智慧卡協定，因此使用NFC手機和HCE套用，就可以方便的模擬出不同類型的智慧卡套用。
同樣市場上很多NFC讀卡終端也支持這些協定，包括一部支持NFC的Android設備作為讀卡器本身。這樣通過HCE技術我們只用Android設備就可以部署一個端對端的NFC解決方案。
Android4.4系統使用NFC論壇制定的的ISO-DEP標準協定(基於ISO/IEC14443-4(ISO-DEP)標準)進行數據傳輸，傳輸的數據單元被稱為套用協定數據單元(APDUs)。
另外，在數字協定方面(相當於MAC層協定)Android系統只要求對頂層的NFC-A(ISO/IEC 14443-3 Type A)技術提供支持，而對NFC-B技術的(ISO/IEC 14443-3 Type B)的支持則是可選的，這些技術提供了包括初始化、衝突檢測等解決方案。
Android系統上的HCE技術是通過系統服務實現的(HCE服務)。使用服務的一大優勢是它可以一直在後台運行而不需要有用戶界面。這個特點就使得HCE技術非常適合像會員卡、交通卡、門禁卡這類的交易，當用戶使用時無需打開程式，只需要將手機放到NFC讀卡器的識別範圍內，交易就會在後台進行。當然更推薦為用戶提供配套的HCE套用UI界面，這樣除了像普通的智慧卡片一樣刷卡使用以外，還可以通過UI界面為用戶提供更多的線上服務功能，包括查詢、充值和信息推送等。
當用戶將手機放到NFC讀卡器的識別範圍時,Android系統需要知道讀卡器真正想要和哪個HCE服務互動，這樣它才能將接收到的數據傳送到相應的HCE套用。HCE參考ISO7816規範，定義了一種通過應用程式AID來選擇相應套用的方法。因此，如果要為自己的新的讀卡設施部署NFC套用，就需要定義自己的AID。
HCE技術實現NFC模擬
在手機上用HCE技術實現NFC卡模擬，首先要創建一個處理交易事務的HCE 服務，Android4.4為HCE服務提供了一個非常方便的基類，我們可以通過繼承基類來實現自己的HCE服務。如果要開發已存在的NFC系統，我們只需要在 HCE 服務中實現NFC 讀卡器期望的套用層協定。反之如果要開發自己的新的NFC 系統，我們就需要定義自己的協定和APDU 序列。一般而言我們應該保證數據交換時使用很少的APDU包數量和很小的數據量，這樣用戶就不必花很長時間將手機放在NFC 讀卡器上。
HCE 技術只是實現了將NFC 讀卡器的數據送至作業系統的HCE 服務或者將回複數據返回給NFC 讀卡器，而對於數據的處理和敏感信息的存儲則沒有具體實現細，所以說到底HCE 技術是模擬NFC 和SE 通信的協定和實現。但是HCE 並沒有實現SE，只是用NFC 與SE 通信的方式告訴NFC 讀卡器後面有SE的支持，從而以虛擬SE 的方式完成NFC 業務的安全保證。既然沒有SE，那么HCE 用什麼來充當SE 呢，解決方案要么是本地軟體的模擬，要么是雲端伺服器的模擬。負責安全的SE如何通過本地化的軟體或者遠程的雲端實現，並且能夠保障安全性，需要HCE廠商自己考慮和實現。
HCE方案與SE方案的路由和兼容
支持HCE功能的Android4.4手機，很多也同時支持SWP-SIM或者SWP-SD之類的SE模式實現手機支付功能，因此存在一個套用AID路由的問題，通常是由CLF晶片中的AID路由表來負責進行相關的路由工作，由手機生產廠商負責開發實現具體的規則。具體系統架構和指令流向如下圖：
因為CLF晶片的路由表，是通過讀卡終端傳送的Select指令中的套用AID來進行區分和路由的，因此對於SE(SWP-SIM)和手機HOSTCPU中的HCE套用，如果各自支持的具體智慧卡套用的AID均不相同，則不會出現任何路由和兼容性的問題，所有的套用均能夠被正確識別和分別路由到SE(SWP-SIM)或者HCE套用，並正常完成交易的實現和處理。
如果SE(SWP-SIM)和手機HOST CPU中的HCE套用，支持的智慧卡套用中有相同的AID，則存在一個路由優先權的問題，同時涉及到支持SE(SWP-SIM)的設備升級到Android4.4之後，對於SWP-SIM中原有的套用的兼容問題。
按照google提供的Android API的要求，HCE APP的路由優先權更高，表示說如果存在相同的AID的套用，則會被優先路由到HCE套用來處理，那么SWP-SIM中的相同AID的套用將無法被調用和使用，會出現系統升級到4.4版本後，無法兼容既有套用使用的問題，除非不安裝HCE 套用。
因此運營商的定製手機，通常會要求修改一下路由的優先權，使SE(SWP-SIM)的路由優先權更好，即如果存在相同的AID的套用，則會被優先路由到SWP-SIM來處理，確保對於舊時發行的支持SE的設備，在系統升級到4.4之後的兼容性。
