詹 麗，姚國祥＋，強(qiáng)衡暢

（暨南大學(xué) 信息科學(xué)技術(shù)學(xué)院，廣東 廣州510632）

0 引 言

目前云計(jì)算因?yàn)榫哂型度氲?、易維護(hù)、部署靈活快速、服務(wù)可靠等特點(diǎn)受到社會各界的關(guān)注，云計(jì)算的定義請參見文獻(xiàn)［1］。當(dāng)前的云計(jì)算服務(wù)可以分為3個(gè)層次，分別是基礎(chǔ)設(shè)施即服務(wù) （IaaS）、平臺及服務(wù) （PaaS）、軟件即服務(wù) （SaaS）［2］。隨著云服務(wù)專業(yè)化發(fā)展的趨勢，云服務(wù)面臨著越來越多的安全性問題，其中就包括非法用戶訪問云服務(wù)，竊取信息與資料；以及合法用戶訪問到非法云服務(wù)，使用戶信息泄露。因此用戶訪問云服務(wù)，需要對云服務(wù)器進(jìn)行安全性認(rèn)證；而當(dāng)云服務(wù)器收到用戶的請求時(shí)，檢驗(yàn)用戶一致性以后，需要對用戶身份進(jìn)行認(rèn)證。因此雙向認(rèn)證對于用戶訪問云計(jì)算的環(huán)境是必須的。

本文提出了一種基于smartcard的雙向認(rèn)證方案用于云用戶安全的訪問云服務(wù)。

1 相關(guān)工作

L.Lamport首次提出用單向的哈希函數(shù)處理密碼口令的遠(yuǎn)程認(rèn)證的方案，此方案中遠(yuǎn)程服務(wù)器存儲經(jīng)過哈希處理的口令［3］。此后，Hwang和Li等人提出了一種基于公共密碼加密系統(tǒng)的smartcard遠(yuǎn)程用戶認(rèn)證方案［4］。但在此方案中任何合法用戶都可以偽造合法ID 和相應(yīng)的口令，導(dǎo)致方案不安全。在此之后，許多人提出了在此方案上改進(jìn)的基于smartcard的遠(yuǎn)程用戶身份認(rèn)證方案［5－8］。

最近，許多人提出的云計(jì)算下遠(yuǎn)程認(rèn)證的方案，Richard等人就提出一種關(guān)于移動用戶的云環(huán)境下的可信認(rèn)證方案［9］。Choudhury等人提出了一種在云環(huán)境下的強(qiáng)用戶認(rèn)證方案［10］。此方案是基于口令、smartcard、OOB這3種方式的強(qiáng)用戶認(rèn)證，但在此方案中不能抵制中間人攻擊。Nayak等人提出了一種改進(jìn)的云環(huán)境下雙向認(rèn)證方案［11］，并在方案中生成了會話密鑰。但是在此方案中的認(rèn)證階段口令是經(jīng)明文傳輸?shù)?，這樣就使得敵手很容易竊取明文并偽造成合法的用戶。

在本文中，提出了一種對文獻(xiàn) ［10，11］的改進(jìn)方案。在改進(jìn)方案中，使用了OOB 和smartcard 兩種安全要素，并生成了會話密鑰，最終保證了認(rèn)證的安全性。

2 云用戶認(rèn)證的安全結(jié)構(gòu)

云認(rèn)證服務(wù)用于為云用戶提供認(rèn)證和注冊云應(yīng)用，它包含3個(gè)基于HTTP接口的服務(wù)：認(rèn)證服務(wù)、注冊服務(wù)和修改密碼服務(wù)。云用戶若要訪問云網(wǎng)絡(luò)服務(wù)器 （cloud web server，CWS）上的資源，必須通過認(rèn)證服務(wù)器 （authentication server，AS）的雙向認(rèn)證，用戶通過認(rèn)證后才能訪問云網(wǎng)絡(luò)服務(wù)器。圖1是關(guān)于云認(rèn)證服務(wù)的安全結(jié)構(gòu)圖。

