專利名稱：一種網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)及方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)及方法，尤其是涉及一種網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)及實(shí)現(xiàn)方法。
背景技術(shù)：
Internet上網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)陌踩Ｕ蠁栴}，得到了國內(nèi)外學(xué)術(shù)界和產(chǎn)業(yè)界的廣泛關(guān)注和重視，經(jīng)過多年的研究和探索，初步形成了一套完整的網(wǎng)絡(luò)安全解決方案和技術(shù)規(guī)范一公鑰基礎(chǔ)設(shè)施(Public Key Infrastructure,PKI)， PKI技術(shù)是應(yīng)用公鑰理論和技術(shù)建立的提供信息安全服務(wù)的基礎(chǔ)設(shè)施。它以數(shù)字證書為媒介，結(jié)合對(duì)稱加密和非對(duì)稱加密技術(shù)，將用戶的公鑰和用戶的其他標(biāo)志信息(如名稱、E-mail、身份證號(hào)等)捆綁在一起，通過密鑰和證書的管理，旨在為用戶建立起安全、可靠的網(wǎng)絡(luò)環(huán)境。并且使用戶可以方便地使用加密和數(shù)字簽名技術(shù)，從而保證所傳輸數(shù)據(jù)的安全性、完整性、有效性和不可否認(rèn)性。
世界上的主要國家都十分重視PKI體系的建設(shè)與研究。如美國政府在完成大量研究的基礎(chǔ)上，已提出了帶橋接CA模式的聯(lián)邦PKI (FPKI)體系，用于支持信息資源的安全共享，為聯(lián)邦政府部門和其他組織機(jī)構(gòu)使用數(shù)字證書技術(shù)實(shí)現(xiàn)信息系統(tǒng)安全、安全電子商務(wù)、安全通信等活動(dòng)提供了設(shè)施、規(guī)則和政策。2000年4月，美國國防部宣布要采用PKI安全倡議方案。幾年前我國才啟動(dòng)PKI體系建設(shè)，截至目前為止，在金融、政府、電信等部門已初步建立了多家CA認(rèn)證中心。推廣PKI應(yīng)用，加強(qiáng)系統(tǒng)之間、部門之間、國家之間PKI體系的互通互聯(lián)，已經(jīng)成為目前PKI建設(shè)亟待解決的迫切問題。
7隨著信息化管理系統(tǒng)在各種辦公管理過程中的普及和推廣，許多企事業(yè)單位紛紛投入資金建立起不同規(guī)模的管理信息系統(tǒng)及辦公自動(dòng)化系統(tǒng)，提高了服務(wù)行業(yè)、窗口行業(yè)及各種企事業(yè)單位的運(yùn)行效率，取得了很好的社會(huì)效益。但是，許多系統(tǒng)從建立之初，缺乏行之有效的，全方案，導(dǎo)致存在不少潛在安全隱患。在如今黑客猖獗的網(wǎng)絡(luò)信息化時(shí)代，黑客等高科技犯罪總是出現(xiàn)在效益好且安全意識(shí)薄弱的環(huán)節(jié)和地方。近年來，在證券、金融等領(lǐng)域通過網(wǎng)絡(luò)非法潛入信息系統(tǒng)，修改客戶資料,非法獲取錢財(cái)?shù)氖虑?，出現(xiàn)的越來越多。提高應(yīng)用系統(tǒng)的安全性已成為信息化應(yīng)用進(jìn)一步發(fā)展迫切需要解決的問題和安全應(yīng)用發(fā)展的原動(dòng)力。
當(dāng)然，隨著信息安全的投入，不是僅僅是在安全上獲得了好處，還因?yàn)橛辛诉M(jìn)一步的安全保障，可以提高管理強(qiáng)度，擴(kuò)展業(yè)務(wù)范圍，增強(qiáng)更靈活的工作方式，使應(yīng)用系統(tǒng)的整體投資有效降低，否則各種風(fēng)險(xiǎn)將時(shí)刻會(huì)有給企業(yè)帶來風(fēng)險(xiǎn)的可能。為此，在現(xiàn)有的應(yīng)用系統(tǒng)基礎(chǔ)上進(jìn)行安全性改造對(duì)一個(gè)需要不斷擴(kuò)大業(yè)務(wù)、提供管理有效性和防范各種金融和法律風(fēng)險(xiǎn)的信息系統(tǒng)來說，顯得非常重要。
目前許多WEB管理信息系統(tǒng)采用基于微軟架構(gòu)的視窗IIS WEB服務(wù)器網(wǎng)站方式，實(shí)現(xiàn)了局域網(wǎng)內(nèi)B/S結(jié)構(gòu)的管理架構(gòu)，通過IIS系統(tǒng)設(shè)置可以獲得對(duì)網(wǎng)站頁面的授權(quán)訪問，即通過在微軟IIS服務(wù)器端簡單地設(shè)置了驗(yàn)證登錄方式，達(dá)到控制不同用戶訪問不同管理資源的目的。該方法具體驗(yàn)證流程如下(1)用戶選擇需要登錄得到授權(quán)頁面；(2)操作系統(tǒng)根據(jù)該頁面的授權(quán)驗(yàn)證設(shè)置，自動(dòng)在客戶端請(qǐng)求用戶輸入用戶名、口令和域；(3)如果驗(yàn)證通過，用戶即獲取進(jìn)入網(wǎng)站某些頁面的訪問權(quán)限；(4)然后服務(wù)器端運(yùn)行程序根據(jù)輸入的用戶名和口令訪問數(shù)據(jù)庫，獲取具體頁面的權(quán)限；(5)程序驗(yàn)證通過后，用戶即可控制所授權(quán)的管理資源。
通過對(duì)這種登錄方式進(jìn)行安全性分析，發(fā)現(xiàn)弊端非常明顯，存在許多明顯的安全隱患。
首先，在這種方式中，口令容易遺忘或被竊取。據(jù)了解，存在數(shù)據(jù)庫內(nèi) 的用戶口令非常簡單，許多為1-9的簡單數(shù)字，許多管理人員不愿使用長度 更長，更加不規(guī)則的口令，完全可以理解，但口令很容易猜出，管理上的這 種現(xiàn)狀不容忽視。另外在雙方相互通信時(shí)，沒有進(jìn)行身份認(rèn)證，如果一方遇 到計(jì)算機(jī)黑客襲擊、電腦病毒、惡意程序攻擊等情況時(shí)，另一方有可能就不 會(huì)收到或延遲收到信息，這樣便會(huì)造成不必的損失。
其次，在某些系統(tǒng)設(shè)計(jì)中，口令在數(shù)據(jù)庫中竟然是明文存儲(chǔ)，存在信息 泄漏或數(shù)據(jù)曝露的潛在威脅，且很難抵擋跨站攻擊和SQL腳本注入密碼攻擊。
再者，Windows系統(tǒng)的安全漏洞以補(bǔ)丁形式不斷更新，對(duì)于辦公人員來說， 很難了解到這些復(fù)雜技術(shù)，并頻繁地更新操作系統(tǒng)。實(shí)際上ns服務(wù)器自身 的安全等級(jí)在所有安全級(jí)別中是非常低的。為此，在充分利用Windows操作 系統(tǒng)的易用性方面，如何借助其他形式有效提供高強(qiáng)度安全，是用戶必須正視 的問題。

