結(jié)合公鑰認證方案Kerberos研究(論文)_第1頁
結(jié)合公鑰認證方案Kerberos研究(論文)_第2頁
結(jié)合公鑰認證方案Kerberos研究(論文)_第3頁
結(jié)合公鑰認證方案Kerberos研究(論文)_第4頁
結(jié)合公鑰認證方案Kerberos研究(論文)_第5頁
已閱讀5頁,還剩9頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、結(jié)合公鑰認證方案的Kerberos研究摘 要:身份認證是網(wǎng)絡通信雙方在通信時驗證對方身份的技術。 Kerberos是基于可信第三方KDC使用對稱密鑰加密算法的認證協(xié)議。本文在對多種身份認證方法研究基礎上,闡述了Kerberos的原理,并分析其安全性和缺陷,提出利用Kerberos公鑰擴展方式來改善Kerberos系統(tǒng)。關鍵詞:身份認證; Kerberos;公鑰證書;PKINIT協(xié)議第一章 身份認證的研究與應用1.1身份認證概述身份認證的本質(zhì)是被認證方有一些信息,如秘密的信息、個人持有的特殊硬件、個人特有的生物學信息,除被認證方自己外,該信息不能被任何第三方偽造。如果被認證方能采用某些方法,使認

2、證方相信他確實擁有那些秘密,則他的身份就得到了認證。1.2身份認證方法的分類根據(jù)被認證方賴以證明身份的秘密的不同,身份認證方法可以分為三大類:基于秘密信息的身份認證技術,基于信物的身份認證技術和基于生物特征的身份認證技術。大致來講,有以下幾種身份認證形式:(1)根據(jù)用戶所知道的某個信息,如口令、密碼;(2)根據(jù)用戶所擁有的某個東西,用戶必須持有的合法的物理介質(zhì),如智能卡、身份證、密鑰盤;(3)根據(jù)用戶所具有的某種生物特征,如指紋、聲音、視網(wǎng)膜掃描等。l 基于口令的認證方式 基于口令的認證方式是較常用的一種技術。認證方收到口令后,將其與系統(tǒng)中存儲的用戶口令進行比較,以確認對象是否為合法訪問者。其

3、優(yōu)點在于簡單易行,一般的系統(tǒng),如Windows,Unix,Netware均提供對口令認證的支持。 但這種方式存在嚴重的安全問題。它是一種單因素的認證,安全性僅依賴于口令,口令一旦泄漏,用戶即可被冒充。也存在口令在傳輸過程中被截獲的安全隱患。2 基于信物(智能卡)的認證方式 智能卡具有硬件加密功能,有較高的安全性。每個用戶持有一張智能卡,智能卡存儲用戶個性化的秘密信息,同時在驗證服務器中也存放該秘密信息。 但其缺陷在于智能卡也可能會丟失、被復制,在這種情況下,系統(tǒng)的安全性也無從保障。3 基于生物特征的認證方式 這種認證方式以人體惟一的、可靠的、穩(wěn)定的生物特征,如指紋、虹膜、掌紋等為依據(jù),利用計算

4、機的強大功能進行圖像處理和模式識別。該技術具有很好的安全性、可靠性和有效性,與傳統(tǒng)的身份確認手段相比,無疑產(chǎn)生了質(zhì)的飛躍。但這種方案一般造價較高,適用于保密程度很高的場合。 1.3身份認證技術如何有效的將各種身份認證技術有機的結(jié)合起來,設計和開發(fā)出更安全、便捷的身份認證系統(tǒng),顯得至關重要。 目前主要有以下幾種身份認證技術。1.3.1 PAP認證(Password Authentification Protocol)PAP認證1是最基本的安全認證協(xié)議,主要是口令核對,用戶輸入用戶名、密碼的驗證過程。用戶與服務器建立連接后,服務器根據(jù)用戶輸入的信息判定是否通過認證。密碼以明文方式傳輸。1.3.2