圖1 云認(rèn)證的安全結(jié)構(gòu)

（1）用戶在云終端輸入ID 和Mobile＿ID 并發(fā)送注冊請求給云認(rèn)證服務(wù)器。若檢驗(yàn)此ID 已存在，則發(fā)送消息給用戶讓用戶重新輸入。若此ID 不存在，認(rèn)證服務(wù)器發(fā)送消息給移動網(wǎng)絡(luò)服務(wù)器 （mobile network server），移動網(wǎng)絡(luò)服務(wù)器通過HTTP／SMS發(fā)送動態(tài)口令到用戶移動設(shè)備上，用戶在終端輸入密碼口令，終端則將處理后的密碼口令發(fā)送給認(rèn)證服務(wù)器。認(rèn)證服務(wù)器將一部分計(jì)算后的用戶信息存入smartcard，并將smartcard發(fā)送給用戶。此時(shí)用戶已成為注冊用戶。

（2）注冊用戶申請?jiān)L問云網(wǎng)絡(luò)服務(wù)器上資源，認(rèn)證服務(wù)器處理合法用戶發(fā)送來的請求。

（3）認(rèn)證服務(wù)器收到申請后對用戶進(jìn)行認(rèn)證，同時(shí)用戶也需要對服務(wù)器進(jìn)行認(rèn)證，實(shí)現(xiàn)雙向認(rèn)證。

（4）雙向認(rèn)證完成后，云用戶便可以訪問云網(wǎng)絡(luò)服務(wù)器上的資源。

本文提出了兩種方式來保證雙向認(rèn)證，一種是帶外數(shù)據(jù)傳輸OOB，用此安全通道來傳輸相關(guān)的口令和一次一密密鑰。另一種是使用smartcard［4－8］，用smartcard存儲用戶和服務(wù)器的相關(guān)信息，來保證雙向認(rèn)證的安全性。

3 提出的方案

在表1中列出的是本文提出的方案將要用到的符號對應(yīng)含義。

表1 符號對應(yīng)表

3.1 初始化階段

首先，用戶需在AS服務(wù)器上進(jìn)行注冊，只有注冊的合法用戶才能向AS發(fā)出訪問請求。圖2描述了主要的初始化流程。

圖2 初始化流程

（1）假設(shè)用戶為U，U 發(fā)送用戶ID 和Mobile＿ID 給認(rèn)證服務(wù)器AS，AS認(rèn)證ID 是否存在。如果存在則放棄，否則將Token通過OOB安全信道的形式發(fā)送給U。

（2）U 收到Token后，輸入密碼口令PWD，并生成隨機(jī)數(shù)m，PWD 將以加密的形式EToken（H（PWDm））發(fā)送給AS。

（3）AS收到EToken（H（PWDm））后，可以解密計(jì)算出H（PWDm），并生成用戶一對一的秘密密鑰KID。同時(shí)計(jì)算出A、B和C。將｛B，C，p，g，H（）｝存入smartcard

（4）當(dāng) 用戶U 收到smartcard 后，將 隨 機(jī) 數(shù)m 存 入smartcard＝ ｛B，C，p，g，H（），m｝。

3.2 登錄和雙向認(rèn)證階段

如果用戶需要訪問云網(wǎng)絡(luò)服務(wù)器上的資源，用戶就需要先通過AS的雙向認(rèn)證。認(rèn)證成功后，用戶才可以訪問云網(wǎng)絡(luò)服務(wù)器。圖3是雙向認(rèn)證的認(rèn)證步驟。

圖3 雙向認(rèn)證步驟

（1）用戶U 需要登錄時(shí)，插入smartcard并輸入ID 和PWD。云終端計(jì)算出c'＝H（PWDm）ID，檢驗(yàn)c'＝c是否相等，如果不相等則放棄，如果相等則繼續(xù)。

