【摘 要】針對最終用戶對NFC現(xiàn)有的SE方案接受度不高的問題，提出普通UIM卡用戶也可使用的基于云平臺的HCE方案，使用敏感數(shù)據(jù)云端保存、使用手機卡固有的ICCID信息加解密等技術(shù)手段，并創(chuàng)新提出使用安全令牌代替用戶真實手機號碼、卡號等信息作為用戶身份識別的臨時卡號，確保應(yīng)用和數(shù)據(jù)的安全性。同時，方案的安全設(shè)計上也充分考慮到了將來硬件和軟件的發(fā)展，為將來預(yù)留的更多的可能性。

【關(guān)鍵詞】NFC HCE 云平臺 安全令牌

一、概述

NFC經(jīng)歷了終端功能從功能機到智能機，終端品牌從諾基亞到三星，終端業(yè)務(wù)管道從互聯(lián)網(wǎng)到移動互聯(lián)網(wǎng)，但發(fā)展始終有一道坎，就是如何解決松耦合的無線通信與安全的平衡。為解決此問題，各方提出的全終端、UIM卡、SD卡，都是使用解決安全問題的SE（安全單元）。但因涉及范圍過大，產(chǎn)業(yè)鏈過長，導(dǎo)致NFC一直無重大突破。

但是又要換手機又要換卡的NFC-SWP卡SE方案還要不被最終用戶所接受。2013年10月31日，Google發(fā)布了最新的Android4.4操作系統(tǒng)，其中提到了一個新的NFC特性，即所謂的HCE（Host Card Emulation）。HCE在一部配備NFC功能的手機實現(xiàn)卡模擬，不需要提供SE，而是由在手機中運行的一個應(yīng)用或云端的服務(wù)器完成SE的功能，此時NFC芯片接收到的數(shù)據(jù)由操作系統(tǒng)或發(fā)送至手機中的應(yīng)用，或通過移動網(wǎng)絡(luò)發(fā)送至云端的服務(wù)器來完成交互。兩種方式的特點都是繞過了手機內(nèi)置的SE的限制。

使用HCE模式，可脫離安全載體SE而部署NFC，較之SE的方案，HCE實施速度快、產(chǎn)業(yè)鏈短，有避免了價格較高的SE芯片，使得SP可簡單地完成NFC應(yīng)用的實現(xiàn)。但因為使用的是容易被模擬的手機APP軟件，HCE的安全性比之SE方案較低。

本文就HCE固有的安全性問題，從設(shè)計安全令牌、密鑰生成及存儲、APP本身的安全性等方面進行研究，提出新的設(shè)計方案，確保NFC移動支付應(yīng)用的安全、順利開展。

二、總體安全設(shè)計

基于普通UIM的HCE應(yīng)用安全設(shè)計，從智能手機平臺的安全性要求入手，結(jié)合翼機通卡應(yīng)用規(guī)范的安全要求，充分分析了HCE技術(shù)可能存在的安全隱患，采用前端HCE APP加上后臺HCE SERVER的云架構(gòu)，并創(chuàng)新提出了安全令牌的設(shè)計，在確保交易兼容性和執(zhí)行效率的基礎(chǔ)上，最大限度的降低風(fēng)險到可控范圍。

方案通過使用普通UIM上存儲的移動用戶識別碼ICCID，對手機號碼和號碼持有人進行認(rèn)證，并將HCE APP與具體的手機號碼和號碼持有人進行綁定，同時采用ICCID作為各種保護密鑰和安全算法的種子和參數(shù)，每次計算均從UIM卡內(nèi)進行讀取和驗證，從而為HCE的純軟件實現(xiàn)方案，提供了一個基于硬件層面的安全因子，大大提升了整體系統(tǒng)的安全等級。

方案的安全設(shè)計還著重對于交易過程中涉及到的密鑰和數(shù)據(jù)的存儲，以及這些密鑰和數(shù)據(jù)的傳輸，設(shè)計了專門的安全保護密鑰和安全存儲、傳輸?shù)姆绞剑源_保在整個HCE應(yīng)用的生命周期中，這些核心敏感數(shù)據(jù)的安全，從而確保整個體系的安全性。

（一）安全令牌的設(shè)計

用戶的手機號碼、真實卡號等信息一直是交易中較為敏感的數(shù)據(jù)，也是用戶極為不愿泄露、對交易最不信任之處。安全令牌是用戶的真實信息根據(jù)一定的規(guī)則變換生成的用于在交易中代替真實卡號的臨時性虛擬卡號，其具有一定的有效期。脫機終端應(yīng)拒絕過期的安全令牌進行消費。

1.安全令牌的生成

