基于普通UIM的HCE應(yīng)用安全設(shè)計(jì)

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

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

一、概述

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

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

使用HCE模式，可脫離安全載體SE而部署NFC，較之SE的方案，HCE實(shí)施速度快、產(chǎn)業(yè)鏈短，有避免了價(jià)格較高的SE芯片，使得SP可簡單地完成NFC應(yīng)用的實(shí)現(xiàn)。但因?yàn)槭褂玫氖侨菀妆荒M的手機(jī)APP軟件，HCE的安全性比之SE方案較低。

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

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

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

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

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

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

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

1.安全令牌的生成

生成規(guī)則：

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

MAC算法：

計(jì)算MAC需要5個(gè)步驟：

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

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

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

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

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

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

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

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

（五）脫機(jī)金額的安全存儲(chǔ)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.文件讀寫控制

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

（八）密鑰的安全存儲(chǔ)

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

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

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

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

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

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

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

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

1.敏感信息防竊取

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

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

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

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

3.敏感信息存儲(chǔ)安全

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

4.客戶端程序防篡改

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

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

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

5.防注入攻擊

對(duì)于輸入信息注入的防范主要通過對(duì)信息進(jìn)行過濾。過濾的位置應(yīng)包括客戶端和服務(wù)端?？蛻舳顺绦蛟谟脩糨斎霑r(shí)應(yīng)對(duì)輸入內(nèi)容進(jìn)行約束，防止用戶輸入可能造成注入攻擊的字符。并在服務(wù)端對(duì)用戶輸入再次過濾，防止通過篡改報(bào)文的方式進(jìn)行注入攻擊。

6.防釣魚

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

7.重放攻擊

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

8.程序接口安全

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

9.密碼鍵盤安全

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

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

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

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

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

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

10.通訊層傳輸安全

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

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

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

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

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

三、總結(jié)

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

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

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

參考文獻(xiàn)：

[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位塊加密算法的運(yùn)算方法

[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è)有限公司。