發(fā)明內(nèi)容
本發(fā)明所要解決的技術(shù)問題在于，針對(duì)現(xiàn)有技術(shù)中存在的缺陷與不足， 提出了一種網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)及實(shí)現(xiàn)方法。
一種網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)，所述網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)包括認(rèn)證中心CA模塊、
認(rèn)證模塊、客戶端和USB Key模塊，
所述認(rèn)證中心CA模塊用于數(shù)字證書的申請(qǐng)、審批、頒發(fā)、更新和撤銷；
所述認(rèn)證模塊包括控制代理模塊和認(rèn)證服務(wù)器，控制代理模塊用于完成 截獲用戶發(fā)向資源服務(wù)器認(rèn)證的請(qǐng)求連接，將其轉(zhuǎn)發(fā)到認(rèn)證服務(wù)器進(jìn)行用戶 的身份認(rèn)證；認(rèn)證服務(wù)器用于完成與客戶端的認(rèn)證工作，并進(jìn)行數(shù)字信封的產(chǎn) 生和數(shù)字證書的驗(yàn)證，認(rèn)證服務(wù)器中設(shè)有用于存放用戶身份認(rèn)證信息和本地安全參數(shù)信息的用戶信息數(shù)據(jù)庫；
所述客戶端位于內(nèi)部網(wǎng)絡(luò)和公共網(wǎng)絡(luò)任何待認(rèn)證的用戶主機(jī)中，客戶端
用于實(shí)現(xiàn)系統(tǒng)和客戶的管理，為終端用戶提供一個(gè)操作界面；
所述USB Key模塊用于提供一個(gè)存儲(chǔ)數(shù)字證書和用戶私鑰的介質(zhì)。 進(jìn)一步，所述客戶端具有一個(gè)認(rèn)證令牌，認(rèn)證令牌用于將認(rèn)證服務(wù)器發(fā)
送的挑戰(zhàn)隨機(jī)動(dòng)態(tài)數(shù)字和種子值通過一個(gè)隨機(jī)函數(shù)生成算法，計(jì)算出相應(yīng)的
動(dòng)態(tài)口令,提供給客戶端。
進(jìn)一步，所述客戶端與控制代理模塊之間采用安全傳輸通道SSL連接，
控制代理模塊和認(rèn)證服務(wù)器之間采用明文傳輸TCP/IP協(xié)議連接。
進(jìn)一步，所述認(rèn)證模塊中的認(rèn)證服務(wù)器與所述客戶端分別進(jìn)行數(shù)字信封
的產(chǎn)生和數(shù)字證書的驗(yàn)證，客戶端與認(rèn)證服務(wù)器端都使用USB Key中的數(shù)字
證書和私鑰信息。
進(jìn)一步，所述客戶端利用認(rèn)證服務(wù)器提供的公鑰，將一個(gè)通信密鑰加密 后傳送給認(rèn)證服務(wù)器，認(rèn)證服務(wù)器通過使用密鑰來解密客戶端傳送過來的信 息。這樣以滿足認(rèn)證服務(wù)器與客戶端之間數(shù)據(jù)傳送的高保密性要求。
所述認(rèn)證中心CA模塊是本認(rèn)證系統(tǒng)的核心和基礎(chǔ)模塊，為數(shù)字證書的査 詢和驗(yàn)證提供基本的數(shù)字證書信息。由于USB Key內(nèi)有CPU，可以在USBKey 內(nèi)進(jìn)行密鑰產(chǎn)生、數(shù)字簽名等功能，這樣就不會(huì)把用戶的保密信息留在客戶 機(jī)上，確保了秘密信息的安全性。所述控制代理模塊是實(shí)現(xiàn)客戶端和認(rèn)證服 務(wù)器認(rèn)證連接轉(zhuǎn)發(fā)的中間環(huán)節(jié)，當(dāng)用戶認(rèn)證成功后為用戶建立訪問資源服務(wù) 器的透明代理。認(rèn)證服務(wù)器發(fā)出的每個(gè)挑戰(zhàn)隨機(jī)數(shù)都是唯一的，并且決不重復(fù) 使用，這樣就保證了每次認(rèn)證過程均生成一個(gè)唯一的與認(rèn)證令牌對(duì)應(yīng)的不可 預(yù)測(cè)的令牌碼，提供給認(rèn)證客戶端。
一種采用上述網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)的網(wǎng)絡(luò)身份認(rèn)證方法，包括以下步驟.-(1)、生成CA根證書和私鑰；(2) 、初始注冊(cè)；
(3) 、設(shè)計(jì)認(rèn)證協(xié)議，客戶端與認(rèn)證服務(wù)器之間進(jìn)行身份認(rèn)證；
(4) 、進(jìn)行數(shù)字證書認(rèn)證，對(duì)客戶端與認(rèn)證服務(wù)器端都分別進(jìn)行數(shù)字信封的 產(chǎn)生和數(shù)字證書的驗(yàn)證。
進(jìn)一步，所述的步驟(1) CA根證書的生成過程具體如下
(1. 1. 1) CA規(guī)定證書的產(chǎn)生和頒發(fā)是分級(jí)進(jìn)行的，即由CA中心的根CA先產(chǎn) 生-一個(gè)自簽的根證書；
(1.1.2)由根CA產(chǎn)生下一級(jí)子CA的證書，由此繼續(xù)，從而得到最終實(shí)體的 證書，所有證書在從屬關(guān)系上形成了一個(gè)金字塔模型，每個(gè)證書都存在于一 個(gè)證書鏈中，證書從屬關(guān)系的驗(yàn)證是通過證書鏈進(jìn)行的，通常為了保證根CA 的安全，CA的層次至少為兩級(jí)，證書鏈的長度至少為3;
(1. 1.3)設(shè)證書的公鑰為P，證書上的簽名為S， n為證書的編號(hào)，C為證書， 則Pn和Sn分別代表證書Cn上的公鑰和簽名，Cn (Pn， Sn)組成該證書， 令Verify (Pm， Sn)代表簽名的驗(yàn)證過程，若結(jié)果為TRUE，則表示證書Cn
(Pn， Sn)由證書Cm (Pm， Sm)簽發(fā)，它們之間具有從屬關(guān)系，否則從屬關(guān) 系不成立；
所述的步驟(1)中私鑰的生成過程具體如下
(1.2.1) 計(jì)算n二pq，其中p， q是任選的兩個(gè)大素?cái)?shù)，為了獲得最大程度 的安全性兩個(gè)數(shù)的長度一樣，而且必須保密；
(1.2.2) 隨機(jī)選取一個(gè)整數(shù)e(公鑰)，使e和(p-1) (q-l)互素； (1.2.3) 計(jì)算私鑰d， d=(e-l)mod((p-l) (q-l))。
進(jìn)一步，所述步驟(2)中的初始注冊(cè)過程具體如下
管理員在認(rèn)證令牌中寫入唯一的ID號(hào)、用戶客戶端認(rèn)證信息以及認(rèn)證服 務(wù)器的公鑰，同時(shí)認(rèn)證服務(wù)器在本地的用戶信息數(shù)據(jù)庫中為用戶生成注冊(cè)信息及在數(shù)據(jù)庫中保存用戶證書，使用戶成為網(wǎng)絡(luò)資源服務(wù)器的合法用戶。 進(jìn)一步，所述的步驟(3)屮的認(rèn)證協(xié)議設(shè)計(jì)具體如下
本發(fā)明的認(rèn)證協(xié)議在傳統(tǒng)的動(dòng)態(tài)口令認(rèn)證機(jī)制中請(qǐng)求/應(yīng)答認(rèn)證方式的 基礎(chǔ)上，對(duì)該協(xié)議在傳輸安全性方面進(jìn)行了改進(jìn)，實(shí)現(xiàn)了客戶端和認(rèn)證服務(wù)器 身份的雙向汄證；認(rèn)證協(xié)議中E表示采用了客戶端的RSA私鑰進(jìn)行簽名，H 表示對(duì)產(chǎn)生的認(rèn)證隨機(jī)數(shù)的MD5散列運(yùn)算，M為本次待認(rèn)證信息，M1=H(M);
客戶端與認(rèn)證服務(wù)器之間的身份認(rèn)證過程,具體如下 (3. 1)當(dāng)用戶在客戶端登錄并向資源服務(wù)器發(fā)出資源訪問請(qǐng)求時(shí)，系統(tǒng) 提示用戶輸入用戶名和口令，并將輸入結(jié)果(UserID， Psw)發(fā)送給控制代理 模塊；
(3.2) 認(rèn)證服務(wù)器首先驗(yàn)證用戶名和口令，如果正確，認(rèn)證服務(wù)模塊和 客戶端按照基于動(dòng)態(tài)口令機(jī)制的認(rèn)證協(xié)議進(jìn)行雙向的身份認(rèn)證，認(rèn)證服務(wù)模 塊將產(chǎn)生并向客戶端發(fā)送一個(gè)隨機(jī)數(shù)認(rèn)證數(shù)據(jù)包作為挑戰(zhàn)，并保存此隨機(jī)數(shù) 到數(shù)據(jù)庫中，如果不正確，傳回提示用戶重新輸入的信息,讓用戶端重新輸入；
(3.3) 客戶端收到包含有隨機(jī)數(shù)的認(rèn)證數(shù)據(jù)包后，判斷數(shù)據(jù)包包頭信息 為認(rèn)證數(shù)據(jù)包時(shí)，將該認(rèn)證請(qǐng)求發(fā)送到認(rèn)證令牌，認(rèn)證令牌接收到該認(rèn)證請(qǐng) 求，系統(tǒng)提示用戶輸入私鑰保護(hù)口令，認(rèn)證令牌將向認(rèn)證服務(wù)器發(fā)起另一個(gè) 認(rèn)證連接，認(rèn)證令牌根據(jù)種子值和挑戰(zhàn)隨機(jī)數(shù)，運(yùn)用隨機(jī)運(yùn)算法則生成認(rèn)證信 息并調(diào)用簽名程序，對(duì)生成的認(rèn)證信息和用戶名、口令進(jìn)行簽名，形成消息 E(ID, Rand， Ml)作為響應(yīng)回送給認(rèn)證服務(wù)器；
(3.4) 認(rèn)證服務(wù)器接收到E(ID，Rand，Ml)消息后，由認(rèn)證服務(wù)器根據(jù)用 戶名在數(shù)據(jù)庫中查找口令和剛剛存儲(chǔ)的隨機(jī)數(shù)，并驗(yàn)證簽名的正確性，再將認(rèn) 證結(jié)果發(fā)送給控制代理模塊，認(rèn)證過程結(jié)束。
進(jìn)--歩，所述的步驟(4)中，對(duì)客戶端身份認(rèn)證過程具體如下
12(4. 1. 1)用戶通過簽名或者解讀數(shù)字信封觸發(fā)對(duì)證書私鑰的請(qǐng)求； (4. 1.2)認(rèn)證接口通過用戶登錄系統(tǒng)提交的身份證書信息從本地證書庫檢索 該數(shù)字證書；
(4.1.3)檢索到證書時(shí)將嘗試請(qǐng)求解密私鑰，此時(shí)前端用戶會(huì)接收到針對(duì)自 己證書的密鑰請(qǐng)求，用戶可以輸入解密U令接受請(qǐng)求或者直接拒絕請(qǐng)求，如 果檢索到證書或用戶接收請(qǐng)求時(shí)，則執(zhí)行步驟(4.1.4)，否則，執(zhí)行步驟
(4.1.5);
(丄1.4)返回簽名密鑰，執(zhí)行步驟(4.1.6);
(4.1.5) 返回請(qǐng)求密鑰錯(cuò)誤狀態(tài)，執(zhí)行步驟(4.1.6); U.1.6)完成請(qǐng)求；
所述的步驟(4)中，對(duì)認(rèn)證服務(wù)器端身份認(rèn)證過程具體如下 (4. 2. 1)服務(wù)器把自己的證書和其他進(jìn)行認(rèn)證所需要的信息傳送給用戶； (4. 2. 2)客戶端檢查服務(wù)器證書的有效日期在通信的當(dāng)日是否仍然有效；
(4.2.3) 客戶端檢査發(fā)放給服務(wù)器，該證書的發(fā)證機(jī)構(gòu)(CA)是否在自己的
"可以信任的CA"名單內(nèi)；
(4.2.4) 如果該CA對(duì)于用戶來講是可信任的，就使用這一證書帶有的公鑰 來檢査該CA對(duì)服務(wù)器證書的簽名以證明服務(wù)器證書的真實(shí)性；
(4. 2. 5)客戶端檢査在服務(wù)器證書中所給出的服務(wù)器域名與此次通信對(duì)象的 域名是否相同；
(4.2.6) 如果上述檢査均正常通過，就完成了服務(wù)器身份的認(rèn)證，否則，若 上述任何一項(xiàng)檢查沒有通過，身份認(rèn)證工作失敗，執(zhí)行(4.2.7);
(4.2.7) 結(jié)束。
本發(fā)明具有以下有益效果
1、認(rèn)證模塊中使用控制代理模塊，從而保證在正常傳輸信息時(shí)，實(shí)現(xiàn)用
戶信息數(shù)據(jù)庫存與認(rèn)證服務(wù)器的分離，充分保證用戶信息的安全；客戶端與控制代理之間采用安全傳輸通道SSL，控制代理模塊和認(rèn)證服務(wù)器之間采用 明文傳輸TCP/IP協(xié)議，信息的傳輸不會(huì)被泄露；
2、 客戶端與認(rèn)證服務(wù)器端都分別進(jìn)行數(shù)字信封的產(chǎn)生和數(shù)字證書的驗(yàn) 證，能夠?qū)崿F(xiàn)客戶端與認(rèn)證服務(wù)器之間的雙向認(rèn)證，客戶端在認(rèn)證服務(wù)器端 認(rèn)證自己的身份時(shí)，可以利用相同的機(jī)制認(rèn)證服務(wù)器的身份；
3、 本發(fā)明采用RSA算法進(jìn)行加密、解密、實(shí)施數(shù)字簽名以及計(jì)算生成私 鑰，實(shí)現(xiàn)了信息傳輸中身份標(biāo)識(shí)和認(rèn)證、抗抵賴性；
4、 本發(fā)明采用認(rèn)證令牌用于客戶端向認(rèn)證服務(wù)器發(fā)送請(qǐng)求進(jìn)行認(rèn)證，這 樣就保證了每次認(rèn)證過程均生成一個(gè)唯一的與認(rèn)證令牌對(duì)應(yīng)的不可預(yù)測(cè)的令 牌碼，提供給認(rèn)證客戶端，實(shí)現(xiàn)了認(rèn)證過程的安全性。