（2）如果上一步完成，說明用戶U 合法。當(dāng)AS收到登錄請求，AS向用戶U 發(fā)送一次一密的密鑰Kone，雙向認(rèn)證完成后Kone將無效。U 生成隨機(jī)數(shù)r1和時(shí)間戳T，可以計(jì)算出如下

用戶U 將y、ID 和時(shí)間戳T 一起作為消息M3發(fā)送給AS。

（3）AS收到消息后，計(jì)算T'－T 是否在時(shí)間戳有效期內(nèi)，如果不在有效期內(nèi)則放棄；如果在有效期，AS接收到y(tǒng)后，生成隨機(jī)數(shù)r2，計(jì)算如下公式

認(rèn)證服務(wù)器AS將z、x'和當(dāng)前時(shí)間戳T1作為M4發(fā)送給用戶。

（4）U 收到M4后，首先計(jì)算出T1'－T1是否在時(shí)間戳有效期內(nèi)，如果不在有效期則放棄。如果在有效期內(nèi)，則計(jì)算y'

用戶U 檢驗(yàn)計(jì)算出的y'與用戶擁有的gr1 相等，若不相等則放棄，若相等則計(jì)算z'

最后用戶U 將z'和當(dāng)前時(shí)間戳T2作為M5發(fā)送給AS。

（5）AS收到M5后，首先計(jì)算出T2'－T2是否在時(shí)間戳有效期內(nèi)，如果不在有效期則放棄。如果在有效期內(nèi)，則檢驗(yàn)以下等式是否相等

若式 （11）不等則放棄，若相等則完成雙向認(rèn)證。最后，用戶和AS計(jì)算出Ksession＝gKID＋Kone 作為會話密鑰。

3.3 改密碼階段

這個(gè)階段是用戶修改密碼的階段。需要用戶輸入ID 和舊密碼PWD，驗(yàn)證過后，再輸入新密碼PWD'，這樣修改密碼的階段就完成了。具體流程如圖4所示。

圖4 修改密碼過程

（1）用戶U 插入smartcard，輸入ID 和PWD，云終端計(jì)算出c'＝H（PWDm）ID，檢驗(yàn)c'＝c是否相等，如果不相等則放棄，相等則向AS發(fā)送修改密碼請求。

（2）當(dāng)認(rèn)證服務(wù)器AS收到修改密碼請求后，發(fā)送新的動態(tài)口令Token'到用戶手持設(shè)備上。

（3）U 收到動態(tài)口令后Token'，生成新PWD'和隨機(jī)數(shù)m'，計(jì)算H（PWD'm'），然后加密作為M2發(fā)送給AS。

（4）AS解密M2，生成新的密鑰KID'，計(jì)算出A，B，C。然后分別將 ｛B，C，p，g，H （）｝放入smartcard中。

（5）當(dāng)用戶U 收到smartcard后，將隨機(jī)數(shù)m 也存入smartcard中。

4 實(shí)驗(yàn)與分析

4.1 安全性驗(yàn)證

