基于SM2和OAuth2.0的強(qiáng)安全身份認(rèn)證方案

陳藝琳,左黎明,郝 恬,羅嬌燕

(華東交通大學(xué) 理學(xué)院,江西 南昌 330013)

0 引 言

隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展,各類應(yīng)用程序?qū)τ脩羯矸菡J(rèn)證的要求也越來越高。用戶身份認(rèn)證技術(shù)是網(wǎng)絡(luò)信息安全體系中至關(guān)重要的一環(huán),“以認(rèn)證為核心”的零信任架構(gòu)成為SaaS等網(wǎng)絡(luò)服務(wù)與物聯(lián)網(wǎng)安全[1]的必要技術(shù)。使用token作為身份認(rèn)證技術(shù)在API接口中最為常見,基于此出現(xiàn)了一系列網(wǎng)絡(luò)通信協(xié)議,其中OAuth2.0協(xié)議因其協(xié)議簡單清晰而被廣泛應(yīng)用。然而,由于開發(fā)者在部署協(xié)議的過程中為了最小代價(jià)整合資源,并沒有嚴(yán)格遵守協(xié)議規(guī)定,這就造成了一系列針對OAuth2.0協(xié)議的攻擊。如淘網(wǎng)址認(rèn)證登錄漏洞(烏云編號wooyun-2012-011104)[2]、由于OAuth 2.0無綁定token問題導(dǎo)致某APP可任意進(jìn)入他人賬號[3](烏云編號:wooyun-2013-017306)、2021年最新微軟和GitHub OAuth實(shí)施漏洞導(dǎo)致重定向攻擊[4]等。不法分子通過身份認(rèn)證漏洞竊取公民隱私,威脅公民個(gè)人信息安全。隨著開發(fā)者安全意識的提高,客戶端應(yīng)用程序?qū)?shù)據(jù)傳輸協(xié)議進(jìn)行了更加嚴(yán)格的規(guī)定。但是在傳統(tǒng)的用戶名密碼登錄模式中,一旦用戶的用戶名和密碼遭到泄露,攻擊者仍然可以偽造用戶身份進(jìn)行數(shù)據(jù)訪問。即使沒有密碼,攻擊者仍然可以通過密碼爆破、字典撞庫等方式竊取用戶身份,侵犯公民數(shù)據(jù)隱私[5]。

針對OAuth2.0協(xié)議產(chǎn)生的安全問題,國內(nèi)外學(xué)者曾進(jìn)行過多方面的研究。2014年,S.Pai和Y.Sharma[6]等人針對應(yīng)用了OAuth2.0協(xié)議的Alloy框架進(jìn)行了分析,并驗(yàn)證其中存在的安全漏洞。CJ Mitchell[7]分析研究了中國基于SSO(Single Sign On)單點(diǎn)登錄的OAuth2.0協(xié)議,總結(jié)出可能存在CSRF漏洞和用戶身份綁定缺陷邏輯漏洞。2019年,劉奇旭[8]研究了面向OAuth2.0授權(quán)服務(wù)API的賬號劫持攻擊威脅檢測,設(shè)計(jì)并實(shí)現(xiàn)了面向OAuth2.0授權(quán)服務(wù)API的賬號劫持攻擊威脅檢測框架OScan。2021年,陳佳[9]研究了電力系統(tǒng)下微服務(wù)架構(gòu)的安全性,設(shè)計(jì)了一種基于JWT規(guī)范的令牌認(rèn)證方案,授權(quán)機(jī)制基于OAuth2.0授權(quán)協(xié)議擴(kuò)展實(shí)現(xiàn)。

針對OAuth2.0協(xié)議的一些安全問題,該文提出了一種基于國密SM2和OAuth2.0強(qiáng)身份認(rèn)證方案,將認(rèn)證參數(shù)通過數(shù)字簽名進(jìn)行保護(hù),實(shí)現(xiàn)了對用戶身份的安全認(rèn)證與安全控制訪問。有效保證了數(shù)據(jù)完整性、數(shù)據(jù)機(jī)密性、不可抵賴性、消息新鮮性與來源可靠性。

1 OAuth2.0協(xié)議及其攻擊

1.1 OAuth2.0協(xié)議

OAuth2.0是一個(gè)開放的標(biāo)準(zhǔn),通常擁有四個(gè)角色參與認(rèn)證流程:資源所有者、資源服務(wù)器、客戶端、授權(quán)服務(wù)器[10]。其中,資源擁有者為給予受保護(hù)資源訪問權(quán)限的主機(jī)或者用戶;授權(quán)服務(wù)器為在對資源擁有者進(jìn)行身份認(rèn)證并獲得授權(quán)后,為客戶端提供訪問令牌;客戶端為通常指代理用戶發(fā)起受保護(hù)資源請求的客戶端應(yīng)用程序;資源服務(wù)器為存儲受保護(hù)資源,接受授權(quán)服務(wù)器提供的訪問令牌的服務(wù)器。

