基于移动端协助的远程用户单一口令认证方法

徐渊，杨超，杨力

（1. 西安财经大学实验实训教学管理中心，陕西 西安 710100；2.西安电子科技大学信息网络技术中心，陕西 西安 710071；3.西安电子科技大学网络与信息安全学院，陕西 西安 710071）

1 引言

随着互联网的迅速发展和应用系统的不断增加，使用口令认证机制来判断远程用户的身份已经变得最为常见。用户仅需使用其预先设置的口令与各种服务器进行认证，认证成功后便可获得应用服务。

然而，用户往往会设置简单易记的口令，且频繁使用。研究发现[1]一般用户会在3个月内登录25个不同的在线服务，但却只有7个口令，若其中之一泄露，将会威胁其他账户信息的安全。当用户忘记某个欲登陆的在线服务的口令时，会逐一尝试自己的口令，直到认证成功。如果该服务器是恶意的，它除了获得此服务的口令外，还会得到用户的其他口令，可能会对用户的其他账户发起跨站点的伪装攻击。即使服务器是所谓的可信服务器，也可能会对用户发起同样的攻击。Facebook的CEO曾在2004年使用 Facebook的登录数据访问一些商业对手和记者的私人邮件[2]。

1992年，Bellovin和Merritt在Diffie-Hellman密钥交换协议的基础上，提出了口令认证密钥交换（PAKE, password-authenticated key exchange）协议的最早例子——加密密钥交换协议（EKE, encrypted key exchange）[3]，此协议实现了双向认证，可以在用户和服务器之间建立一条安全的认证信道。因此，专家们都在此基础上进行研究，衍生出许多变化版本[4-5]，但它们都无法抵御恶意服务器和跨站点伪装。APAKE（asymmetric password-authenticated key exchange）协议要求只有用户知道口令，服务器存储口令的一个单向函数[6-7]，然而，该协议还是容易受到服务器的字典攻击以及电脑黑客从服务器窃取信息的影响。Boyen[8]表明任何基于口令的认证协议（协议只涉及客户和服务器双方）都会受到服务器的字典攻击。服务器总是会尝试每一个可能的单一口令，看其是否可以认证成功。Boyen的HPAKE（hardened password authenticated key exchange）协议[9]让用户控制字典攻击的代价；用户需选择一个安全参数τ，在注册和认证阶段执行θ（τ）。由此可见，早期的口令认证机制的一个内在限制就是认证协议只涉及两方，即客户端和服务器端。

解决双方口令认证机制内在限制的一个有效方法就是增加一个信任的移动设备且可由用户自己携带，这样的设备（如智能卡）[10-12]，可以完全消除对口令认证的需求。但是，文献[10]不能很好地衡量多个在线服务；文献[11]只将离线字典猜测攻击作为目标，却忽视了内部攻击和拒绝服务攻击的危害；而文献[12]无法完全抵抗口令猜测攻击，且需要大量的计算开销。基于此，文献[13-14]提出了结合口令、智能卡和生物特征的三因子认证方案，该方案虽然具有一定的优势，但还是无法解决智能卡带来的不安全和不方便问题。文献[15]做出了很大的改进，但是方案的局限性在于需要依赖于服务器的公钥来完成认证。

早在2004年，文献[16]提出由手机作为便携的移动设备。但是在该方案中，还需要增加一个安全可信的代理方，这使得系统部署较为繁琐；而且手机端和代理方需要进行多次交互，更容易遭受中间人攻击，因此，该方案无法广泛地应用于实际认证中。方案[17]在此基础上，提出了简易有效的基于指纹与移动端协助的口令认证方法，但是该方法会受限于手机对指纹的提取技术。

文献[18-19]提出的方案，都是利用手机扫描二维码的形式对认证时的秘密信息进行加密或解密操作。但文献[18]的方案中，用户需要在设备上添加事先预设的条形码，当进行多个在线服务时，预设步骤较为繁琐，而且所需的存储量较大，因此该方案可操作性不强；文献[19]的方案中，每个二维码为某个对象或应用提供了一个唯一标识符来自动检测系统、贸易、工业、医院等，任何一个带有视频采集功能的读写器都可以直接从标签中读出内容。当条形码包含私密信息时，就会造成数据私密信息的安全风险。

