移動身份認證中的隱私保護方法的研究

◆鄭 芳 魏建琴 李平珍

?

移動身份認證中的隱私保護方法的研究

◆鄭 芳 魏建琴 李平珍

（山西財經(jīng)大學(xué)信息管理學(xué)院 山西 030006）

為了方便用戶使用，幾乎所有的移動應(yīng)用程序都提供了一種使用手機短信驗證碼進行身份認證的一次一密功能，但是作為用戶身份之一的手機號碼，可能被不可信服務(wù)提供商泄露，也可能由于多服務(wù)提供商的數(shù)據(jù)共享而遭到數(shù)據(jù)挖掘的攻擊，從而泄露了用戶的隱私軌跡，如用戶去過的商店、KTV、醫(yī)院等信息。本文創(chuàng)新性地將可信第三方服務(wù)器和數(shù)據(jù)分割技術(shù)引入移動認證隱私保護技術(shù)中，通過引入可信第三方服務(wù)器，將手機號碼從服務(wù)提供商服務(wù)器分離出來，存儲到可信第三方服務(wù)器，從而保證其不被泄露以保護用戶隱私，并詳細闡述了本方案的設(shè)計過程，以及實現(xiàn)本方案所遇到的問題的技術(shù)解決方法，最后從理論上分析了本方案的隱私保護性能，通過實驗演示了其時間效率，證明其具有可行性。

移動認證；隱私保護；可信第三方服務(wù)器;短信驗證；

0 引言

隨著移動互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展、智能手機的廣泛普及和處理速度的不斷提高，許多移動應(yīng)用程序被開發(fā)出來，如酒店預(yù)訂APP、看病預(yù)約APP、移動辦公APP、機票購買APP等，這些應(yīng)用為我們的生活提供了很多服務(wù)，為了方便用戶快速使用這些APP，除了使用傳統(tǒng)的基于用戶名和密碼的登錄注冊方式外，還提供了基于手機短信驗證碼的一次一密的快速登錄注冊功能，但是因為手機號碼是用戶在現(xiàn)實生活中的真實身份之一，和姓名、住址等一樣，代表著用戶的真實信息，如果攻擊者將用戶的網(wǎng)絡(luò)信息和真實身份關(guān)聯(lián)起來，在結(jié)合一些其它信息，如某個人認識這個手機號碼的主任，那么個人將沒有隱私可言。

大部分移動應(yīng)用程序使用和用戶身份相關(guān)的信息主要是手機號碼，因為它們都提供了基于短消息的身份認證技術(shù)，主要涉及的場景包括注冊、登錄、密碼找回等，還有的移動應(yīng)用程序如電商應(yīng)用程序要求知道用戶的住址，但本文只研究適合于絕大部分應(yīng)用程序的手機號碼的隱私保護問題，其它的身份信息如住址等、姓名等的保護可以借鑒本文的方法。

0.1 隱私攻擊模型

通過手機短信驗證碼進行登錄注冊，會將手機號碼保留到服務(wù)提供商的服務(wù)器上，這種情況可能導(dǎo)致用戶的隱私泄露，主要表現(xiàn)為：

（1）不可信服務(wù)提供商銷售用戶隱私信息[1]；

（2）不可信服務(wù)提供商惡意收集用戶信息[2][3]；（3）基于數(shù)據(jù)挖掘的隱私泄露[4][5]進行數(shù)據(jù)挖掘；（4）服務(wù)提供商的服務(wù)器被攻擊[6][7][8][9]。

0.2 研究背景