在上述方案中，如果消息M1、M2、M3、M4、M5不被敵手竊取，則可以計(jì)算出步驟1中c'＝c等式成立、步驟4中y'與gr2modp 相等、步驟5中的式 （11）成立。由以下計(jì)算式可以證明得出以上結(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被敵手篡改，等式將不成立，即雙向認(rèn)證無法完成，從而抵制了非法用戶訪問服務(wù)器。在認(rèn)證階段，口令Token是通過OOB安全信道的形式發(fā)送的，而且EToken（H（PWDm））通過安全信道傳送，使得敵手無法獲得Token并解密EToken（H（PWDm））。步驟1中檢驗(yàn)c'＝c等式成立的目的是為了檢驗(yàn)登錄用戶的一致性。步驟4中檢驗(yàn)y'與gr2modp 相等的目的是用戶驗(yàn)證認(rèn)證服務(wù)器的合法性。步驟5中的式 （11）成立的目的則是認(rèn)證服務(wù)器驗(yàn)證登錄用戶的合法性。

4.2 安全性分析

（1）一致性檢驗(yàn)

本方案使用smartcard存儲密碼和用戶，并且在用戶終端對用戶進(jìn)行一致性檢驗(yàn)。認(rèn)證服務(wù)器不用建立并存儲用戶密碼列表，抵抗了敵手隨意竊取并篡改用戶密碼列表的攻擊。

（2）抵抗重放攻擊

在雙向認(rèn)證階段，敵手即使竊取了消息M3、M4和M5。由于M3中的y＝xgr1＋T＋Kone modp，其中Kone為針對會話的一次一密的密鑰，因此敵手若想重放M3來實(shí)現(xiàn)重放攻擊是無法成功的。

（3）抵抗中間人攻擊

在雙向認(rèn)證階段，敵手可以通過公共信道獲取消息M3、M4和M5，得到以 下 信 息y ＝gKIDgr1＋T＋Kone modp，z ＝gr1＋KID＋Kone modp，x' ＝ gr2＋KonegKID modp，z' ＝gr2＋KID＋Kone modp。但是敵手卻無法由以上得到的已知信息計(jì)算出gKID、gKone、gr1、gr2，所以敵手無法實(shí)現(xiàn)中間人攻擊。

（4）完成雙向認(rèn)證

在雙向認(rèn)證過程的第四步中，檢驗(yàn)了y'＝gr1modp，從而實(shí)現(xiàn)了用戶對AS的服務(wù)器認(rèn)證。在雙向認(rèn)證過程的第五步中，檢驗(yàn)了z'·g－KID·gKone ＝gr2modp，從而實(shí)現(xiàn)了AS對用戶的認(rèn)證。以上過程完成了雙向認(rèn)證，從而防止敵手來冒充AS或者用戶。

（5）抵抗密碼猜測攻擊

雖然在注冊階段的 （ID，Mobile＿ID）是通過公共信道發(fā)送的，但是PWD 與隨機(jī)數(shù)異或后通過口令Token加密并通過安全信道傳輸給AS。由此可知PWD 通過隨機(jī)數(shù)而隱藏，并進(jìn)一步通過Token加密來保證不被敵手獲竊取。

（6）抵抗拒絕服務(wù)攻擊 （denial－of－service，DoS）

拒絕服務(wù)攻擊指的是非法用戶發(fā)送大量的連接請求，導(dǎo)致服務(wù)器無法響應(yīng)合法用戶的請求。由于在本文的方案中用戶的ID 和PWD 都是在終端上通過smartcard進(jìn)行驗(yàn)證的，所以非法用戶在發(fā)送請求前無法通過一致性檢驗(yàn)，因此杜絕了非法用戶發(fā)送大量持續(xù)的連接請求的可能性。從而使得本方案可以抵制DoS攻擊。

（7）抵抗并行會話攻擊

如果方案運(yùn)行兩次或多次并且某一次認(rèn)證過程中產(chǎn)生的消息被用于形成另一次認(rèn)證過程中的消息，會產(chǎn)生并行會話攻擊。本方案在認(rèn)證階段通過3 次發(fā)送明文M3、M4和M5都含有時(shí)間戳T、T1、T2，因此敵手無法通過并行會話攻擊。

4.3 性能分析

在這一部分，本方案與Choudhury 等人的方案［10］和Nayak等人的方案［11］進(jìn)行了比較，文獻(xiàn) ［10，11］與本方案有一些共同之處，如都含有修改密碼服務(wù)，也在一定程度上保證了一致性和雙向認(rèn)證，但是這些方案還是具有一些安全性不足之處。如表2所示。

表2 本文與其它方案安全性比較

由于文獻(xiàn) ［11］的方案中注冊階段的ID 和PWD 是通過明文傳輸?shù)模艽a口令PWD 并沒有經(jīng)過單向函數(shù)哈希處理，使得敵手容易在此階段竊取ID 和PWD，從而可以竊取用戶PWD。由于敵手可以獲取PWD 并且B也是通過公共信道傳輸?shù)?，從而可以簡單地?jì)算出A＝B ⊕PWD，在認(rèn)證階段敵手就可以利用計(jì)算出的A 偽裝成合法用戶進(jìn)行認(rèn)證，因此文獻(xiàn) ［11］的方案并不可以抵制中間人攻擊。由于文獻(xiàn) ［11］的方案未涉及smartcard技術(shù)，因此驗(yàn)證用戶一致性并不是在終端，這樣敵手可以偽裝成合法用戶多次發(fā)送登錄請求?？沈?yàn)證此方案并不可以抵抗DoS 攻擊。在文獻(xiàn) ［11］的方案中用戶與服務(wù)器傳遞的消息中并沒有使用時(shí)間戳，因此敵手可以竊取某一次認(rèn)證產(chǎn)生的消息用于下一次的認(rèn)證過程，該方案則無法抵抗并行會話攻擊。

