HCE基礎知識普及
NFC技術發展
NFC(Near Field Communication)是“近場通訊”的簡稱,採用短距離RF(射頻)通訊技術。NFC 工作頻率為13.56Hz,有效範圍為500px 以內,其傳輸速度有106 Kbit/秒、212 Kbit/秒或者424 Kbit/秒三種,能夠應用在手機/平板、電腦/遊戲機、印表機、電子產品,甚至家電裝置中。
NFC技術已經有十來年曆史,在過去的幾年裡一直被稱為很有前景的便利移動支付技術。但即使在NFC手機日漸成為智慧機標配的今天,基於NFC的移動支付卻沒有在消費者群體中形成氣候。一個重要的原因在於:所有人都在爭著控制NFC 技術的安全元件(the Secure Element)。安全元件,顧名思義,是保證財產資訊保安的,控制這個就可以控制每一筆交易的費用。SE導致了金融機構、OEM和運營商之間無休止的爭鬥,沒辦法聯合起來,這使得NFC移動支付發展緩慢。
HCE概念
HCE(host-based cardemulation),即基於主機的卡模擬。
在一部配備NFC功能的手機實現卡模擬,目前有兩種方式:一種是基於硬體的,稱為虛擬卡模式(Virtual Card Mode);一種是基於軟體的,被稱為主機卡模式(Host Card Mode)。
在虛擬卡模式下,需要提供安全模組SE(Secure Elemen),SE提供對敏感資訊的安全儲存和對交易事務提供一個安全的執行環境。NFC晶片作為非接觸通訊前端,將從外部讀寫器接收到的命令轉發到SE,然後由SE處理,並通過NFC控制器回覆。
在主機卡模式下,不需要提供SE,而是由在手機中執行的一個應用或雲端的伺服器完成SE的功能,此時NFC晶片接收到的資料由作業系統或傳送至手機中的應用,或通過行動網路傳送至雲端的伺服器來完成互動。兩種方式的特點都是繞過了手機內建的SE的限制。這一標準的妙處在於,它不需要整個行業為了控制安全元件而爭鬥。
使用基於主機的卡模擬時(HCE),NFC 控制器從外部讀寫終端接收到的資料將直接被髮送到主機系統上,而不是安全模組。上圖描述了這個過程。
HCE技術的關鍵大事記
2012/09/19,SimplyTapp在Android第三方CyanogenMod韌體中實現主機卡模擬技術HCE;
2013/11/01,Google釋出最新的Android4.4作業系統,支援主機卡模擬HCE技術,目前已通過谷歌錢包將HCE應用到Nexus 5手機中,可支援Paypass;
2013/12/13,美國連鎖咖啡TimHortons在北美4000多家門店推出基於HCE的NFC支付應用;
2014/02/17,西班牙銀行Bankinter釋出基於HCE技術的虛擬卡手機錢包;
2014/02/19,Visa和萬事達卡同時宣佈將基於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之後的相容性。