文獻[10]論述了可信第三方平臺在電子商務(wù)協(xié)議中的架構(gòu)及其實現(xiàn)，文獻[11]提出了利用可信第三方平臺對用戶提供精準(zhǔn)推薦，文獻[12]提出了一種一次一密的分組加密方案，文獻[13]分析了一次一密技術(shù)的安全性，文獻[14]提出了一種將海量數(shù)據(jù)分割成多個獨立小數(shù)據(jù)，以加快數(shù)據(jù)挖掘速度的算法，文獻[15]提出一種基于圖像內(nèi)容的新的數(shù)據(jù)分割方法，較大程度地改善了視頻流的傳輸質(zhì)量，文獻[16]提出一種用于實現(xiàn)用戶與云端之間雙向身份認證的方案，用來解決目前云環(huán)境下用戶與云端之間進行身份認證時所存在的安全問題和不足，文獻[17]提出了一種更安全的測量設(shè)備無關(guān)的量子身份認證協(xié)議，文獻[18]提出了一種可證安全的高效無證書兩方認證密鑰協(xié)商協(xié)議。文獻[10][11]是可信第三方平臺在電子商務(wù)和推薦技術(shù)中的應(yīng)用，對本文具有借鑒作用；目前存在的身份認證技術(shù)的研究，多是像文獻[16][17][18]所提到的，主要集中在利用公鑰證書、量子技術(shù)進行身份認證或者是關(guān)于無證書的身份認證的研究，而基于短信驗證碼的移動身份認證的安全性的研究卻不多，這方面已有的研究也主要集中在基于短信驗證碼在移動支付等信息系統(tǒng)中的應(yīng)用[19][20]，文獻[13]是對一次一密從網(wǎng)絡(luò)安全的角度分析其是否容易被攻擊，但并沒有研究其帶來的隱私泄露問題；文獻[14][15]提出的數(shù)據(jù)分割技術(shù)主要應(yīng)用在圖像傳輸和海量數(shù)據(jù)挖掘中，而這種技術(shù)在安全中的應(yīng)用的研究卻不多，且分割后的數(shù)據(jù)還是存儲在一個服務(wù)器上，并沒有涉及到多個服務(wù)器。

0.3 本文的創(chuàng)新

基于以上對隱私攻擊的分析發(fā)現(xiàn)，代表用戶身份的手機號碼是用戶隱私泄露的關(guān)鍵，如果沒有現(xiàn)實生活中的身份信息，即使用戶的網(wǎng)上活動信息被泄露，由于無法和現(xiàn)實生活中的個人相結(jié)合，也不會對個人用戶造成太大威脅。而大部分移動應(yīng)用程序采集和用戶身份相關(guān)的信息主要是手機號碼，所以我們提出了一種方案來保護手機號碼，此方案的主要思想是引入可信第三方服務(wù)器和數(shù)據(jù)分割的思想，將原來存儲在服務(wù)提供商服務(wù)器上的數(shù)據(jù)分成兩部分，一部分是手機號碼，另一部分是其它和身份無關(guān)的數(shù)據(jù)，然后將手機號碼從服務(wù)提供商的服務(wù)器上分離出來，存儲在第三方服務(wù)器上，從而保護由手機號碼引起的用戶隱私信息的泄露。為了實現(xiàn)這個方案，我們提出了路徑尋找法、會話號和虛擬身份法、文件索引法。在以下的內(nèi)容中，我們將詳細探討此方案的體系結(jié)構(gòu)和實現(xiàn)算法。

0.4 本文的組織結(jié)構(gòu)

本文第二部分提出了本方案的體系結(jié)構(gòu)和工作過程，同時提出了實現(xiàn)本方案遇到的問題；第三部分就第二部分中提出的問題分別進行解決；第四部分對本方案從理論上進行了安全性分析；第五部分通過實驗分析了時間效率，證明了其可行性。

1 本方案的體系結(jié)構(gòu)

1.1 傳統(tǒng)的短信驗證過程

圖1為傳統(tǒng)短信驗證示例圖，其工作流程（流程1）為：

圖1 傳統(tǒng)的短信驗證示意圖

（1）移動客戶端輸入手機號碼，向服務(wù)提供商發(fā)起短信驗證碼請求；

（2）服務(wù)提供商生成驗證碼，將短信驗證碼和手機號碼一起發(fā)送給短信平臺；

（3）短信平臺將驗證碼發(fā)往手機端。

（4）手機端將驗證碼發(fā)往服務(wù)提供商；

（5）服務(wù)提供商將其與自己生成的驗證碼進行比較,如果相同，則驗證通過。

1.2 引入可信第三方服務(wù)器