5、CHAP認證(Challenge Handshake Authentification Protocol) CHAP認證2是一種被廣泛接受的工業(yè)標準,通過三次握手方式周期性的對被認證方的身份進行認證。其認證過程是,首先在通信雙方鏈路建立階段完成后,驗證方向客戶發(fā)送一個請求字符串,由標識符ID,隨機數(shù)據(jù),本地主機名或用戶名組成;然后,客戶方以請求的MDS哈希值作為響應;最后認證方對發(fā)回的值進行校驗,接受認證,并返回成功與否的信息。在雙方通信過程中系統(tǒng)將以隨機的時間間隔重復上述三步認證過程。 在CHAP協(xié)議的實際使用過程中,用戶為了便于記憶,往往使用容易記憶的口令,這樣的口令不能有效地抵抗攻擊者的

6、字典攻擊;而在服務器端,用戶的口令是以明文方式存放,如果攻擊者攻破服務器,那么就能輕而易舉取得用戶的口令。這些都是CHAP協(xié)議使用過程中的巨大隱患。1.3.3 一次性口令認證 一次性口令認證3在登錄過程中加入不確定的因素,使每次登錄過程中傳送的信息都不相同,以提高登錄過程安全性。 但是一次性口令認證只能防止在初次登錄到站點時的重放攻擊。認證結(jié)束之后,如果再登錄網(wǎng)內(nèi)的其他機器時,口令將以明文方式傳輸,此時口令的安全性就取決于企業(yè)內(nèi)部網(wǎng)的安全性了。并且還存在小數(shù)攻擊的問題。1.3.4 基于挑戰(zhàn)/應答(Challenge/Response)方式的身份認證機制 每次認證時認證服務器都給客戶端發(fā)送一個不

7、同的“挑戰(zhàn)”字串,客戶端收到后做出相應的應答。RADIUS(Remote Authentication Dial-In User Service)認證4就是采用這種方式,是目前撥號業(yè)務中較為成熟的一種遠程認證技術。 RADIUS認證系統(tǒng)采用基于UDP協(xié)議的客戶機/服務器模式來認證和管理遠程用戶的連接和會話,是一種集“認證、授權、審計”(AAA技術)于一體的集中式管理方法。Radius系統(tǒng)只加密用戶口令,用戶其他信息以明文方式發(fā)送。1.3.5 Kerberos認證 Kerberos5是基于可信賴第三方認證協(xié)議,是較為成熟的身份認證機制。它利用隨機產(chǎn)生的票據(jù)來獲取會話密鑰,避免了用戶口令在網(wǎng)絡上的

8、傳播,將認證從不安全的工作站轉(zhuǎn)移到集中的認證服務器上,為開放網(wǎng)絡環(huán)境中的兩個主體提供身份認證,并通過會話密鑰對通信進行加密。 Kerberos協(xié)議是當今重要的身份認證協(xié)議,優(yōu)點很明顯,但從其密鑰分配和認證過程來看,還存在以下不足之處:使用對稱算法DES(Data Encryption Standard,數(shù)據(jù)加密標準)作為協(xié)議的基礎,這就帶來了密鑰交換、密鑰存儲、以及密鑰管理的困難,N個用戶想同時通信,就需要N*(N-1)/2個密鑰;沒有提供有效抵御口令猜測攻擊的手段,同時還存在時鐘同步問題。1.3.6 X.509基于X.509證書6的認證技術類似于Kerberos技術,它也依賴于共同依賴的第三

9、方來實現(xiàn)認證,這里可依賴的第三方是指CA(Certificate Authority)的認證機構(gòu)。該認證機構(gòu)負責認證用戶的身份并向用戶簽發(fā)數(shù)字證書。數(shù)字證書遵循X.509標準所規(guī)定的格式,因此稱為X.509證書。持有此證書的用戶就可以憑此證書訪問那些信任CA的服務器?;赬.509證書的認證實際上是將個體之間的信任轉(zhuǎn)化為個體對組織機構(gòu)的信任,因此這種認證系統(tǒng)需要有CA的支持。目前,使用最多的認證方式還是最簡單的口令形式,類似于系統(tǒng)登錄過程中輸入用戶名/口令的基本認證方式系統(tǒng)事先保存每個用戶的二元組信息,進入系統(tǒng)時用戶輸入其對應的用戶名和密碼,系統(tǒng)根據(jù)保存的用戶信息與用戶輸入的信息相比較,從而判

