移動(dòng)支付情境下網(wǎng)絡(luò)安全問(wèn)題分析與解決方案
**
安徽師范大學(xué)數(shù)學(xué)計(jì)算機(jī)科學(xué)學(xué)院 2012級(jí)物聯(lián)網(wǎng)工程專業(yè) 韓文鍇
**1 **引言****
**
早在2010年丝里，中國(guó)移動(dòng)通信集團(tuán)就將移動(dòng)支付定為其重點(diǎn)發(fā)展戰(zhàn)略之一[1]
。隨著移動(dòng)互聯(lián)網(wǎng)和物聯(lián)網(wǎng)的迅猛發(fā)展卒蘸，QR-Code雌隅、RFID、NFC支付都成為物聯(lián)網(wǎng)移動(dòng)支付的新載體缸沃。支付寶掃碼支付恰起、Apple Pay等業(yè)務(wù)也遍布全球。在蘋果于2015年3月10日舉辦的特別產(chǎn)品發(fā)布會(huì)上趾牧，其CEO庫(kù)克宣布：目前在美國(guó)有超過(guò)2500家銀行已支持Apple Pay检盼，接受Apple Pay的網(wǎng)店多達(dá)70余萬(wàn)處，包括4萬(wàn)余臺(tái)可口可樂(lè)販賣機(jī)的眾多自動(dòng)販?zhǔn)蹤C(jī)也紛紛支持Apple Pay翘单，而且每天都有更多的商戶和應(yīng)用在加入這個(gè)行列吨枉。[2]
但支付問(wèn)題涉及個(gè)人財(cái)產(chǎn)及隱私問(wèn)題，因此其安全問(wèn)題顯得更加敏感哄芜。其挑戰(zhàn)是多方面的[3-4]
貌亭，不僅來(lái)自于傳統(tǒng)互聯(lián)網(wǎng)的賬號(hào)密碼管理、木馬病毒竊取忠烛、社會(huì)詐騙手段属提，更有數(shù)據(jù)傳輸反監(jiān)聽(tīng)、動(dòng)態(tài)Token和用戶隱私保護(hù)等多方面新挑戰(zhàn)美尸。
本文就移動(dòng)支付情境下網(wǎng)絡(luò)安全問(wèn)題進(jìn)行分析冤议，并針對(duì)以上不同技術(shù)和應(yīng)用情景，提供在數(shù)據(jù)傳輸反監(jiān)聽(tīng)师坎、用戶隱私保護(hù)等新興挑戰(zhàn)方面可能的解決方案和建議恕酸。
**2 **移動(dòng)支付安全分析****
**
移動(dòng)支付的過(guò)程主要由用戶端、服務(wù)端和商戶端三個(gè)部分組成胯陋。用戶端由每一個(gè)支付工具的用戶組成蕊温，服務(wù)端包括如銀聯(lián)袱箱、支付寶、Paypal义矛、Apple Pay這些提供支付服務(wù)的運(yùn)營(yíng)商发笔，而商戶端則由線下商鋪、自動(dòng)販?zhǔn)蹤C(jī)等實(shí)體經(jīng)營(yíng)商戶組成凉翻。其三者關(guān)系主要可以從下圖1中看到了讨。其中服務(wù)端則是整個(gè)體系中在技術(shù)與安全上最重要的一環(huán)，它不僅要保證用戶和交易信息在三者間準(zhǔn)確制轰、高效地傳輸前计，更需要保證交易信息和過(guò)程的安全性。
圖1
支付過(guò)程與關(guān)系
一般情況下的支付流程用偽代碼可以表示其過(guò)程如下：
Step 1：用戶在商戶選購(gòu)商品垃杖，若成功選中商品男杈，進(jìn)入Step 2，否則結(jié)束调俘；
Step 2：用戶使用相應(yīng)服務(wù)端應(yīng)用通過(guò)QR-Code, NFC等技術(shù)獲取商品和商戶信息伶棒，并發(fā)起支付請(qǐng)求且進(jìn)行下一步，若請(qǐng)求失敗則重復(fù)此步脉漏；
Step 3：服務(wù)端接收到用戶苞冯、商品和商戶信息后，認(rèn)證用戶信息和賬號(hào)余額侧巨，若余額充足且賬戶合法舅锄，則進(jìn)行支付操作，將成功支付信息發(fā)送給商戶且進(jìn)行下一步司忱，并定期將付款轉(zhuǎn)賬給商戶皇忿，否則結(jié)束；
Step 4：商戶端接收支付信息并將貨品交送給用戶坦仍，結(jié)束流程鳍烁。
在此過(guò)程中，安全問(wèn)題主要出現(xiàn)在Step 2-4中繁扎。
在Step 2中幔荒，要保證用戶在面對(duì)偽造商戶端時(shí)信息和財(cái)產(chǎn)不受損，且信息發(fā)送的過(guò)程中不被截仁崦怠爹梁；在Step 3-4中，要保證賬戶信息不泄露提澎、對(duì)商戶不可見(jiàn)姚垃。
而經(jīng)過(guò)查閱文獻(xiàn)資料和現(xiàn)實(shí)實(shí)例分析，解決上述個(gè)問(wèn)題可以使用動(dòng)態(tài)握手協(xié)議和數(shù)據(jù)傳輸加密技術(shù)保證商戶信息可靠性和發(fā)送信息不被截取盼忌、用動(dòng)態(tài)Token技術(shù)保證用戶信息的保密性积糯。
**3 **安全支付技術(shù)分析****
**
3.1 TLS****協(xié)議
**
TLS握手協(xié)議提供的連接安全具有三個(gè)基本屬性：
1.可以使用非對(duì)稱的掂墓，或公共密鑰的密碼術(shù)來(lái)認(rèn)證對(duì)等方的身份。該認(rèn)證是可選的看成，但至少需要一個(gè)結(jié)點(diǎn)方君编。
2.共享加密密鑰的協(xié)商是安全的。對(duì)偷竊者來(lái)說(shuō)協(xié)商加密是難以獲得的川慌。此外經(jīng)過(guò)認(rèn)證過(guò)的連接不能獲得加密啦粹，即使是進(jìn)入連接中間的攻擊者也不能。
3.協(xié)商是可靠的窘游。沒(méi)有經(jīng)過(guò)通信方成員的檢測(cè)，任何攻擊者都不能修改通信協(xié)商跳纳。
TLS協(xié)議允許C/S模型的應(yīng)用程序跨網(wǎng)絡(luò)通訊忍饰，旨在防止竊聽(tīng)和篡改的方式進(jìn)行溝通。TLS協(xié)議的優(yōu)勢(shì)在于它是與應(yīng)用層協(xié)議獨(dú)立無(wú)關(guān)的寺庄。高層的應(yīng)用層協(xié)議（例如：HTTP艾蓝、FTP、Telnet等等）能透明的創(chuàng)建于TLS協(xié)議之上斗塘。TLS協(xié)議在應(yīng)用層協(xié)議通信之前就已經(jīng)完成加密算法赢织、通信密鑰的協(xié)商以及服務(wù)器認(rèn)證工作。在此之后應(yīng)用層協(xié)議所傳送的數(shù)據(jù)都會(huì)被加密馍盟，從而保證通信的私密性于置。
TLS協(xié)議是可選的，所以如果需要使用就必須配置客戶端和服務(wù)器贞岭，有兩種主要方式實(shí)現(xiàn)這一目標(biāo)：一個(gè)是使用統(tǒng)一的TLS協(xié)議端口號(hào)（例如：用于HTTPS的端口443）八毯；另一個(gè)是客戶端請(qǐng)求服務(wù)器連接到TLS時(shí)使用特定的協(xié)議機(jī)制（例如：郵件、新聞協(xié)議和STARTTLS)瞄桨。一旦客戶端和服務(wù)器都同意使用TLS協(xié)議话速，他們通過(guò)使用一個(gè)握手過(guò)程協(xié)商出一個(gè)有狀態(tài)的連接以傳輸數(shù)據(jù)。通過(guò)握手芯侥，客戶端和服務(wù)器協(xié)商各種參數(shù)用于創(chuàng)建安全連接：
l 當(dāng)客戶端連接到支持TLS協(xié)議的服務(wù)器要求創(chuàng)建安全連接并列出了受支持的密碼組合（加密密碼算法和加密哈希函數(shù)）泊交，握手開(kāi)始。
l 服務(wù)器從該列表中決定加密和散列函數(shù)柱查，并通知客戶端廓俭。
l 服務(wù)器發(fā)回其數(shù)字證書(shū)，此證書(shū)通常包含服務(wù)器的名稱物赶、受信任的證書(shū)頒發(fā)機(jī)構(gòu)（CA）和服務(wù)器的公鑰白指。
l 客戶端確認(rèn)其頒發(fā)的證書(shū)的有效性。
l 為了生成會(huì)話密鑰用于安全連接酵紫，客戶端使用服務(wù)器的公鑰加密隨機(jī)生成的密鑰告嘲，并將其發(fā)送到服務(wù)器错维，只有服務(wù)器才能使用自己的私鑰解密。
l 利用隨機(jī)數(shù)橄唬，雙方生成用于加密和解密的對(duì)稱密鑰赋焕。
這就是TLS 協(xié)議的握手，握手完畢后的連接是安全的仰楚，直到連接（被）關(guān)閉隆判。如果上述任何一個(gè)步驟失敗，TLS 握手過(guò)程就會(huì)失敗僧界，并且斷開(kāi)所有的連接侨嘀。
3.2 ****動(dòng)態(tài)Token**技術(shù)****
**
Token技術(shù)在Apple Pay等支付系統(tǒng)中廣泛應(yīng)用[5]，Token SP根據(jù)Token Requestor提供的PAN(主帳號(hào))生成Token后捂襟，將Token作為PAN的替代值流轉(zhuǎn)在支付的各個(gè)環(huán)節(jié)咬腕，使得在支付流程中，獨(dú)一無(wú)二的PAN只在Token SP葬荷、轉(zhuǎn)接方涨共、發(fā)卡方間傳遞，由于三者專線連接且彼此互信宠漩，且當(dāng)Token被檢測(cè)到風(fēng)險(xiǎn)或到期時(shí)举反，將再次生成新Token替代，從而大幅降低支付過(guò)程中PAN泄漏的可能性扒吁，極大地提高了PAN的安全性火鼻。
3.2.1 Token****申請(qǐng)流程
**
NFC終端傳遞PAN至Token Requestor;
Token Requestor向Token SP發(fā)起Token申請(qǐng)，發(fā)送PAN;
Token SP根據(jù)PAN雕崩，生成對(duì)應(yīng)的Token并返回至Token Requestor凝危，同時(shí)建立PAN至Token的映射并存儲(chǔ)在Token庫(kù)中，與發(fā)卡方共享此Token庫(kù);
Token Requestor將返回的Token傳遞至NFC終端晨逝。
圖2 Token申請(qǐng)流程
**
**
3.2.2 Token****應(yīng)用流程
**
圖3 Token應(yīng)用流程
- Token從NFC終端開(kāi)始蛾默，依次傳遞至POS、收單方捉貌、轉(zhuǎn)接方;
2．轉(zhuǎn)接方通過(guò)與Token SP的接口支鸡，發(fā)送Token至Token SP;
Token SP對(duì)Token執(zhí)行去令牌化操作，并將PAN傳遞至轉(zhuǎn)接方;
轉(zhuǎn)接方將Token&PAN傳遞至發(fā)卡方趁窃，發(fā)卡方用Token庫(kù)進(jìn)行驗(yàn)證牧挣，驗(yàn)證通過(guò)后，再將PAN傳遞至轉(zhuǎn)接方;
驗(yàn)證后的Token從轉(zhuǎn)接方開(kāi)始醒陆，依次傳遞至收單方和POS瀑构，之后Token作為PAN的替代值繼續(xù)后續(xù)的交易流程。
以上是Token的技術(shù)實(shí)現(xiàn)方案刨摩，可以看到寺晌，在交易過(guò)程中世吨，PAN傳遞且僅傳遞在Token SP、發(fā)卡方和轉(zhuǎn)接方三者之間呻征，且Token的動(dòng)態(tài)性保證了交易信息的保密性耘婚。
參考文獻(xiàn)
**
[1] http://www.edu.cn/tgyy_7952/20100714/t20100714_496025.shtml
[2]http://finance.ifeng.com/a/20150310/13542799_0.shtml
[3] http://www.cebnet.com.cn/2014/0717/270517.shtml
[4]王學(xué)剛.NFC移動(dòng)支付及其安全管理[J].中國(guó)管理信息化,2012,15(21):79-80.
