基于移動端協(xié)助的遠程用戶單一口令認證方法

徐淵，楊超，楊力

（1. 西安財經大學實驗實訓教學管理中心，陜西 西安 710100；2.西安電子科技大學信息網絡技術中心，陜西 西安 710071；3.西安電子科技大學網絡與信息安全學院，陜西 西安 710071）

1 引言

隨著互聯(lián)網的迅速發(fā)展和應用系統(tǒng)的不斷增加，使用口令認證機制來判斷遠程用戶的身份已經變得最為常見。用戶僅需使用其預先設置的口令與各種服務器進行認證，認證成功后便可獲得應用服務。

然而，用戶往往會設置簡單易記的口令，且頻繁使用。研究發(fā)現[1]一般用戶會在3個月內登錄25個不同的在線服務，但卻只有7個口令，若其中之一泄露，將會威脅其他賬戶信息的安全。當用戶忘記某個欲登陸的在線服務的口令時，會逐一嘗試自己的口令，直到認證成功。如果該服務器是惡意的，它除了獲得此服務的口令外，還會得到用戶的其他口令，可能會對用戶的其他賬戶發(fā)起跨站點的偽裝攻擊。即使服務器是所謂的可信服務器，也可能會對用戶發(fā)起同樣的攻擊。Facebook的CEO曾在2004年使用 Facebook的登錄數據訪問一些商業(yè)對手和記者的私人郵件[2]。

1992年，Bellovin和Merritt在Diffie-Hellman密鑰交換協(xié)議的基礎上，提出了口令認證密鑰交換（PAKE, password-authenticated key exchange）協(xié)議的最早例子——加密密鑰交換協(xié)議（EKE, encrypted key exchange）[3]，此協(xié)議實現了雙向認證，可以在用戶和服務器之間建立一條安全的認證信道。因此，專家們都在此基礎上進行研究，衍生出許多變化版本[4-5]，但它們都無法抵御惡意服務器和跨站點偽裝。APAKE（asymmetric password-authenticated key exchange）協(xié)議要求只有用戶知道口令，服務器存儲口令的一個單向函數[6-7]，然而，該協(xié)議還是容易受到服務器的字典攻擊以及電腦黑客從服務器竊取信息的影響。Boyen[8]表明任何基于口令的認證協(xié)議（協(xié)議只涉及客戶和服務器雙方）都會受到服務器的字典攻擊。服務器總是會嘗試每一個可能的單一口令，看其是否可以認證成功。Boyen的HPAKE（hardened password authenticated key exchange）協(xié)議[9]讓用戶控制字典攻擊的代價；用戶需選擇一個安全參數τ，在注冊和認證階段執(zhí)行θ（τ）。由此可見，早期的口令認證機制的一個內在限制就是認證協(xié)議只涉及兩方，即客戶端和服務器端。

解決雙方口令認證機制內在限制的一個有效方法就是增加一個信任的移動設備且可由用戶自己攜帶，這樣的設備（如智能卡）[10-12]，可以完全消除對口令認證的需求。但是，文獻[10]不能很好地衡量多個在線服務；文獻[11]只將離線字典猜測攻擊作為目標，卻忽視了內部攻擊和拒絕服務攻擊的危害；而文獻[12]無法完全抵抗口令猜測攻擊，且需要大量的計算開銷?；诖?，文獻[13-14]提出了結合口令、智能卡和生物特征的三因子認證方案，該方案雖然具有一定的優(yōu)勢，但還是無法解決智能卡帶來的不安全和不方便問題。文獻[15]做出了很大的改進，但是方案的局限性在于需要依賴于服務器的公鑰來完成認證。

早在2004年，文獻[16]提出由手機作為便攜的移動設備。但是在該方案中，還需要增加一個安全可信的代理方，這使得系統(tǒng)部署較為繁瑣；而且手機端和代理方需要進行多次交互，更容易遭受中間人攻擊，因此，該方案無法廣泛地應用于實際認證中。方案[17]在此基礎上，提出了簡易有效的基于指紋與移動端協(xié)助的口令認證方法，但是該方法會受限于手機對指紋的提取技術。