為了防止服務(wù)提供商泄露用戶的隱私信息，本文在移動客戶端和服務(wù)提供商之間引入了可信第三方服務(wù)器，其架構(gòu)圖如圖2所示，其工作流程（流程2）為：

（1）移動客戶端輸入手機號碼，發(fā)起獲取短信驗證碼的請求，將請求提交給可信第三方服務(wù)器，對應(yīng)圖2中的第①步；

（2）可信第三方服務(wù)器過濾掉手機號碼，將請求發(fā)送給服務(wù)提供商，對應(yīng)圖2中的第②步；

（3）服務(wù)提供商生成短信驗證碼，發(fā)送給可信第三方服務(wù)器，對應(yīng)圖2中的第③步；

（4）可信第三方服務(wù)器將短信驗證碼發(fā)給短信平臺，對應(yīng)圖2中的第④步；

圖2 引入新方案后的工作流程示意圖

（5）跳轉(zhuǎn)到圖1中的③④⑤步。

和流程1比較，流程2發(fā)生了很多變化，由此也帶來了新的問題，主要表現(xiàn)為：

問題1：如何尋找路徑。在新的方案中，傳輸路徑發(fā)生了變化，流程1中，移動客戶端直接將請求發(fā)送給服務(wù)提供商，而流程2中，傳輸路線變?yōu)椋阂苿涌蛻舳恕尚诺谌椒?wù)器→服務(wù)提供商→可信第三方服務(wù)器→短信平臺，帶來的問題是：如何尋找路徑；

問題2：服務(wù)提供商不知道是哪個用戶發(fā)來的請求。通過手機號碼進行登錄注冊的用戶，由于可信第三方服務(wù)器過濾掉了手機號碼，導(dǎo)致服務(wù)提供商無法識別用戶的身份；

問題3：大量服務(wù)提供商和少量可信第三方服務(wù)器的矛盾。一個可信第三方服務(wù)器要為大量的服務(wù)提供商提供身份信息過濾服務(wù)，第三方服務(wù)器如何識別請求來自于哪個服務(wù)提供商。

問題4：訪問授權(quán)。由于短信平臺的服務(wù)是服務(wù)提供商購買的，不是可信第三方購買，但本方案中，是可信第三方平臺將短信驗證碼發(fā)往短信平臺，而不是服務(wù)提供商，多以需要服務(wù)提供商將訪問短信平臺的權(quán)限授予短信平臺。

在以下的章節(jié)中，將針對以上問題分別探討解決方法。

2 問題的解決方法

2.1 URL路徑尋找

為了解決問題1，我們引入flag標(biāo)記來標(biāo)識路徑的次序，請求從移動客戶端發(fā)起，設(shè)此時flag的初始值為0，之后每傳輸?shù)较乱粋€接收端，flag的值自動加1，因為短信平臺通過手機號碼識別客戶端，不需要使用URL地址，所以flag的值指示到短信平臺結(jié)束。其示意圖如圖3所示。

圖3 URL路線尋找示意圖

我們將圖3中的內(nèi)容用一個XML進行存儲，XML文件的內(nèi)容如下：

這個XML文件被被存儲在圖3中的每個端點上，其中url位于HTTP數(shù)據(jù)包的包頭，flag位于HTTP數(shù)據(jù)體中，每傳輸?shù)揭粋€端點，flag自動加1，然后，根據(jù)flag的值在文件中查找url的值，將其作為下一站的目標(biāo)URL，其算法為：

算法：GetTargetURL(flag)

輸入：flag；

輸出：下一個節(jié)點的URL地：tUrl；

（1）Begin:

（2）flag++;

（3）tUrl ←根據(jù)flag在XML文件中查找url；

（4）return tUrl;

（5）End

2.2 會話號Session Number和網(wǎng)絡(luò)虛擬身份標(biāo)識符UserId

針對問題2，我們引入了會話號Session Number和網(wǎng)絡(luò)虛擬身份標(biāo)識符UserId。