生成規(guī)則：

TOKEN SERVICE將以上數(shù)據(jù)元順序連接，使用HCE安全令牌生成密鑰，對以上數(shù)據(jù)元計算按如下方式計算出MAC值。

MAC算法：

計算MAC需要5個步驟：

步驟1：取8字節(jié)的隨機數(shù)‘00’作為初始變量。

步驟2：按照順序?qū)⑸梢卮_認(rèn)值生成時所需的數(shù)據(jù)元順序連接在一起形成一個數(shù)據(jù)塊。

步驟3：將步驟2產(chǎn)生的大數(shù)據(jù)塊分成8字節(jié)為單位的小數(shù)據(jù)塊，標(biāo)號分別為D1，D2，D3，D4等，最后的數(shù)據(jù)塊可能為1-8個字節(jié)。

步驟4：對最后一個數(shù)據(jù)塊按如下方法填充數(shù)據(jù)，使其達到8個字節(jié)。

若最后一數(shù)據(jù)塊長度已經(jīng)為8字節(jié)，其后仍然添加8個字節(jié)的十六進制數(shù)字‘80 00 00 00 00 00 00 00’。

若最后一數(shù)據(jù)塊長度不足8字節(jié)，則在其后添加十六進制數(shù)字‘80’，若仍不足8字節(jié)，則在其后添加十六進制數(shù)字‘00’，直至達到8個字節(jié)為止。

步驟5：對這些8字節(jié)長度的數(shù)據(jù)塊采用指定的密鑰（以DES算法進行加密，見圖1）。

采用該算法來計算的8字節(jié)長度數(shù)據(jù)塊的個數(shù)取決于步驟2計算的數(shù)據(jù)塊的長度。MAC 是最后得到的8字節(jié)數(shù)據(jù)加密塊的前4個字節(jié)（從左側(cè)起）。

（五）脫機金額的安全存儲

脫機金額為敏感信息數(shù)據(jù)，在HCE APP應(yīng)用中需按照一定的規(guī)則存儲：

（1）使用數(shù)據(jù)保護密鑰對4字節(jié)的脫機金額進行加密，生成16字節(jié)的脫機金額密文數(shù)據(jù)，確保數(shù)據(jù)保密性；

（2）采用SHA-1摘 要算法對16字節(jié)的脫機金額密文數(shù)據(jù)進行計算，生成20字節(jié)的摘 要值，確保數(shù)據(jù)防篡改；

（3）將16字節(jié)的脫機密文數(shù)據(jù)和20字節(jié)的HASH摘 要值，按照字節(jié)分址存放原則，進行分散存儲。

當(dāng)應(yīng)用進行圈存/消費交易時，驗證20字節(jié)的摘 要值通過后方可進行后續(xù)的計算；同時交易結(jié)束時，按照存儲規(guī)則重新生成脫機金額密文數(shù)據(jù)和摘 要值。

（六）應(yīng)用數(shù)據(jù)的存儲

其中，為降低HCE APP應(yīng)用在手機設(shè)備中存在的一些安全隱患，應(yīng)用數(shù)據(jù)推薦采用密文+HASH摘 要方式存儲，并采用分址存放；HCE SERVER結(jié)合應(yīng)用數(shù)據(jù)存儲載體的安全性，選擇合適的存儲方式。

（七）內(nèi)容訪問控制

在使用過程中，HCE APP需要對應(yīng)用文件、密鑰、脫機金額等做一定的讀寫操作。在此過程中，應(yīng)用需要對HCE APP做權(quán)限限制和保護。

1.獲取HCE APP的訪問權(quán)限---下載開通

HCE APP在手機設(shè)備上安裝完成，需要連接HCE SERVER下載相關(guān)交易數(shù)據(jù)，同時完成應(yīng)用功能的開通，才能支持門禁、考勤、錢包消費等功能的正常使用。用戶下載開通應(yīng)用時需輸入手機號和短信驗證碼，支持HCE的TSM系統(tǒng)需要驗證手機號的匹配及驗證碼的正確性，以保證手機設(shè)備的合法性。

2.密鑰的訪問權(quán)限

HCE APP中的所有密鑰均禁止任何方式的讀寫，且在應(yīng)用中以密文形式存儲，確保數(shù)據(jù)的安全性。當(dāng)HCE APP的安全令牌進行更新時，HCE SERVER端以安全報文方式下發(fā)對應(yīng)的消費/TAC子密鑰，及傳輸和數(shù)據(jù)保護密鑰的密鑰分散因子。

3.應(yīng)用數(shù)據(jù)的訪問權(quán)限—脫機金額