文獻[18-19]提出的方案，都是利用手機掃描二維碼的形式對認證時的秘密信息進行加密或解密操作。但文獻[18]的方案中，用戶需要在設備上添加事先預設的條形碼，當進行多個在線服務時，預設步驟較為繁瑣，而且所需的存儲量較大，因此該方案可操作性不強；文獻[19]的方案中，每個二維碼為某個對象或應用提供了一個唯一標識符來自動檢測系統(tǒng)、貿易、工業(yè)、醫(yī)院等，任何一個帶有視頻采集功能的讀寫器都可以直接從標簽中讀出內容。當條形碼包含私密信息時，就會造成數據私密信息的安全風險。

SPA（single password authentication）[20]方案要求額外增加一個存儲設備（云存儲器或可信的手機設備）來存儲用戶的數據，以此來輔助用戶進行注冊和認證。當存儲設備是云存儲器時，利用 HCR（hidden credential retrieval from a reusable password）[8]協(xié)議的思想，在不可信的云存儲器上存儲認證密文，但其需要設置安全信道，這在實際應用中很難實現。此外，其還需要假設云存儲器和在線服務不能“勾結”，否則會帶來嚴重的安全問題。當存儲設備是可信的手機設備時，強制要求此手機一直是完全可信的，不存在任何惡意代碼侵襲，而且也不能與服務器進行“勾結”，若手機丟失或被偷，則用戶存儲在手機上的密文信息就很有可能被對手破解。這一系列的缺陷大大降低了協(xié)議的可用性和安全性。

PPSS（password-protected secret sharing）[21]是Bagherzandi、Jarecki和 Saxena在 2011年的 CCS（computer and communications security）會議上提出的，允許用戶在多個服務器之間來分配個人數據，以便使用單一且用戶易記的口令來恢復該個人數據，其中任何一個單獨的服務器，甚至某些服務器相互“勾結”（勾結數量必須小于一定的規(guī)模），也無法對口令嵌入離線字典攻擊或獲取到任何關于個人數據的信息。接著，Camenisch、Lysyanskaya和Neven對 PPSS進行改進，在 2012年首次提出 2PASS（two-server password-protected secret sharing）[22]，實現了在2個服務器之間來分配個人數據。但是，這些協(xié)議都是用來在不可信的服務器上存儲用戶個人數據信息，并沒有將其用于在線服務的認證協(xié)議中。此外，它們都需要額外服務器（至少2個）的協(xié)助，給用戶的日常使用和管理造成了很大的不便。

本文提出了一種基于服務器與移動設備間秘密共享的單一口令認證方法（SPASS, single password authentication based on secret sharing between server and mobile device），該方法不需要增加額外的服務器，減少了服務器之間相互識別所耗費的時間和存儲空間，實現了在有便攜式移動設備參與的情況下，僅使用單一口令就可以和多個在線服務進行安全認證，進一步提高了用戶私密信息的安全性。

2 系統(tǒng)模型與敵手模型

2.1 系統(tǒng)模型

SPASS方案中的移動設備包含平板電腦、智能手機等，本文以智能手機作為移動設備為例進行詳細討論。系統(tǒng)架構模型如圖1所示，主要包含個人電腦（PC，personal computer）、云服務器（CS，cloud server）和移動智能手機（MP，mobile smart phone）三部分。圖1中①和②屬于注冊階段，③、④和⑤屬于認證階段。

圖1 系統(tǒng)模型

云服務器（CS）：負責在注冊階段存儲用戶口令、認證密鑰的部分信息；認證階段驗證用戶口令，若正確，向客戶端提供其所存儲的認證密鑰的部分信息，最后完成認證。要求CS能夠接入互聯(lián)網，并具有必要的存儲空間。

個人電腦（PC）：主要負責在注冊階段錄入用戶注冊信息且生成隨機的認證密鑰；認證階段對檢索到的密鑰參數進行運算處理。要求PC可以連接到互聯(lián)網，能夠遠程登錄CS并與其進行通信。

移動智能手機（MP）：注冊階段存儲用戶口令、認證密鑰的另一部分信息；認證階段協(xié)助CS完成對口令的驗證后，為用戶提供其所存儲的認證密鑰的另一部分信息。MP除了具有基本的功能外，還能夠通過Wi-Fi功能連接到CS，以便與CS進行通信，并且也需要一定的存儲空間。

2.2 敵手模型

上述系統(tǒng)模型主要包括3種實體，即云服務器、個人電腦和移動智能手機，僅當實體可信時，系統(tǒng)才會誠實執(zhí)行此協(xié)議。因此，其對應的敵手模型可總結如下。

