基于NFC的點(diǎn)對(duì)點(diǎn)支付模擬實(shí)現(xiàn)

陳鏡宇，孫 麗，楊 靜，劉雨婷

（東南大學(xué)成賢學(xué)院 電子與計(jì)算機(jī)工程學(xué)院，江蘇 南京 210000）

0 引 言

當(dāng)今社會(huì)，移動(dòng)互聯(lián)網(wǎng)技術(shù)的迅速發(fā)展推動(dòng)無線通信技術(shù)不斷前進(jìn)，當(dāng)前，由于智能手機(jī)的普及，現(xiàn)金支付的方式逐漸轉(zhuǎn)為移動(dòng)支付，當(dāng)下，移動(dòng)支付已經(jīng)成為當(dāng)前最為流行的支付方式。移動(dòng)支付的實(shí)現(xiàn)方式可分為兩種：一種是通過短信、WAP等遠(yuǎn)程控制完成支付；另一種是通過近距離非接觸技術(shù)完成支付，主要的近距離通信技術(shù)有RFID、NFC、藍(lán)牙等[1]。其中，NFC近場(chǎng)移動(dòng)支付成為一種便捷且相對(duì)安全的移動(dòng)支付方式。目前，NFC技術(shù)應(yīng)用較為廣泛，市面上使用NFC技術(shù)做移動(dòng)支付的場(chǎng)景，大多是手機(jī)模擬成常用的支付卡，例如常見的公交卡等，然后手機(jī)模擬成公交卡與POS機(jī)進(jìn)行交易[2-3]。然而，利用POS機(jī)作為交易的一方終究有其局限性，首當(dāng)其沖的便是其便攜性，因此，利用NFC技術(shù)實(shí)現(xiàn)兩部手機(jī)之間，即以點(diǎn)對(duì)點(diǎn)，手機(jī)之間背對(duì)背的方式相靠進(jìn)行交易，能極大便利人們的生活。

1 NFC技術(shù)

NFC是Near Field Communication的縮寫，即近距離無線通信技術(shù)。與RFID類似，NFC信息也是通過頻譜中無線頻率部分的電磁感應(yīng)耦合方式傳遞。但由于NFC采取了獨(dú)特的信號(hào)衰減技術(shù)，相對(duì)于RFID而言NFC具有距離近、帶寬高、能耗低等特點(diǎn)[4]。

NFC技術(shù)的支付優(yōu)點(diǎn)在于：首先，與其他通信技術(shù)相比，NFC的傳輸距離最近，距離近意味著更高的安全性，更有利于傳輸財(cái)務(wù)信息或敏感的個(gè)人信息等重要數(shù)據(jù)；其次，相比于紅外，NFC更為快捷、可靠和簡(jiǎn)單[4-5]。

NFC移動(dòng)通信終端共有3種工作狀態(tài)：卡模擬狀態(tài)、識(shí)讀器狀態(tài)、點(diǎn)對(duì)點(diǎn)通信狀態(tài)。其中，點(diǎn)對(duì)點(diǎn)通信狀態(tài)即2個(gè)NFC移動(dòng)通信終端靠近可互相通信，實(shí)現(xiàn)數(shù)據(jù)傳輸[4-5]。

NDEF（NFC Data Exchange Format）定義了消息的封裝格式，對(duì)于需要傳輸或存儲(chǔ)的原始數(shù)據(jù)進(jìn)行了封裝處理，該格式主要應(yīng)用于標(biāo)簽領(lǐng)域或者2個(gè)NFC設(shè)備之間[4-5]。

2 開發(fā)實(shí)現(xiàn)

2.1 系統(tǒng)開發(fā)環(huán)境

使用Android Studio作為開發(fā)環(huán)境，一是因?yàn)槠浠贕radle構(gòu)件項(xiàng)目，可以導(dǎo)入來自Github或其他網(wǎng)站的包，大大節(jié)省開發(fā)成本，降低開發(fā)難度；其次，Android Studio有Google的支持，可以快速引用Google的JDK，從而快速構(gòu)件UI。

MySQL是一種持久性的關(guān)系型數(shù)據(jù)庫，事務(wù)一旦提交，那么所有更改就會(huì)保存到數(shù)據(jù)庫中進(jìn)行。此舉的好處在于，當(dāng)系統(tǒng)崩潰時(shí)，數(shù)據(jù)依舊不會(huì)丟失。此外，通過JDBC連接數(shù)據(jù)庫的Java更適配MySQL。

2.2 系統(tǒng)運(yùn)行環(huán)境

