徐淵，楊超，楊力

（1. 西安財(cái)經(jīng)大學(xué)實(shí)驗(yàn)實(shí)訓(xùn)教學(xué)管理中心，陜西 西安 710100；2.西安電子科技大學(xué)信息網(wǎng)絡(luò)技術(shù)中心，陜西 西安 710071；3.西安電子科技大學(xué)網(wǎng)絡(luò)與信息安全學(xué)院，陜西 西安 710071）

1 引言

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

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

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

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

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

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

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

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

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

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

2.1 系統(tǒng)模型

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

圖1 系統(tǒng)模型

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

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

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

2.2 敵手模型

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

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

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

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

3 SPASS方案設(shè)計(jì)實(shí)現(xiàn)

3.1 SPASS方案設(shè)計(jì)思想

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

3.2 SPASS方案詳細(xì)設(shè)計(jì)

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

此外，方案要求參與認(rèn)證的 CS與 MP在認(rèn)證階段需要向?qū)Ψ阶C明其所陳述信息的正確性（本質(zhì)上，加密是正確的計(jì)算）。因此，在方案的描述中，定義 ZK{（w）:predicate（w,y）= 1}來表示可以證明某個(gè)關(guān)于公共值y和證據(jù)值w的描述是正確的。

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

注冊階段和認(rèn)證階段的具體步驟分別描述如下。

1）注冊階段

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

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

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

① 詢問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。

⑤ 計(jì)算簽名τ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）認(rèn)證階段

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

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

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

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

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

⑦ 向 MP證明E1是正確的。

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

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

⑥ 向CS證明E是正確的。

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

③ 用sk解密E，看結(jié)果是否為1。

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

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

① 與CS一起核實(shí)證據(jù)π3。

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

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

① 解析來自CS的消息，驗(yàn)證簽名 v erPS1（（sid,解密密文恢復(fù)認(rèn)證密鑰K←K1K2。

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

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

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

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

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

SPASS方案包含以下6個(gè)算法模塊。

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

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

3）store模塊：MP存儲PC端產(chǎn)生的數(shù)據(jù)信息p2和K2，而PC端不需存儲任何信息，用戶只需記住（name，pwd）。

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

5）retrieve模塊：PC客戶端解密上述密文信息得到K1，并從MP中得到K2，此時(shí)PC客戶端便可計(jì)算恢復(fù)出認(rèn)證密鑰K。

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

4.2 安全游戲

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

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

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

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

game one（蜜罐攻擊） 在此游戲中，對手充當(dāng)?shù)氖菒阂獾脑诰€服務(wù)器，挑戰(zhàn)者扮演的角色是PC端和手機(jī)，它們均被認(rèn)為是可信的；而對手扮演服務(wù)器的角色，可以讓PC客戶端使用手機(jī)執(zhí)行register、preAuth 和authenticate 階段。若在這場游戲中，對手得到了用戶口令，則對手勝利。

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

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

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

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

4.3 SPASS方案的安全性

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

證明

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

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

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

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

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

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

output對手輸出一個(gè)位數(shù)b’，若b=b’，則對手勝利。

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

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

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

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

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

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

證畢。

因此，用戶完全不必?fù)?dān)心手機(jī)丟失或遭受惡意軟件侵襲，以及服務(wù)器端的蜜罐攻擊和釣魚網(wǎng)站的攻擊，因?yàn)橹荒軓氖謾C(jī)上竊取部分隨機(jī)串，而服務(wù)器端也不再直接存儲用戶的口令，或口令的確定函數(shù)?？傊?，任何一方的淪陷都不會影響用戶私密信息（如口令）的安全。

5 性能分析與評估

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

5.1 測試方案與場景

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

圖4 測試方案總體示意

表1 云服務(wù)器參數(shù)

客戶端PC的配置參數(shù)如表2所示。

表2 客戶端PC參數(shù)

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

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

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

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

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

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

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

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

圖5 注冊階段流程說明

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

圖6 認(rèn)證階段流程說明

5.2 測試結(jié)果

5.2.1 場景1測試結(jié)果

1）注冊階段

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

表3 場景1注冊階段時(shí)間/ms

2）認(rèn)證階段

用戶想要訪問服務(wù)器時(shí)，在PC端輸入自己的用戶名和口令，服務(wù)器對用戶身份進(jìn)行驗(yàn)證。分別測出認(rèn)證階段的6個(gè)部分所耗時(shí)間，將結(jié)果展示如表4所示。