10、斷用戶身份的合法性。其安全性僅基于用戶口令的保密性,不能有效的抵御口令猜測攻擊;并且用戶名和口令都是以明文方式在網(wǎng)絡中傳輸,極易遭受重放攻擊(Replay Attack)。攻擊者通過監(jiān)聽網(wǎng)絡連接來獲得合法用戶的登錄名和口令等認證信息,隨后利用這個獲得的登錄用戶名和口令對系統(tǒng)進行非法訪問。1.4 身份認證技術的評價身份認證在一個安全系統(tǒng)中起著至關重要的作用,因此認證技術決定了系統(tǒng)安全程度。如何評價某一認證技術,可以遵循以下幾個標準7:(l)可行性(2)認證強度(3)認證粒度(4)認證數(shù)據(jù)正確。在深入比較和分析各種認證方法的基礎上, Kerberos協(xié)議是身份認證領域中較為成熟的應用協(xié)議,具有如下

11、的一些優(yōu)點:它是基于可信賴的第三方的認證方式,適合于開放式的復雜網(wǎng)絡環(huán)境;認證過程設計合理,安全性高;采用集中的用戶帳號管理,減少了系統(tǒng)維護的負擔;采用雙向認證機制等等。第一章 Kerberos協(xié)議分析2.1 Kerberos概述Kerberos是MIT在80年代中期為其Athena8計劃開發(fā)的一種基于KDC概念和Needham-schroeder方法的分布式認證服務系統(tǒng),它可以在不安全的網(wǎng)絡環(huán)境中為用戶對遠程服務器的訪問提供自動的鑒別,數(shù)據(jù)安全性和完整性服務,以及密鑰管理服務。Kerberos的設計是針對以下要求實現(xiàn)的:(l) 安全性:網(wǎng)絡中的竊聽者不能獲得必要的信息來假冒網(wǎng)絡的用戶(2)

12、可靠性: Kerberos應該具有高度的可靠性,并采用一個系統(tǒng)支持另一個系統(tǒng)的分布式服務結(jié)構(gòu)(3) 透明性:用戶除了被要求輸入密碼外,不會覺察出認證的進行過程(4) 可擴充性: 系統(tǒng)應能夠支持更多的用戶和服務器,具有較好的伸縮性Kerberos的設計目的分為三個領域:認證、授權、記賬,可用作建造安全網(wǎng)絡的一個成分,它提供了可用于安全網(wǎng)絡環(huán)境的認證機制和加密工具9。2.2 Kerberos協(xié)議原理Kerberos系統(tǒng)要求用戶使用其用戶名和口令作為自己的標識,而客戶與服務器之間的交互則使用由對應的用戶名和口令所生成的會話密鑰。每個用戶都與KDC共享一個從自己口令中導出的密鑰,稱為主密鑰。當用戶A登

13、錄進本地系統(tǒng)的時候,便從KDC獲取一個訪問KDC所需的會話密鑰Sa和一個TGT(Ticket Granting Ticket),因此KDC又稱為TGS(Ticket Granting Server)。當A要訪問B時,便憑借所獲得的TGT向KDC申請一個臨時的會話密鑰Kab,客戶使用這個會話密鑰與對應的服務器交互。KDC自己擁有主密鑰,用于在自己頒發(fā)的各種通知單中放置一塊鑒別信息,以防止對通知單的偽造。在討論協(xié)議之前我們需要定義一些符號和概念。c:客戶機 S:服務器a:客戶的網(wǎng)絡地址 v:票據(jù)的有效時間t:時間標記 DC:密鑰分發(fā)中心 S:票據(jù)分發(fā)服務器 AS:認證服務器Kx: X與KDC的共享

14、密鑰 Kx,y: X與Y的會話密鑰Tx,y: X使用Y時的憑據(jù) Ax,y: 從X到Y(jié)的鑒別碼mKx: 用X的秘密密鑰加密的m在Kerberos V系統(tǒng)中,整個認證過程模型如圖2-1:在Kerberos認證模型中使用了兩種數(shù)據(jù)結(jié)構(gòu)作為包含有信任信息的信任狀,分別是票據(jù)Tc,s和認證標記Ac,s。它們都是基于對稱密鑰加密的,但是被不同的密鑰加密。票據(jù)被用來在身份認證服務器和應用服務器之間安全的傳遞票據(jù)使用者的身份。在圖2-1中Kerberous:基本認證過程可以分三段個階段,分別由三組消息交換來完成。2.2.1票據(jù)允許票據(jù)的獲得客戶方和AS之間的消息交換和稱為初始票據(jù)交換,這一階段完成的是客戶方向