可信第三方服務(wù)器過濾掉代表用戶身份信息的電話號碼后，失去了標(biāo)識用戶身份的標(biāo)識，當(dāng)服務(wù)提供商收到請求包后，無法判斷出請求來自哪個用戶。為了解決這個問題，我們引入了網(wǎng)絡(luò)虛擬身份標(biāo)識符UserId，以虛擬身份來區(qū)分服務(wù)提供商服務(wù)器上的每個用戶，UserId在用戶注冊時由用戶填寫。

但此時又會出現(xiàn)一個問題，如果用戶是第一次訪問服務(wù)提供商，即未注冊就直接用手機號碼進行登錄，此時用戶還沒有UserId。針對這個問題，我們引入了會話號Session Number，以此標(biāo)識用戶本次會話，Session Number唯一。

此時，問題2基本有了解決方案，根據(jù)圖2所示，主要改進的地方涉及到圖2中的第①②③④步，以下小節(jié)為改進內(nèi)容。

2.2.1 第①步中，可信第三方服務(wù)器的處理過程

可信第三方服務(wù)器啟動后，首先初始化一張表T，其結(jié)構(gòu)為：

T{Telephone Number, UserId, Session Number}

用來存儲會話記錄，當(dāng)收到移動客戶端發(fā)來的請求（其請求包的內(nèi)容為{Telepphone Number, flag}）后，可信第三方服務(wù)器的處理過程為（這里忽略根據(jù)flag查找URL路徑的過程，此過程在3.1中有詳細描述）：

（1）獲取請求包中Telephone Number的值；

（2）在表中通過Telephone Number查找UserId，這里有兩種情況，如果用戶已經(jīng)訪問過（類似的場景如登錄、密碼找回等），則得到UserId的值；如果用戶第一次訪問（類似的場景如注冊），則設(shè)置UserId的值為null，系統(tǒng)根據(jù)算法生成一個Session Number，用它代表本次會話，然后將記錄{Telephone Number, null, Session Number}插入表中；

（3）創(chuàng)建一個新的HTTP包，包體數(shù)據(jù)結(jié)構(gòu)為{UserId, Session Number}，Telephone Number被保存在了第三方服務(wù)器上，而沒有發(fā)送給服務(wù)提供商;

（4）將生成的HTTP包發(fā)送給服務(wù)提供商，即進入圖2中的第②步。

2.2.2 第②步中，服務(wù)器提供商的處理過程

服務(wù)器提供商的服務(wù)器啟動后，首先初始化一張用戶表U，主要數(shù)據(jù)結(jié)構(gòu)為：

U{UserId, password};

（1）獲取收到的HTTP包中的數(shù)據(jù)：UserId和Session Number的值；

（2）如果包中UserId的值為空，表示用戶第一次訪問，為其生成一個系統(tǒng)id，將其值賦給UserId；

（3）系統(tǒng)根據(jù)算法生成一個短信驗證碼：Message Authenti cation Code；

（4）創(chuàng)建一個新的HTTP包，包體數(shù)據(jù)結(jié)構(gòu)為{UserId, Session Number, Message Authentication Code};

（5）將生成的HTTP包發(fā)回給服務(wù)提供商，即進入圖2中的第③步。

2.2.3 第③步中，可信第三方服務(wù)器的處理過程

（1）獲取收到的HTTP包中的數(shù)據(jù)；UserId、Session Number和Message Autenticaiton Code的值；

（2）用UserId在表T中查找Telephon Number，如果結(jié)果為空，表示這個UserId是系統(tǒng)生成的，之前沒有記錄，然后用Session Number在表中查找Telephone Number并獲取其值；

（3）生成一個新的HTTP包，其包體的數(shù)據(jù)結(jié)構(gòu)為：{Telephone Number, Message Authentication Code};

（4）將其發(fā)送給短信平臺，進入圖2中的第④步。

2.3 少量可信服務(wù)器和大量服務(wù)提供商

如何讓一個可信服務(wù)器識別大量的服務(wù)提供商，針對問題3，我們在第三方可信服務(wù)器上引入了一張索引表I，其結(jié)構(gòu)為：

I{Domain Name, Database Name, Path}

其中Domain Name為域名，Database Name為數(shù)據(jù)庫名，Path為數(shù)據(jù)庫的路徑，其示意圖如圖4所示，其處理流程為：