SPA（single password authentication）[20]方案要求额外增加一个存储设备（云存储器或可信的手机设备）来存储用户的数据，以此来辅助用户进行注册和认证。当存储设备是云存储器时，利用 HCR（hidden credential retrieval from a reusable password）[8]协议的思想，在不可信的云存储器上存储认证密文，但其需要设置安全信道，这在实际应用中很难实现。此外，其还需要假设云存储器和在线服务不能“勾结”，否则会带来严重的安全问题。当存储设备是可信的手机设备时，强制要求此手机一直是完全可信的，不存在任何恶意代码侵袭，而且也不能与服务器进行“勾结”，若手机丢失或被偷，则用户存储在手机上的密文信息就很有可能被对手破解。这一系列的缺陷大大降低了协议的可用性和安全性。

PPSS（password-protected secret sharing）[21]是Bagherzandi、Jarecki和 Saxena在 2011年的 CCS（computer and communications security）会议上提出的，允许用户在多个服务器之间来分配个人数据，以便使用单一且用户易记的口令来恢复该个人数据，其中任何一个单独的服务器，甚至某些服务器相互“勾结”（勾结数量必须小于一定的规模），也无法对口令嵌入离线字典攻击或获取到任何关于个人数据的信息。接着，Camenisch、Lysyanskaya和Neven对 PPSS进行改进，在 2012年首次提出 2PASS（two-server password-protected secret sharing）[22]，实现了在2个服务器之间来分配个人数据。但是，这些协议都是用来在不可信的服务器上存储用户个人数据信息，并没有将其用于在线服务的认证协议中。此外，它们都需要额外服务器（至少2个）的协助，给用户的日常使用和管理造成了很大的不便。

本文提出了一种基于服务器与移动设备间秘密共享的单一口令认证方法（SPASS, single password authentication based on secret sharing between server and mobile device），该方法不需要增加额外的服务器，减少了服务器之间相互识别所耗费的时间和存储空间，实现了在有便携式移动设备参与的情况下，仅使用单一口令就可以和多个在线服务进行安全认证，进一步提高了用户私密信息的安全性。

2 系统模型与敌手模型

2.1 系统模型

SPASS方案中的移动设备包含平板电脑、智能手机等，本文以智能手机作为移动设备为例进行详细讨论。系统架构模型如图1所示，主要包含个人电脑（PC，personal computer）、云服务器（CS，cloud server）和移动智能手机（MP，mobile smart phone）三部分。图1中①和②属于注册阶段，③、④和⑤属于认证阶段。

图1 系统模型

云服务器（CS）：负责在注册阶段存储用户口令、认证密钥的部分信息；认证阶段验证用户口令，若正确，向客户端提供其所存储的认证密钥的部分信息，最后完成认证。要求CS能够接入互联网，并具有必要的存储空间。

个人电脑（PC）：主要负责在注册阶段录入用户注册信息且生成随机的认证密钥；认证阶段对检索到的密钥参数进行运算处理。要求PC可以连接到互联网，能够远程登录CS并与其进行通信。

移动智能手机（MP）：注册阶段存储用户口令、认证密钥的另一部分信息；认证阶段协助CS完成对口令的验证后，为用户提供其所存储的认证密钥的另一部分信息。MP除了具有基本的功能外，还能够通过Wi-Fi功能连接到CS，以便与CS进行通信，并且也需要一定的存储空间。

2.2 敌手模型

上述系统模型主要包括3种实体，即云服务器、个人电脑和移动智能手机，仅当实体可信时，系统才会诚实执行此协议。因此，其对应的敌手模型可总结如下。

1）云服务器是半可信的。假设注册阶段的云服务器是可信的，则用户已经成功完成个人信息注册。此后，当对手发起主动攻击时，云服务器就有可能遭受来自外部对手的重放攻击或字典攻击，也可能会遭受系统内部攻击，即其自身可能是恶意的，只在线下对已存储的用户密文信息发起攻击。

2）个人电脑是不可信的。当用户发起认证请求时，其需要在客户端PC输入用户名和口令，而此时PC也许已经遭受到恶意软件或病毒的侵袭，敌手会发起被动攻击，利用键盘记录器记录下用户的口令，从而进一步地获取用户私密信息。

3）移动智能手机是不可信的。用户在注册阶段和认证阶段都会用到移动智能手机，而手机可能丢失、被偷或者被恶意软件侵害，则对手可能获得存储在手机上的部分用户认证信息，从而试图恢复原始信息并发起主动攻击，冒充用户与服务器进行通信。

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）系统中，已被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的描述是正确的。

