◆孙 永

（中国银行软件中心 北京 100094）

基于口令的强身份鉴别协议

◆孙 永

（中国银行软件中心 北京 100094）

本文围绕身份鉴别分析了Web应用安全现状、存在的问题，介绍了基于口令鉴别协议的发展，提出SRP协议改进方案，实现身份双向鉴别、解决中间人攻击、会话假冒、通信数据保密性、完整性等问题。最后对不依赖PKI和数字证书体系解决交易数据签名和防抵赖进行了初步探讨。

基于口令身份鉴别；SRP协议；双向鉴别；会话假冒；中间人攻击

0 前言

本文讨论的用户只限于桌面浏览器互联网客户端应用的用户，不包括移动应用和内网应用的用户；讨论的焦点是身份鉴别，不关注权限、可用性等其它安全问题。安全控件、动态口令、PKI系统以及内部网络层、系统层等基础设施本身的安全也不在本文讨论范围内。

对互联网应用熟悉的读者可以跳过第二节；对信息安全技术熟悉的读者可以直接跳到第五节开始阅读。

1 银行互联网应用现状

1.1 注册

常见用户注册方式有类，一类是用户自己通过互联网或代理机构注册，设置身份识别和鉴别标识；另一类是其他人代理用户通过联机或批量的方式注册。后者容易出现身份标识和密码泄露、弱密码、用户不知情等风险。

1.2 用户身份鉴别

登录身份鉴别：通过用户登录名、手机号等提供唯一身份标识，通过静态口令、短信、动态口令、数字证书等方式进行身份鉴别，通过限制错误次数、图片验证码等机制防范自动登录攻击。身份鉴别可以由本系统完成，也可以由受信任的第三方系统完成。登录后用随机但固定的会话id作为每次请求的身份鉴别标识。生物识别方式由于设备限制还未大量采用。

加强身份鉴别：对高风险交易，除要求已经登录外还需要提供短信、动态口令、数字证书、其它口令等方式进行加强身份鉴别，一般要求采用与登录不同的双因子鉴别手段。

身份鉴别次数限制：为了防止攻击者通过猜测或字典方式进行暴力攻击，对身份鉴别失败设置次数限制。当连续鉴别失败次数达到设定次数后需要暂时或永久锁死，需等待一定时间或通过其它途径解锁后才能再次身份鉴别。

静态口令策略：为了降低静态口令猜测和泄露风险，对静态口令的长度、复杂性、最长最短有效期、循环历史进行一定的限制。对于柜台设置的弱口令、非本人设置的口令要求首次登录后强制修改。

1.3 服务器身份鉴别

服务器证书识别：通过客户端浏览器与服务器建立SSL/TLS连接，客户端验证由信任的证书颁发机构颁发的服务器证书实现。

用户提示信息：用户登录后显示其昵称、预留欢迎信息、最近登录成功和失败时间等内容，辅助识别钓鱼网站，预防进一步的损失。

1.4 会话管理

会话与用户关系：除了会话ID唯一、不可预测的要求外，还要求登录或退出后更换会话，并且同一用户不能同时维持多个有效会话。

会话失效时间：如果用户长时间没有操作，服务器会使会话失效。有时会增加强制会话失效机制，在用户登录后连续操作的情况下，在一个比较长的固定时间后强制会话失效。

1.5 交易数据安全

数据保密性：客户端在通讯层通过SSL/TLS用128位以上对称算法对数据加密，在DMZ区SSL加速器上解密。口令等关键敏感信息在应用层进行端到端加密传输，加密存储。

数据完整性：一般依赖于SSL/TLS协议本身保护数据完整性。有时采用基于对称加密或散列的完整性保护机制。

2 潜在的问题

服务器假冒：应用层与网络传输层在安全上是分离的，没有有机地结合在一起。一般网络传输层SSL/TLS采用单向认证方式，浏览器只对网站服务器做数字证书认证，网站服务器不验证浏览器端的数字证书。采用双向认证采用硬件载体证书（USBKey）对用户来说操作繁琐，采用文件证书又不够安全。