在文獻(xiàn) ［10］也涉及了smartcard技術(shù)，并且在注冊階段也對PWD 進(jìn)行單向哈希處理，因此文獻(xiàn) ［10］能夠抵制重放攻擊和DoS攻擊。在該方案的隨機(jī)數(shù)x與y是在注冊階段生成而不是在登錄認(rèn)證階段生成，因此用戶每次申請登錄認(rèn)證時(shí)的x與y都沒有改變，因而敵手可以根據(jù)公共信道中發(fā)送的信息B ＝gh（I｜｜J）＋h（x）＋h（y）modp、C ＝h（I｜｜J）與h（x），計(jì)算得出gh（y）。因?yàn)間h（y）是用戶認(rèn)證AS的重要依據(jù)，所以敵手計(jì)算出gh（y）后可根據(jù)雙方發(fā)送的消息來偽裝成AS。因此此方案無法抵制中間人攻擊。文獻(xiàn) ［10］的認(rèn)證過程中只是在消息M3中含有時(shí)間戳T，但是AS發(fā)送給用戶的消息中沒有時(shí)間戳。由于系統(tǒng)故障或者計(jì)時(shí)誤差，可能會使得時(shí)鐘無法同步，如果攻擊者的時(shí)鐘超前于接受者，攻擊者可以截獲發(fā)送者的消息，發(fā)動并行會話攻擊?？芍朔桨笩o法抵制并行會話攻擊。

由4.2中的安全性分析可知，本方案即具有文獻(xiàn) ［10，11］中所擁有的安全性能即雙向認(rèn)證、一致性分析、修改密碼、抵抗重放攻擊、抵抗DoS攻擊，也同時(shí)具備兩個(gè)方案中所不能達(dá)到安全性能即抵抗中間人攻擊和抵抗并行會話攻擊。由此可知本方案要比文獻(xiàn) ［10，11］更安全，從而保證用戶與云服務(wù)器的安全。

5 結(jié)束語

針對云用戶安全認(rèn)證的問題，本文提出了一種改進(jìn)的基于smartcard的雙向認(rèn)證方案，提高了方案的安全性能。本文方案分為注冊、認(rèn)證和修改密碼3個(gè)階段。注冊階段使用smartcard讓認(rèn)證服務(wù)器從用戶密碼表解放出來，并在用戶終端實(shí)現(xiàn)一致性檢驗(yàn)抵制了DoS攻擊。認(rèn)證階段完成了用戶和認(rèn)證服務(wù)器的雙向認(rèn)證，并且提出的方案保證雙向認(rèn)證所需的安全性。修改密碼階段給用戶提供靈活的用戶體驗(yàn)，而且只有授權(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ì)算安全研究［J］.軟件學(xué)報(bào)，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.