HCE APP提供了專用命令獲取錢包脫機金額，在應(yīng)用中以密文+HASH摘 要方式存在，并進行分址存儲；當(dāng)HCE APP檢測到脫機金額被惡意篡改時，將無法使用正常交易功能。HCE APP可通過（空中）充值交易增加脫機金額余額。

4.文件讀寫控制

HCE APP應(yīng)用內(nèi)的基本數(shù)據(jù)文件和交易明細(xì)記錄文件，均為自由讀取。其中交易明細(xì)記錄文件由HCE APP自動維護，內(nèi)部數(shù)據(jù)文件禁止以任何方式的訪問/更新。

（八）密鑰的安全存儲

密鑰安全存儲主要在兩大應(yīng)用中：HEC APP和HCE SERVER云端存儲。

1.HCE APP的密鑰存儲規(guī)則

TAC密鑰/消費密鑰：使用數(shù)據(jù)保護密鑰加密，以密文形式存儲于應(yīng)用中，并采用分址方式存放；

傳輸密鑰/數(shù)據(jù)保護密鑰：不以任何形式存放于應(yīng)用中，交易時隨密鑰分散因子動態(tài)生成，交易完成時密鑰將自動銷毀。

2.HCE SERVER的密鑰存儲規(guī)則

通過多種方式存儲于HCE SERVER端，如加密機、對象，保證密鑰在HCE SERVER的安全存放，且在任何情況下都不會被泄露。

（九）HCE應(yīng)用APP本身的安全

HCE應(yīng)用移動客戶端APP也是整體業(yè)務(wù)流程中不可或缺的一環(huán)，故其本身的安全性也有較高的要求。APP應(yīng)滿足但不限于以下安全要求：

1.敏感信息防竊取

在用戶輸入敏感信息時，應(yīng)采用自定義鍵盤，禁止使用操作系統(tǒng)默認(rèn)鍵盤或第三方輸入法鍵盤。自定義鍵盤應(yīng)采取隨機布放機制設(shè)置按鍵布局。當(dāng)采取隨機布放按鍵方式后，仍可通過讀取按鍵信息并截取屏幕中自定義鍵盤位置信息，分析后獲得輸入的敏感信息，此時應(yīng)采取有效措施防止未授權(quán)程序截屏。

經(jīng)過自定義鍵盤輸入的敏感信息應(yīng)在輸入后立即進行加密，防止在函數(shù)參數(shù)傳輸過程中以及通信報文中出現(xiàn)明文形式的敏感信息。傳輸數(shù)據(jù)時采用雙向認(rèn)證方式，降低中間人攻擊風(fēng)險。

2.內(nèi)存敏感數(shù)據(jù)防泄漏

通過自定義鍵盤輸入敏感信息時，用戶輸入完畢立即清空使用的內(nèi)存空間中的內(nèi)容，防止敏感信息在內(nèi)存中殘留。

3.敏感信息存儲安全

在手機客戶端存儲敏感信息時，應(yīng)通過Hash、加密等算法對數(shù)據(jù)進行保護，防止敏感信息泄漏。并在其中加入隨機數(shù)據(jù)，防止敏感信息重放。

4.客戶端程序防篡改

對于客戶端程序的篡改，主要應(yīng)采取兩方面防護措施：客戶端程序自身完整性校驗、靜態(tài)分析干擾。

無論操作系統(tǒng)是否對客戶端程序進行完整性校驗，程序自身應(yīng)采取完整性校驗措施。通過對程序自身特有的相關(guān)信息（如簽名證書信息、核心代碼Hash值等）進行校驗，以保證其完整性。

通過對代碼的分析仍然可能繞過客戶端程序自身的完整性校驗機制。應(yīng)采取有效的靜態(tài)分析干擾措施增加對代碼分析的難度。

5.防注入攻擊

對于輸入信息注入的防范主要通過對信息進行過濾。過濾的位置應(yīng)包括客戶端和服務(wù)端。客戶端程序在用戶輸入時應(yīng)對輸入內(nèi)容進行約束，防止用戶輸入可能造成注入攻擊的字符。并在服務(wù)端對用戶輸入再次過濾，防止通過篡改報文的方式進行注入攻擊。

6.防釣魚

應(yīng)采取預(yù)留信息等有效措施防范釣魚攻擊。

7.重放攻擊

對傳遞身份認(rèn)證信息和交易信息的通信報文進行數(shù)字簽名，并在簽名內(nèi)容中包含隨機因素，防止重放攻擊。

8.程序接口安全

在客戶端程序設(shè)計及開發(fā)過程中，嚴(yán)格審查接口函數(shù)的參數(shù)類型和取值范圍。

9.密碼鍵盤安全