用户识别假冒网站主要靠：（1）识别URL地址和HTTPS协议，但这一点很容易被用户忽视，通过域名仿冒、DNS劫持、SSL中间人等手段也很容易欺骗用户；（2）登录后检查预留信息等标识，但这时候重要认证信息已经被攻击者获取。

会话假冒：会话层采用简单的会话ID识别会话，与应用层用户身份关联，但与SSL/TLS会话及密钥毫无关联。攻击者可以劫持用户会话，随后可以任意操作交易。原用户无法察觉此问题，两个人可以并行操作，直到一方点击退出按钮。由于SSL/TLS连接与会话建立是分离的，所以此攻击可以实施。

控件问题：银行系统普遍采用SSL加速器在DMZ区做SSL/TLS解密，关键敏感信息仅采用HTTPS不符合端到端加密的安全要求，因此登录口令等信息的输入普遍采用安全控件。安全控件目前还面临浏览器间不兼容、高版本浏览器逐渐禁止使用的困难。对于海外市场，很多国家也禁止安装安全控件。

3 安全期望

3.1 身份识别

因为用户标识的唯一性和注册交易必须提示用户用户名是否已经存在，所以无法完全避免用户名猜测，通过图片验证码仅仅可以减轻程序自动猜测。除非使用USBKEY等随身设备，桌面设备很少采用计算机硬件作为身份标识。

3.2 身份鉴别

身份鉴别方式分为以下三类：

（1）用户是什么（声音识别，视网膜扫描）；

（2）用户有什么（ID卡，动态口令牌）；

（3）用户知道什么（口令，PIN码）。

身份鉴别是应用安全的第一道关，是诸如访问控制、数据保密、抗抵赖、资源控制、安全审计等其它安全防范的前提。但绝大部分的应用都使用了静态口令身份鉴别方法。

动态口令牌是“用户有什么”（令牌）和“用户知道什么”（一次性口令）的结合，一次性口令鉴别的过程与静态口令类似，下面对于口令鉴别的讨论大部分情况下也适用于一次性口令。从密码学的角度看存在相当多的身份鉴别协议，很多理论上的身份认证协议需要一个可信的第三方或一个数字证书体系，这在实际应用中过于复杂，成本很高，不能作为最基本的通用身份认证方案。我们期望最基本的身份鉴别协议要满足以下要求：

（1）不需要依赖于第三方、公钥基础体系、永久存储口令的文件或工具，只需要身份识别符和人类可以记忆的口令即可完成身份鉴别过程。

（2）身份鉴别过程的安全和可靠不依赖于其它层面的安全，只依赖于协议本身。

（3）身份鉴别过程在客户端、服务器双方进行，要达到双方互相鉴别的目的。对服务器的鉴别不能只依赖于用户主动识别服务器证书或预留信息。

（4）身份鉴别过程可以防止窃听、重放攻击，通讯中不暴露口令或其等价物，每次身份鉴别过程通讯内容不一致。

（5）身份鉴别过程可以防止离线字典攻击，攻击者不能利用通讯中传输的内容暴力破解口令。

（6）身份鉴别过程可以防止中间人攻击，攻击者不能成功假冒通讯双方或获取重要信息。

（7）如果攻击者获得服务器端存储的口令验证表，他仍然不能直接获得口令，也不能假冒用户。对于口令验证表的字典攻击只能同时针对一个用户。

（8）身份鉴别过程产生一个会话密钥，用于关键交易数据的加密、解密。

目前常规的静态口令鉴别不能满足上述3、4、5、6、8条，动态口令鉴别不能满足第1、3、4、6、8条。

3.3 数据完整

在交易过程中需要满足以下要求：

（1）客户端提交的数据在传输过程中需要保证数据的完整，被攻击者以伪造、增加、删除、修改方式篡改后能够被服务器发觉。

（2）在服务器端向客户端发送数据过程中需要保证数据的完整，被攻击者以伪造、增加、删除、修改方式篡改后能够被客户端发觉。