（1）獲取請求包中的URL地址；

（2）將URL與索引表I中的Domain Name相比較，如果URL中包含Domain Name，則找到其對應(yīng)的Path的值；

（3）根據(jù)Path的值連接對應(yīng)的數(shù)據(jù)庫。

以下面的例子為例，來說明其實現(xiàn)過程：

（1）假設(shè)從請求包中獲取的URL為：HTTP://www.A.com/login.jsp ；

（2）在索引表I中查找URL所包含的Domain Name，然后得到對應(yīng)的Path的值為：HTTP://www.A.com；

（3）以Path作為連接地址，連接數(shù)據(jù)庫。

3.4 訪問授權(quán)

在本方案中, 是TTPS將Message Authentication Code 發(fā)送給短信平臺，而不是服務(wù)提供商將其發(fā)送給短信平臺，購買短信平臺服務(wù)的是短信平臺，而不是TTPS，所以需要服務(wù)提供商將訪問短信平臺的權(quán)限授予TTPS，本文提出了一種將服務(wù)提供商訪問短信平臺的權(quán)限授予TTPS，其方法為：服務(wù)提供商自動生成一個隨機數(shù)S，然后用服務(wù)提供商的私鑰對其進行簽名，短信平臺用服務(wù)提供商的公鑰進行驗證。算法為：

輸出：result: 授權(quán)訪問成功與否的標(biāo)志；

（1）Begin:

（7）短信平臺用服務(wù)提供商的公鑰對簽名進行驗證：

（8）End

3 性能分析

3.1 隱私性能分析

3.1.1 防止身份信息的泄露

因為手機號碼存儲在可信第三方平臺，而不是服務(wù)提供商處，所以，攻擊者即使獲得了用戶活動信息，也無法和真實信息聯(lián)系，故無法和現(xiàn)實生活中的人有聯(lián)系，隱私不會被泄露。

3.1.2 阻止了推斷攻擊

3.1.3 可信服務(wù)商被攻擊

假設(shè) 可信第三方平臺被攻擊，Jack得到了Alice的信息{Telephone Number, UserId}。

Jack用Alice的Telephone Number+短信驗證碼進行登錄，由于Jack沒有Alice的手機，所以得不到短信驗證碼，所以登錄失敗；同理，如果Jack用Alice的UserId+密碼進行登錄，由于Jack沒有密碼，所以登錄失敗。

3.1.4 可信第三方和服務(wù)提供商同時被攻擊

系統(tǒng)整體隱私泄露值為：

3.2 時間效率評估

我們在實驗環(huán)境Intel? Core? i5-825U CPU @ 1.60GHz，8.00GB RAM，Win10，MySQL（線程池中開啟20個線程）上模擬了本方案的通信時間，收集到的數(shù)據(jù)所示，其中n表示數(shù)據(jù)庫中表中的記錄數(shù)，從表中可以看到我們采集了n=1000，5000，10000，50000，100000，500000的時候，處理每一次請求所花費的時間，其單位為毫秒（ms）。本次實驗我們重復(fù)了10次，x表示重復(fù)的次數(shù)。

圖4 在不同n的取值下，請求響應(yīng)時間圖

從圖中第一行記錄可以觀察到，其值比后邊九條記錄都大，其差值大概是400ms，這個值是每次系統(tǒng)初始化時，連接數(shù)據(jù)庫的時間。

根據(jù)圖4，對每一個n取其平均時間，結(jié)果如圖5所示，因為n=1000,5000的時間太小，所以只繪了n=10000，50000，100000，500000的時間值。

圖5 n取不同值時的平均請求響應(yīng)時間

從圖中可以看出，本方案的最大處理時間大概是7000ms，即7s，而一個短信驗證碼的等待時間一般是1分鐘，即60s，所以本方案在工程應(yīng)用中是可行的。

4 總結(jié)

本文通過引入可信第三方服務(wù)器阻止了基于手機短信的移動身份認證中的隱私泄露，通過安全性的理論分析和時間延遲性的實驗演示，證明本方案在理論上和工程上都具有可行性。