（1）客戶端程序中應(yīng)使用自定義密碼鍵盤替代手機操作系統(tǒng)默認(rèn)鍵盤或第三方輸入法鍵盤。

（2）自定義密碼鍵盤中按鍵順序應(yīng)隨機布放。

（3）宜禁止其他程序截屏以獲得密碼鍵盤當(dāng)前的按鍵布放順序。

（4）使用密碼鍵盤輸入敏感后應(yīng)立即加密。

（5）敏感信息輸入結(jié)束后，密碼鍵盤應(yīng)立即清除內(nèi)存中暫存敏感信息。

（6）禁止明文顯示密碼鍵盤輸入的信息，應(yīng)以屏蔽方式顯示。

10.通訊層傳輸安全

基于HCE的線上支付交易，應(yīng)滿足以下安全要求：

（1）應(yīng)使用足夠強度的加密算法和安全協(xié)議保護客戶端與服務(wù)器之間的連接，例如使用SSL/TLS和IPSEC 等協(xié)議。

（2）如使用SSL協(xié)議，應(yīng)使用3.0及以上相對高版本的協(xié)議，取消對低版本協(xié)議的支持。

（3）客戶端到服務(wù)器的SSL加密密鑰長度應(yīng)不低于128位，用于簽名的RSA 密鑰長度應(yīng)不低于1152位，用于簽名的ECC密鑰長度應(yīng)不低于160位。

（4）定時重新協(xié)商會話密鑰。

三、總結(jié)

本方案在進行安全設(shè)計與實現(xiàn)過程中，有針對性的從智能手機平臺的安全性要求入手，普通UIM卡的唯一識別信息，充分分析了HCE技術(shù)可能存在的安全隱患，在不影響用戶體驗和確保兼容性的前提下，設(shè)計了合理可靠的安全體系。安全體系從敏感數(shù)據(jù)的傳輸、保護、安全存儲、訪問控制以及手機應(yīng)用APP本身等多方面、全方位的進行了安全的設(shè)計和防護，確保系統(tǒng)整體的安全保障。

方案創(chuàng)新性的設(shè)計實現(xiàn)了一套安全令牌機制，通過有時效性的安全令牌，實現(xiàn)對于用戶實際賬戶的保護和控制，并將安全風(fēng)險控制在有限的時間段內(nèi)，最大限度的降低風(fēng)險。通過與UIM卡內(nèi)唯一識別信息的綁定與校驗，彌補了HCE應(yīng)用技術(shù)純軟件實現(xiàn)條件下的安全性不足的權(quán)限，結(jié)合通用硬件實現(xiàn)對于敏感數(shù)據(jù)的存儲、傳輸?shù)募用鼙Ｗo與校驗。

同時，方案的安全設(shè)計上也充分考慮到了將來硬件和軟件的發(fā)展，為將來預(yù)留的更多的可能性，隨著UIM卡硬件的發(fā)展以及HCE技術(shù)本身的發(fā)展，系統(tǒng)可以方便的對安全保障方式進行更新和升級，使得應(yīng)用的安全發(fā)展跟上時代的腳步。

參考文獻：

[1]Host-basedCardEmulation[EB/OL].https：//developer.android.com/guide/topics/connectivity/nfc/hce.html

[2]HCE security implications Analyzing the security aspects of HCE，2014.1.8

[3]GB/T 18238.3 信息技術(shù)安全技術(shù)散列函數(shù)第3部分：專用散列函數(shù)（GB/T 18238.3—2002，ISO/IEC 10118-1：1994，IDT）

[4]JR/T 0025.2 中國金融集成電路（IC）卡規(guī)范第1部分：電子錢包/電子存折應(yīng)用卡片規(guī)范

[5]JR/T 0025.2 中國金融集成電路（IC）卡規(guī)范第2部分：電子錢包/電子存折應(yīng)用規(guī)范

[6]ISO 8732 信息處理64位塊加密算法的運算方法

[7]ISO/IEC 10116：1993 信息技術(shù)安全技術(shù)n位塊密碼算法的操作方式

[8]Sarah ClarkBell ID launches NFC secure element in the cloud platform，2013.6.5

作者簡介：

1.曹懿軍，男（1978.10.04—），籍貫：浙江平湖，工程師，本科，工作于中國電信股份有限公司浙江分公司。

2.洪一帆，男，（1978.02.25—），籍貫：浙江浦江，工程師，碩士研究生，工作于浙江省公眾信息產(chǎn)業(yè)有限公司。

3.張雪穎，女，（1987.01.18—），籍貫：浙江杭州，工程師，工程碩士，工作于浙江省公眾信息產(chǎn)業(yè)有限公司。