在客戶端、資源管理器、授權(quán)管理器、三方不互信的情況下,OAuth2.0協(xié)議允許資源所有者通過授權(quán)服務(wù)器授權(quán)第三方應(yīng)用程序訪問存儲在資源服務(wù)器上的受保護(hù)的信息,而不需要共享密碼。常見的授權(quán)服務(wù)器有國外的Facebook、Google,國內(nèi)的騰訊、新浪等。OAuth2.0一般情況下有四種模式,即:授權(quán)碼模式、簡化授權(quán)模式、密碼模式、客戶端憑證模式。OAuth2.0協(xié)議中四個(gè)角色的交互流程如圖1所示。

圖1 OAuth2.0協(xié)議交互流程

其中,授權(quán)碼模式一般用于帶有Server端的應(yīng)用程序。其認(rèn)證流程如下:

(1)客戶端通過用戶代理去授權(quán)服務(wù)器進(jìn)行授權(quán),攜帶客戶端標(biāo)識及重定向URI,response_type值為code;

(2)資源擁有者進(jìn)行授權(quán);

(3)接收到資源擁有者的確認(rèn)授權(quán)后,授權(quán)服務(wù)器攜帶授權(quán)碼請求客戶端的重定向URI,客戶端提取授權(quán)碼,再次向授權(quán)服務(wù)器請求access_token;

(4)授權(quán)服務(wù)器返回給客戶端access_token;

(5)客戶端攜帶access_token訪問資源服務(wù)器;

(6)資源服務(wù)器向授權(quán)服務(wù)器驗(yàn)證access_token,并向用戶代理響應(yīng)請求。

1.2 針對基于OAuth2.0認(rèn)證方案的攻擊

OAuth2.0協(xié)議在部署時(shí),為了讓平臺方以最小的代價(jià)整合所有資源,協(xié)議對許多方面并不做強(qiáng)制要求,這就導(dǎo)致一些平臺的開發(fā)者在開發(fā)過程中由于安全意識薄弱,并沒有正確地應(yīng)用OAuth2.0協(xié)議,造成了許多安全問題[11]。OAuth2.0協(xié)議中,各個(gè)角色所承擔(dān)的功能不同,于是可以劃分出以下幾種攻擊方式。該文就其中一些典型漏洞做出解釋。

(1)針對客戶端的攻擊。

針對客戶端的CSRF(Cross-Site Request Forgery)[12]攻擊流程如圖2所示。攻擊者偽造合法請求,誘導(dǎo)完成了身份授權(quán)的受害用戶觸發(fā)該請求,從而達(dá)到竊取令牌的目的。漏洞的原因是客戶端應(yīng)用程序錯誤使用或未使用state參數(shù),該參數(shù)值是一個(gè)隨機(jī)字符串,用于維持請求和回調(diào)之間的狀態(tài)。攻擊完成的前提是受害者在客戶端應(yīng)用程序完成授權(quán)。由于請求都來自客戶端應(yīng)用程序而非資源擁有者,而且授權(quán)碼是資源擁有者與客戶端的唯一標(biāo)識,授權(quán)服務(wù)器并不知道授權(quán)碼來自哪個(gè)資源擁有者。

圖2 針對OAuth2.0協(xié)議客戶端的CSRF攻擊流程

(2)針對授權(quán)服務(wù)器的攻擊。

redirect_uri被篡改為惡意鏈接重定向地址redirect_uri,是指授權(quán)服務(wù)器將授權(quán)通過后的響應(yīng)發(fā)送到的重定向URI。若客戶端在注冊時(shí)使用了不嚴(yán)格的重定向地址,或者授權(quán)服務(wù)器未對重定向地址進(jìn)行嚴(yán)格校驗(yàn),就會導(dǎo)致重定向地址被篡改為另外的回調(diào)URL,甚至在對重定向地址進(jìn)行了校驗(yàn)的情況下頁可以被繞過。利用這種URL跳轉(zhuǎn)或XSS漏洞,可以獲取到相關(guān)授權(quán)token,危害到目標(biāo)用戶的賬號權(quán)限。下面進(jìn)行詳細(xì)說明。

若客戶端在注冊時(shí)使用了不嚴(yán)格的重定向地址,就可能造成授權(quán)服務(wù)器在校驗(yàn)時(shí)因校驗(yàn)不完整的而繞過。若授權(quán)服務(wù)器只對重定向地址的根域做了匹配,即只要請求的URI中包含注冊的URI就認(rèn)為是合法請求,那么授權(quán)碼和state就會因重定向地址篡改而被發(fā)送至攻擊者構(gòu)造的惡意地址;獲取到授權(quán)碼之后,攻擊者便可以使用受害者的授權(quán)碼和state偽造身份向客戶端發(fā)起正常回調(diào)請求,客戶端校驗(yàn)后向授權(quán)服務(wù)器發(fā)送令牌申請,完成后攻擊者便可訪問受害者的資源。