本系統(tǒng)運(yùn)行于兩部均內(nèi)置有源NFC芯片的手機(jī)，而且由于本系統(tǒng)中NFC的工作狀態(tài)為點(diǎn)對(duì)點(diǎn)通信狀態(tài)，所以要求手機(jī)支持Android Beam功能[6]。而這兩部手機(jī)都具有該功能，因此滿足系統(tǒng)需要。

2.3 總體設(shè)計(jì)方案

本文設(shè)計(jì)了基于Android平臺(tái)開發(fā)使用NFC作為通信技術(shù)的模擬支付軟件。軟件的設(shè)計(jì)重點(diǎn)在于2臺(tái)支持NFC傳輸?shù)氖謾C(jī)之間的數(shù)據(jù)傳輸，以及對(duì)整個(gè)交易過程中的一些安全方案的研究。系統(tǒng)中主要利用XML語言設(shè)計(jì)軟件的前端UI，使用Java進(jìn)行后端的邏輯處理，使用MySQL數(shù)據(jù)庫存儲(chǔ)用戶的個(gè)人信息以及賬戶金額等。

由前文可知，NFC共有3種工作模式，對(duì)于識(shí)讀器狀態(tài)，此時(shí)與手機(jī)進(jìn)行交互的目標(biāo)更多是NFC論壇上定義的1、2、3、4標(biāo)簽[3]，這4種標(biāo)簽并不符合實(shí)際的交易情景，所以不予考慮；其次是卡模擬狀態(tài)，對(duì)于卡模擬狀態(tài)，由于Android的卡模擬基于ISO7816-4協(xié)議，而市面上大多數(shù)流通的卡，例如校園卡、公司員工卡等，一般都是MIFARE Classic系列的卡[6]，這些卡基本遵守ISO14443A標(biāo)準(zhǔn)，且卡均有加密，有自己的安全元件，即手機(jī)不能完全模擬這些卡的所有扇區(qū)。此外，如果使用卡模擬狀態(tài)，還需要考慮硬件方面與軟件的兼容問題。綜上所述，使用點(diǎn)對(duì)點(diǎn)狀態(tài)作為本系統(tǒng)的通信狀態(tài)較為合適。

系統(tǒng)本身采用MVP（Model, View, Presenter）設(shè)計(jì)模式。用戶通過View層進(jìn)行交互，將數(shù)據(jù)傳輸給Presenter層進(jìn)行處理。數(shù)據(jù)被Presenter層交給Model層進(jìn)行格式處理，然后再返回到Presenter層，Presenter層再將數(shù)據(jù)傳給數(shù)據(jù)庫進(jìn)行同步，同時(shí)調(diào)用View層的回調(diào)接口以更新View層，從而響應(yīng)用戶。設(shè)計(jì)模式示意圖如圖1所示。

圖1 系統(tǒng)的設(shè)計(jì)模式示意圖

2.4 用戶注冊(cè)、登錄和找回密碼功能設(shè)計(jì)

2.4.1 用戶注冊(cè)

用戶輸入賬號(hào)、手機(jī)號(hào)碼進(jìn)行注冊(cè)。注冊(cè)界面調(diào)用了MobTech的短信驗(yàn)證服務(wù)，只有通過輸入正確的手機(jī)賬號(hào)后才能獲取驗(yàn)證碼。只有注冊(cè)手機(jī)和驗(yàn)證碼相匹配，才能完成注冊(cè)。通過手機(jī)號(hào)碼與短信驗(yàn)證碼綁定來防止惡意注冊(cè)。完成注冊(cè)后，Presenter層會(huì)對(duì)密碼進(jìn)行MD5非對(duì)稱加密后存儲(chǔ)到數(shù)據(jù)庫中，加密是為了保證數(shù)據(jù)庫泄露后密碼難以被破解，登錄界面如圖2所示。

圖2 注冊(cè)界面示意圖

2.4.2 找回密碼

由于注冊(cè)時(shí)通過手機(jī)號(hào)碼驗(yàn)證，那么在找回密碼時(shí)，也應(yīng)該用手機(jī)號(hào)碼找回。通過驗(yàn)證之后，連續(xù)2次輸入密碼防止用戶誤輸入。找回密碼示意圖如圖3所示。

圖3 找回密碼界面示意圖

2.4.3 登錄

輸入正確的賬號(hào)/手機(jī)號(hào)碼和密碼后，即能成功登錄主界面。

2.5 支付與收款功能設(shè)計(jì)

2.5.1 支付功能設(shè)計(jì)

