基于SM2和OAuth2.0的强安全身份认证方案

陈艺琳,左黎明,郝 恬,罗娇燕

(华东交通大学 理学院,江西 南昌 330013)

0 引 言

随着互联网技术的发展,各类应用程序对用户身份认证的要求也越来越高。用户身份认证技术是网络信息安全体系中至关重要的一环,“以认证为核心”的零信任架构成为SaaS等网络服务与物联网安全[1]的必要技术。使用token作为身份认证技术在API接口中最为常见,基于此出现了一系列网络通信协议,其中OAuth2.0协议因其协议简单清晰而被广泛应用。然而,由于开发者在部署协议的过程中为了最小代价整合资源,并没有严格遵守协议规定,这就造成了一系列针对OAuth2.0协议的攻击。如淘网址认证登录漏洞(乌云编号wooyun-2012-011104)[2]、由于OAuth 2.0无绑定token问题导致某APP可任意进入他人账号[3](乌云编号:wooyun-2013-017306)、2021年最新微软和GitHub OAuth实施漏洞导致重定向攻击[4]等。不法分子通过身份认证漏洞窃取公民隐私,威胁公民个人信息安全。随着开发者安全意识的提高,客户端应用程序对数据传输协议进行了更加严格的规定。但是在传统的用户名密码登录模式中,一旦用户的用户名和密码遭到泄露,攻击者仍然可以伪造用户身份进行数据访问。即使没有密码,攻击者仍然可以通过密码爆破、字典撞库等方式窃取用户身份,侵犯公民数据隐私[5]。

针对OAuth2.0协议产生的安全问题,国内外学者曾进行过多方面的研究。2014年,S.Pai和Y.Sharma[6]等人针对应用了OAuth2.0协议的Alloy框架进行了分析,并验证其中存在的安全漏洞。CJ Mitchell[7]分析研究了中国基于SSO(Single Sign On)单点登录的OAuth2.0协议,总结出可能存在CSRF漏洞和用户身份绑定缺陷逻辑漏洞。2019年,刘奇旭[8]研究了面向OAuth2.0授权服务API的账号劫持攻击威胁检测,设计并实现了面向OAuth2.0授权服务API的账号劫持攻击威胁检测框架OScan。2021年,陈佳[9]研究了电力系统下微服务架构的安全性,设计了一种基于JWT规范的令牌认证方案,授权机制基于OAuth2.0授权协议扩展实现。

针对OAuth2.0协议的一些安全问题,该文提出了一种基于国密SM2和OAuth2.0强身份认证方案,将认证参数通过数字签名进行保护,实现了对用户身份的安全认证与安全控制访问。有效保证了数据完整性、数据机密性、不可抵赖性、消息新鲜性与来源可靠性。

1 OAuth2.0协议及其攻击

1.1 OAuth2.0协议

OAuth2.0是一个开放的标准,通常拥有四个角色参与认证流程:资源所有者、资源服务器、客户端、授权服务器[10]。其中,资源拥有者为给予受保护资源访问权限的主机或者用户;授权服务器为在对资源拥有者进行身份认证并获得授权后,为客户端提供访问令牌;客户端为通常指代理用户发起受保护资源请求的客户端应用程序;资源服务器为存储受保护资源,接受授权服务器提供的访问令牌的服务器。

在客户端、资源管理器、授权管理器、三方不互信的情况下,OAuth2.0协议允许资源所有者通过授权服务器授权第三方应用程序访问存储在资源服务器上的受保护的信息,而不需要共享密码。常见的授权服务器有国外的Facebook、Google,国内的腾讯、新浪等。OAuth2.0一般情况下有四种模式,即:授权码模式、简化授权模式、密码模式、客户端凭证模式。OAuth2.0协议中四个角色的交互流程如图1所示。

图1 OAuth2.0协议交互流程

其中,授权码模式一般用于带有Server端的应用程序。其认证流程如下:

(1)客户端通过用户代理去授权服务器进行授权,携带客户端标识及重定向URI,response_type值为code;

(2)资源拥有者进行授权;

(3)接收到资源拥有者的确认授权后,授权服务器携带授权码请求客户端的重定向URI,客户端提取授权码,再次向授权服务器请求access_token;

(4)授权服务器返回给客户端access_token;

(5)客户端携带access_token访问资源服务器;

(6)资源服务器向授权服务器验证access_token,并向用户代理响应请求。