15、KDC請求與TGS通信時使用的票據(jù)以及會話密鑰的過程,在RFC1510中被稱為認證服務交換。用戶進行網(wǎng)絡登錄時,需要輸入用戶名和口令,客戶方通過發(fā)出消息KRB_AS_REQ向AS申請TGT,AS以消息KRB_AS_REQ作為響應。KRB_AS_REQ中主要包含有客戶方名字,服務器名字和一個Nonce,這里的服務器是特殊的服務器(票據(jù)發(fā)放服務器TGS)。AS收到請求后判斷請求的客戶方確實存在,然后隨機生成一個加密密鑰Kc,tgs作為下一階段客戶方與TGS通信時使用的會話密鑰,構(gòu)造一個特殊的票據(jù)TGT。TGT中列出了客戶方,會話密鑰,以及開始和時效時間等信息,用TGS的秘密密鑰進行加密。AS將新的

16、會話密鑰和Nonce用客戶方的密鑰Kc加密,完成一個簡單的挑戰(zhàn)/響應過程以保證消息的新鮮性,再將這些消息與TGT一起構(gòu)成KRB_AS_REQ作為消息2送回給客戶方。客戶方計算機利用用戶輸入的口令變換出K。就能獲得會話密鑰Kc,tgs,并且從Nonce可以驗證該消息是新鮮的,確信獲得的TGT是剛從AS最新生成的。2.2.2服務器票據(jù)的獲得消息3和4構(gòu)成了服務器票據(jù)交換過程,使客戶方向TGS請求與最終應用服務器進行通信所需要的票據(jù)和會話密鑰的過程。票據(jù)發(fā)放服務交換是在客戶方與TGS之間進行的消息交換,當客戶方需要與某個特定的服務器進行通信時需要向TGS申請訪問該服務所需要的票據(jù)。對已有的票據(jù)進行更

17、新,確認等也可以利用這一交換。TGS交換的消息的格式與AS交換的消息的格式相類似,但是有一個顯著的區(qū)別在于這里使用的加密解密密鑰是會話密鑰而不是客戶方的共享密鑰。TGS交換由KRB_TG_REQ和KRB_TG_REP兩個消息組成在KRB_TG_REQ中包含有客戶方訪問TGS的TGT,需要訪問的服務器名字,保證消息新鮮性的Nonce以及一個身份認證者(就是用會話密鑰簽名的客戶方信息),這是為了保證這些數(shù)據(jù)在傳輸過程中沒有被篡改。TGS用自己的密鑰Ktgs驗證了TGT后獲得會話密鑰和客戶方要訪問的應用服務器名稱,從數(shù)據(jù)庫中獲得應用服務器的密鑰K:后隨機生成客戶方與應用服務器之間通信用的會話密鑰和票

18、據(jù)。TGS將客戶與服務器之間使用的新的會話密鑰和Nonce用它從客戶方發(fā)過來的TGT中獲得的會話密鑰Kc,tgs加密后與新的服務器票據(jù)一起構(gòu)成響應消息KRB_TGS_REP傳回給客戶方,完成TGS交換。2.2.3應用服務請求經(jīng)過AS交換和TGS交換后,客戶方獲得了與服務器方進行通信所需要的票據(jù)和會話密鑰。下面只要通過客戶/服務器認證交換就可以完成雙方的認證過程??蛻?服務器認證交互是由KRB_TG_REQ和KRB_AP_REP兩個消息組成的,其中后一個消息只是在需要雙向認證,服務器向客戶證實自己的身份時才使用的,對應于圖2-1中的消息5和6。KRB_AP_REQ的結(jié)構(gòu)很簡單,包含有認證者信息和

19、提交給服務器的票據(jù)。票據(jù)本身己經(jīng)完全能夠證明客戶方的身份,認證者標記這是防止票據(jù)被篡改。服務器通過解密KRB_AP_REQ中的認證者標記獲得客戶方的時間標記或者是序列號,將這些信息用會話密鑰加密后就構(gòu)成了消息KRB_AP_REP??蛻舴奖A粲凶罱舾煞昼妰?nèi)所有接收到的時間標記或者序列號的最大值,來防止重放攻擊。第三章 Kerberos協(xié)議安全分析和改進措施3.1 Kerberos協(xié)議安全分析盡管Kerberos的公開報告STEI88聲稱Kerberos具有“高度的安全性、可靠性、透明性和可伸縮性:如果系統(tǒng)自身是安全的,則Kerberos身份驗證服務就是安全的”等優(yōu)點,但從第二章的Kerbero

