詹 麗,姚國祥+,強衡暢
(暨南大學 信息科學技術(shù)學院,廣東 廣州510632)
目前云計算因為具有投入低、易維護、部署靈活快速、服務可靠等特點受到社會各界的關(guān)注,云計算的定義請參見文獻[1]。當前的云計算服務可以分為3個層次,分別是基礎(chǔ)設(shè)施即服務 (IaaS)、平臺及服務 (PaaS)、軟件即服務 (SaaS)[2]。隨著云服務專業(yè)化發(fā)展的趨勢,云服務面臨著越來越多的安全性問題,其中就包括非法用戶訪問云服務,竊取信息與資料;以及合法用戶訪問到非法云服務,使用戶信息泄露。因此用戶訪問云服務,需要對云服務器進行安全性認證;而當云服務器收到用戶的請求時,檢驗用戶一致性以后,需要對用戶身份進行認證。因此雙向認證對于用戶訪問云計算的環(huán)境是必須的。
本文提出了一種基于smartcard的雙向認證方案用于云用戶安全的訪問云服務。
L.Lamport首次提出用單向的哈希函數(shù)處理密碼口令的遠程認證的方案,此方案中遠程服務器存儲經(jīng)過哈希處理的口令[3]。此后,Hwang和Li等人提出了一種基于公共密碼加密系統(tǒng)的smartcard遠程用戶認證方案[4]。但在此方案中任何合法用戶都可以偽造合法ID 和相應的口令,導致方案不安全。在此之后,許多人提出了在此方案上改進的基于smartcard的遠程用戶身份認證方案[5-8]。
最近,許多人提出的云計算下遠程認證的方案,Richard等人就提出一種關(guān)于移動用戶的云環(huán)境下的可信認證方案[9]。Choudhury等人提出了一種在云環(huán)境下的強用戶認證方案[10]。此方案是基于口令、smartcard、OOB這3種方式的強用戶認證,但在此方案中不能抵制中間人攻擊。Nayak等人提出了一種改進的云環(huán)境下雙向認證方案[11],并在方案中生成了會話密鑰。但是在此方案中的認證階段口令是經(jīng)明文傳輸?shù)?,這樣就使得敵手很容易竊取明文并偽造成合法的用戶。
在本文中,提出了一種對文獻 [10,11]的改進方案。在改進方案中,使用了OOB 和smartcard 兩種安全要素,并生成了會話密鑰,最終保證了認證的安全性。
云認證服務用于為云用戶提供認證和注冊云應用,它包含3個基于HTTP接口的服務:認證服務、注冊服務和修改密碼服務。云用戶若要訪問云網(wǎng)絡(luò)服務器 (cloud web server,CWS)上的資源,必須通過認證服務器 (authentication server,AS)的雙向認證,用戶通過認證后才能訪問云網(wǎng)絡(luò)服務器。圖1是關(guān)于云認證服務的安全結(jié)構(gòu)圖。
圖1 云認證的安全結(jié)構(gòu)
(1)用戶在云終端輸入ID 和Mobile_ID 并發(fā)送注冊請求給云認證服務器。若檢驗此ID 已存在,則發(fā)送消息給用戶讓用戶重新輸入。若此ID 不存在,認證服務器發(fā)送消息給移動網(wǎng)絡(luò)服務器 (mobile network server),移動網(wǎng)絡(luò)服務器通過HTTP/SMS發(fā)送動態(tài)口令到用戶移動設(shè)備上,用戶在終端輸入密碼口令,終端則將處理后的密碼口令發(fā)送給認證服務器。認證服務器將一部分計算后的用戶信息存入smartcard,并將smartcard發(fā)送給用戶。此時用戶已成為注冊用戶。
(2)注冊用戶申請訪問云網(wǎng)絡(luò)服務器上資源,認證服務器處理合法用戶發(fā)送來的請求。
(3)認證服務器收到申請后對用戶進行認證,同時用戶也需要對服務器進行認證,實現(xiàn)雙向認證。
(4)雙向認證完成后,云用戶便可以訪問云網(wǎng)絡(luò)服務器上的資源。
本文提出了兩種方式來保證雙向認證,一種是帶外數(shù)據(jù)傳輸OOB,用此安全通道來傳輸相關(guān)的口令和一次一密密鑰。另一種是使用smartcard[4-8],用smartcard存儲用戶和服務器的相關(guān)信息,來保證雙向認證的安全性。
在表1中列出的是本文提出的方案將要用到的符號對應含義。
表1 符號對應表
首先,用戶需在AS服務器上進行注冊,只有注冊的合法用戶才能向AS發(fā)出訪問請求。圖2描述了主要的初始化流程。
圖2 初始化流程
(1)假設(shè)用戶為U,U 發(fā)送用戶ID 和Mobile_ID 給認證服務器AS,AS認證ID 是否存在。如果存在則放棄,否則將Token通過OOB安全信道的形式發(fā)送給U。
(2)U 收到Token后,輸入密碼口令PWD,并生成隨機數(shù)m,PWD 將以加密的形式EToken(H(PWDm))發(fā)送給AS。
(3)AS收到EToken(H(PWDm))后,可以解密計算出H(PWDm),并生成用戶一對一的秘密密鑰KID。同時計算出A、B和C。將{B,C,p,g,H()}存入smartcard
(4)當 用戶U 收到smartcard 后,將 隨 機 數(shù)m 存 入smartcard= {B,C,p,g,H(),m}。
如果用戶需要訪問云網(wǎng)絡(luò)服務器上的資源,用戶就需要先通過AS的雙向認證。認證成功后,用戶才可以訪問云網(wǎng)絡(luò)服務器。圖3是雙向認證的認證步驟。
圖3 雙向認證步驟
(1)用戶U 需要登錄時,插入smartcard并輸入ID 和PWD。云終端計算出c'=H(PWDm)ID,檢驗c'=c是否相等,如果不相等則放棄,如果相等則繼續(xù)。
(2)如果上一步完成,說明用戶U 合法。當AS收到登錄請求,AS向用戶U 發(fā)送一次一密的密鑰Kone,雙向認證完成后Kone將無效。U 生成隨機數(shù)r1和時間戳T,可以計算出如下
用戶U 將y、ID 和時間戳T 一起作為消息M3發(fā)送給AS。
(3)AS收到消息后,計算T'-T 是否在時間戳有效期內(nèi),如果不在有效期內(nèi)則放棄;如果在有效期,AS接收到y(tǒng)后,生成隨機數(shù)r2,計算如下公式
認證服務器AS將z、x'和當前時間戳T1作為M4發(fā)送給用戶。
(4)U 收到M4后,首先計算出T1'-T1是否在時間戳有效期內(nèi),如果不在有效期則放棄。如果在有效期內(nèi),則計算y'
用戶U 檢驗計算出的y'與用戶擁有的gr1 相等,若不相等則放棄,若相等則計算z'
最后用戶U 將z'和當前時間戳T2作為M5發(fā)送給AS。
(5)AS收到M5后,首先計算出T2'-T2是否在時間戳有效期內(nèi),如果不在有效期則放棄。如果在有效期內(nèi),則檢驗以下等式是否相等
若式 (11)不等則放棄,若相等則完成雙向認證。最后,用戶和AS計算出Ksession=gKID+Kone 作為會話密鑰。
這個階段是用戶修改密碼的階段。需要用戶輸入ID 和舊密碼PWD,驗證過后,再輸入新密碼PWD',這樣修改密碼的階段就完成了。具體流程如圖4所示。
圖4 修改密碼過程
(1)用戶U 插入smartcard,輸入ID 和PWD,云終端計算出c'=H(PWDm)ID,檢驗c'=c是否相等,如果不相等則放棄,相等則向AS發(fā)送修改密碼請求。
(2)當認證服務器AS收到修改密碼請求后,發(fā)送新的動態(tài)口令Token'到用戶手持設(shè)備上。
(3)U 收到動態(tài)口令后Token',生成新PWD'和隨機數(shù)m',計算H(PWD'm'),然后加密作為M2發(fā)送給AS。
(4)AS解密M2,生成新的密鑰KID',計算出A,B,C。然后分別將 {B,C,p,g,H ()}放入smartcard中。
(5)當用戶U 收到smartcard后,將隨機數(shù)m 也存入smartcard中。
在上述方案中,如果消息M1、M2、M3、M4、M5不被敵手竊取,則可以計算出步驟1中c'=c等式成立、步驟4中y'與gr2modp 相等、步驟5中的式 (11)成立。由以下計算式可以證明得出以上結(jié)論。
(1)x =A'·g-ID·g-H(PWD⊕m)modp
(2)y =x ⊕gr1+T+Kone modp
(3)z=(y ⊕gKID)·g-T·gKID modp
(4)y'=z·g-KID ·g-Kone modp
(5)z'=(x'⊕gKID)·gKID modp
如果消息M1、M2、M3、M4、M5被敵手篡改,等式將不成立,即雙向認證無法完成,從而抵制了非法用戶訪問服務器。在認證階段,口令Token是通過OOB安全信道的形式發(fā)送的,而且EToken(H(PWDm))通過安全信道傳送,使得敵手無法獲得Token并解密EToken(H(PWDm))。步驟1中檢驗c'=c等式成立的目的是為了檢驗登錄用戶的一致性。步驟4中檢驗y'與gr2modp 相等的目的是用戶驗證認證服務器的合法性。步驟5中的式 (11)成立的目的則是認證服務器驗證登錄用戶的合法性。
(1)一致性檢驗
本方案使用smartcard存儲密碼和用戶,并且在用戶終端對用戶進行一致性檢驗。認證服務器不用建立并存儲用戶密碼列表,抵抗了敵手隨意竊取并篡改用戶密碼列表的攻擊。
(2)抵抗重放攻擊
在雙向認證階段,敵手即使竊取了消息M3、M4和M5。由于M3中的y=xgr1+T+Kone modp,其中Kone為針對會話的一次一密的密鑰,因此敵手若想重放M3來實現(xiàn)重放攻擊是無法成功的。
(3)抵抗中間人攻擊
在雙向認證階段,敵手可以通過公共信道獲取消息M3、M4和M5,得到以 下 信 息y =gKIDgr1+T+Kone modp,z =gr1+KID+Kone modp,x' = gr2+KonegKID modp,z' =gr2+KID+Kone modp。但是敵手卻無法由以上得到的已知信息計算出gKID、gKone、gr1、gr2,所以敵手無法實現(xiàn)中間人攻擊。
(4)完成雙向認證
在雙向認證過程的第四步中,檢驗了y'=gr1modp,從而實現(xiàn)了用戶對AS的服務器認證。在雙向認證過程的第五步中,檢驗了z'·g-KID·gKone =gr2modp,從而實現(xiàn)了AS對用戶的認證。以上過程完成了雙向認證,從而防止敵手來冒充AS或者用戶。
(5)抵抗密碼猜測攻擊
雖然在注冊階段的 (ID,Mobile_ID)是通過公共信道發(fā)送的,但是PWD 與隨機數(shù)異或后通過口令Token加密并通過安全信道傳輸給AS。由此可知PWD 通過隨機數(shù)而隱藏,并進一步通過Token加密來保證不被敵手獲竊取。
(6)抵抗拒絕服務攻擊 (denial-of-service,DoS)
拒絕服務攻擊指的是非法用戶發(fā)送大量的連接請求,導致服務器無法響應合法用戶的請求。由于在本文的方案中用戶的ID 和PWD 都是在終端上通過smartcard進行驗證的,所以非法用戶在發(fā)送請求前無法通過一致性檢驗,因此杜絕了非法用戶發(fā)送大量持續(xù)的連接請求的可能性。從而使得本方案可以抵制DoS攻擊。
(7)抵抗并行會話攻擊
如果方案運行兩次或多次并且某一次認證過程中產(chǎn)生的消息被用于形成另一次認證過程中的消息,會產(chǎn)生并行會話攻擊。本方案在認證階段通過3 次發(fā)送明文M3、M4和M5都含有時間戳T、T1、T2,因此敵手無法通過并行會話攻擊。
在這一部分,本方案與Choudhury 等人的方案[10]和Nayak等人的方案[11]進行了比較,文獻 [10,11]與本方案有一些共同之處,如都含有修改密碼服務,也在一定程度上保證了一致性和雙向認證,但是這些方案還是具有一些安全性不足之處。如表2所示。
表2 本文與其它方案安全性比較
由于文獻 [11]的方案中注冊階段的ID 和PWD 是通過明文傳輸?shù)模艽a口令PWD 并沒有經(jīng)過單向函數(shù)哈希處理,使得敵手容易在此階段竊取ID 和PWD,從而可以竊取用戶PWD。由于敵手可以獲取PWD 并且B也是通過公共信道傳輸?shù)?,從而可以簡單地計算出A=B ⊕PWD,在認證階段敵手就可以利用計算出的A 偽裝成合法用戶進行認證,因此文獻 [11]的方案并不可以抵制中間人攻擊。由于文獻 [11]的方案未涉及smartcard技術(shù),因此驗證用戶一致性并不是在終端,這樣敵手可以偽裝成合法用戶多次發(fā)送登錄請求。可驗證此方案并不可以抵抗DoS 攻擊。在文獻 [11]的方案中用戶與服務器傳遞的消息中并沒有使用時間戳,因此敵手可以竊取某一次認證產(chǎn)生的消息用于下一次的認證過程,該方案則無法抵抗并行會話攻擊。
在文獻 [10]也涉及了smartcard技術(shù),并且在注冊階段也對PWD 進行單向哈希處理,因此文獻 [10]能夠抵制重放攻擊和DoS攻擊。在該方案的隨機數(shù)x與y是在注冊階段生成而不是在登錄認證階段生成,因此用戶每次申請登錄認證時的x與y都沒有改變,因而敵手可以根據(jù)公共信道中發(fā)送的信息B =gh(I||J)+h(x)+h(y)modp、C =h(I||J)與h(x),計算得出gh(y)。因為gh(y)是用戶認證AS的重要依據(jù),所以敵手計算出gh(y)后可根據(jù)雙方發(fā)送的消息來偽裝成AS。因此此方案無法抵制中間人攻擊。文獻 [10]的認證過程中只是在消息M3中含有時間戳T,但是AS發(fā)送給用戶的消息中沒有時間戳。由于系統(tǒng)故障或者計時誤差,可能會使得時鐘無法同步,如果攻擊者的時鐘超前于接受者,攻擊者可以截獲發(fā)送者的消息,發(fā)動并行會話攻擊??芍朔桨笩o法抵制并行會話攻擊。
由4.2中的安全性分析可知,本方案即具有文獻 [10,11]中所擁有的安全性能即雙向認證、一致性分析、修改密碼、抵抗重放攻擊、抵抗DoS攻擊,也同時具備兩個方案中所不能達到安全性能即抵抗中間人攻擊和抵抗并行會話攻擊。由此可知本方案要比文獻 [10,11]更安全,從而保證用戶與云服務器的安全。
針對云用戶安全認證的問題,本文提出了一種改進的基于smartcard的雙向認證方案,提高了方案的安全性能。本文方案分為注冊、認證和修改密碼3個階段。注冊階段使用smartcard讓認證服務器從用戶密碼表解放出來,并在用戶終端實現(xiàn)一致性檢驗抵制了DoS攻擊。認證階段完成了用戶和認證服務器的雙向認證,并且提出的方案保證雙向認證所需的安全性。修改密碼階段給用戶提供靈活的用戶體驗,而且只有授權(quán)用戶才可以隨意修改密碼。最后,將本方案與其它方案的比較,分析了本方案優(yōu)越的安全性。
[1]FENG Dengguo,ZHANG Min,ZHANG Yan,et al.Study on cloud computing security[J].Journal of Software,2011,22 (1):71-83 (in Chinese).[馮登國,張敏,張妍,等.云計算安全研究[J].軟件學報,2011,22 (1):71-83.]
[2]Armbrust M,F(xiàn)ox A,Griffith R,et al.Above the clouds:A berkely view of cloud computing [R].USA:University of California Berkeley,2009.
[3]Lamport L.Password authentication with insecure communication [J].Communications of ACM,1981,24 (11):770-772.
[4]Hwang M S,Li L H.A new remote user authentication scheme using smartcards [J].IEEE Transactions on Consumer Electronics,2000,46 (1):28-30.
[5]Yang G,Wong D S,Wang H,et al.Two-factor mutual authentication based on smart cards and passwords [J].Journal of Computer and System Sciences,2008,74 (7):1160-1172.
[6]Shen Z H.A new modified remote user authentication scheme using smart cards [J].Applied Mathematics,2008,23 (3):371-376.
[7]Li Yang,Ma Jianfeng,Qi Jiang.Mutual authentication scheme with smart cards and password under trusted computing [J].International Journal of Network Security,2012,14 (3):156-163.
[8]Manoj Kumar.An enhanced remote user authentication scheme with smart card [J].International Journal of Network Security,2010,10 (3):175-184.
[9]Richard Chow,Markus Jakobsson,Ryusuke Masuoka,et al.Authentication in the clouds:A framework and its application to mobile users [C]//Proceedings of the ACM Workshop on Cloud Computing Security Workshop,2010.
[10]Choudhury A J,Kumar P,Sain M,et al.A strong user authentication framework for cloud computing [C]//IEEE Asia-Pacific Services Computing Conference,2011.
[11]Sanjeet Kumar Nayak,Subasish Mohapatra,Banshidhar Majhi.An improved mutual authentication framework for cloud computing[J].International Journal of Computer Applications,2012,52 (5):36-41.