1.3 國密SM2數(shù)字簽名

國密SM2算法是國家密碼局于2010年頒布的橢圓曲線公鑰密碼算法,在政府、銀行和關(guān)鍵基礎(chǔ)措施系統(tǒng)中得到廣泛應(yīng)用,目前國家對國密算法使用已經(jīng)有強(qiáng)制性要求[13]。使用SM2算法進(jìn)行數(shù)字簽名主要有三個(gè)步驟:密鑰生成、簽名生成和驗(yàn)證簽名。國內(nèi)已有眾多將SM2簽名算法或其改進(jìn)算法應(yīng)用于各類認(rèn)證方案中的實(shí)例[14]。

參數(shù)說明和密鑰生成見文獻(xiàn)[15],簽名生成和驗(yàn)證過程如下:

(1)簽名生成。

國密SM2數(shù)字簽名生成算法流程如圖3所示。用戶A具有長度為entlenA比特的可辨別標(biāo)識IDA,記ENTLA是由整數(shù)entlenA轉(zhuǎn)換而成的兩個(gè)字節(jié),雜湊值ZA=H256(ENTLA‖IDA‖a‖b‖xG‖yG‖xA‖yA)。

圖3 SM2數(shù)字簽名算法流程

(2)簽名驗(yàn)證。

國密SM2數(shù)字簽名算法的驗(yàn)證流程如圖4所示。設(shè)接收到的消息M'及其數(shù)字簽名(r',s'),接收用戶用圖4所示流程驗(yàn)證數(shù)字簽名的合法性。

圖4 SM2簽名驗(yàn)證算法流程

2 強(qiáng)安全方案設(shè)計(jì)及其關(guān)鍵實(shí)現(xiàn)

2.1 強(qiáng)安全方案設(shè)計(jì)

身份認(rèn)證一般有三種場景[16],基于桌面應(yīng)用的客戶端模式(C/S)[17]、基于移動端app(APP/S)客戶端模式[18]和基于瀏覽器的客戶端模式(B/S)[19]。三種場景下均采用國密SM2算法進(jìn)行數(shù)字簽名。三端交互的具體流程如圖5所示,其中C為客戶端,S1為授權(quán)服務(wù)器,S2為資源服務(wù)器。

圖5 C/S、B/S、APP/S下的身份認(rèn)證流程

(1)C→S1。

首先客戶端發(fā)送訪問申請,若未授權(quán),則授權(quán)服務(wù)器返回授權(quán)頁面。

(2)C→S1。

用戶確認(rèn)授權(quán),簽名內(nèi)容

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

(3)S1→C。

授權(quán)服務(wù)器驗(yàn)證簽名,并返回授權(quán)碼信息簽名,簽名內(nèi)容

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

(4)C→S2。

客戶端請求token,簽名內(nèi)容

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

(5)S1→C。

授權(quán)服務(wù)器驗(yàn)證簽名,并返回access_token,簽名內(nèi)容

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

(6)C→S2。

客戶端使用access_token請求資源服務(wù)器。

(7)S2→S1。

資源服務(wù)器將access_token發(fā)送至授權(quán)服務(wù)器進(jìn)行驗(yàn)證。

(8)S1→S2。

授權(quán)服務(wù)器返回驗(yàn)證結(jié)果。

(9)S2→C。

若驗(yàn)證成功,則資源服務(wù)器返回客戶端請求的受保護(hù)資源。

2.2 授權(quán)碼模式及其實(shí)現(xiàn)

授權(quán)服務(wù)器端統(tǒng)一采用C#開發(fā)的ashx一般處理程序進(jìn)行數(shù)據(jù)驗(yàn)證;帶有Server端的客戶端也采用一般處理程序ashx作為redirect_uri客戶端重定向地址。在基于桌面應(yīng)用客戶端C/S架構(gòu)下,使用C#開發(fā)WinForm程序,并進(jìn)行SM2算法的簽名和驗(yàn)證。

C#客戶端對消息進(jìn)行簽名:

TanSM2 sm2=new TanSM2();

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

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

sm2.TanSM2Sign(msg, user_prikey,

out sigtoCA);

服務(wù)端進(jìn)行簽名驗(yàn)證:

TanSM2 sm2=new TanSM2();

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

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

bool flag = sm2.TanSM2Verify

(msg,pubkey,sig);

第一步,客戶端向授權(quán)服務(wù)器端發(fā)送請求簽名,數(shù)據(jù)格式如圖6所示。