由于本方案中没有假设安全信道，消息可能来自任何一方，因此参与方之间发送给彼此的所有消息都应该加上标签（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。注册阶段的具体协议如图2所示。

图2 注册阶段的具体协议

步骤1用户PC执行如下计算。

① 询问FCRS获得 PK，发送（authentication，sid，CS）给FCA获得（PE，PS1）。

步骤2 CS执行如下操作。

① 收到来自用户的消息，解析为（Reg, sid, qid,

② 发送（authentication，sid，MP）给FCA，获得PS2。

④ 检查是否在状态中没有记录的stCS（sid）。

步骤3MP执行如下操作。

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

② 发送（authentication，sid，CS）给FCA，获得（PE，PS1）。

④ 检查是否在状态中没有记录的stMP（sid）；然后直接输入p2和K2。

⑤ 计算签名τ2←sigSS2（sid,qid,C,C,succ） ，发送给CS。

步骤4CS执行如下操作。

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

步骤5用户PC执行如下操作。

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

2）认证阶段

图3 认证阶段的具体协议

步骤1用户PC执行如下计算。

步骤2CS执行如下操作。

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

⑤ 产生适合于同态加密方案的密钥对（pk,sk）keyg（1k）；选择

⑦ 向 MP证明E1是正确的。

步骤3MP执行如下操作。

③ 解析来自 CS的消息为（Aut,sid,qid',1,pk,；并且与CS相互作用来检查证据π。验证1签名是否满足

⑥ 向CS证明E是正确的。

步骤4CS执行如下操作。

③ 用sk解密E，看结果是否为1。

④ 向 MP证明E解密后结果为 1。π3:=

步骤5MP执行如下操作。

① 与CS一起核实证据π3。

② 直接在PC端输入MP存储的K2。

步骤6用户PC执行如下操作。

① 解析来自CS的消息，验证签名 v erPS1（（sid,解密密文恢复认证密钥K←K1K2。

② 用认证密钥K和随机挑战chal进行计算，得到认证响应response ← MAC（K,chal）。向CS发送认证响应response进行认证。

步骤7CS继续执行如下操作。

计算MAC（K,chal）并与接收到的 response进行对比，一致则接受此次登录认证，否则拒绝登录认证。

4 SPASS方案的安全性证明与分析

4.1 SPASS方案安全算法的模块划分

SPASS方案包含以下6个算法模块。

1）userGen模块：该算法用于生成用户名name和口令pwd。

2）register模块：用户使用这个双方协议与CS进行注册。最终，PC端将随机产生的认证密钥K、计算出的密文F以及用户凭证C、一起发送给CS，CS存储该信息状态。

3）store模块：MP存储PC端产生的数据信息p2和K2，而PC端不需存储任何信息，用户只需记住（name，pwd）。

4）preAuth模块：客户端PC使用其用户名name和口令pwd，并借助MP从CS检索其密文信息′。CS给PC发送和挑战信息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（蜜罐攻击） 在此游戏中，对手充当的是恶意的在线服务器，挑战者扮演的角色是PC端和手机，它们均被认为是可信的；而对手扮演服务器的角色，可以让PC客户端使用手机执行register、preAuth 和authenticate 阶段。若在这场游戏中，对手得到了用户口令，则对手胜利。

定义3[18]假设PPT对手赢得game one游戏的概率是则 SPASS 方案满足基于game one的安全性。

game two（外部攻击） 此游戏中，对手可以扮演 PC客户端的角色，而挑战者扮演手机端和N个不同服务器的角色，对手将模拟PC客户端向每个服务器发起T次PreAuth和authentication请求。对手还可以扮演手机端的角色（即手机设备被对手偷掉），而挑战者扮演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，则挑战者将会在该区域选择位数b，并设置pwdb作为其口令。

Play：对手与客户端和手机端通过以下的协议进行交互。挑战者保留一个sid，它可以唯一地标识每一次交互。

playRegister：PC客户端必须与一个由对手选择的服务器进行注册。对手产生服务器名并且发送给挑战者。然后挑战者和对手执行 register，此时挑战者扮演的是诚实的PC客户端并输入（name，pwd，servername）。resister协议完成后，挑战者模拟PC端和手机端之间的存储协议，存储（p2，K2）。