1）云服務器是半可信的。假設注冊階段的云服務器是可信的，則用戶已經成功完成個人信息注冊。此后，當對手發(fā)起主動攻擊時，云服務器就有可能遭受來自外部對手的重放攻擊或字典攻擊，也可能會遭受系統(tǒng)內部攻擊，即其自身可能是惡意的，只在線下對已存儲的用戶密文信息發(fā)起攻擊。

2）個人電腦是不可信的。當用戶發(fā)起認證請求時，其需要在客戶端PC輸入用戶名和口令，而此時PC也許已經遭受到惡意軟件或病毒的侵襲，敵手會發(fā)起被動攻擊，利用鍵盤記錄器記錄下用戶的口令，從而進一步地獲取用戶私密信息。

3）移動智能手機是不可信的。用戶在注冊階段和認證階段都會用到移動智能手機，而手機可能丟失、被偷或者被惡意軟件侵害，則對手可能獲得存儲在手機上的部分用戶認證信息，從而試圖恢復原始信息并發(fā)起主動攻擊，冒充用戶與服務器進行通信。

3 SPASS方案設計實現

3.1 SPASS方案設計思想

本方案將認證密鑰和口令編碼后產生的隨機串分配在CS和MP，進行認證時，用戶需要從CS和MP檢索到這些隨機串，然后恢復出完整的口令和認證密鑰。這樣，用戶不僅可以與不可信的 MP進行交互，而且不需要在PC存儲任何個人隱私數據，不論MP或CS任何一方遭受攻擊，都不會影響信息的安全。此外，本方案中用戶PC與CS的交互、MP與CS的交互都不需要假設安全信道，也不需要添加額外的服務器。

3.2 SPASS方案詳細設計

假設如下。1）公共參考字符串的泛函數FCRS描述由GGen（1k）生成的一個階為素數q的群G和生成元g，以及由（keyg, enc, dec）產生的公鑰PK，且其對應的私鑰是未知的。2）系統(tǒng)中，已被FCA證實的所有服務器的公鑰是存在的，而且不要求用戶擁有這樣的公鑰。更確切地說，假設參與認證的服務器已經由（keyg2，enc2，dec2）生成了密鑰對（PE，SE）、由（keysig，sig，ver）生成了密鑰對（PS1，SS1），而智能手機只需要通過（keysig, sig, ver）生成密鑰對（PS2，SS2）。此外，已經通過使用（Register,S,（PE，PS1））來調用FCA實現了該服務器公鑰的注冊，使用（register，M，PS2）來調用FCA實現了該智能手機公鑰的注冊。

此外，方案要求參與認證的 CS與 MP在認證階段需要向對方證明其所陳述信息的正確性（本質上，加密是正確的計算）。因此，在方案的描述中，定義 ZK{（w）:predicate（w,y）= 1}來表示可以證明某個關于公共值y和證據值w的描述是正確的。

由于本方案中沒有假設安全信道，消息可能來自任何一方，因此參與方之間發(fā)送給彼此的所有消息都應該加上標簽（reg，sid，qid）或（aut，sid，qid），以及與各自的具體步驟相一致的序號。

注冊階段和認證階段的具體步驟分別描述如下。

1）注冊階段

在這個階段，用戶需要首先輸入（reg，sid，p，K），其中sid=（name，CS，MP），name是用戶選擇的用戶名；p是用戶選擇的口令， MACKeyGen（1k）K→是隨機產生的認證密鑰，假設p和K都已經被編碼為G中的元素；MP和CS的內部永久性存儲分別表示為stMP和stCS。注冊階段的具體協(xié)議如圖2所示。

圖2 注冊階段的具體協(xié)議

步驟1用戶PC執(zhí)行如下計算。

① 詢問FCRS獲得 PK，發(fā)送（authentication，sid，CS）給FCA獲得（PE，PS1）。

步驟2 CS執(zhí)行如下操作。

① 收到來自用戶的消息，解析為（Reg, sid, qid,

② 發(fā)送（authentication，sid，MP）給FCA，獲得PS2。

④ 檢查是否在狀態(tài)中沒有記錄的stCS（sid）。

步驟3MP執(zhí)行如下操作。

① 解析來自CS的消息為（reg，sid，qid，1，σ）。

② 發(fā)送（authentication，sid，CS）給FCA，獲得（PE，PS1）。

④ 檢查是否在狀態(tài)中沒有記錄的stMP（sid）；然后直接輸入p2和K2。

⑤ 計算簽名τ2←sigSS2（sid,qid,C,C,succ） ，發(fā)送給CS。

步驟4CS執(zhí)行如下操作。