圖6 客戶端向授權(quán)服務(wù)器發(fā)送請求數(shù)據(jù)格式

生成5位隨機(jī)字符串state,并加入時(shí)間戳date。

第二步,授權(quán)服務(wù)器向客戶端重定向地址發(fā)送授權(quán)碼,數(shù)據(jù)格式如圖7所示。服務(wù)端獲取到j(luò)son數(shù)據(jù)后,從中解析出加密后的密文參數(shù),并使用服務(wù)端私鑰進(jìn)行解密。解密完成后,從數(shù)據(jù)庫中查找該用戶的公鑰,并使用用戶公鑰對客戶端發(fā)送的明文消息進(jìn)行簽名驗(yàn)證。驗(yàn)證成功后,授權(quán)服務(wù)器向重定向地址發(fā)送授權(quán)碼code。

圖7 授權(quán)服務(wù)器返回授權(quán)碼數(shù)據(jù)格式

第三步,客戶端攜帶授權(quán)碼向授權(quán)服務(wù)器請求access_token,請求數(shù)據(jù)格式如圖8所示。重定向地址接收到授權(quán)碼之后,解密并驗(yàn)證簽名。驗(yàn)證通過后攜帶授權(quán)碼向授權(quán)服務(wù)器/token目錄請求access_token。

圖8 客戶端攜帶授權(quán)碼申請令牌數(shù)據(jù)格式

第四步,服務(wù)端向客戶端返回access_token,返回?cái)?shù)據(jù)格式如圖9所示。服務(wù)端驗(yàn)證code后,向客戶端返回access_token。

圖9 授權(quán)服務(wù)器返回令牌數(shù)據(jù)格式

下一步客戶端便可以使用access_token訪問資源服務(wù)器上的受保護(hù)資源,資源服務(wù)器將請求轉(zhuǎn)發(fā)至CA驗(yàn)證access_token的有效性之后便可將受保護(hù)資源返回給客戶端。

3 安全性分析

3.1 基本分析

(1)數(shù)據(jù)機(jī)密性。

由于在數(shù)據(jù)傳輸過程中使用國密SM2簽名算法對交互數(shù)據(jù)進(jìn)行數(shù)字簽名,并在授權(quán)服務(wù)器端進(jìn)行簽名驗(yàn)證,防止了攻擊者惡意篡改數(shù)據(jù)。

(2)數(shù)據(jù)完整性。

授權(quán)服務(wù)器端會逐一驗(yàn)證簽名中的參數(shù)和傳遞的參數(shù)是否一致,攻擊者無法刪除掉交互過程中的任意參數(shù)。

(3)不可抵賴性。

客戶端會和用戶都擁有自己的唯一私鑰,并用客戶端和用戶的唯一私鑰進(jìn)行簽名。授權(quán)服務(wù)器會使用私鑰對應(yīng)的公鑰進(jìn)行驗(yàn)證,保證了數(shù)據(jù)的不可抵賴性。

(4)消息新鮮性。

消息的新鮮性可有效抵抗重放攻擊。在發(fā)送的消息中加入時(shí)間戳與隨機(jī)字符串state,授權(quán)服務(wù)器根據(jù)時(shí)間戳來確定消息的新鮮性。

3.2 對比分析

各個(gè)應(yīng)用了OAuth2.0協(xié)議平臺方案安全性對比分析如表1所示。

表1 安全性對比分析

方案1:微軟和GitHub OAuth;

方案2:人人網(wǎng)OAuth 2.0授權(quán);

方案3:百度開放平臺OAuth授權(quán)接口;

方案4:基于國密SM2的OAuth2.0認(rèn)證。

從表1中可以看出,方案1、2、3由于存在重定向uri篡改問題,在數(shù)據(jù)機(jī)密性和來源可靠性方面存在安全問題。方案4采用國密SM2算法對信息進(jìn)行數(shù)字簽名,有效保證了數(shù)據(jù)完整性、數(shù)據(jù)機(jī)密性、不可抵賴性、消息新鮮性與來源可靠性。

4 結(jié)束語

針對目前OAuth2.0協(xié)議中存在的數(shù)據(jù)來源性問題,提出了一種基于國密SM2的OAuth2.0身份認(rèn)證方案。方案對可能會被篡改的信息如uid、client_id、state、date 、redirect_uri等進(jìn)行數(shù)字簽名,并在授權(quán)服務(wù)器端進(jìn)行簽名驗(yàn)證。隨后針對B/S、C/S、APP/S三種場景下的身份認(rèn)證進(jìn)行仿真實(shí)驗(yàn),實(shí)驗(yàn)表明該方案具有數(shù)據(jù)機(jī)密性、數(shù)據(jù)完整性、不可抵賴性、消息新鮮性,且傳輸效率未降低。