playPreAuth：对手要求PC端运行PreAuth协议。挑战者扮演 PC端执行 PreAuth协议，输入（name，pwd）。PreAuth协议完成后，挑战者在它的PreAuth数据库存储（name，sid，chal）。

playAuthenticate：对手要求PC端运行authenticate协议。挑战者通过PreAuth数据库查看与name相关的 sid。随后挑战者模拟 PC端和手机端之间的retrieve协议获得部分认证密钥K2，挑战者使用K和对手执行authenticate协议。

output对手输出一个位数b’，若b=b’，则对手胜利。

由此可见，对手赢得此游戏仅仅需要区分2个口令。因此，对手猜测到正确口令的概率不可能大于所以可以得出，对手能够赢得这场游戏的概率故SPASS方案具有基于game one的安全性。

对于game two的安全游戏，场景可以还原如下[37]。

1）对手模拟客户端 PC，每猜测一个口令pwd’，就向某个服务器发起一次执行 PreAuth和authentication的请求，在每一次的交互阶段，对手都可以验证他猜测的口令是否正确，以便下一次做出更适合的猜测。对于每个服务器i，i∈[1,N]，对手最多可以发起T次 PreAuth和authentication请求，在该游戏的最终输出阶段，对手还可以多进行一次猜测，即最多进行TN+1次的猜测。因此，对手在该过程中猜测到用户口令的概率P[对手得到口令]≤ProbGuess（TN+1）。故对手能够获赢得这场游戏的概率P2≤ProbGuess（TN+1）+neg（k）。

2）当对手扮演手机端的角色时，在协议的开始，手机是可靠的。对手不能得到store或retrieve请求的任何结果。在某一时刻，对手也许会损坏存储设备（手机）。一旦损坏手机，对手就会得到存储在手机上的所有信息。然而这时，挑战者会停止与设备的交互（模拟现实世界的场景：用户的手机一旦被窃取便被停止使用）。更加确切地说，挑战者不再模拟请求 store或 retrieve，这意味着在register和authentication阶段的查询期间，挑战者将提前终止。因此，对手几乎不可能获得用户口令，故P2是一个可以忽略的小值。

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

综上所述，SPASS方案满足基于定义3和定义4的安全性，故SPASS方案是安全的。

证毕。

因此，用户完全不必担心手机丢失或遭受恶意软件侵袭，以及服务器端的蜜罐攻击和钓鱼网站的攻击，因为只能从手机上窃取部分随机串，而服务器端也不再直接存储用户的口令，或口令的确定函数。总之，任何一方的沦陷都不会影响用户私密信息（如口令）的安全。

5 性能分析与评估

本节主要从时间和存储方面对本方案的具体实用性进行评估。在时间方面，对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的开发环境下由 JAVA语言进行编写，方案中用到的ElGamal、MAC等的加密算法使用了bouncy castle库。测试场景如下。

场景 1同一用户完成方案的注册阶段和认证阶段，输入相同的用户名和口令，分别测试整个注册阶段和认证阶段所需时间。各自测试10组数据，分别计算出用户在注册阶段和认证阶段所耗时间的平均值。

场景 2分析口令熵对本协议运行时间的影响，因此在注册阶段和认证阶段分别选取 10组不同用户，其设置的口令的长短、复杂度各不相同，最终，分别进行测试评估。

场景1和场景2中使用的安卓设备是安卓模拟器。

场景 3分析不同的安卓设备（安卓模拟器、魅族手机、Sony手机）对方案运行时间的影响。此场景中，用户分别使用这3种不同的设备完成方案的注册和认证阶段，分别测试其所耗时间。

方案的具体测试中需要的装备阶段：手机端和用户端已经分别和云服务器端建立认证信道，即它们均可以和服务器端交互认证信息，为了简化但又不失对协议性能评估的准确性，该阶段的性能不予测试。

因此，具体测试中将注册阶段的总时间TR（单位为ms）分为2个部分：tR1和tR2。如图5所示，其中tR1是从用户在PC端输入用户名name和口令p开始，到PC端生成p和认证密钥K的份额p1、p2和K1、K2以及计算出p1、K1的密文F结束时所耗时间；tR2是将用户的密文发送至云服务器所耗时间。

图5 注册阶段流程说明