如果满足上述要求，必须在客户端和服务器端对交易数据进行计算产生一个指纹，数据被篡改后通过指纹验证能够被发现。攻击者无法伪造指纹，但是攻击者截断通讯时服务器无法得知数据丢失。因为互联网和HTTP协议本身不可靠，发现数据被篡改时不需要自动恢复数据，只需要废弃数据，通讯被截断时也不需要终止会话。

3.4 数据保密

在交易过程中需要满足以下要求：

（1）客户端提交的敏感数据在传输过程中需要加密传输，窃听的攻击者无法解密数据。

（2）在服务器端向客户端发送的敏感数据需要加密传输，窃听的攻击者无法解密数据。

如果严格按照端到端的方式满足上述要求，必须在客户端和服务器端对敏感数据加密。出于性能的考虑，选用对称算法，用身份鉴别过程中产生的会话密钥进行数据加解密。

3.5 抗抵赖

在交易过程中需要满足以下要求：

客户端提交的重要交易数据在传输前在客户端以某种形式签名，除知道口令的客户端外，攻击者和服务器无法仿造此签名。通过此签名和当时的口令可以证明客户端确实发出过交易数据。因为没有第三方可信时间服务器，以服务器时间为准。

因为网络金融应用中客户端不宜记录交易数据，所以基本没有对服务器的抗抵赖要求，通过数据完整性提供的功能，保证数据是由服务器发出的真实完成数据即可。

3.6 防会话假冒

HTTP现有的会话识别方式无法避免会话假冒。为了防止这种攻击，会话过程中需要服务器发送数据时带随机挑战码，客户端每次对服务器发送的挑战码进行某种加密计算，而攻击者无法模仿。因为不是严格的一发一收的串行会话，所以服务器应能够容忍一定的并发会话。如果全部会话数据已经在应用层加密，就已经起到防会话假冒的作用。

4 基于口令鉴别协议的发展

基于口令的身份鉴别只需要用户记住相对简短的口令，不需要依赖设备或软件辅助记录很长的秘密信息（如私钥），出于成本、简单和易用的考虑，口令鉴别是最广范应用的鉴别方法。口令鉴别的基础是客户端知道一个秘密（口令），服务器也知道这个秘密或与这个秘密相关的信息，而攻击者不知道此秘密。从最不安全到最安全，口令鉴别协议发展出以下各种形式：

4.1 简单口令鉴别

最简单的身份鉴别方法是客户和服务器共享一个相同的口令，登录时客户输入用户名和这个口令，服务器验证这个口令是否匹配。这是最不安全也是应用最多的方式，面临窃听、服务器口令表被窃等各种攻击。

4.2 散列口令鉴别

稍好一点的方法是客户不直接发送口令，而是发送口令（加盐）的散列值，服务器端存放（加盐的）口令散列值。这种方式的优点是窃听者不能直接获取口令明文，攻破服务器之后也不能拿到明文口令类表。但是窃听者可以用一个口令字典进行散列计算，与窃听的单一口令或窃取的口令列表比对，从中找到匹配的口令，实现离线字典攻击。加盐的原因是防止攻击者对口令字典进行一次散列计算就可以与所有口令列表进行匹配，加盐后攻击者不得不对每个盐进行全字典散列运算，这往往是不切实际的。更直接的攻击方式是重放攻击，攻击者不需要破解口令，只需要发送记录的散列值就可以假冒客户。

4.3 挑战应答口令鉴别

4.3.1 形式描述

这种形式的具体协议有很多，但都有如下形式：

（1）客户端发送用户名和随机消息给服务器；

（2）服务器发送给客户端一个随机消息，称作挑战（challenge）；

（3）客户端基于挑战、第一个随机消息、口令执行某种计算。将此应答（response）发送给服务器，服务器做同样的计算来验证客户端的应答。