1.2 针对基于OAuth2.0认证方案的攻击

OAuth2.0协议在部署时,为了让平台方以最小的代价整合所有资源,协议对许多方面并不做强制要求,这就导致一些平台的开发者在开发过程中由于安全意识薄弱,并没有正确地应用OAuth2.0协议,造成了许多安全问题[11]。OAuth2.0协议中,各个角色所承担的功能不同,于是可以划分出以下几种攻击方式。该文就其中一些典型漏洞做出解释。

(1)针对客户端的攻击。

针对客户端的CSRF(Cross-Site Request Forgery)[12]攻击流程如图2所示。攻击者伪造合法请求,诱导完成了身份授权的受害用户触发该请求,从而达到窃取令牌的目的。漏洞的原因是客户端应用程序错误使用或未使用state参数,该参数值是一个随机字符串,用于维持请求和回调之间的状态。攻击完成的前提是受害者在客户端应用程序完成授权。由于请求都来自客户端应用程序而非资源拥有者,而且授权码是资源拥有者与客户端的唯一标识,授权服务器并不知道授权码来自哪个资源拥有者。

图2 针对OAuth2.0协议客户端的CSRF攻击流程

(2)针对授权服务器的攻击。

redirect_uri被篡改为恶意链接重定向地址redirect_uri,是指授权服务器将授权通过后的响应发送到的重定向URI。若客户端在注册时使用了不严格的重定向地址,或者授权服务器未对重定向地址进行严格校验,就会导致重定向地址被篡改为另外的回调URL,甚至在对重定向地址进行了校验的情况下页可以被绕过。利用这种URL跳转或XSS漏洞,可以获取到相关授权token,危害到目标用户的账号权限。下面进行详细说明。

若客户端在注册时使用了不严格的重定向地址,就可能造成授权服务器在校验时因校验不完整的而绕过。若授权服务器只对重定向地址的根域做了匹配,即只要请求的URI中包含注册的URI就认为是合法请求,那么授权码和state就会因重定向地址篡改而被发送至攻击者构造的恶意地址;获取到授权码之后,攻击者便可以使用受害者的授权码和state伪造身份向客户端发起正常回调请求,客户端校验后向授权服务器发送令牌申请,完成后攻击者便可访问受害者的资源。

1.3 国密SM2数字签名

国密SM2算法是国家密码局于2010年颁布的椭圆曲线公钥密码算法,在政府、银行和关键基础措施系统中得到广泛应用,目前国家对国密算法使用已经有强制性要求[13]。使用SM2算法进行数字签名主要有三个步骤:密钥生成、签名生成和验证签名。国内已有众多将SM2签名算法或其改进算法应用于各类认证方案中的实例[14]。

参数说明和密钥生成见文献[15],签名生成和验证过程如下:

(1)签名生成。

国密SM2数字签名生成算法流程如图3所示。用户A具有长度为entlenA比特的可辨别标识IDA,记ENTLA是由整数entlenA转换而成的两个字节,杂凑值ZA=H256(ENTLA‖IDA‖a‖b‖xG‖yG‖xA‖yA)。

图3 SM2数字签名算法流程

(2)签名验证。

国密SM2数字签名算法的验证流程如图4所示。设接收到的消息M'及其数字签名(r',s'),接收用户用图4所示流程验证数字签名的合法性。

图4 SM2签名验证算法流程

2 强安全方案设计及其关键实现

2.1 强安全方案设计

身份认证一般有三种场景[16],基于桌面应用的客户端模式(C/S)[17]、基于移动端app(APP/S)客户端模式[18]和基于浏览器的客户端模式(B/S)[19]。三种场景下均采用国密SM2算法进行数字签名。三端交互的具体流程如图5所示,其中C为客户端,S1为授权服务器,S2为资源服务器。

图5 C/S、B/S、APP/S下的身份认证流程

(1)C→S1。

首先客户端发送访问申请,若未授权,则授权服务器返回授权页面。

(2)C→S1。

用户确认授权,签名内容

sig1=uid‖client_id‖redirect_uri‖datestate ‖response_type。

(3)S1→C。

授权服务器验证签名,并返回授权码信息签名,签名内容

sig2=code‖uid‖client_id‖state‖date‖redirect_uri。

(4)C→S2。

客户端请求token,签名内容

sig3=code‖uid‖client_id‖state‖date‖grant_type‖ redirect_uri。

(5)S1→C。