将认证阶段的总时间TA（单位为ms）分为6个部分，分别是tA1、tA2、tA3、tA4、tA5和tA6。如图6所示，其中tA1+tA2为用户在PC端产生口令的密文，然后向云服务器端请求对应的认证密钥密文所耗时间之和；tA3为云服务器端进行加密计算及将密文发送给安卓设备所耗时间；tA4为安卓设备进行加密计算及将加密结果发送给云服务器端所耗时间；tA5为云服务器端验证口令及发送挑战和认证密钥密文所耗时间；tA6为PC端计算出用户的认证信息并发送给云服务器所耗时间。

图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手机和魅族手机来对本协议的注册阶段和认证阶段进行测试。

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，故口令的长度对本协议注册阶段所耗时间影响不大。可画出长度不同的用户口令在注册阶段的耗时对比，如图9所示。

图9 口令长度不同时注册阶段实验数据

由场景 2中情况 1所测得的认证阶段数据结果，如表6所示，可以计算出当不同用户输入其对应的口令进行认证时，所耗费的最长时间与最短时间的差值为 996.92 ms，小于相同口令的差值1 131.17 ms，故口令的长度对本协议的认证阶段总时间的影响不大。图 10为不同长度的用户口令在认证阶段的耗时对比。

图10 口令长度不同时认证阶段实验数据

根据场景 2中情况 2的注册阶段所测得的数据，如表7所示，可以得出，当口令的复杂度不同时，所耗费的最长时间和最短时间相差123.53 ms，同样，小于相同口令的差值134.9 ms，所以说口令的复杂度对本协议的注册阶段的耗时影响不大。此情况的注册阶段的耗时对比如图11所示。

图11 口令复杂度不同时注册阶段实验数据

根据场景2中情况2的认证阶段所测得的数据（如表 8所示）可以得出，当不同用户输入其对应的口令认证时，所耗费的最长时间与最短时间的差值是656.07 ms，远小于相同口令时的差值1 131.17 ms，所以口令的复杂度对认证总耗时影响不大。此情况下，不同用户在认证阶段的耗时对比如图 12所示。

图12 口令复杂度不同时认证阶段实验数据

场景 3，即用户使用不同的安卓设备参与认证，由表 9测得的数据可以看出，3种设备在整个注册阶段的总耗时并没有太大差异（最多相差32.22 ms），这是因为本方案的注册阶段是在 PC端和服务器之间完成的，安卓设备只是被用来存储一些用户数据信息。而由表10所展示的数据结果可以看出，在协议的认证阶段，使用安卓模拟器参与协议认证所消耗的总时间远远大于使用实际手机参与认证所耗费的总时间，而两者在实际中所耗费的传输时间几乎没有差别，因此可以得出，这种明显的时间差距主要是来自安卓设备的计算时间。协议中使用不同安卓设备参与认证时，注册阶段和认证阶段所耗时间对比如图13所示。

由测试方案可知，安卓设备的计算时间和传输时间总计为tA4，但由于安卓模拟器与服务器之间的传输时间和实际手机设备与服务器的传输时间基本无差别（小于3 ms），所以在安卓设备上的计算时间就可以使用tA4进行对比，用户在不同的安卓设备上进行计算所耗时间对比如图14所示。由图14可以看出，本协议的认证阶段，不同类型的安卓设备的计算耗时中，安卓模拟器的最长，而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个服务器的认证信息。因此，可使用当前标准的移动设备实现线性存储。

综上所述，本文提出的方案在时间性能方面虽然没有什么明显的优势，尤其是认证阶段耗时略长，但是在存储及安全方面却有很大的提高。

6 结束语

当用户使用单一口令和多个在线服务进行认证时，为了保障口令的安全性和用户身份认证方法的完善性，本文提出了SPASS方案利用手机辅助用户认证，其中PC端不存储用户的任何认证信息，且认证信息并非单一地存储于手机端，而是在手机端和服务器端共享。此外，经过一系列的计算，手机端和服务器端存储的认证信息均为随机串，即使任何一方遭受攻击，攻击者也只可能恢复部分认证信息，而无法获得完整的认证信息。经过严格的安全性证明和实验测试，结果表明，SPASS方案虽然在时间效率上没有太大的优势，但是具有较高的安全性能，可以在远程用户仅使用单一口令和多个在线服务进行认证时，保护用户口令不会受到字典攻击、蜜罐攻击等威胁，即使在成功的中间人攻击下，也可以保护用户固定且长期的口令，具有很高的应用价值。