① 解析來自MP的消息，檢查是否 v erPS2（（sid,

步驟5用戶PC執(zhí)行如下操作。

解析來自CS的消息，檢查是否 v erPS1（（sid,qid,。如果是，輸出（reg，sid，qid，succ）。

2）認證階段

圖3 認證階段的具體協(xié)議

步驟1用戶PC執(zhí)行如下計算。

步驟2CS執(zhí)行如下操作。

② 向外界輸出（ANot,sid,qid'），等待輸入如果a= d eny，則失敗。

⑤ 產生適合于同態(tài)加密方案的密鑰對（pk,sk）keyg（1k）；選擇

⑦ 向 MP證明E1是正確的。

步驟3MP執(zhí)行如下操作。

③ 解析來自 CS的消息為（Aut,sid,qid',1,pk,；并且與CS相互作用來檢查證據π。驗證1簽名是否滿足

⑥ 向CS證明E是正確的。

步驟4CS執(zhí)行如下操作。

③ 用sk解密E，看結果是否為1。

④ 向 MP證明E解密后結果為 1。π3:=

步驟5MP執(zhí)行如下操作。

① 與CS一起核實證據π3。

② 直接在PC端輸入MP存儲的K2。

步驟6用戶PC執(zhí)行如下操作。

① 解析來自CS的消息，驗證簽名 v erPS1（（sid,解密密文恢復認證密鑰K←K1K2。

② 用認證密鑰K和隨機挑戰(zhàn)chal進行計算，得到認證響應response ← MAC（K,chal）。向CS發(fā)送認證響應response進行認證。

步驟7CS繼續(xù)執(zhí)行如下操作。

計算MAC（K,chal）并與接收到的 response進行對比，一致則接受此次登錄認證，否則拒絕登錄認證。

4 SPASS方案的安全性證明與分析

4.1 SPASS方案安全算法的模塊劃分

SPASS方案包含以下6個算法模塊。

1）userGen模塊：該算法用于生成用戶名name和口令pwd。

2）register模塊：用戶使用這個雙方協(xié)議與CS進行注冊。最終，PC端將隨機產生的認證密鑰K、計算出的密文F以及用戶憑證C、一起發(fā)送給CS，CS存儲該信息狀態(tài)。

3）store模塊：MP存儲PC端產生的數據信息p2和K2，而PC端不需存儲任何信息，用戶只需記?。╪ame，pwd）。

4）preAuth模塊：客戶端PC使用其用戶名name和口令pwd，并借助MP從CS檢索其密文信息′。CS給PC發(fā)送和挑戰(zhàn)信息chal。

5）retrieve模塊：PC客戶端解密上述密文信息得到K1，并從MP中得到K2，此時PC客戶端便可計算恢復出認證密鑰K。

6）authenticate模塊：PC客戶端使用K和chal向 CS證明它有相應的賬戶憑證，CS輸出 accept或者reject。

4.2 安全游戲

在 SPASS 方案中，手機可能會丟失或者被盜，則惡意的對手可能使用用戶存儲在手機上的信息訪問服務器，甚至破解用戶的口令；PC端和服務器端也可能會遭受到對手的攻擊。因此，對 SPASS方案定義 game one和 game two這 2種安全游戲，由于用戶通常只能記住一個簡短的低熵口令，通常根據2個參數定義安全性[18]：k是一個較大的數（80～128）bit，l是一個較小的數（30～40）bit，用m＜＜k來強調值m遠遠小于值k。符號ProbGuess（N）表示對手猜測N次可以猜到用戶口令的概率。ProbGuess（N）表示認證方案的安全性的固有上界。定義neg（k）：若對任意常數c，存在有限的K，對于任意k＞K，都有則 neg（k）是一個可以忽略的函數。

定義1 猜測概率[18]定義Adv是一個基于概率多項式時間（PPT）的對手，擁有用戶在userGen階段選取口令的先驗知識。本文定義

定義 2安全的口令加密[18]若對于任意的PPT對手，adv具有如下概率。

則基于口令的加密方案就可以安全地阻擋隨機消息下的字典攻擊。

game one（蜜罐攻擊） 在此游戲中，對手充當的是惡意的在線服務器，挑戰(zhàn)者扮演的角色是PC端和手機，它們均被認為是可信的；而對手扮演服務器的角色，可以讓PC客戶端使用手機執(zhí)行register、preAuth 和authenticate 階段。若在這場游戲中，對手得到了用戶口令，則對手勝利。