因为服务器的挑战在每次鉴别尝试时都不相同，一个捕获的应答在未来的会话中是无用的，这可以抵御重放攻击。但是攻击者可以从一个成功的鉴别尝试中捕获随机数、挑战、应答，并用离线字典攻击猜测出口令。而且挑战-应答协议是明文等价的，所以一个即获得口令文件又可以窃听的入侵者可以轻易击败它。

4.3.2 实例MS-CHAPv2

MS-CHAPv2[1]协议是微软用于拨号网络认证和VPN登录的协议，是PPP[2]（点对点协议）的CHAP[3]（挑战应答认证协议）的一种实现，在MS-CHAPv1[4]基础上改进而来，MS-CHAPv2在v1基础上增加了相互认证功能。B.Schneier等对MS-CHAPv1的分析[5]发现有严重安全问题，因此微软推出了改进的MS-CHAPv2。但B.Schneier等对MS-CHAPv2的分析[6]发现它仍然易受到L0phtcrack等工具的离线字典猜测攻击，安全依赖于用户选择的口令是否足够复杂；而且对MS-CHAPv1的兼容支持导致版本回退攻击：攻击者可以让客户端和服务器都认为对方只能支持MS-CHAPv1。

4.3.3 EKE协议族

Bellovin和Merritt在1992年提出了加密密钥交换（Encrypted Key Exchange，EKE）[7]协议，使用对称和公钥密码术的结合，而且不依赖可信第三方或PKI体系，抵御离线字典攻击。EKE也执行一个密钥交换，所以一旦鉴别建立之后双方可以加密它们的传输。EKE的最大问题是明文等价，需要客户和主机访问同样的秘密口令或口令散列值。后续还有许多通讯协议如DH-EKE[8]、SPEKE[9]、A-EKE[10]等在EKE基础上增加前向保密、解决明文等价问题，但未能同时解决所有问题。B-SPEKE[11]解决了前向保密、解决明文等价问题，但以牺牲性能为代价。

4.4 AKE框架

4.4.1 AKE介绍

在EKE发展的基础上，出现了称为不对称密钥交换AKE（Asymmetric Key Exchange）的新架构，是一个基于验证码协议的一般化形式。因为验证码和口令设计为不等价的，这强制要求协议的计算结构天生非对称。能够构造安全的基于验证码协议所必须的数学变换的方法屈指可数。EKE类的协议使用预先共享的秘密（口令）作为鉴别基础。这意味着双方维持相同或等价的字符串用于间接鉴别对方。因为拥有这个秘密足以模仿对方，而且这个秘密在双方有被窃的可能，所以双方都有责任安全地交换初始秘密、小心地保护这个秘密。

然而AKE描述了一个“对换秘密”方法，双方计算一个秘密并用单向函数计算产生一个对方也掌握的验证码。虽然保护验证码防止字典攻击仍然很重要，但被窃的验证码不再足以模仿用户，仍然需要对应的秘密口令。这项技术的一个特殊案例是只有一方产生秘密并计算验证码，这在对方是存储许多验证码的多用户系统时看起来非常有用。这种应用中用户的秘密（口令）在初始设置和交换过程中永远不需要离开用户主机；只需要发送验证码。

4.4.2 AKE实例 SRP

满足AKE框架的协议有多个，SRP[12]是没有其中专利、得到较多实际应用的一种，并已经发布了三个IETF RFC文档[13，14，15]。SRP经过分析和改进，SRP-6版本定义如下：

表1 SRP-6数学符号

注册过程：客户端选择选一个随机数盐s，并计算v，将s和v发送到服务器保存，x被丢弃。

鉴别过程：

SRP协议在仅使用口令的情况下可以满足以下安全要求，并产生一个会话密钥：

（1）在身份鉴别过程中没有口令或它相关的信息被泄露，防止攻击者从交换的消息中猜测或证实口令。

（2）在身份鉴别过程中没有关于会话密钥的相关信息被泄露。因为会话密钥是一个强密码的密钥，不需要担心对它的尝试攻击。