在待支付界面之前設(shè)置一個(gè)界面，這樣用戶可以在該界面輸入金額和支付密碼。在提交之前，首先系統(tǒng)會(huì)從數(shù)據(jù)庫獲得當(dāng)前用戶的余額，如果待支付的金額大于余額，那么就無法發(fā)起交易。否則就會(huì)判斷用戶的支付密碼是否與設(shè)定的一致，如果不一致，那么仍舊不能發(fā)起交易。只有滿足以上2個(gè)條件，用戶才能發(fā)起交易并進(jìn)入等待交易界面。在等待交易界面中，只有當(dāng)收款方也進(jìn)入等待交易界面時(shí)，兩者手機(jī)背對(duì)背相靠后，才能觸發(fā)交易流程。等待支付的界面如圖4所示。等待支付界面顯示付款方的一些個(gè)人信息以便支付方自己進(jìn)行信息核對(duì)。

圖4 等待支付界面示意圖

2.5.2 收款功能設(shè)計(jì)

收款方點(diǎn)擊“收款”按鈕，進(jìn)入收款界面后便進(jìn)入等待收款狀態(tài)。當(dāng)雙方通過手機(jī)背靠背貼近進(jìn)行交易時(shí)。支付方發(fā)起支付請(qǐng)求，成功發(fā)起后，數(shù)據(jù)通過NFC傳輸。收款方接收完數(shù)據(jù)后，其系統(tǒng)先進(jìn)行支付業(yè)務(wù)邏輯的處理，隨后更新UI以通知收款方交易完成。UI更新后的示意圖如圖5所示。支付方信息顯示在屏幕上以便收款方和支付方進(jìn)行信息與身份核對(duì)。

圖5 交易完成后收款方的界面示意圖

2.6 NFC傳輸邏輯實(shí)現(xiàn)

2.6.1 支付方發(fā)送數(shù)據(jù)的邏輯實(shí)現(xiàn)

為了能讓系統(tǒng)在手機(jī)上啟用NFC功能，首先，需要在項(xiàng)目的配置文件AndroidManifest.xml中申明NFC權(quán)限。其次，創(chuàng)建并實(shí)現(xiàn)方法initNFC以完成對(duì)NFC的初始化。Google官方提供了獲得默認(rèn)NFC適配器的方法，為NfcAdapter.getDefaultAdapter。成功獲得后，創(chuàng)建PendingIntent和過濾類型為ACTION_NDEF_DISCOVERED的意圖過濾器，為系統(tǒng)啟動(dòng)前臺(tái)調(diào)度系統(tǒng)做準(zhǔn)備。前者的作用在于Android系統(tǒng)掃描到標(biāo)簽后，會(huì)對(duì)PendingIntent的內(nèi)容進(jìn)行填充，從而產(chǎn)生可以發(fā)起傳輸?shù)慕缑?。后者的作用就是過濾發(fā)出和接收包含NDEF負(fù)載的標(biāo)簽且類型申明為ACTION_NDEF_DISCOVERED的Intent[6]。通過使用前臺(tái)調(diào)度系統(tǒng)，系統(tǒng)可以通過過濾器攔截Intent以優(yōu)于其他軟件來處理NFC數(shù)據(jù)，避免與其他系統(tǒng)和軟件沖突。

NDEF的數(shù)據(jù)封裝在NdefMessage內(nèi)，而NdefMessage包含一條或多條NdefRecord記錄[6]。官方提供的方法是createNdefMessage，該方法需要開發(fā)者重寫以創(chuàng)建一條NdefMessage。

為了能成功創(chuàng)建NdefMessage，還需要?jiǎng)?chuàng)建NdefRecord記錄，因此創(chuàng)建方法createRecord。根據(jù)NFC論壇對(duì)NdefRecord的結(jié)構(gòu)定義，第一條NdefRecord的第一個(gè)字節(jié)為消息頭。消息頭內(nèi)需要包括3位TNF（Type Name Format）、可變長度類型、可變長度ID。本系統(tǒng)指定的TNF類 型 為 TNF_WELL_KNOWN，RTD（Record Type Definition）的類型為RTD_TEXT[6-7]。數(shù)據(jù)的主體部分先經(jīng)Model層進(jìn)行JSON格式化處理變?yōu)镾tring類型，然后再轉(zhuǎn)換成Byte字節(jié)數(shù)組，并將數(shù)組的頭字節(jié)置空以存放數(shù)據(jù)頭。NdefRecord創(chuàng)建成功后，用其創(chuàng)建NdefMessage。最后，調(diào)用方法nfcAdapter.setNdefPushMessageCallback發(fā)送數(shù)據(jù)。

2.6.2 收款方接收數(shù)據(jù)的邏輯實(shí)現(xiàn)