定義3[18]假設PPT對手贏得game one游戲的概率是則 SPASS 方案滿足基于game one的安全性。

game two（外部攻擊） 此游戲中，對手可以扮演 PC客戶端的角色，而挑戰(zhàn)者扮演手機端和N個不同服務器的角色，對手將模擬PC客戶端向每個服務器發(fā)起T次PreAuth和authentication請求。對手還可以扮演手機端的角色（即手機設備被對手偷掉），而挑戰(zhàn)者扮演PC客戶端和N個不同服務器的角色。如果對手可以在authentication階段使服務器信服并輸出accept，即對手在此游戲的過程中猜到了正確的用戶口令，則對手勝利。

定義4[18]假設PPT對手贏得game two游戲的概率是P2，若P2≤ProbGuess（TN+1）+neg（k），則SPASS方案滿足基于game two的安全性。

定義5安全的SPASS方案 若 SPASS方案可以同時滿足基于game one的安全性和基于game two的安全性，則可以認為SPASS方案是安全的。

4.3 SPASS方案的安全性

定理SPASS方案是滿足定義5的安全方案。

證明

對于game one的安全游戲，場景可以還原如下[18]。

對手：即惡意的服務器，先選擇2個口令pwd0和pwd1，則挑戰(zhàn)者將會在該區(qū)域選擇位數b，并設置pwdb作為其口令。

Play：對手與客戶端和手機端通過以下的協(xié)議進行交互。挑戰(zhàn)者保留一個sid，它可以唯一地標識每一次交互。

playRegister：PC客戶端必須與一個由對手選擇的服務器進行注冊。對手產生服務器名并且發(fā)送給挑戰(zhàn)者。然后挑戰(zhàn)者和對手執(zhí)行 register，此時挑戰(zhàn)者扮演的是誠實的PC客戶端并輸入（name，pwd，servername）。resister協(xié)議完成后，挑戰(zhàn)者模擬PC端和手機端之間的存儲協(xié)議，存儲（p2，K2）。

playPreAuth：對手要求PC端運行PreAuth協(xié)議。挑戰(zhàn)者扮演 PC端執(zhí)行 PreAuth協(xié)議，輸入（name，pwd）。PreAuth協(xié)議完成后，挑戰(zhàn)者在它的PreAuth數據庫存儲（name，sid，chal）。

playAuthenticate：對手要求PC端運行authenticate協(xié)議。挑戰(zhàn)者通過PreAuth數據庫查看與name相關的 sid。隨后挑戰(zhàn)者模擬 PC端和手機端之間的retrieve協(xié)議獲得部分認證密鑰K2，挑戰(zhàn)者使用K和對手執(zhí)行authenticate協(xié)議。

output對手輸出一個位數b’，若b=b’，則對手勝利。

由此可見，對手贏得此游戲僅僅需要區(qū)分2個口令。因此，對手猜測到正確口令的概率不可能大于所以可以得出，對手能夠贏得這場游戲的概率故SPASS方案具有基于game one的安全性。

對于game two的安全游戲，場景可以還原如下[37]。

1）對手模擬客戶端 PC，每猜測一個口令pwd’，就向某個服務器發(fā)起一次執(zhí)行 PreAuth和authentication的請求，在每一次的交互階段，對手都可以驗證他猜測的口令是否正確，以便下一次做出更適合的猜測。對于每個服務器i，i∈[1,N]，對手最多可以發(fā)起T次 PreAuth和authentication請求，在該游戲的最終輸出階段，對手還可以多進行一次猜測，即最多進行TN+1次的猜測。因此，對手在該過程中猜測到用戶口令的概率P[對手得到口令]≤ProbGuess（TN+1）。故對手能夠獲贏得這場游戲的概率P2≤ProbGuess（TN+1）+neg（k）。

2）當對手扮演手機端的角色時，在協(xié)議的開始，手機是可靠的。對手不能得到store或retrieve請求的任何結果。在某一時刻，對手也許會損壞存儲設備（手機）。一旦損壞手機，對手就會得到存儲在手機上的所有信息。然而這時，挑戰(zhàn)者會停止與設備的交互（模擬現實世界的場景：用戶的手機一旦被竊取便被停止使用）。更加確切地說，挑戰(zhàn)者不再模擬請求 store或 retrieve，這意味著在register和authentication階段的查詢期間，挑戰(zhàn)者將提前終止。因此，對手幾乎不可能獲得用戶口令，故P2是一個可以忽略的小值。