圖1為本發(fā)明網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)具體實(shí)施例的系統(tǒng)結(jié)構(gòu)圖； 圖2為本發(fā)明網(wǎng)絡(luò)身份認(rèn)證方法中客戶端與認(rèn)證服務(wù)器之間身份認(rèn)證交 互信息流程圖3為本發(fā)明網(wǎng)絡(luò)身份認(rèn)證方法中客戶端認(rèn)證過程流程圖； 圖4為本發(fā)明網(wǎng)絡(luò)身份認(rèn)證方法中服務(wù)器端認(rèn)證過程流程圖； 圖5為本發(fā)明網(wǎng)絡(luò)身份認(rèn)證方法中數(shù)字信封加密發(fā)送過程圖； 圖6為本發(fā)明網(wǎng)絡(luò)身份認(rèn)證方法中數(shù)字信封解密接收過程圖。
具體實(shí)施例方式
下面通過附圖和具體實(shí)施例對(duì)本發(fā)明的技術(shù)方案做進(jìn)一步地詳細(xì)描述， 但本發(fā)明的保護(hù)范圍并不限于此。
參照?qǐng)Dl， 一種網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)，包括認(rèn)證中心CA模塊、認(rèn)證模塊、
客戶端以及USB Key模塊。
所述認(rèn)證中心CA模塊負(fù)責(zé)證書的申請(qǐng)、審批、頒發(fā)、更新和撤銷功能；所述認(rèn)證模塊主要包括控制代理模塊和認(rèn)證服務(wù)器，控制代理模塊主要 完成截獲用戶發(fā)向資源服務(wù)器認(rèn)證的請(qǐng)求連接，將其轉(zhuǎn)發(fā)到認(rèn)證服務(wù)器進(jìn)行 用戶的身份認(rèn)證,保證在正常傳輸信息時(shí)，實(shí)現(xiàn)用戶信息數(shù)據(jù)庫與認(rèn)證服務(wù)器 的分離，充分保證用戶信息的安全。認(rèn)證服務(wù)器主要完成與客戶端的認(rèn)證工fK 并進(jìn)行了數(shù)字信封的產(chǎn)生和數(shù)字證書的驗(yàn)證，各種用戶的身份認(rèn)證信息和本 地的一些安全參數(shù)信息，都存放在用戶信息數(shù)據(jù)庫中。為了保護(hù)用戶與認(rèn)證 服務(wù)器之間的通信以及實(shí)現(xiàn)用戶對(duì)服務(wù)器的身份認(rèn)證，認(rèn)證服務(wù)器和用戶分
別擁有一對(duì)RSA公私密鑰對(duì)和CA機(jī)構(gòu)頒發(fā)的證書，用戶可以通過使用認(rèn)證服
務(wù)器的公鑰加密信息來驗(yàn)證服務(wù)器的身份是否合法，從而達(dá)到雙向驗(yàn)證的目
的；
所述認(rèn)證客戶端位于內(nèi)部網(wǎng)絡(luò)和公共網(wǎng)絡(luò)任何待認(rèn)證的用戶主機(jī)中，認(rèn) 證客戶端主要實(shí)現(xiàn)系統(tǒng)和客戶的管理，為終端用戶提供一個(gè)簡潔方便的操作 界面，并進(jìn)行了數(shù)字信封的產(chǎn)生和數(shù)字證書的驗(yàn)證。
所述客戶端擁有一個(gè)認(rèn)證令牌，認(rèn)證令牌用于將認(rèn)證服務(wù)器發(fā)送的挑戰(zhàn) 隨機(jī)動(dòng)態(tài)數(shù)字和種子值通過一個(gè)隨機(jī)函數(shù)生成算法，計(jì)算出相應(yīng)的動(dòng)態(tài)口令， 提供給客戶端。
所述USB Key模塊主要是提供給用戶一個(gè)存儲(chǔ)數(shù)字證書和用戶私鑰的介質(zhì)。
所述客戶端與控制代理模塊之間采用安全傳輸通道SSL連接，控制代理 模塊和認(rèn)證服務(wù)器之間采用明文傳輸TCP/IP協(xié)議連接。
所述認(rèn)證模塊中的認(rèn)證服務(wù)器與所述客戶端分別進(jìn)行數(shù)字信封的產(chǎn)生和 數(shù)字證書的驗(yàn)證，所述客戶端與所述認(rèn)證服務(wù)器端都使用USB Key中的數(shù)字 證書和私鑰信息。所述客戶端利用認(rèn)證服務(wù)器提供的公鑰，將一個(gè)通信密鑰 加密后傳送給認(rèn)證服務(wù)器，認(rèn)證服務(wù)器通過使用密鑰來解密客戶端傳送過來 的信息。
參照?qǐng)D2所示為本發(fā)明的客戶端與認(rèn)證服務(wù)器之間身份認(rèn)證系統(tǒng)交互信息流程圖，其中，具體步驟如下
步驟201，當(dāng)用戶在客戶端登錄并向資源服務(wù)器發(fā)出資源訪問請(qǐng)求時(shí)，系 統(tǒng)提示用戶輸入用戶名和口令，并將輸入結(jié)果(UserID， Psw)發(fā)送給控制代 理模塊；
歩驟202，認(rèn)證服務(wù)器首先驗(yàn)證用戶名和口令，如果正確，認(rèn)證服務(wù)^t塊 和客戶端按照基于動(dòng)態(tài)口令機(jī)制的認(rèn)證協(xié)議進(jìn)行雙向的身份認(rèn)證，認(rèn)證服務(wù) 模塊將產(chǎn)生并向客戶端發(fā)送一個(gè)隨機(jī)數(shù)認(rèn)證數(shù)據(jù)包作為挑戰(zhàn)，并保存此隨機(jī) 數(shù)到數(shù)據(jù)庫中，如果不正確，傳回提示用戶重新輸入的信息，讓用戶端重新輸 入；
步驟203，客戶端收到包含有隨機(jī)數(shù)的認(rèn)證數(shù)據(jù)包后，判斷數(shù)據(jù)包包頭信
息為認(rèn)證數(shù)據(jù)包時(shí)，將該認(rèn)證請(qǐng)求發(fā)送到認(rèn)證令牌，認(rèn)證令牌接收到該認(rèn)證
請(qǐng)求，系統(tǒng)提示用戶輸入私鑰保護(hù)口令，認(rèn)證令牌將向認(rèn)證服務(wù)器發(fā)起另一
個(gè)認(rèn)證連接，汄證令牌根據(jù)種子值和挑戰(zhàn)隨機(jī)數(shù)，運(yùn)用隨機(jī)運(yùn)算法則生成認(rèn)證
信息并調(diào)用簽名程序,對(duì)生成的認(rèn)證信息和用戶名、口令進(jìn)行簽名，形成消息
E(ID, Rand， Ml)作為響應(yīng)回送給認(rèn)證服務(wù)器；
步驟204，認(rèn)證服務(wù)器接收到E(ID,Rand，Ml)消息后，由認(rèn)證服務(wù)器根據(jù)
用戶名在數(shù)據(jù)庫中查找口令和剛剛存儲(chǔ)的隨機(jī)數(shù)，并驗(yàn)證簽名的正確性,再將
認(rèn)證結(jié)果發(fā)送給控制代理模塊，認(rèn)證過程結(jié)束。
參照?qǐng)D3，本發(fā)明網(wǎng)絡(luò)身份認(rèn)證方法中，對(duì)客戶端身份認(rèn)證過程，具體歩 驟如下
步驟301，用戶通過簽名或者解讀數(shù)字信封觸發(fā)對(duì)證書私鑰的請(qǐng)求；
歩驟302，認(rèn)證接口通過用戶登錄系統(tǒng)提交的身份證書信息從本地證書庫 檢索該數(shù)字證書；
歩驟303，檢索到證書時(shí)將嘗試請(qǐng)求解密私鑰，此時(shí)前端用戶會(huì)接收到針對(duì)自己證書的密鑰請(qǐng)求，用戶可以輸入解密口令接受請(qǐng)求或者直接拒絕請(qǐng)求，
如果檢索到證書或用戶接收請(qǐng)求時(shí)，則執(zhí)行步驟304，否則，執(zhí)行歩驟305; 歩驟304，返回簽名密鑰，執(zhí)行步驟306; 步驟305，返回請(qǐng)求密鑰錯(cuò)誤狀態(tài)，執(zhí)行步驟306; 步驟306，完成請(qǐng)求。
參照?qǐng)D4，本發(fā)明網(wǎng)絡(luò)身份認(rèn)證方法中，對(duì)服務(wù)器端身份認(rèn)證過程，具體 歩驟如下
歩驟401，服務(wù)器把自己的證書和其他進(jìn)行認(rèn)證所需要的信息傳送給用戶； 步驟402，客戶端檢査服務(wù)器證書的有效日期在通信的當(dāng)日是否仍然有效；
步驟403，客戶端檢査發(fā)放給服務(wù)器，該證書的發(fā)證機(jī)構(gòu)(CA)是否在自 己的"可以信任的CA"名單內(nèi)(客戶端存放有該名單)；
步驟404，如果該CA對(duì)于用戶來講是可信任的，就使用這一證書帶有的 公鑰來檢査該CA對(duì)服務(wù)器證書的簽名以證明服務(wù)器證書的真實(shí)性；
歩驟405，客戶端檢査在服務(wù)器證書中所給出的服務(wù)器域名與此次通信對(duì) 象(即服務(wù)器)的域名是否相同(此項(xiàng)不屬于SSLv3協(xié)議)；
步驟406，如果上述檢査均正常通過，就完成了服務(wù)器身份的認(rèn)證，否則， 若上述任何一項(xiàng)檢查沒有通過，身份認(rèn)證工作失敗，執(zhí)行步驟407;
步驟407，會(huì)話終止，斷開連接。
參照?qǐng)D5，本發(fā)明網(wǎng)絡(luò)身份認(rèn)證方法中，對(duì)客戶端與服務(wù)器端都進(jìn)行數(shù)字 信封加密過程，具體步驟如下
步驟501，將要傳送的信息經(jīng)雜湊函數(shù)(HASH)運(yùn)算，得到一個(gè)數(shù)據(jù)摘要 MD， MD-HASH (信息);
歩驟502，發(fā)送者A用自己的私鑰PVA對(duì)數(shù)據(jù)摘要MD進(jìn)行加密，得到A的說明書第12/12頁
數(shù)字簽名；
步驟503，發(fā)送者A將信息明文、數(shù)字簽名和他證書上的公鑰三項(xiàng)信息， 通過對(duì)稱算法，用對(duì)稱密鑰SK進(jìn)行加密，得到密文E;
步驟504，發(fā)送者在發(fā)送信息之前，必須先得到接收方B的證書公鑰PB,;， 用PBB加密密鑰SK，開成一個(gè)數(shù)字信封DE;
步驟505， E+DE，也就是將密文與數(shù)字信封連接起來，即為將要發(fā)送的內(nèi)容。
參照?qǐng)D6，本發(fā)明網(wǎng)絡(luò)身份認(rèn)證方法中，對(duì)客戶端與服務(wù)器端都進(jìn)行數(shù)字 信封解密過程，具體歩驟如下
步驟601，接收者B用自己的私鑰解開所收到的數(shù)字信封DE，并從中取 出A所用過的對(duì)稱密鑰SK;
步驟602，接收者B用SK將密文E解密還原成信息明文、數(shù)字簽名和A的 證書公鑰；
歩驟603， B將數(shù)字簽名用A的證書公鑰PBA進(jìn)行解密，將數(shù)字簽名還原 成信息摘耍MD;
歩驟604，B再將己收到的信息明文用同樣的HASH函數(shù)算法進(jìn)行雜湊運(yùn)算， 得到一個(gè)新的信息摘要MD';
步驟605，對(duì)數(shù)字簽名進(jìn)行校驗(yàn)，比較已還原的MD和新生產(chǎn)的MD'是否 相等，二者必須相等無誤，否則，B有權(quán)拒絕接收。
以上所述實(shí)施方式僅為本發(fā)明的一個(gè)實(shí)施例，本發(fā)明不限于上述實(shí)施例， 對(duì)于木領(lǐng)域一般技術(shù)人員而言，在不背離本發(fā)明原理的前提下對(duì)它所做的任 何顯而易見的改動(dòng)，都屬于本發(fā)明的構(gòu)思和所附權(quán)利要求保護(hù)的范圍。
權(quán)利要求
1、一種網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)，其特征在于所述網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)包括認(rèn)證中心CA模塊、認(rèn)證模塊、客戶端和USB Key模塊，所述認(rèn)證中心CA模塊用于數(shù)字證書的申請(qǐng)、審批、頒發(fā)、更新和撤銷；所述認(rèn)證模塊包括控制代理模塊和認(rèn)證服務(wù)器，控制代理模塊用于完成截獲用戶發(fā)向資源服務(wù)器認(rèn)證的請(qǐng)求連接，將其轉(zhuǎn)發(fā)到認(rèn)證服務(wù)器進(jìn)行用戶的身份認(rèn)證；認(rèn)證服務(wù)器用于完成與客戶端的認(rèn)證工作，并進(jìn)行數(shù)字信封的產(chǎn)生和數(shù)字證書的驗(yàn)證，認(rèn)證服務(wù)器中設(shè)有用于存放用戶身份認(rèn)證信息和本地安全參數(shù)信息的用戶信息數(shù)據(jù)庫；所述客戶端位于內(nèi)部網(wǎng)絡(luò)和公共網(wǎng)絡(luò)任何待認(rèn)證的用戶主機(jī)中，客戶端用于實(shí)現(xiàn)系統(tǒng)和客戶的管理，為終端用戶提供操作界面；所述USB Key模塊用于提供一個(gè)存儲(chǔ)數(shù)字證書和用戶私鑰的介質(zhì)。
2、 根據(jù)權(quán)利要求l所述的網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)，其特征在于所述客戶端 具有一個(gè)認(rèn)證令牌，認(rèn)證令牌用于將認(rèn)證服務(wù)器發(fā)送的挑戰(zhàn)隨機(jī)動(dòng)態(tài)數(shù) 字和種子值通過一個(gè)隨機(jī)函數(shù)生成算法，計(jì)算出相應(yīng)的動(dòng)態(tài)口令，提供 給客戶端。
3、 根據(jù)權(quán)利要求l所述的網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)，其特征在于所述客戶端與控制代理模塊之間采用安全傳輸通道SSL連接，控制代理模塊和認(rèn)證 服務(wù)器之間采用明文傳輸TCP/IP協(xié)議連接。
4、 根據(jù)權(quán)利要求l所述的網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)，其特征在于所述認(rèn)證模塊中的認(rèn)證服務(wù)器與所述客戶端分別進(jìn)行數(shù)字信封的產(chǎn)生和數(shù)字證書的驗(yàn)證，所述客戶端與所述認(rèn)證服務(wù)器端都使用USB Key中的數(shù)字證書和私鑰信息。
5、 根據(jù)權(quán)利要求4所述的網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)，其特征在于所述客戶端 利用認(rèn)證服務(wù)器提供的公鑰，將一個(gè)通信密鑰加密后傳送給認(rèn)證服務(wù)器， 認(rèn)證服務(wù)器通過使用密鑰來解密客戶端傳送過來的信息。
6、 一種采用權(quán)利要求l所述網(wǎng)絡(luò)身份認(rèn)證系統(tǒng)的網(wǎng)絡(luò)身份認(rèn)證方法，其 特征在于包括以下步驟(1) 、生成CA根證書和私鑰；(2) 、初始注冊(cè)；(3) 、設(shè)計(jì)認(rèn)證協(xié)議，客戶端與認(rèn)證服務(wù)器之間進(jìn)行身份認(rèn)證；(4) 、進(jìn)行數(shù)字證書認(rèn)證，對(duì)客戶端與認(rèn)證服務(wù)器端都分別進(jìn)行數(shù)字信 封的產(chǎn)生和數(shù)字證書的驗(yàn)證。
7、 根據(jù)權(quán)利要求6所述的網(wǎng)絡(luò)身份認(rèn)證方法，其特征在于所述的步驟(1) CA根證書的生成過程具體如下(1. 1. 1) CA規(guī)定證書的產(chǎn)生和頒發(fā)是分級(jí)進(jìn)行的，即由CA中心的根CA 先產(chǎn)生一個(gè)自簽的根證書；(1.1.2)由根CA產(chǎn)生下一級(jí)子CA的證書，由此繼續(xù)，從而得到最終實(shí) 體的證書，所有證書在從屬關(guān)系上形成了一個(gè)金字塔模型，每個(gè)證書都 存在于一個(gè)證書鏈中，證書從屬關(guān)系的驗(yàn)證是通過證書鏈進(jìn)行的，通常 為了保證根CA的安全，CA的層次至少為兩級(jí)，證書鏈的長度至少為3;(1. 1.3)設(shè)證書的公鑰為P，證書上的簽名為S， n為證書的編號(hào)，C為 證書，貝U Pn和Sn分別代表證書Cn上的公鑰和簽名，Cn (Pn， Sn)組 成該證書，令Verify (Pm， Sn)代表簽名的驗(yàn)證過程，若結(jié)果為TRUE， 則表示證書Cn (Pn， Sn)由證書Cm (Pm， Sm)簽發(fā)，它們之間具有從 屬關(guān)系，否則從屬關(guān)系不成立；所述的步驟(1)中私鑰的生成過程具體如下(1.2.1)計(jì)算n二pq，其中p， q是任選的兩個(gè)大素?cái)?shù)，為了獲得最大程度的安全性兩個(gè)數(shù)的長度一樣，而且必須保密；(1.2.2) 隨機(jī)選取一個(gè)整數(shù)e(公鑰)，使e和(p-1)(Q-l)互素；(1.2.3) 計(jì)算私鑰d， d=(e-1)mod((p-1) (q-l))。
8、 根據(jù)權(quán)利要求6所述的網(wǎng)絡(luò)身份認(rèn)證方法，其特征在于所述步驟(2)中的初始注冊(cè)過程具體如下管理員在認(rèn)證令牌中寫入唯一的ID號(hào)、用戶客戶端認(rèn)證信息以及 認(rèn)證服務(wù)器的公鑰，同時(shí)認(rèn)證服務(wù)器在本地的用戶信息數(shù)據(jù)庫中為用戶 生成注冊(cè)信息及在數(shù)據(jù)庫中保存用戶證書，使用戶成為網(wǎng)絡(luò)資源服務(wù)器 的合法用戶。
9、 根據(jù)權(quán)利要求6所述的網(wǎng)絡(luò)身份認(rèn)證方法，其特征在于所述的步驟(3)中的認(rèn)證協(xié)議設(shè)計(jì)具體如下本發(fā)明的認(rèn)證協(xié)議在傳統(tǒng)的動(dòng)態(tài)口令認(rèn)證機(jī)制中請(qǐng)求/應(yīng)答認(rèn)證方 式的基礎(chǔ)上，對(duì)該協(xié)議在傳輸安全性方面進(jìn)行了改進(jìn)，實(shí)現(xiàn)了客戶端和認(rèn)證服務(wù)器身份的雙向認(rèn)證；認(rèn)證協(xié)議中E表示采用了客戶端的RSA私鑰進(jìn)行簽名，H表示對(duì)產(chǎn)生的認(rèn)證隨機(jī)數(shù)的MD5散列運(yùn)算，M為本次 待認(rèn)證信息，M1=H(M);客戶端與認(rèn)證服務(wù)器之間的身份認(rèn)證過程，具體如下 (3. 1)當(dāng)用戶在客戶端登錄并向資源服務(wù)器發(fā)出資源訪問請(qǐng)求時(shí)， 系統(tǒng)提示用戶輸入用戶名和口令，并將輸入結(jié)果(UserID， Psw)發(fā)送給 控制代理模塊；(3.2)認(rèn)證服務(wù)器首先驗(yàn)證用戶名和口令，如果正確，認(rèn)證服務(wù)模 塊和客戶端按照基于動(dòng)態(tài)口令機(jī)制的認(rèn)證協(xié)議進(jìn)行雙向的身份認(rèn)證，認(rèn) 證服務(wù)模塊將產(chǎn)生并向客戶端發(fā)送一個(gè)隨機(jī)數(shù)認(rèn)證數(shù)據(jù)包作為挑戰(zhàn)，并保存此隨機(jī)數(shù)到數(shù)據(jù)庫中，如果不正確，傳回提示用戶重新輸入的信息，讓用戶端重新輸入；(3. 3)客戶端收到包含有隨機(jī)數(shù)的認(rèn)證數(shù)據(jù)包后，判斷數(shù)據(jù)包包頭信息為認(rèn)證數(shù)據(jù)包時(shí)，將該認(rèn)證請(qǐng)求發(fā)送到認(rèn)證令牌，認(rèn)證令牌接收到該認(rèn)證請(qǐng)求，系統(tǒng)提示用戶輸入私鑰保護(hù)口令，認(rèn)證令牌將向認(rèn)證服務(wù)器發(fā)起另一個(gè)認(rèn)證連接，認(rèn)證令牌根據(jù)種子值和挑戰(zhàn)隨機(jī)數(shù)，運(yùn)用隨機(jī)運(yùn)算法則生成認(rèn)證信息并調(diào)用簽名程序，對(duì)生成的認(rèn)證信息和用戶名、口令進(jìn)行簽名，形成消息E(ID，Rand，Ml)作為響應(yīng)回送給認(rèn)證服務(wù)器；(3.4)認(rèn)證服務(wù)器接收到E(ID,Rand，Ml)消息后，由認(rèn)證服務(wù)器根據(jù)用戶名在數(shù)據(jù)庫中査找口令和剛剛存儲(chǔ)的隨機(jī)數(shù)，并驗(yàn)證簽名的正確性,再將認(rèn)證結(jié)果發(fā)送給控制代理模塊，認(rèn)證過程結(jié)束。
10、根據(jù)權(quán)利要求6所述的網(wǎng)絡(luò)身份認(rèn)證方法，其特征在于所述的步驟(4)中，對(duì)客戶端身份認(rèn)證過程具體如下(4. 1. 1)用戶通過簽名或者解讀數(shù)字信封觸發(fā)對(duì)證書私鑰的請(qǐng)求；(4. 1. 2)認(rèn)證接口通過用戶登錄系統(tǒng)提交的身份證書信息從本地證書庫檢索該數(shù)字證書；(4. 1. 3)檢索到證書時(shí)將嘗試請(qǐng)求解密私鑰，此時(shí)前端用戶會(huì)接收到針對(duì)自己證書的密鑰請(qǐng)求，用戶可以輸入解密口令接受請(qǐng)求或者直接拒絕請(qǐng)求，如果檢索到證書或用戶接收請(qǐng)求時(shí)，則執(zhí)行步驟(4.1.4)，否則，執(zhí)行步驟(4.1.5);(4.1.4) 返回簽名密鑰，執(zhí)行歩驟(4.1.6);(4.1.5) 返回請(qǐng)求密鑰錯(cuò)誤狀態(tài)，執(zhí)行歩驟(4.1.6);(4.1.6) 完成請(qǐng)求；所述的步驟(4)中，對(duì)認(rèn)證服務(wù)器端身份認(rèn)證過程具體如下(4. 2. 1)服務(wù)器把自己的證書和其他進(jìn)行認(rèn)證所需要的信息傳送給用戶；(4.2.2) 客戶端檢査服務(wù)器證書的有效日期在通信的當(dāng)日是否仍然有效；(4.2.3) 客戶端檢查發(fā)放給服務(wù)器，該證書的發(fā)證機(jī)構(gòu)(CA)是否在自己的"可以信任的CA"名單內(nèi)；(4.2.4) 如果該CA對(duì)于用戶來講是可信任的，就使用這一證書帶有的公鑰來檢查該CA對(duì)服務(wù)器證書的簽名以證明服務(wù)器證書的真實(shí)性；(4. 2. 5)客戶端檢査在服務(wù)器證書中所給出的服務(wù)器域名與此次通信對(duì)象的域名是否相同；(4. 2.6)如果上述檢查均正常通過，就完成了服務(wù)器身份的認(rèn)證，否則，若上述任何一項(xiàng)檢査沒有通過，身份認(rèn)證工作失敗，執(zhí)行(4.2.7);(4.2.7) 結(jié)束。
全文摘要
本發(fā)明涉及一種身份認(rèn)證系統(tǒng)及認(rèn)證方法，所述身份認(rèn)證系統(tǒng)包括認(rèn)證中心CA模塊、認(rèn)證模塊、客戶端以及USB Key模塊，所述認(rèn)證中心CA模塊負(fù)責(zé)證書的申請(qǐng)、審批、頒發(fā)、更新和撤銷功能；所述認(rèn)證模塊分別對(duì)客戶端和服務(wù)器端進(jìn)行數(shù)字信封的產(chǎn)生和數(shù)字證書的驗(yàn)證；所述客戶端主要實(shí)現(xiàn)系統(tǒng)和客戶的管理；所述USB Key模塊主要是提供給用戶一個(gè)存儲(chǔ)數(shù)字證書和用戶私鑰的介質(zhì)。本發(fā)明采用數(shù)字信封技術(shù)，能滿足數(shù)據(jù)傳輸?shù)母弑Ｃ苄砸?；認(rèn)證令牌用于客戶端向認(rèn)證服務(wù)器發(fā)送請(qǐng)求進(jìn)行認(rèn)證，實(shí)現(xiàn)認(rèn)證過程的安全性，客戶端與認(rèn)證服務(wù)器都分別進(jìn)行數(shù)字信封的產(chǎn)生和數(shù)字證書的驗(yàn)證，能夠?qū)崿F(xiàn)客戶端到與認(rèn)證服務(wù)器之間的雙向認(rèn)證。
文檔編號(hào)H04L29/06GK101674304SQ20091015330
公開日2010年3月17日 申請(qǐng)日期2009年10月15日 優(yōu)先權(quán)日2009年10月15日
發(fā)明者俞承永, 徐慧英, 朱信忠, 趙建民 申請(qǐng)人:浙江師范大學(xué)