與支付方的邏輯類似，首先收款方也需要對(duì)NFC進(jìn)行初始化、創(chuàng)建PendingIntent和設(shè)置意圖過濾器。與支付方不同的是，收款方需要在Activity的onNewIntent方法中實(shí)現(xiàn)對(duì)Intent的過濾邏輯處理。當(dāng)NFC適配器過濾到支付方的Intent的Action為ACTION_NDEF_DISCOVERED時(shí)，就要對(duì)接收的數(shù)據(jù)進(jìn)行處理。

官方提供了一個(gè)名為getParcelableArrayExtra的方法來獲得序列化后的數(shù)據(jù)。該方法將其轉(zhuǎn)換成NdefMessage，即字節(jié)數(shù)組。通過切片獲取其第一個(gè)字節(jié)數(shù)組后的數(shù)據(jù)并反向JSON轉(zhuǎn)換成JavaBean類。這樣收款方就獲取了支付方傳輸?shù)臄?shù)據(jù)類。

2.7 交易邏輯

付款方將個(gè)人與交易信息傳輸給收款方后，收款方與數(shù)據(jù)庫進(jìn)行交互以完成交易業(yè)務(wù)。

3 歸納與改進(jìn)

3.1 歸納

軟件的優(yōu)點(diǎn)更多是NFC的優(yōu)點(diǎn)，但是軟件的缺點(diǎn)也十分明顯。首先，軟件在交易邏輯的實(shí)現(xiàn)上并不完整，在雙方傳輸完數(shù)據(jù)后，數(shù)據(jù)的更改和與數(shù)據(jù)庫的交互是在收款方的手機(jī)上，這樣會(huì)導(dǎo)致更大的安全隱患[3]；盡管一個(gè)NdefMessage能包含多個(gè)NdefRecord，但通過NFC傳輸數(shù)據(jù)時(shí)，每次只能傳輸一個(gè)NdefMessage，即對(duì)比通過TCP傳輸?shù)摹岸啻挝帐帧?，NFC單次傳輸后接收方不能返回?cái)?shù)據(jù)，從而缺少接收數(shù)據(jù)后的回復(fù)確認(rèn)功能。

3.2 改進(jìn)

上文提到，NFC的數(shù)據(jù)傳輸不經(jīng)過網(wǎng)絡(luò)且若交易最終向后端發(fā)起請(qǐng)求方是收款方，那交易時(shí)若支付方無法連接網(wǎng)絡(luò)，收款方就可以直接通過網(wǎng)絡(luò)實(shí)現(xiàn)后端數(shù)據(jù)更新，這樣在支付方無網(wǎng)絡(luò)的情況下也能進(jìn)行交易，達(dá)到類似“電子錢包”的效果[8-9]。如果模擬該效果，那么支付方需要本地創(chuàng)建數(shù)據(jù)文件來存放個(gè)人信息。類比HTTPS的加密傳輸，服務(wù)端可以向客戶端返回含有公鑰的證書，客戶端添加隨機(jī)長整數(shù)到個(gè)人信息文件后用公鑰加密，交易時(shí)將加密信息一同發(fā)出，交易后服務(wù)端再通過私鑰進(jìn)行身份解密以判斷身份[10]。

此外，除了對(duì)交易過程中的數(shù)據(jù)進(jìn)行加密，用戶可以設(shè)置每次交易完成后自動(dòng)關(guān)閉NFC功能來保證不正常且非自愿的惡意交易。

如果犧牲用戶的體驗(yàn)，即發(fā)起2次NFC傳輸，第二次讓收款方發(fā)送信息驗(yàn)證數(shù)據(jù)。那么支付方在發(fā)送數(shù)據(jù)前先對(duì)數(shù)據(jù)進(jìn)行備份，然后將其與收款方發(fā)回的數(shù)據(jù)進(jìn)行比對(duì)來判斷數(shù)據(jù)是否被篡改。如果發(fā)生篡改則立即通知后端取消交易并通知用戶交易環(huán)境不安全。

4 結(jié) 語

如今的移動(dòng)交易發(fā)展迅猛，使用手機(jī)進(jìn)行支付已經(jīng)成為當(dāng)今主流支付手段。本系統(tǒng)以NFC技術(shù)為基礎(chǔ)，設(shè)計(jì)了一款模擬交易軟件。相比通過掃碼支付，用戶通過該軟件可以通過手機(jī)背對(duì)背相靠的方式完成小額付款，不僅便捷，更由于雙方交易不經(jīng)過網(wǎng)絡(luò)，也會(huì)更加安全。同時(shí)，針對(duì)該系統(tǒng)提出了一些改進(jìn)方案和一定的安全研究，在一定程度上，該軟件甚至可以模擬成一個(gè)“數(shù)字錢包”。