所以，SPASS方案滿足基于game two的安全性。

綜上所述，SPASS方案滿足基于定義3和定義4的安全性，故SPASS方案是安全的。

證畢。

因此，用戶完全不必擔心手機丟失或遭受惡意軟件侵襲，以及服務器端的蜜罐攻擊和釣魚網站的攻擊，因為只能從手機上竊取部分隨機串，而服務器端也不再直接存儲用戶的口令，或口令的確定函數?？傊魏我环降臏S陷都不會影響用戶私密信息（如口令）的安全。

5 性能分析與評估

本節(jié)主要從時間和存儲方面對本方案的具體實用性進行評估。在時間方面，對SPASS方案的注冊階段和認證階段分別在3種不同場景下進行所耗時間的測試，并對測試結果數據進行展示和對比分析。在存儲方面，主要對SPASS方案具體實現過程中用戶的參與設備，即PC端和手機端的存儲量進行分析評估。

5.1 測試方案與場景

測試SPASS方案的實驗設備為一臺PC、一個云服務器和一個安卓設備，其中的云服務器是租用部署于青島的阿里云服務器，測試方案如圖4所示。租用的云服務器的配置參數如表1所示。

圖4 測試方案總體示意

表1 云服務器參數

客戶端PC的配置參數如表2所示。

表2 客戶端PC參數

安卓設備分為 2類：1）安卓模擬器 Android 4.3.1-API Level 18，CPU ARM（armeabi-v7a），RAM 1024，VM Heap 32，Internal Storage 200 MiB；2）安卓手機，魅族MX4，Flyme OS 4.0，真八核處理器MTK 6595魅族定制版處理器；索尼 Xperia SL（LT26ii），Android 4.1.2，高通驍龍MSM8260雙核1.7 GHz處理器。

SPASS方案的測試程序主要在Eclipse的開發(fā)環(huán)境下由 JAVA語言進行編寫，方案中用到的ElGamal、MAC等的加密算法使用了bouncy castle庫。測試場景如下。

場景 1同一用戶完成方案的注冊階段和認證階段，輸入相同的用戶名和口令，分別測試整個注冊階段和認證階段所需時間。各自測試10組數據，分別計算出用戶在注冊階段和認證階段所耗時間的平均值。

場景 2分析口令熵對本協(xié)議運行時間的影響，因此在注冊階段和認證階段分別選取 10組不同用戶，其設置的口令的長短、復雜度各不相同，最終，分別進行測試評估。

場景1和場景2中使用的安卓設備是安卓模擬器。

場景 3分析不同的安卓設備（安卓模擬器、魅族手機、Sony手機）對方案運行時間的影響。此場景中，用戶分別使用這3種不同的設備完成方案的注冊和認證階段，分別測試其所耗時間。

方案的具體測試中需要的裝備階段：手機端和用戶端已經分別和云服務器端建立認證信道，即它們均可以和服務器端交互認證信息，為了簡化但又不失對協(xié)議性能評估的準確性，該階段的性能不予測試。

因此，具體測試中將注冊階段的總時間TR（單位為ms）分為2個部分：tR1和tR2。如圖5所示，其中tR1是從用戶在PC端輸入用戶名name和口令p開始，到PC端生成p和認證密鑰K的份額p1、p2和K1、K2以及計算出p1、K1的密文F結束時所耗時間；tR2是將用戶的密文發(fā)送至云服務器所耗時間。

圖5 注冊階段流程說明

將認證階段的總時間TA（單位為ms）分為6個部分，分別是tA1、tA2、tA3、tA4、tA5和tA6。如圖6所示，其中tA1+tA2為用戶在PC端產生口令的密文，然后向云服務器端請求對應的認證密鑰密文所耗時間之和；tA3為云服務器端進行加密計算及將密文發(fā)送給安卓設備所耗時間；tA4為安卓設備進行加密計算及將加密結果發(fā)送給云服務器端所耗時間；tA5為云服務器端驗證口令及發(fā)送挑戰(zhàn)和認證密鑰密文所耗時間；tA6為PC端計算出用戶的認證信息并發(fā)送給云服務器所耗時間。

圖6 認證階段流程說明

5.2 測試結果

5.2.1 場景1測試結果

1）注冊階段

此場景下，同一用戶在PC端輸入相同的用戶名和口令進行注冊，重復進行 10次，結果如表 3所示。

表3 場景1注冊階段時間/ms