表4 場景1認(rèn)證階段時(shí)間/ms

5.2.2 場景2測試結(jié)果

情況1口令的長度不同

1）注冊階段

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

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

2）認(rèn)證階段

用戶在PC端輸入其已經(jīng)注冊的相應(yīng)用戶名和口令，測出當(dāng)口令長度不同時(shí)認(rèn)證階段的各個(gè)部分所耗時(shí)間，測出的10組數(shù)據(jù)展示，如表6所示。

情況2口令復(fù)雜度不同

3）注冊階段

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

4）認(rèn)證階段

當(dāng)用戶需要登錄服務(wù)器進(jìn)行身份認(rèn)證時(shí)，需要在PC端輸入其已注冊的用戶名和口令，測出認(rèn)證階段的各個(gè)組成部分所耗時(shí)間，測出對應(yīng)的 10組數(shù)據(jù)，如表8所示。

表6 場景2中的情況1認(rèn)證階段時(shí)間/ms

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

表8 場景2中的情況2認(rèn)證階段時(shí)間/ms

5.2.3 場景3測試結(jié)果

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

1）注冊階段

同一用戶在 PC端輸入用戶名和口令進(jìn)行注冊，對整個(gè)注冊階段所耗時(shí)間進(jìn)行測試，如表 9所示。

表9 場景3注冊階段時(shí)間/ms

2）認(rèn)證階段

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

表10 場景3認(rèn)證階段時(shí)間/ms

5.3 性能分析

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

圖7 場景1注冊階段實(shí)驗(yàn)數(shù)據(jù)和平均時(shí)間

圖8 場景1認(rèn)證階段實(shí)驗(yàn)數(shù)據(jù)和平均時(shí)間

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

圖9 口令長度不同時(shí)注冊階段實(shí)驗(yàn)數(shù)據(jù)

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

圖10 口令長度不同時(shí)認(rèn)證階段實(shí)驗(yàn)數(shù)據(jù)

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

圖11 口令復(fù)雜度不同時(shí)注冊階段實(shí)驗(yàn)數(shù)據(jù)

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

圖12 口令復(fù)雜度不同時(shí)認(rèn)證階段實(shí)驗(yàn)數(shù)據(jù)

場景 3，即用戶使用不同的安卓設(shè)備參與認(rèn)證，由表 9測得的數(shù)據(jù)可以看出，3種設(shè)備在整個(gè)注冊階段的總耗時(shí)并沒有太大差異（最多相差32.22 ms），這是因?yàn)楸痉桨傅淖噪A段是在 PC端和服務(wù)器之間完成的，安卓設(shè)備只是被用來存儲一些用戶數(shù)據(jù)信息。而由表10所展示的數(shù)據(jù)結(jié)果可以看出，在協(xié)議的認(rèn)證階段，使用安卓模擬器參與協(xié)議認(rèn)證所消耗的總時(shí)間遠(yuǎn)遠(yuǎn)大于使用實(shí)際手機(jī)參與認(rèn)證所耗費(fèi)的總時(shí)間，而兩者在實(shí)際中所耗費(fèi)的傳輸時(shí)間幾乎沒有差別，因此可以得出，這種明顯的時(shí)間差距主要是來自安卓設(shè)備的計(jì)算時(shí)間。協(xié)議中使用不同安卓設(shè)備參與認(rèn)證時(shí)，注冊階段和認(rèn)證階段所耗時(shí)間對比如圖13所示。

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

圖14 不同設(shè)備算法運(yùn)行時(shí)間對比

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

表11 計(jì)算消耗對比

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

表12 安全指標(biāo)對比

在存儲方面，PC端不需要存儲任何信息，因此用戶可以使用不同的客戶端電腦來訪問其賬戶。而用戶需要通過對不同的服務(wù)器使用不同的認(rèn)證密鑰K來防止該服務(wù)器模仿自身登錄訪問其他服務(wù)器，因此，移動設(shè)備的存儲量應(yīng)該和服務(wù)器的數(shù)量是線性關(guān)系。一個(gè)MAC密鑰是128 B，一個(gè)內(nèi)存為1MB的移動設(shè)備就可以存儲8 192個(gè)服務(wù)器的認(rèn)證信息。因此，可使用當(dāng)前標(biāo)準(zhǔn)的移動設(shè)備實(shí)現(xiàn)線性存儲。

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

6 結(jié)束語

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