20、s系統(tǒng)具體的密鑰分配、認證過程和攻擊的角度來看,Kerberos的局限性也是比較明顯的10,有以下幾個方面存在不足之處:1.時間同步問題:整個Kerberos的協(xié)議都嚴重地依賴于時鐘,實際證明,要求在分布式系統(tǒng)環(huán)境中實現(xiàn)良好的時鐘同步,是一個很難的課題,而且大多數(shù)網(wǎng)絡的時間協(xié)議都是不安全的。但這并不是說Kerberos沒有出路可言。如果能夠?qū)崿F(xiàn)一種基于安全機制的時間服務,或是研制一種相對獨立于計算機和網(wǎng)絡環(huán)境、且基于一種或幾種世界標準時鐘的,能夠準確進行時間轉(zhuǎn)化和時間服務的聯(lián)機物理時鐘,這種問題將得到較好的解決。2.口令猜測問題:Kerberos的口令沒有進行額外的特殊處理,攻擊者可以收集大量

21、的許可證,通過計算和密鑰分析進行口令猜測。攻擊者使用強力攻擊(即窮舉法)的時間復雜度僅和用戶口令的長度成比例。若是增加密鑰長度換取更高的安全,會造成用戶的使用困難和增加系統(tǒng)加/解密開銷。3.認證域之間的信任問題:認證域之間的多級跳躍過程復雜且不明確,相互信任和協(xié)調(diào)不方便。若各Kerberos區(qū)域形成復雜或不規(guī)則的網(wǎng)狀結(jié)構(gòu),則要求方便的域間服務,將付出極大的代價,即系統(tǒng)的可擴充性不強。針對這種無序的狀況,應有規(guī)劃有目的地建立起全球一體化的分層(樹狀)結(jié)構(gòu),形成良好的信任鏈條。4.密鑰的存儲問題:Kerberos認證中心要求保存大量的共享私鑰,隨網(wǎng)絡用戶數(shù)量的增加,密鑰管理與分配較復雜,需要特別細

22、致的安全保護措施(甚至應采用硬件/物理方法),將付出極大的系統(tǒng)代價。5.系統(tǒng)程序的安全性、完整性問題:對Kerberos系統(tǒng)程序進行攻擊,特別是惡意篡改登錄程序,是有效的攻擊方法。所以,必須花一定的系統(tǒng)代價去防范對認證系統(tǒng)本身的集中攻擊。其中,建立高性能的防火墻和進行日志是必要的。對于以上Kerberos協(xié)議中的不足之處,加強工作可以引用執(zhí)行公開密鑰算法和密鑰管理中使用的智能卡11l接口。3.2 Kerberos結(jié)合公鑰認證方案的研究Kerberos在最初設計的時候沒有采用公鑰體系,這是因為當時應用公鑰體系的某些條件還不成熟。例如公鑰算法的復雜程度比較高,需要占用一定的CPU資源,當初的一些計

23、算機在性能上還不能滿足高效的應用公鑰算法的要求;另外公鑰基礎設施也尚不完備,與之配套的全球目錄服務系統(tǒng),證書和密鑰的管理等方面的標準也不成熟。但是隨著時間的推移和技術的發(fā)展,從安全技術的角度上來說,采用公鑰系統(tǒng)也能夠彌補對稱密鑰系統(tǒng)的一些難解決的問題,特別是在Internet環(huán)境中公鑰系統(tǒng)比對稱密鑰系統(tǒng)有著明顯的優(yōu)勢。但是公鑰體系并不能消除對于其他安全和身份認證服務的需要,也不會取代傳統(tǒng)基于KDC的身份認證系統(tǒng),特別是像Kerberos系統(tǒng)。公鑰基礎設施PKI和Kerberos都是提供身份認證和授權服務的,但是它們各有特點和適用的范圍。PKI適合在事先無法確定用戶的場合下,例如在Interne