[1]劉向宇,王斌,楊曉春.社會網(wǎng)絡(luò)數(shù)據(jù)發(fā)布隱私保護技術(shù)綜述[J].軟件學(xué)報,2014.

[2]牟凡. 中美電子商務(wù)消費者信息隱私權(quán)保護制度比較研究[D].南京大學(xué),2012.

[3]郭磊，胡曉勤，江天宇，等. 基于行為特征識別的網(wǎng)絡(luò)詐騙嫌疑人追蹤系統(tǒng)[J]. 信息網(wǎng)絡(luò)安全，2014.

[4]高強,張鳳荔,王瑞錦,周帆.軌跡大數(shù)據(jù):數(shù)據(jù)處理關(guān)鍵技術(shù)研究綜述[J].軟件學(xué)報,2017.

[5]王丹,顧明昌,趙文兵.跨站腳本漏洞滲透測試技術(shù)[J].哈爾濱工程大學(xué)學(xué)報,2017.

[6]陳小兵. Linux操作系統(tǒng)root賬號密碼獲取防范技術(shù)研究[J]. 信息網(wǎng)絡(luò)安全，2014.

[7]張慧琳,鄒維,韓心慧.網(wǎng)頁木馬機理與防御技術(shù)[J].軟件學(xué)報,2013.

[8]王學(xué)強，雷靈光，王躍武. 移動互聯(lián)網(wǎng)安全威脅研究[J]. 信息網(wǎng)絡(luò)安全，2014.

[9]李冰. 國內(nèi)SNS社交網(wǎng)站隱私安全問題及對策研究[D].陜西師范大學(xué),2012.

[10]卿斯?jié)h. 電子商務(wù)協(xié)議中的可信第三方角色[J]. 軟件學(xué)報, 2003.

[11]王福, 康健. 基于可信第三方的圖書情報機構(gòu)個性化信息推送研究[J]. 圖書情報工作, 2015.

[12]張玉安, 馮登國. 一種實用的仿一次一密分組加密方案[J]. 北京郵電大學(xué)學(xué)報, 2005.

[13]王勇. 一次一密體制的安全性分析與改進[A]. 中國軟件工程大會CCSE專家理事會.第四屆中國軟件工程大會論文集[C].中國軟件工程大會CCSE專家理事會:,2007.

[14]覃政仁,吳渝,王國胤.一種基于RoughSet的海量數(shù)據(jù)分割算法[J].模式識別與人工智能,2006.

[15]杜建超,吳成柯,楊亞東,肖嵩.一種基于圖像內(nèi)容的數(shù)據(jù)分割方法[J].西安電子科技大學(xué)學(xué)報,2006.

[16]王中華,韓臻,劉吉強,張大偉,常亮.云環(huán)境下基于PTPM和無證書公鑰的身份認證方案[J].軟件學(xué)報,2016.

[17]董穎娣,彭進業(yè),張曉博,張振龍.基于測量設(shè)備無關(guān)協(xié)議的量子身份認證方案[J].通信學(xué)報,2016.

[18]周彥偉,楊波,張文政.一種改進的無證書兩方認證密鑰協(xié)商協(xié)議[J].計算機學(xué)報,2017.

[19]王紅新,楊德禮,姜楠,馬慧.一種終端認證簡化的在線移動支付模式與協(xié)議[J].計算機研究與發(fā)展,2013.

[20]馮錫煒.短消息應(yīng)用系統(tǒng)的技術(shù)和實現(xiàn)[J].撫順石油學(xué)院學(xué)報,2003.

山西財經(jīng)大學(xué)校級青年基金項目“社交網(wǎng)絡(luò)隱私在云計算平臺下的研究”（QN2015014）；國家自然科學(xué)基金“基于在線多源沖突數(shù)據(jù)融合分類方法的信用評級研究”（71701116）；山西省教育科學(xué)“十三五”規(guī)劃課題“以計算思維為導(dǎo)向的經(jīng)管類專業(yè)Python課程教學(xué)研究與實踐”（GH-16045），面向綜合能力培養(yǎng)的財經(jīng)類高校Python課程教學(xué)研究與實踐（2017216）。