基于移动端协助的远程用户单一口令认证方法
1
2
3
Single password authentication method for remote user based on mobile terminal assistance
1
2
3
通讯作者:
修回日期: 2018-09-23 网络出版日期: 2019-02-25
基金资助: |
|
Revised: 2018-09-23 Online: 2019-02-25
Fund supported: |
|
作者简介 About authors
徐渊(1991-),女,陕西西安人,西安财经大学助理实验师,主要研究方向为云计算、网络安全 。
杨超(1979-),男,陕西西安人,博士,西安电子科技大学教授、博士生导师,主要研究方向为密码学、信息和网络安全 。
杨力(1977-),男,陕西西安人,博士,西安电子科技大学教授、博士生导师,主要研究方向为移动互联网安全、云计算安全和可信计算技术 。
针对口令认证系统中用户频繁重复使用同一弱口令的问题,提出一种基于服务器与便携移动设备间秘密共享的单一口令认证方法,允许远程用户使用单一口令和多个在线服务进行安全认证,且客户端PC无需存储用户的任何秘密信息;即使移动设备丢失或被盗,也不会损害用户信息。安全性分析与性能测试结果表明,新方法大大提高了用户私密信息的安全性,可以抵御字典攻击、蜜罐攻击、跨站点编程攻击及网络钓鱼攻击,减轻用户记忆负担,缓解存储压力,易于部署。
关键词:
To address the issue that users frequently reuse their weak passwords in password-based authentication system,single password authentication based on secret sharing between server and mobile terminal (SPASS) was proposed,which allows a remote user to use a single password to authenticate to multiple services securely and has no need to store any secret of the user in the client PC.Even when the mobile device is lost or stolen,no damage to the user’s information will be induced.Security analysis and performance test show that SPASS greatly improves the security of the user’s secret information and resists dictionary attacks,honeypot attacks,cross-site scripting attacks etc.Furthermore,the proposed scheme can lighten burden of the user’s memory,reduce the storage pressure and easy to be deployed.
Keywords:
本文引用格式
徐渊, 杨超, 杨力.
XU Yuan.
1 引言
随着互联网的迅速发展和应用系统的不断增加,使用口令认证机制来判断远程用户的身份已经变得最为常见。用户仅需使用其预先设置的口令与各种服务器进行认证,认证成功后便可获得应用服务。
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]让用户控制字典攻击的代价;用户需选择一个安全参数 τ,在注册和认证阶段执行θ(τ)。由此可见,早期的口令认证机制的一个内在限制就是认证协议只涉及两方,即客户端和服务器端。
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是用户选择的口令,K→MACKeyGen(1k)是随机产生的认证密钥,假设p和K都已经被编码为G中的元素;MP和CS的内部永久性存储分别表示为stMP和stCS。注册阶段的具体协议如图2所示。
图2
步骤1 用户PC执行如下计算。
① 询问 FCRS获得 PK,发送(authentication,sid,CS)给FCA获得(PE,PS1)。
② 选择 p1← GR 和K1← GR,计算
③ 选择随机数
在服务器的公钥下加密,即
④ 发送
步骤2 CS执行如下操作。
① 收到来自用户的消息,解析为(Reg,sid,qid,1,F,C,
② 发送(authentication,sid,MP)给FCA,获得PS2。
③ 用标签
④ 检查是否在状态中没有记录的stCS (sid)。
⑤ 计算签名
步骤3 MP执行如下操作。
① 解析来自CS的消息为(reg,sid,qid,1,σ)。
② 发送(authentication,sid,CS)给FCA,获得(PE,PS1)。
③ 检查是否
④ 检查是否在状态中没有记录的stMP(sid);然后直接输入p2和K2。
⑤ 计算签名
⑥ 更新状态
步骤4 CS执行如下操作。
① 解析来自MP的消息,检查是否
② 计算
③ 更新状态
步骤5 用户PC执行如下操作。
解析来自CS的消息,检查是否
2) 认证阶段
此时,用户输入(aut,sid,qid’,p’),MP和CS将它们各自的状态信息 stMP和 stCS(sid)作为输入。其中考虑安全因素,用户此时输入的口令可能正确,也可能不正确,因此,将其记为p’。认证阶段的具体协议如图3所示。
图3
步骤1 用户PC执行如下计算。
① 询问FCRS获得PK,发送(authentication,sid,CS)给FCA获得(PE,PS1)。
② 选择p1'← GR ,计算
③ 选择随机数s'← R Zq,在CRS下加密p'1,即C'←encPK(p1';s');在服务器的公钥下加密,即
④ 发送密文(F’,C’,PKu) 给CS。
步骤2 CS执行如下操作。
① 解析来自用户的消息为(aut,sid,qid’,1, F’,C’,PKu)。如果不存在状态信息st CS(sid),则失败;否则恢复~ ~
② 向外界输出(ANot,sid,qid'),等待输入(Perm,sid,qid',a),其中 a {allow,deny}∈ ,如果a=deny,则失败。
③ 用标签(sid,qid’,C’,PKu)解密F,如果标签错误,则失败。
④ 检查是否
⑤ 产生适合于同态加密方案的密钥对(pk,sk) keyg(1k);选择r1← R Zq,计算
⑥ 计算签名
⑦ 向 MP 证明 E1是正确的。
步骤3 MP执行如下操作。
① 输入(Aut,sid,qid',p')2 ,如果不存在状态信息stMP(sid),则失败;否则恢复
② 向外界输出(ANot,sid,qid'),等待输入(Perm,sid,qid',a),其中a {allow,deny}∈ 。如果a=deny,则失败。
③ 解析来自 CS 的消息为(Aut,sid,qid',1,pk,E1,σ '1);并且与CS相互作用来检查证据π1。验证签名是否满足
④ 选择随机数r2,z← R Zq,计算
⑤ 计算
⑥ 向CS证明E是正确的。
步骤4 CS执行如下操作。
① 将来自MP的消息解析为(E,σ'2),且和MP相互作用核实证据π2。
② 验证签名是否满足
③ 用sk解密E,看结果是否为1。
④ 向 MP 证明 E 解密后结果为 1。π3 :=ZK{(sk):1=decsk(E)}。
⑤ 选择随机数
步骤5 MP执行如下操作。
① 与CS一起核实证据π3。
② 直接在PC端输入MP存储的K2。
步骤6 用户PC执行如下操作。
① 解析来自CS的消息,验证签名
② 用认证密钥K和随机挑战chal进行计算,得到认证响应response←MAC(K,chal)。向CS发送认证响应response进行认证。
步骤7 CS继续执行如下操作。
计算MAC(K,chal)并与接收到的 response 进行对比,一致则接受此次登录认证,否则拒绝登录认证。
4 SPASS方案的安全性证明与分析
4.1 SPASS方案安全算法的模块划分
SPASS方案包含以下6个算法模块。
1) userGen模块:该算法用于生成用户名name和口令pwd。
2) register模块:用户使用这个双方协议与CS进行注册。最终,PC端将随机产生的认证密钥K、计算出的密文 F 以及用户凭证 C、
3) store模块:MP存储PC端产生的数据信息p2和K2,而PC端不需存储任何信息,用户只需记住(name,pwd)。
4) preAuth模块:客户端PC使用其用户名name和口令pwd,并借助MP从CS检索其密文信息
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)<k-c,则neg(k)是一个可以忽略的函数。
定义1 猜测概率[18]定义Adv是一个基于概率多项式时间(PPT)的对手,拥有用户在userGen阶段选取口令的先验知识。本文定义
由于 pwd 的选择不需要服从均匀分布,所以
定义 2 安全的口令加密[18]若对于任意的PPT对手,adv具有如下概率。
则基于口令的加密方案就可以安全地阻挡随机消息下的字典攻击。
game one(蜜罐攻击) 在此游戏中,对手充当的是恶意的在线服务器,挑战者扮演的角色是PC端和手机,它们均被认为是可信的;而对手扮演服务器的角色,可以让PC客户端使用手机执行register、preAuth 和authenticate 阶段。若在这场游戏中,对手得到了用户口令,则对手胜利。
定义3[18]假设PPT对手赢得game one游戏的概率是P1,若
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个口令。因此,对手猜测到正确口令的概率不可能大于
对于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 测试方案与场景
图4
客户端PC的配置参数如表2所示。
安卓设备分为 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种不同的设备完成方案的注册和认证阶段,分别测试其所耗时间。
方案的具体测试中需要的装备阶段:手机端和用户端已经分别和云服务器端建立认证信道,即它们均可以和服务器端交互认证信息,为了简化但又不失对协议性能评估的准确性,该阶段的性能不予测试。
因此,具体测试中将注册阶段的总时间T(R 单位为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
次数 | tR1 | tR2 | 总时间TR |
1 | 554.04 | 11.83 | 565.87 |
2 | 562.12 | 12.04 | 574.16 |
3 | 589.61 | 12.26 | 601.87 |
4 | 597.05 | 11.92 | 608.97 |
5 | 688.92 | 11.85 | 700.77 |
6 | 566.47 | 11.62 | 578.08 |
7 | 565.16 | 11.68 | 576.84 |
8 | 600.3 | 11.65 | 611.95 |
9 | 566.57 | 11.78 | 578.35 |
10 | 563.02 | 11.91 | 574.93 |
2) 认证阶段
用户想要访问服务器时,在 PC 端输入自己的用户名和口令,服务器对用户身份进行验证。分别测出认证阶段的6个部分所耗时间,将结果展示如表4所示。
5.2.2 场景2测试结果
情况1 口令的长度不同
1) 注册阶段
选取10组不同的用户进行测试,用户在PC端输入其用户名和口令进行注册,其中不同用户所选口令的长度各不相同(例如,密码长度从一位增加至10位),测得的10组数据如表5所示。
表4 场景1认证阶段时间/ms
次数 | tA1 | tA2 | tA3 | tA4 | tA5 | tA6 | 总时间TA |
1 | 634.95 | 12.16 | 3 852.79 | 2 685.00 | 3 020.25 | 551.69 | 10 756.84 |
2 | 588.71 | 12.12 | 3 088.24 | 2 451.40 | 3 008.86 | 537.88 | 9 687.21 |
3 | 693.18 | 12.13 | 3 462.55 | 2 693.89 | 2 968.58 | 542.65 | 10 372.98 |
4 | 603.26 | 11.90 | 3 762.82 | 2 729.93 | 2 958.64 | 568.11 | 10 634.66 |
5 | 666.91 | 11.71 | 3 490.51 | 2 743.85 | 2 938.28 | 581.18 | 10 432.44 |
6 | 588.29 | 11.72 | 3 472.58 | 2 701.08 | 2 943.11 | 567.73 | 10 284.51 |
7 | 586.82 | 11.81 | 3 976.51 | 2 492.83 | 2 964.37 | 565.19 | 10 597.53 |
8 | 696.74 | 11.88 | 3 415.59 | 3 150.62 | 2 929.69 | 574.21 | 10 778.73 |
9 | 705.49 | 13.57 | 3 787.21 | 2 816.02 | 2 916.69 | 579.40 | 10 818.38 |
10 | 667.10 | 11.78 | 3 217.01 | 2 690.37 | 2 895.12 | 551.87 | 10 033.25 |
表5 场景2中的情况1注册阶段时间/ms
用户 | tR1 | tR2 | 总时间TR |
user1 | 593.71 | 11.32 | 605.03 |
user2 | 660.72 | 11.43 | 672.15 |
user3 | 555.57 | 11.91 | 567.48 |
user4 | 633.15 | 11.41 | 644.56 |
user5 | 574.02 | 12.16 | 586.18 |
user6 | 571.38 | 11.66 | 583.04 |
user7 | 672.64 | 11.63 | 684.27 |
user8 | 564.88 | 11.52 | 576.40 |
user9 | 600.78 | 11.44 | 612.22 |
user10 | 563.25 | 11.39 | 574.93 |
2) 认证阶段
用户在 PC 端输入其已经注册的相应用户名和口令,测出当口令长度不同时认证阶段的各个部分所耗时间,测出的10组数据展示,如表6所示。
情况2 口令复杂度不同
3) 注册阶段
在该情况下,选取 10 组不同用户进行测试。这10个用户分别在PC端输入其用户名和口令进行注册,其中不同用户的口令的复杂度各不相同(例如数字、大小写字母以及特殊字符的组合不同),测得的数据如表7所示。
4) 认证阶段
当用户需要登录服务器进行身份认证时,需要在 PC 端输入其已注册的用户名和口令,测出认证阶段的各个组成部分所耗时间,测出对应的 10 组数据,如表8所示。
表6 场景2中的情况1认证阶段时间/ms
用户 | tA1 | tA2 | tA3 | tA4 | tA5 | tA6 | 总时间TA |
user1 | 706.66 | 11.18 | 3 870.38 | 2 476.76 | 2 896.26 | 620.59 | 10581.83 |
user2 | 656.90 | 11.67 | 3 021.22 | 2 516.65 | 2 972.40 | 540.37 | 9719.21 |
user3 | 590.32 | 11.40 | 3 942.38 | 2 667.09 | 2 940.90 | 564.04 | 10716.13 |
user4 | 636.21 | 11.50 | 3 436.28 | 2 472.99 | 2 917.59 | 563.28 | 10037.85 |
user5 | 661.22 | 11.52 | 3 441.83 | 2 480.50 | 2 936.19 | 548.34 | 10079.60 |
user6 | 696.98 | 11.67 | 3 155.77 | 2 690.94 | 2 919.25 | 545.47 | 10020.08 |
user7 | 583.52 | 11.43 | 3 485.63 | 2 716.33 | 2 896.02 | 561.31 | 10254.24 |
user8 | 580.69 | 12.01 | 3 730.85 | 2 517.52 | 2 949.34 | 561.96 | 10352.37 |
user9 | 591.99 | 11.73 | 3 333.63 | 2 476.16 | 2 992.37 | 551.10 | 9956.98 |
user10 | 696.74 | 11.47 | 3 313.86 | 2 507.97 | 2 933.24 | 548.51 | 10011.79 |
表7 场景2中的情况2注册阶段时间/ms
用户 | tR1 | tR2 | 总时间TR |
user1 | 576.09 | 11.99 | 588.08 |
user2 | 677.24 | 11.78 | 689.02 |
user3 | 553.82 | 11.67 | 565.49 |
user4 | 577.40 | 12.14 | 589.54 |
user5 | 561.34 | 11.67 | 573.01 |
user6 | 600.80 | 11.78 | 612.58 |
user7 | 659.23 | 12.15 | 671.38 |
user8 | 638.52 | 11.69 | 650.21 |
user9 | 578.69 | 11.68 | 590.37 |
user10 | 556.91 | 12.04 | 568.95 |
5.2.3 场景3测试结果
在此场景中,用户分别使用安卓模拟器、Sony手机和魅族手机来对本协议的注册阶段和认证阶段进行测试。
表8 场景2中的情况2认证阶段时间/ms
次数 | tA1 | tA2 | tA3 | tA4 | tA5 | tA6 | 总时间TA |
user1 | 674.89 | 11.56 | 3 589.07 | 2 487.21 | 2 682.28 | 539.95 | 10 291.97 |
user2 | 652.75 | 11.64 | 3 538.29 | 2 702.91 | 3 001.16 | 627.43 | 10 534.18 |
user3 | 598.73 | 11.67 | 3 730.33 | 2 710.31 | 3 160.28 | 524.04 | 10 735.36 |
user4 | 597.75 | 11.60 | 3 389.03 | 2 670.76 | 2 921.73 | 532.14 | 10 123.01 |
user5 | 602.49 | 11.78 | 3 558.93 | 2 792.32 | 3 042.90 | 543.13 | 10 551.55 |
user6 | 679.08 | 12.04 | 3 584.63 | 2 780.92 | 2 851.92 | 583.65 | 10 492.24 |
user7 | 705.12 | 11.57 | 3 401.68 | 2 665.76 | 2 845.77 | 550.11 | 10 180.01 |
user8 | 602.14 | 11.81 | 3 769.10 | 2 786.24 | 2 858.46 | 562.39 | 10 590.14 |
user9 | 627.65 | 12.54 | 3 329.07 | 2 664.68 | 2 886.40 | 558.95 | 10 079.29 |
user10 | 611.41 | 11.89 | 3 564.91 | 2 682.28 | 2 844.04 | 529.52 | 10 244.05 |
1) 注册阶段
同一用户在 PC 端输入用户名和口令进行注册,对整个注册阶段所耗时间进行测试,如表9所示。
表9 场景3注册阶段时间/ms
设备 | tR1 | tR2 | 总时间TR |
安卓模拟器 | 555.89 | 11.71 | 567.60 |
Sony | 564.45 | 11.59 | 576.04 |
魅族 | 532.69 | 11.69 | 544.38 |
2) 认证阶段
用户使用这 3 种不同安卓设备分别参与认证时,在 PC 端输入自己的用户名和口令,请求服务器对其身份进行认证,测试此认证阶段的各个部分所耗时间,如表10所示。
表10 场景3认证阶段时间/ms
设备 | tA1 | tA2 | tA3 | tA4 | tA5 | tA6 | 总时间TA |
安卓模拟器 | 655.94 | 12.14 | 3 746.96 | 2697.21 | 2 886.60 | 603.58 | 10 602.43 |
Sony | 631.69 | 11.53 | 3 737.36 | 174.27 | 2 911.79 | 598.03 | 8 064.67 |
魅族 | 627.51 | 11.68 | 3 758.87 | 152.76 | 2 919.66 | 574.56 | 8 045.04 |
5.3 性能分析
图7
图8
图9
图10
图11
图12
图13
图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方案。
但是,本文的SPASS方案对认证密钥和口令进行了编码、随机取串、签名运算以及零知识证明等,大大提高了方案的安全可靠性,在实际的使用过程中能够明显体现出来。表12给出了mobile SPA方案与本文提出的 SPASS 方案部分简单常见的安全指标对比。
在存储方面,PC 端不需要存储任何信息,因此用户可以使用不同的客户端电脑来访问其账户。而用户需要通过对不同的服务器使用不同的认证密钥K来防止该服务器模仿自身登录访问其他服务器,因此,移动设备的存储量应该和服务器的数量是线性关系。一个MAC密钥是128 B,一个内存为1MB的移动设备就可以存储8 192个服务器的认证信息。因此,可使用当前标准的移动设备实现线性存储。
综上所述,本文提出的方案在时间性能方面虽然没有什么明显的优势,尤其是认证阶段耗时略长,但是在存储及安全方面却有很大的提高。
6 结束语
当用户使用单一口令和多个在线服务进行认证时,为了保障口令的安全性和用户身份认证方法的完善性,本文提出了SPASS方案利用手机辅助用户认证,其中PC端不存储用户的任何认证信息,且认证信息并非单一地存储于手机端,而是在手机端和服务器端共享。此外,经过一系列的计算,手机端和服务器端存储的认证信息均为随机串,即使任何一方遭受攻击,攻击者也只可能恢复部分认证信息,而无法获得完整的认证信息。经过严格的安全性证明和实验测试,结果表明,SPASS 方案虽然在时间效率上没有太大的优势,但是具有较高的安全性能,可以在远程用户仅使用单一口令和多个在线服务进行认证时,保护用户口令不会受到字典攻击、蜜罐攻击等威胁,即使在成功的中间人攻击下,也可以保护用户固定且长期的口令,具有很高的应用价值。
参考文献
A large-scale study of Web password habits
[C]//
In:2004,Mark Zuckerberg broke into a facebook user’s private email account
[EB]. ,
Encrypted key exchange:password-based protocols secure against dictionary attack
[C]//
The secure remote password protocol
[C]//
Augmented encrypted key exchange:a password-based protocol secure against dictionary attacks and password file compromise
[C]//
A method for making password-based key exchange resilient to server compromise
[C]//
Hidden credential retrieval from a reusable password
[C]//
Hpake:password authentication secure against cross-site user impersonation
[C]//
Cryptanalysis and improvement of efficient password-based user authentication scheme using hash function
[C]//
Secure and efficient smart card based remote user password authentication scheme
[J]. ,
An improved password authentication scheme for smart card
[C]//
A password authentication method for remote users based on smart card and biometrics
[J]. ,
A novel and efficient session spanning biometric and password based three-factor authentication protocol for consumer USB Mass Storage Devices
[J]. ,
基于生物特征和口令的双因子认证与密钥协商协议
[J]. ,
Two-factor authenticated key agreement protocol based on biometric feature and password
[J].
一种新的基于指纹与移动端协助的口令认证方法
[J]. ,
A new password authentication method based on fingerprint and mobile phone assistance
[J].
Seeing-is-believe:using camera phones for human-verifiable authentication
[C]//
QR-TAN:secure mobile transaction authentication
[C]//
Single password authentication
[J]. ,
Password-protected secret sharing
[C]//
Practical yet universally composable two-server password-authenticated secret sharing
[C]//
/
〈 | 〉 |