24、t中用戶隨時可能產(chǎn)并且也無法確定用戶的具體情況,因此在電子郵件安全,電子商務事務等上邊的應用非常的適合。Kerberos適用于用戶和應用事先都已經(jīng)知道的的Intranet的環(huán)境,而PKl適合于Intranet和Extranet的網(wǎng)絡環(huán)境。因此PKI和Kerberos經(jīng)常同時出現(xiàn),使用Kerberos向網(wǎng)絡認證了用戶,然后獲得用于數(shù)字簽名等功能的公鑰證書或者私鑰數(shù)據(jù)。經(jīng)常同時出現(xiàn),使用Kerberos向網(wǎng)絡認證了用戶,然后獲得用于數(shù)字簽名等功能的公鑰證書或者私鑰數(shù)據(jù)。隨著公鑰系統(tǒng)的不斷發(fā)展和基礎設施的改進,人們提出了很多的Kerberos公鑰擴展方案,這些方案提供Kerberos與公鑰系統(tǒng)的互操

25、作性并且改善Kerberos系統(tǒng)的性能,其中包括領域間采用公鑰認證方式,利用公鑰進行預認證方式等。IETF的通用認證技術工作組提出了若干方案,如利用公鑰進行預認證PKINIT12,利用公鑰跨區(qū)域認證PKCROSS,基于公鑰的Kerberos協(xié)議PKCROSS13等。提供了Kerberos與公鑰系統(tǒng)的結(jié)合并且改善了Kerberos系統(tǒng)性能。3.2 PKINIT協(xié)議所有版本的Kerberos都在尋找在通信雙方建立安全同時維護數(shù)據(jù)的保密性和完整性同時發(fā)現(xiàn)假冒者和重放的攻擊。在Kerberos的早期版本,集中化的密鑰分發(fā)中心通過對稱密鑰加密來認證用戶,然后給這個用戶一個共享密鑰來與服務器進行后續(xù)的通信

26、。這會潛在引起KDC成為整個系統(tǒng)的瓶頸同時單個登陸點的失敗會引起整個系統(tǒng)的崩潰。另外在Kerberos基本協(xié)議中每一次客戶向AS要求票據(jù)允許票據(jù)時,票據(jù)允許票據(jù)總是由一個長期的客戶方與AS共享的密鑰加密,這個密鑰是由用戶口令經(jīng)過計算產(chǎn)生的。但是由于用戶趨向于選擇的低質(zhì)量容易記憶的口令,所以共享密鑰容易遭受到字典猜測攻擊,成了整個Kerberos系統(tǒng)的安全弱點。PKINIT協(xié)議試圖利用引入基于X.509的公鑰證書來克服這個弱點。在初始認證階段AS_REQ和AS_REP消息中使用公鑰機制,后續(xù)的消息操作繼續(xù)使用原來的Kerberos的協(xié)議。PKINIT協(xié)議消息交互過程如下:PKINIT利用Kerb

27、eros版本5中的PA(Pre-authentication)域。用戶同往常一樣向KDC發(fā)出認證請求,所不同的是用戶在初始認證步驟中使用公鑰體系,他的證書初始認證的PA域中。KDC接收到認證請求后,驗證用戶的公鑰證書與往常一樣簽發(fā)TGT,但是不是使用用戶的長期的密鑰進行加密,而是使用隨機生成的密鑰。該隨機密鑰用用戶證書中的公鑰進行加密并且用KDC的私鑰進行簽名,出現(xiàn)在響應信息的PA域。AS_REQ *這個消息定義公鑰數(shù)據(jù)的傳輸PA_PK_AS_REQ,客戶端發(fā)送公鑰證書和證書鏈(用戶證書user Cert)在用戶和KDC之間建立信任,以及傳播用戶的公鑰。公鑰可以由證書權威簽發(fā),如果KDC是受信

28、任的權威也可以由KDC來維護公鑰。初始認證的PA域中包含的數(shù)據(jù)內(nèi)容有:PA_PK_AS_REQ=signedAuthPack,trustedCertificates,kdcCert,encryptionCertSignedAuthPack是客戶端用私鑰簽名的認證數(shù)據(jù)結(jié)構(gòu)。這個數(shù)據(jù)結(jié)構(gòu)由AuthPack數(shù)據(jù)以及用戶用私鑰對其的簽名信息(signerInfos)構(gòu)成。而AuthPack由隨機數(shù),客戶方時間,校驗和等內(nèi)容組成,以防止重放攻擊。trustedCertifiers是客戶端信任的CA列表。kdcCert指明了客戶端己經(jīng)擁用的KDC證書。encryptionCert主要用于客戶端的Diffi