2）認證階段

用戶想要訪問服務器時，在PC端輸入自己的用戶名和口令，服務器對用戶身份進行驗證。分別測出認證階段的6個部分所耗時間，將結果展示如表4所示。

表4 場景1認證階段時間/ms

5.2.2 場景2測試結果

情況1口令的長度不同

1）注冊階段

選取10組不同的用戶進行測試，用戶在PC端輸入其用戶名和口令進行注冊，其中不同用戶所選口令的長度各不相同（例如，密碼長度從一位增加至10位），測得的10組數據如表5所示。

表5 場景2中的情況1注冊階段時間/ms

2）認證階段

用戶在PC端輸入其已經注冊的相應用戶名和口令，測出當口令長度不同時認證階段的各個部分所耗時間，測出的10組數據展示，如表6所示。

情況2口令復雜度不同

3）注冊階段

在該情況下，選取 10組不同用戶進行測試。這10個用戶分別在PC端輸入其用戶名和口令進行注冊，其中不同用戶的口令的復雜度各不相同（例如數字、大小寫字母以及特殊字符的組合不同），測得的數據如表7所示。

4）認證階段

當用戶需要登錄服務器進行身份認證時，需要在PC端輸入其已注冊的用戶名和口令，測出認證階段的各個組成部分所耗時間，測出對應的 10組數據，如表8所示。

表6 場景2中的情況1認證階段時間/ms

表7 場景2中的情況2注冊階段時間/ms

表8 場景2中的情況2認證階段時間/ms

5.2.3 場景3測試結果

在此場景中，用戶分別使用安卓模擬器、Sony手機和魅族手機來對本協(xié)議的注冊階段和認證階段進行測試。

1）注冊階段

同一用戶在 PC端輸入用戶名和口令進行注冊，對整個注冊階段所耗時間進行測試，如表 9所示。

表9 場景3注冊階段時間/ms

2）認證階段

用戶使用這 3種不同安卓設備分別參與認證時，在PC端輸入自己的用戶名和口令，請求服務器對其身份進行認證，測試此認證階段的各個部分所耗時間，如表10所示。

表10 場景3認證階段時間/ms

5.3 性能分析

根據場景1的注冊階段所測數據結果，如表3所示，可以計算出用戶在PC端完成注冊時所需要的平均時間大約為597.18 ms，如圖7所示。由認證階段所測數據結果，如表4所示，可計算出用戶使用安卓模擬器時，實現服務器對PC用戶身份進行認證時所需要的平均時間為10 439.65 ms，如圖8所示。

圖7 場景1注冊階段實驗數據和平均時間

圖8 場景1認證階段實驗數據和平均時間

由場景 2中情況 1所測得的注冊階段數據結果，如表5所示，可以得出，當不同的用戶輸入長度不同的口令進行注冊時，這個注冊階段所耗費的最長時間與最短時間相差116.79 ms，小于相同口令的差值134.9 ms，故口令的長度對本協(xié)議注冊階段所耗時間影響不大。可畫出長度不同的用戶口令在注冊階段的耗時對比，如圖9所示。

圖9 口令長度不同時注冊階段實驗數據

由場景 2中情況 1所測得的認證階段數據結果，如表6所示，可以計算出當不同用戶輸入其對應的口令進行認證時，所耗費的最長時間與最短時間的差值為 996.92 ms，小于相同口令的差值1 131.17 ms，故口令的長度對本協(xié)議的認證階段總時間的影響不大。圖 10為不同長度的用戶口令在認證階段的耗時對比。

圖10 口令長度不同時認證階段實驗數據

根據場景 2中情況 2的注冊階段所測得的數據，如表7所示，可以得出，當口令的復雜度不同時，所耗費的最長時間和最短時間相差123.53 ms，同樣，小于相同口令的差值134.9 ms，所以說口令的復雜度對本協(xié)議的注冊階段的耗時影響不大。此情況的注冊階段的耗時對比如圖11所示。

圖11 口令復雜度不同時注冊階段實驗數據

根據場景2中情況2的認證階段所測得的數據（如表 8所示）可以得出，當不同用戶輸入其對應的口令認證時，所耗費的最長時間與最短時間的差值是656.07 ms，遠小于相同口令時的差值1 131.17 ms，所以口令的復雜度對認證總耗時影響不大。此情況下，不同用戶在認證階段的耗時對比如圖 12所示。

圖12 口令復雜度不同時認證階段實驗數據