（3）即没有用户口令又没有主机口令文件的攻击者无法发动对口令的离线字典攻击。这可以降低对用户口令复杂度的要求，即使弱口令也能在应用系统对在线攻击进行限制的情况下保持较高的安全。

（4）攻击者不能对客户端或服务器成功模仿对方或得到任何关于口令或会话密钥的信息。攻击者最多只能导致鉴别失败。

（5）如果攻击者攻破服务器获得口令文件，它能够能防止攻击者在不经过昂贵的字典搜索的情况下模仿一个客户端。

（6）已经入侵服务器的攻击者不能从合法的鉴别尝试中获得口令。

（7）如果过去的会话密钥被窃，它不能帮助入侵者猜测或推算用户的口令。

（8）如果用户的口令被窃，它不能让入侵者确定过去的会话密钥并解密会话。

5 改进的身份鉴别解决方案

（1）身份鉴别

静态口令简单的一次交互的身份鉴别协议无法满足安全的要求，挑战应答协议和EKE类协议也不够好，使用SRP或类似协议是一个较好的解决方法。因为现有银行网络应用在服务器端已经注册了大量用户，一般也不存放口令明文，因此需要对SRP协议进行适应分析。

SRP需要三次交互，第一次仅是通过用户名获得盐。盐的作用是为了防止攻击者获得服务器口令清单后容易实施字典攻击设置的一个障碍，在用户注册时设置，以后不再变化，对攻击者不需要保密。为了数据兼容性，对已经有盐存储口令的网络应用我们仍然保留这个设计，同时在不降低协议强度的基础上将SRP的三次交互减少为两次交互。采用SRP除完成双方相互认证外还可以产生会话密钥用于加密敏感数据。

表2 身份鉴别

（2）会话识别

为了防止攻击者通过某种方式获得会话ID后模仿登录后的用户，应用必须在应用服务器提供的会话机制之外实现自己的会话识别。会话识别包括服务器识别客户端和客户端识别服务器两部分，因为请求都是由客户端主动发起，所以对服务器识别意义不大。登录握手后双方已经建立会话密钥，以后的交互过程中每次服务器响应时产生服务器端的挑战码，在客户端下次提交或发送请求时对此服务器挑战码进行加密，由服务器进行验证。因为这种交互不完全是串行的，所以服务器需要保留并验证最后几次的挑战码。

上述会话识别机制只能保护登录之后的会话，因此登录之前的交易需要尽可能少暴露重要信息。

（3）注册过程

SRP身份鉴别的前提是双方预先协商口令及其验证码。计算在客户端进行，服务器端只需要保存验证码v：

如果注册过程是在柜台等安全内网，直接传输v没有问题，但在互联网环境下，上述注册过程并不够安全，因此更好的方式为：在注册时使用一个双方已知的秘密（比如电话银行密码、卡密码等）作为鉴别口令通过SRP协议建立安全通道，使用会话密钥K加密v后传输。

（4）修改、重置静态口令过程

无论是登录后修改口令还是登录前重置口令，都需要先验证身份，建立安全通道，使用会话密钥K加密新口令的验证码v后传输。

（5）交易数据机密性

通过SRP建立会话后，双向通讯数据通过会话密钥K加密，加密采用AES、SM4等强对称算法。为了便于传输加密结果使用Base64编码。

（6）交易数据完整性

数据完整性的实现方式有多种，可以对交易数据通过会话密钥K产生的密钥进行HMAC等算法产生一个鉴别码，也可以使用下一节采用的交易签名方式来进行。交易数据要在加密前参加鉴别码运算。

会话密钥在会话结束后不在服务器保存。如果需要事后进行监督、电子证据提取，最好使用交易签名保证数据完整性。

（7）防抵赖

防抵赖是通过对数据签名来完成。普通客户大部分不使用PKI数字证书，所以签名最好由SRP协议握手过程中产生的非对称密钥对完成。