授权服务器验证签名,并返回access_token,签名内容

sig4=state‖access_token‖uid‖client_id‖date‖token_type。

(6)C→S2。

客户端使用access_token请求资源服务器。

(7)S2→S1。

资源服务器将access_token发送至授权服务器进行验证。

(8)S1→S2。

授权服务器返回验证结果。

(9)S2→C。

若验证成功,则资源服务器返回客户端请求的受保护资源。

2.2 授权码模式及其实现

授权服务器端统一采用C#开发的ashx一般处理程序进行数据验证;带有Server端的客户端也采用一般处理程序ashx作为redirect_uri客户端重定向地址。在基于桌面应用客户端C/S架构下,使用C#开发WinForm程序,并进行SM2算法的签名和验证。

C#客户端对消息进行签名:

TanSM2 sm2=new TanSM2();

String msg=uid+"#"+time+"#"+state+"#"+

redirect_uri+"#"+client_id+"#"+response_type;

sm2.TanSM2Sign(msg, user_prikey,

out sigtoCA);

服务端进行签名验证:

TanSM2 sm2=new TanSM2();

String msg=uid+"#"+time+"#"+state+"#"+

redirect_uri+"#"+client_id+"#"+response_type;

bool flag = sm2.TanSM2Verify

(msg,pubkey,sig);

第一步,客户端向授权服务器端发送请求签名,数据格式如图6所示。

图6 客户端向授权服务器发送请求数据格式

生成5位随机字符串state,并加入时间戳date。

第二步,授权服务器向客户端重定向地址发送授权码,数据格式如图7所示。服务端获取到json数据后,从中解析出加密后的密文参数,并使用服务端私钥进行解密。解密完成后,从数据库中查找该用户的公钥,并使用用户公钥对客户端发送的明文消息进行签名验证。验证成功后,授权服务器向重定向地址发送授权码code。

图7 授权服务器返回授权码数据格式

第三步,客户端携带授权码向授权服务器请求access_token,请求数据格式如图8所示。重定向地址接收到授权码之后,解密并验证签名。验证通过后携带授权码向授权服务器/token目录请求access_token。

图8 客户端携带授权码申请令牌数据格式

第四步,服务端向客户端返回access_token,返回数据格式如图9所示。服务端验证code后,向客户端返回access_token。

图9 授权服务器返回令牌数据格式

下一步客户端便可以使用access_token访问资源服务器上的受保护资源,资源服务器将请求转发至CA验证access_token的有效性之后便可将受保护资源返回给客户端。

3 安全性分析

3.1 基本分析

(1)数据机密性。

由于在数据传输过程中使用国密SM2签名算法对交互数据进行数字签名,并在授权服务器端进行签名验证,防止了攻击者恶意篡改数据。

(2)数据完整性。

授权服务器端会逐一验证签名中的参数和传递的参数是否一致,攻击者无法删除掉交互过程中的任意参数。

(3)不可抵赖性。

客户端会和用户都拥有自己的唯一私钥,并用客户端和用户的唯一私钥进行签名。授权服务器会使用私钥对应的公钥进行验证,保证了数据的不可抵赖性。

(4)消息新鲜性。

消息的新鲜性可有效抵抗重放攻击。在发送的消息中加入时间戳与随机字符串state,授权服务器根据时间戳来确定消息的新鲜性。

3.2 对比分析

各个应用了OAuth2.0协议平台方案安全性对比分析如表1所示。

表1 安全性对比分析

方案1:微软和GitHub OAuth;

方案2:人人网OAuth 2.0授权;

方案3:百度开放平台OAuth授权接口;

方案4:基于国密SM2的OAuth2.0认证。

从表1中可以看出,方案1、2、3由于存在重定向uri篡改问题,在数据机密性和来源可靠性方面存在安全问题。方案4采用国密SM2算法对信息进行数字签名,有效保证了数据完整性、数据机密性、不可抵赖性、消息新鲜性与来源可靠性。

4 结束语

针对目前OAuth2.0协议中存在的数据来源性问题,提出了一种基于国密SM2的OAuth2.0身份认证方案。方案对可能会被篡改的信息如uid、client_id、state、date 、redirect_uri等进行数字签名,并在授权服务器端进行签名验证。随后针对B/S、C/S、APP/S三种场景下的身份认证进行仿真实验,实验表明该方案具有数据机密性、数据完整性、不可抵赖性、消息新鲜性,且传输效率未降低。