29、e-Hellman證書。整個信息包含在Kerberos預認證字段為支持協(xié)議擴展而定義的。AS_REP*這個消息定義了KDC向客戶端返回的消息PA_PK_AS_REP。KDC通過驗證SignedAuthPack的數(shù)字簽名來證實用戶的身份。通過驗證之后,KDC返回給用戶一個用用戶公鑰加密KDC的公鑰的證書鏈(kdcCert),KDC的數(shù)字簽名(SignedReplyKeyPack)和會話密鑰(encTmpKeyPack)的消息。KDC加密的票據(jù)允許票據(jù)響應消息不是用與用戶長期共享的密鑰,而是產(chǎn)生一個隨機密鑰來加密響應消息,然后對隨機密鑰使用用戶公鑰加密和KDC的私鑰簽名。客戶端驗證數(shù)字簽名可以確定

30、KDC的身份和獲取TGT。用戶從AS_REP*消息中獲取的TGT和基本Kerberos沒有區(qū)別,所以后面消息交互3,4,5使用傳統(tǒng)的Kerberos的消息處理。從上述的消息交互分析過程中可以看出,與Kerberos基本認證協(xié)議相比PKINIT只對前兩條認證消息中用PA數(shù)據(jù)類型進行公鑰信息交換,實現(xiàn)上對Kerberos改動很少。3.3現(xiàn)有方法的不足之處PKINIT的主要目的是為Kerberos提供公鑰初始認證的解決方案。采用公開密鑰證書,一個客戶方可以向KDC證明自己的身份并且獲得TGT,TGT能使客戶方獲得對Kerberos化服務的服務票據(jù)。與Kerberos標準協(xié)議相比在PKINIT中AS_

31、REQ和AS_REP消息都保持了原狀,PKINIT只是在初始消息、交換利用了新的PA數(shù)據(jù)類型來進行公鑰信息交換。由于Kerberos版本4中KDC對于任何人發(fā)出的認證請求都給予響應,有人指出應該讓請求服務的一方首先證明自己的身份,因此在Kerberos版本5中加入了PA域。PKINIT協(xié)議就利用了PA域進行客戶和服務器公鑰證書的交換,證書的交換、公鑰認證和TGT的傳遞在兩個消息中就能夠完成。以上的Kerberos公鑰結(jié)合方案還是存在一下的不足之處:(l)PKINIT協(xié)議雖然是一個高效的公鑰結(jié)合機制,但是PKINIT只描述了標準Kerberos認證協(xié)議中使用的消息語法,所有的私鑰和公鑰都由KDC

32、直接管理,沒有結(jié)合PKI來管理證書或者撤消列表。這樣限制了PKINIT的應用范圍。(2)在Kerberos基本認證過程6個消息中有4個需要KDC參與。Kerberos結(jié)合公鑰密碼后,KDC的用于公鑰密碼的計算量比原來對稱密鑰要增大,當用戶認證請求增多時,KDC可能成為整個系統(tǒng)中計算瓶頸的潛在因素,導致影響整個系統(tǒng)的性能。小結(jié)本章對身份認證方法和技術及Kerberos協(xié)議的安全性和缺陷作了分析。Kerberos存在“時間同步、口令攻擊、沒有提供用戶對KBS和TGS的認證、不能分別處理認證信息與保密信息、密鑰管理工作繁重”等缺點。嚴重的局限了Kerberos系統(tǒng)在Internet環(huán)境下的應用。隨著公鑰基礎設施的不斷發(fā)展改進,提出利用公鑰進行預認證PKINIT,提供Kerberos與公鑰系統(tǒng)的互操作性并且改善Kerberos系統(tǒng)的性能。參考文獻:曹璞. 基于公鑰密碼的Kerberos認證協(xié)議研究. 2000. J/OL.許建. 基于Kerberos的身份認證機制研究. 2004. J/OL.1 RFC 1334. PPP Authentication Protocols.2 RFC 1994. PPP Challenge Handshake Authentication Protocols(CHAP).3 RFC

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論