对客户端的防抵赖：数据提交前由安全控件先散列计算，然后用私钥进行计算签名，服务器用公钥进行验证。为了事后进行验签名，服务器需要保留原始数据、数据签名、当时的用户公钥。因为会话中产生的公私钥对仅在一次会话中有效，即使记录下来也不好证明当时的公钥，所以使用和口令相关的私钥x和口令验证码v，服务器需要记录历史口令验证码。可以采用的签名算法有很多，因为SRP协议基于离散对数问题，所以用基于离散对数的签名算法更方便一些。以ElGamal签名算法为例：

签名过程：M=H（message）

选择随机数r，r与n-1互质

计算 c = gr（mod n）

再用扩展 Euclidean 算法对下面方程求解d：

签名就是（c，d），随机数r丢弃。

验证过程：要验证下式：

同时要检验是否满足1＜= c ＜ n。防止签名伪造。

对服务器的防抵赖：因为在Web方式下客户端一般不会记录交易日志，所以基本没有防抵赖的需求。如果将来需要，可以按照上述算法同样处理。

防抵赖算法同时能够完成客户端交易数据完整性的功能。因为其他人没有签名私钥，防抵赖算法也能代替会话识别功能。

（8）实现问题

因为SRP协议相对较新，应用较少，JDK目前不直接提供支持。虽然有一些开源密码项目已经支持SRP协议，在某些Linux系统中得到应用，但仍需要在对此方案进行安全评审，并在评审通过的基础上搭建环境进行代码开发和试验。SRP协议与常见安全规范、安全检查要求中不一致的地方还需要协商解决。

SRP协议不能解决所有的安全问题，客户端需要一个最小的安全条件——浏览器本身的安全。在没有硬件封装、也无法利用可信插件的情况下，基于脚本的客户端SRP协议需要依赖于浏览器的安全。

[1]Zorn,G． Microsoft PPP CHAP Extensions，Version 2．RFC 2759,January ，2000．

[2]Simpson,W．，Editor．The Point-to-Point Protocol（PP P）．STD 51，RFC 1661，Daydreamer，July ，1994．

[3]Simpson,W．PPP Challenge Handshake Authentication P rotocol（CHAP），RFC 1994，August 1996．

[4]Zorn,G．,Cobb,S．Microsoft PPP CHAP Extensions, RFC 2433,October， 1998．

[5]B．Schneier,Mudge．Cryptanalysis of Microsoft's Point-to -Point Tunneling Protocol（PPTP），Proceedings of the 5th ACM Conference on Communications and Computer Securit y，ACM Press，pp．132-141．

[6]B．Schneier,Mudge．Cryptanalysis of Microsoft's PPTP A uthentication Extensions（MS-CHAPv2），CQRE '99，Spring er-Verlag，1999．

[7]S．M．Bellovin,M．Merritt．Encrypted key exchange：Passwo rd-based protocols secure against dictionary attacks．In Proceedi ngs of the 1992 IEEE Computer Society Conference on Rese arch in Security and Privacy，pages 72-84，1992．

[8]M．Steiner，G．Tsudik，and M．Waidner．Refinement and extension of encrypted key exchange．ACM Operating Systems Review，29（3），July 1995．

[9] D．Jablon，Strong Password-Only Authenticated Key E xchange，Computer Communication Review，26（5）：5-26，October， 1996．

[10]S．M．Bellovin and M．Merritt．Augmented encrypted key exchange：A password-based protocol secure against dictionar y attacks and password file compromise．Technical report，AT& T Bell Laboratories，1994．

[11]D．Jablon，Extended Password Key Exchange Protocols I mmune to Dictionary Attacks，IEEE Computer Society．Jun，1997．

[12] T．Wu．Secure remote password protocol．In Network and Distributed System Security Symposium，1998．

[13] T．Wu．Telnet Authentication：SRP．RFC 2944，Septe mber ，2000．

[14] T．Wu．The SRP Authentication and Key Exchange S ystem．RFC 2945，September， 2000．

[15]Taylor,T．Wu,N．Mavrogiannopoulos,T．Perrin．Using the Secure Remote Password（SRP）Protocol for TLS Authentic ation，RFC 5054，November， 2007．