場景 3，即用戶使用不同的安卓設備參與認證，由表 9測得的數據可以看出，3種設備在整個注冊階段的總耗時并沒有太大差異（最多相差32.22 ms），這是因為本方案的注冊階段是在 PC端和服務器之間完成的，安卓設備只是被用來存儲一些用戶數據信息。而由表10所展示的數據結果可以看出，在協(xié)議的認證階段，使用安卓模擬器參與協(xié)議認證所消耗的總時間遠遠大于使用實際手機參與認證所耗費的總時間，而兩者在實際中所耗費的傳輸時間幾乎沒有差別，因此可以得出，這種明顯的時間差距主要是來自安卓設備的計算時間。協(xié)議中使用不同安卓設備參與認證時，注冊階段和認證階段所耗時間對比如圖13所示。

由測試方案可知，安卓設備的計算時間和傳輸時間總計為tA4，但由于安卓模擬器與服務器之間的傳輸時間和實際手機設備與服務器的傳輸時間基本無差別（小于3 ms），所以在安卓設備上的計算時間就可以使用tA4進行對比，用戶在不同的安卓設備上進行計算所耗時間對比如圖14所示。由圖14可以看出，本協(xié)議的認證階段，不同類型的安卓設備的計算耗時中，安卓模擬器的最長，而2個安卓手機（Sony手機和魅族手機）的計算耗時差距不大，產生這種差距的主要原因是安卓模擬器在處理器和設置參數上與安卓手機相比有一定的差距，所以影響了其運行效率。

圖14 不同設備算法運行時間對比

由于已有的 PPSS[21]和 2PASS[22]方案都旨在解決如何在不可信的服務器上安全存儲用戶個人數據信息的問題，并沒有涉及關于用戶和多個在線服務進行的單一口令安全認證。因此，本文的方法僅與已有的mobile SPA[20]進行性能比較。表11給出了已有的mobile SPA[20]方案和本文的SPASS方案在注冊階段個人電腦（PC）與移動智能手機（MP）的主要計算消耗對比，其中，mac為MAC運算，h為散列運算，s為加密/解密運算。已知mobile SPA方案在認證階段的時間消耗是其在云服務器（CS）的計算時間為1 ms、在MP的計算時間為2 ms和傳輸時間為 35 ms的總和，即 38 ms；而本文的SPASS方案在手機上的測量時間都高于38 ms。由此可見，僅在計算消耗方面，本文的方案高于 mobile SPA方案。

表11 計算消耗對比

但是，本文的SPASS方案對認證密鑰和口令進行了編碼、隨機取串、簽名運算以及零知識證明等，大大提高了方案的安全可靠性，在實際的使用過程中能夠明顯體現出來。表12給出了mobile SPA方案與本文提出的 SPASS方案部分簡單常見的安全指標對比。

表12 安全指標對比

在存儲方面，PC端不需要存儲任何信息，因此用戶可以使用不同的客戶端電腦來訪問其賬戶。而用戶需要通過對不同的服務器使用不同的認證密鑰K來防止該服務器模仿自身登錄訪問其他服務器，因此，移動設備的存儲量應該和服務器的數量是線性關系。一個MAC密鑰是128 B，一個內存為1MB的移動設備就可以存儲8 192個服務器的認證信息。因此，可使用當前標準的移動設備實現線性存儲。

綜上所述，本文提出的方案在時間性能方面雖然沒有什么明顯的優(yōu)勢，尤其是認證階段耗時略長，但是在存儲及安全方面卻有很大的提高。

6 結束語

當用戶使用單一口令和多個在線服務進行認證時，為了保障口令的安全性和用戶身份認證方法的完善性，本文提出了SPASS方案利用手機輔助用戶認證，其中PC端不存儲用戶的任何認證信息，且認證信息并非單一地存儲于手機端，而是在手機端和服務器端共享。此外，經過一系列的計算，手機端和服務器端存儲的認證信息均為隨機串，即使任何一方遭受攻擊，攻擊者也只可能恢復部分認證信息，而無法獲得完整的認證信息。經過嚴格的安全性證明和實驗測試，結果表明，SPASS方案雖然在時間效率上沒有太大的優(yōu)勢，但是具有較高的安全性能，可以在遠程用戶僅使用單一口令和多個在線服務進行認證時，保護用戶口令不會受到字典攻擊、蜜罐攻擊等威脅，即使在成功的中間人攻擊下，也可以保護用戶固定且長期的口令，具有很高的應用價值。