密碼協(xié)議書稿中文第5章

個好的協(xié)議，既適合應(yīng)用又具有強安全屬性是非常有性的工作。有助讀者深度理解可信任新鮮性方法，并應(yīng)用該方法對實際的協(xié)議進行安全強度評估?；ヂ?lián)網(wǎng)是由計算機節(jié)點和設(shè)備組成的一個巨大的開放式網(wǎng)絡(luò)。為了應(yīng)對復(fù)雜的網(wǎng)絡(luò)，級之間的通信以及計算機網(wǎng)絡(luò)協(xié)議設(shè)計的抽象描述。在其最基本的形式中，網(wǎng)絡(luò)結(jié)構(gòu)被分為7個層級，從分別為：應(yīng)用層，表示層，會話層，傳輸層，網(wǎng)絡(luò)層，數(shù)據(jù)鏈路層及 net/ftp:ssh, net/ftp:ssh,http:https,傳輸層圖5.1持系統(tǒng)向后兼容性，協(xié)議的改變應(yīng)該對系統(tǒng)影響盡量的小[13]。例如：SSL協(xié)議避免了修改”TCP?！盜PSec對于應(yīng)用是中，要設(shè)計出一個好的協(xié)議，既適合應(yīng)用又具有強安全屬性是非常有性的工作。Layer）就是在將Http和SSL相結(jié)合，為Web瀏覽器提供數(shù)據(jù)性和完整性服務(wù)，例如在網(wǎng)Security別在年和年推出TLS1.1（RFC4346，TLS1.2（RFC5246。SSL還有考慮互操作性，可擴展性以及相關(guān)的效率等。SSL協(xié)議允許客戶端/服務(wù)器端在一定的方式下通信，能夠防范、竄改、等。SSL握手協(xié)議可以被認為是一個在客SSL協(xié)議在較上一層的密鑰交換協(xié)議，能夠在兩個應(yīng)用端初始化密鑰，并同步其狀態(tài)。在執(zhí)行完密鑰交換協(xié)議可以被透明地在SSL協(xié)議之上執(zhí)行，無需用戶參與。用來加密以及SSL記錄完整性的操作，是通過一個套件所決定。一個典型的例子是，使用DES算法加密數(shù)據(jù)，并8 8 8 16 16384字其中的類型是所封裝段使用的上層協(xié)議，用十進制標識，例如：20SSL握手協(xié)議是SSL記錄協(xié)議之上的一個高端協(xié)議。SSL握手協(xié)議允許服務(wù)器和客戶端8 5.1SSL導致出錯告警。數(shù)據(jù)握手進程由如圖5.2所示步驟展開。圖5.2完整的SSL 消息1（o消息32UNIX格式的時間戳和一個由客戶端生成的28字節(jié)隨機數(shù)套件，o.cipher_suites是一系列客戶端支持的選項，這些選項按enum{true,false}I enum{null,rc4,rc2,des,3des,des40,fortezza}enum{null,md5,sha}MACAlgorithm;struct{BulkCipherAlgorithmbulkcipheralgorithm;MACAlgorithmmacalgorithm;CipherTypecipher uint8hashsize;uint8IVsize;}消息 o消息SessionID來會話沒有被因此也不能被恢復(fù)。（1）Server消息：如果密鑰交換方法不是的，當服務(wù)器需要被認證時(通常情況是這樣)，服務(wù)器在發(fā)送出Servero后馬上發(fā)送一個。通常是一個X.509V3中包含了足夠的關(guān)于、所有者的公鑰以及簽發(fā)機構(gòu)的信息。服務(wù)器發(fā)送系列證⑵消息將由RSA公鑰或者Diffie-man公鑰加密后發(fā)送。ServerKeyExchange消息中包含了服務(wù)器的生成公鑰的成分，這些成分與Server中列表的公鑰材料匹配。用于Diffie-man密鑰協(xié)商的成分在需要時也包含在三元組（p,g,gy）中，其中p是大素數(shù)模，g⑶Request消 Request消息給客戶，向客戶端要求一個。這條消息將直接接在Server 消息之后，或者在ServerKeyExchange消息。Request消息將會詳細說明服務(wù)器端接受的的類型，以及服務(wù)器端信任的簽發(fā) o階段消息的數(shù)據(jù)傳送，消息3（消息⑴KeyExchange消 man,此時將會送出公鑰參數(shù)⑵Verify消在大多數(shù)的例子中，如果客戶端發(fā)送出了一個，則它在此時也將發(fā)送一Verify消息。這條消息中可能包含一個和ServerKeyMessage消息中格式相同的簽ChangeCipherSpecFinished節(jié)數(shù)字的主密鑰master_secret。+o.random+Servero.random))+MD5(pre_master_secret+SHA(‘BB’+pre_master_secret+o.random+Servero.random))+MD5(pre_master_secret+SHA(‘CCC’+pre_master_secret+o.random+Server（d）4（ChangeCipherSpec&Finished消息ChangeCipherSpecFinished消息，以便允許客戶端確認服出現(xiàn)的警報值如表5.2所示。5.2SSL計算key_block值，直到足夠多的輸出值生成。KeyMD5(mastersecret+SHA(‘A’+mastersecret+Servero.random++[.._write_IV[CipherSpec.IV_size]/*non-exportciphers*/server_write_IV[CipherSpec.IV_size]/*non-exportciphers*/性的缺失給出針對SSL協(xié)議的。另外，針對TLS再協(xié)商協(xié)議的也作簡要介紹。例5.1（完整的帶雙方認證的SSL握手協(xié)議）。當一個新的會話開始后，SSL中的加5.3給出SSL握手協(xié)議中與認證及密鑰建立相關(guān)的圖5.3完整的帶雙方認證的SSL握手協(xié)C表示一個客戶端（例如客戶端的Web瀏覽器），S表示一個Web服務(wù)器。VerC戶端發(fā)送的o消息中所要求的協(xié)議版本。VerS表示被使用的協(xié)議版本（即服務(wù)器個絕對時間相關(guān)的時間戳，在這里時鐘并不需要由基本的SSL協(xié)議來設(shè)定正確，但是書不對pre_master_secret,master_secret和其他的為加密和MAC計算所設(shè)置的密鑰和信息SSCC 對，即C擁有KCK1，S擁有KSK1 NS，并發(fā)送C,NC,NSK1給服務(wù)器方SCSSC,NC,NSK1

C 送給Ck k上，這個協(xié)議并沒有達到事先所期望的安全密鑰交換和認證的目標。于只有C能使用它的私鑰K1對消息進行簽名N,N，且C的 C SKCK確 了，S將會相信kCS是和C相關(guān)聯(lián)的。S在收到NC,NS1后，由引理4.1可得KC認為NS是新鮮的。由引理4，由于只有S可以使用它的私鑰K1從密文k CS且S的在消息4中被明確地了，將相信、S、kCS和主體S是相關(guān)聯(lián)的。 例5.2（1-對完整的帶雙方認證的SSL握手協(xié)議的）從S的角度看，kCS與S圖5.4對完整的帶雙方認證的SSL握手協(xié)議的用來II 己的密鑰對，如C知道KCK1，S知道KSK1，I知道KIK 消息1，并成C與S開始在（的）C和S之間運行協(xié)議。代CertS，并將消息2即VerS,TSNSSIDSCertI發(fā)送給C。C在收到消息2后，C為C和I之間的協(xié)議運行隨機選擇了一個新的會話密鑰kCS，并用I的公鑰KI加密kCS發(fā)送給I。在消息3中，C使用CK1生成了NN來表明它是CC真正的C，并發(fā)送了消息C,NC,NSK1C

。

SKII加密kCS，生成了消息3’kCSKCertC,NCNSK1和C,NCNSK1

C在收到消息3’后，SK1得到了kCS，并且在驗證完NNS認為與C SKC在這整個結(jié)束后，者I使得S產(chǎn)生了錯誤的信任：S錯誤的認為自己與C完成了一次成功的協(xié)議運行，且與C共享了一個新的會話密鑰kCS。事實上，C對于I(C)和S之間的這次密鑰建立一無所知，CI新協(xié)商了一個會話密鑰kCSS錯誤地認例5.3（針對完整的帶雙方認證的SSL握手協(xié)議的）從C的角度來看，kCS與C主圖5.5對完整的帶雙方認證的SSL握手協(xié)議的用來IKI，它們都由機構(gòu)CA簽發(fā)。KI和K1分別是I的公鑰和私鑰。其他的符號和原I 道它自己的密鑰對，如C知道KCK1，S知道KSK1，I知道KIK 在消息1中，客戶端C發(fā)起了一個C和S之間的協(xié)議運行。者I截獲了消息1，并把它替換成CertI，并把消息2VerS,TS,NSSIDSCertI發(fā)送給了C。kCS

,CertC,NC,NSK1,C,NC,NSK1

。 III使得S和CC和S均認為他們和對方成功地完成了協(xié)議運行，并與對方了新的會話密鑰kCS，然而，事實上C和S之間的共享密鑰kCS已經(jīng)被I所掌握。在SSL握手協(xié)議的一次運行中，客戶端可能會選擇，從而客戶端不需要被服務(wù)當中可能包含信息，如客戶的信息，書名和交貨地址等[13]。向客戶端回復(fù)相同的ID，即與客戶端o消息中提供的ID相同。這表明會話恢復(fù)正在進行中，并會話雙方必須直接運行接下來的finished消息，且忽略所有的可選消息及 存，在其中尋找相應(yīng)的匹配。如果一個相應(yīng)的匹配被找到了，則服務(wù)器將會基于相應(yīng) ，同樣發(fā)送給SSSCNC,NS 在消息4中，將它 與隨機數(shù)、S一起加密，并發(fā)送S,NS,NC 給C CSkCS，且S的在消息4中被明確地了，S認為NC,NS,kCS與S是相關(guān)聯(lián)的。 例5.4（針對SSL再協(xié)商協(xié)議的）從S的角度來看，C通信的真實性是缺失的，因此可以構(gòu)建如下：圖5.7對SSL再協(xié)商協(xié)議的用來在消息1中，者I通過成C開始了SSL再協(xié)商的過程，它想要恢復(fù)一個與C的已在收到消息1后，S在它的會話緩存中查找匹配的會話ID，并回復(fù)消息2給成C的攻密鑰kCS，并將kCS用KS加密后發(fā)送給S。I(C)同樣將之前發(fā)送的握手信息使用kCS加密后在收到消息3后，S使用它的私鑰K1得到新的會話密鑰kCS，并驗證C,N,N S

S在這個對于SSL再協(xié)商協(xié)議的結(jié)束后，者I使得S產(chǎn)生了錯誤的信任：S與C完成了一次成功的協(xié)議運行，且與C了一個新的會話密鑰kCS。事實上，C對于此事（建立C和S之間的會話密鑰）一無所知，只是S是與I了新會話密鑰kCS。此外，S認為用kCS以上的可以由者I直接成合法客戶端C所啟動，甚至并不需要C。這個例子對于者來說或許很有，因為它允許者在任何時間發(fā)起一次，且這TLS（包含RFC5246以及之前版本，SSLV3以及之前的版本）在現(xiàn)實世界中容易與再有三種針對HTTPS協(xié)議再協(xié)商的一般，這三種之間有細微的不同。但這三種攻擊都能達成一個結(jié)果：者有能力執(zhí)行一個HTTP，并被合法的用戶（即中間人例5.5（針對客戶端認證的再協(xié)商）服務(wù)器無法確定客戶端是否提供了一個有效的認證，除非它收到了客戶端的請求，并且通過它的認證規(guī)則將其過濾。對于需要客戶端認證的請求，HTTPS服務(wù)器必須通過重建TLS信道來獲取客戶端的并使HTTPS缺乏特定的回復(fù)代碼來告知客戶端重發(fā)一個帶有新的已認例5.6（針對不同服務(wù)器需求差異的再協(xié)商）管理資源的HTTPS服務(wù)器有不同的密碼套件需求，可能在另一種再協(xié)商下很脆弱。由于對套件安全強度的需求不同，Web服務(wù)器常常在協(xié)商TLS連接時選擇支持一個最基本的強度。只有在看到客戶端的URL請求后，服務(wù)器才能準確的決定采用哪一種套件。如果當前的套件并不是所人所建立的協(xié)議執(zhí)行被認證通過。IPSec有兩種模式：傳輸模式（在兩個主機之間）和隧道模式（在主機和內(nèi)）；EncapsulatingSeurityPayload,RFC2406[18]）和互聯(lián)網(wǎng)密鑰交換協(xié)議（IKE,InternetKeyExchangeProtocol,RFC2409[19]）。AH提供完整性保護，ESP提供性服務(wù)和可選的完整性“認證頭”(AH)的附加域[17,20]。認證保護（事實上是指帶有源的數(shù)據(jù)完整性）是IPSec的強制性服務(wù)。在IP數(shù)據(jù)包中，AH的位置位于“IP頭”和“TCP域”之間（見圖5.8圖5.8AH的結(jié)構(gòu)及其在傳輸模式下在IP圖5.9AH的結(jié)構(gòu)及其在隧道模式下在IP性（加密）保護是Ic的一個可選服務(wù)。為實現(xiàn)這一服務(wù)，數(shù)據(jù)包中由一個32位倍數(shù)長的數(shù)據(jù)報來提供這一服務(wù)，該數(shù)據(jù)塊被命名為“封裝安全載荷（S）”[19。P在P（見圖5.105.1（注意S也可以跟在后TC域”之間。S的格式如圖5.所示。圖 圖 圖 第二個子域被稱作“序列號”（SequenceNumber），它可以用于防止對IP包的重放。第三個子域被稱作“載荷數(shù)據(jù)”（PayloadData），它的長度是不確定的，用于表示機’值為‘FF’，即255(10)。填充數(shù)據(jù)的字節(jié)長度稱為“填充長度”（PadLength）?；ヂ?lián)網(wǎng)密鑰交換（InternetKeyExchange,IKE）是由國際標準組織為互聯(lián)網(wǎng)安全SA），而且可以為SNMPv3、RIPv2、OSPFv2等任何要求的協(xié)議協(xié)商安全參數(shù)。和管理安全關(guān)聯(lián)（SecurityAssociation,SA,包括密鑰、算法和參數(shù)），認證雙方分有能力進行簽名的驗證，公鑰（即）應(yīng)該是受到信任的和可核實的。SA定義了兩個主5.1（安全關(guān)聯(lián)，SA）SA，簡單地說SA就是兩網(wǎng)安全關(guān)聯(lián)和密鑰交換協(xié)議”（InternetSecurityAssociationandKeyManagementProtocol,ISAKMP）[RFC2408][21]，“Oakley密鑰確定協(xié)議”（OakleyKeyDeterminationProtocol,OAKLEY）[RFC2412][22]以及“通用互聯(lián)網(wǎng)安全密鑰交換體制”（VersatileSecureKeyExchangeMechanismforInternet,SKEME）[23]。以及如何降低的可能（例如，服務(wù)和重放）。然而，ISAKMP沒有提IKE鑰。對于IKE階段1，IKE有幾種密鑰交換模式，包括主模式、進取模式、基本模式和新組階段1假設(shè)參與密鑰交換的雙方中的任意一方都能夠驗證另一方的能力，這種的私鑰獲得。階段1通過向通信對方發(fā)送證明其能力的IKE階段消息，試圖認證對方，僅僅5.2（IKE密鑰材料）SKEYID是一個字符串，它來源于消息交換中僅被活現(xiàn)的參與者對于簽名公鑰：SKEYIDprf(noncesgxymod對于加密公鑰：SKEYID=prf(hash(nonces),對于預(yù)共享的密鑰：SKEYIDprf(pre-sharedsecretkey對于生成其他密鑰的：SKEYID_d=prf(SKEYID,gxy∣ 對于完整性密鑰：SKEYID_a=prf(SKEYID, 對于加密密鑰：SKEYID_e=prf(SKEYID, man機制中的共享。種最常用的模式。主模式（MM）包括六條消息交換，在階段1種密鑰類型，在IKE階段1IKE階段1一共，IKE階段1結(jié)果可以有多種稱謂：Phase-1SA,ISAKMPSA,IKESA等。他們都意味著同樣的東西。Phase-1SA也用于保護階段2協(xié)商過程以及在IKE中其他可能會送出的信息通知。圖5.13IKE階段1R是一個ISAMPESA用來列出發(fā)起者和響應(yīng)者所分（yxn,E負載是Difie-a換-nE都用于在E中計算Phase1SA的數(shù)CR載示請包含C（機構(gòu)D負載是用來告訴其它方發(fā)送者或者響應(yīng)者是誰。CERT負載包含了發(fā)送者或者響應(yīng)者的終端實體證書，而且可能用來發(fā)送撤銷表RL。簽名負載IG是其他方必須驗證的數(shù)字簽名。*表示該內(nèi)容是否被發(fā)送是可選的，或者是依具體情況而定。 IKE協(xié)議基于Diffie-man密鑰交換算法，這是最早的公鑰算法（1976年）。消息3用于在密鑰交換(KE)負載內(nèi)交換Diffie-man公鑰。每當階段1的協(xié)商執(zhí)行時，Diffie-man公鑰將自動被創(chuàng)建，且在Phase-1SA銷毀后自動銷毀。息一起）用于在IKE計算Phase-1SA中的數(shù)據(jù)。隨機數(shù)NONCE負載包含由隨機數(shù)CR負載包含CA的名稱，這個CA將能簽發(fā)它想要接收到的終端實體的（通信對手的）。如果CR負載是空的，這意味著它請求來自任意CA的任意（即對CA和在消息4在消息5發(fā)送CERT負載也會導致IKE協(xié)商。 書的者（機構(gòu)，CA）是否可信，也核實是否有效（并非被撤銷的），等在消息6Diffie-man公共值被計算得出，從而可以計算生成密鑰。在對通信進行保護時，ISAKMP在這些數(shù)據(jù)包被發(fā)送且數(shù)字簽名被成功驗證后，這個階段1的協(xié)商結(jié)果就是Phase-1圖5.14IKE階段1數(shù)據(jù)，并表明它的。哈希算法和其他能保護IP通信的安全屬性。階段1的提案僅僅只是為了保護Phase-1SA快速模式，它用于保護實際的IP通信。由于ISAKMPSA是雙向的，因此任一通信參與者都圖5.15IKE階段2 ID負載，標記為IDI和IDR,分別表示發(fā)起者的ID和響應(yīng)者的ID。ID負載在階段2中是可之為“人ID”（ID），“偽ID”（pseudoID）或其他類似稱呼，因為他們并不一定表示實際參與協(xié)商的主體，例如安全網(wǎng)關(guān)SecurityGateway(SGW)代表某個客戶端參與協(xié)在發(fā)送完最后一個數(shù)據(jù)包消息3后，IKE階段2就完成了，階段2的運行結(jié)果是形成了兩例5.8（IKE階段1主模式）IKE階段1主模式中與認證和密鑰建立圖 SAA和SAB分別是A和B的安全關(guān)聯(lián)。A和B使用SAA,SABx和y分別是由發(fā)起者A和響應(yīng)者B隨機選擇的私有值。gx,gy分別表示A和B IDA和IDB分別是A和B的終端。HASHA=prf1HASHB=prf1 ，B通過CA來A的會話狀態(tài)信息，CB的作用亦然。注意本書不對SKEYID，SKEYID_d,SKEYID_a,SKEYID_g等進行嚴格區(qū)分，因為后面是撤銷的等等）。這意味著他們知道CA的公鑰，即都能得到A的KA和B的KB。每一 機數(shù)）。此時，A和B都能計算出新會話密鑰。SKEYID=prf2(NA∣NB∣gxy)。AA密鑰SKEYID將跟在ISAKMP頭后面的所有負載即IDA,CertA,HASHAK在收到消息5后，B使用SKEYID將收到的密文IDA,CertA,HASHAK

HASHAK

HASHAprf1SKEYIDgxgyCACBSAAIDAK協(xié)議的成功執(zhí)行將能認證通信參與者A和B的，并在A和B之間建立一個新會話密 隨機數(shù)NA的新鮮性，且A也認為x是的而NA是不的。 有值y的性和新鮮性，并確信隨機數(shù)NB是新鮮的和不的。此時，B還計算了新在收到消息4后，由引理4.2可得，A認為NB是不的而y是的。此時，A也計算了新會話密鑰SKEYIDprf2NA∣NB∣gxy)，且由引理4.2和引理4.3可得，A能確信SKEYID由于只有A能使用A的私鑰對新鮮的哈希值HASHA=prf1(SKEYID∣gx∣gy∣CA∣CB∣在這整個協(xié)議運行結(jié)束后，A相信主體B是活現(xiàn)的，新的會話密鑰SKEYID是的，新鮮的并與B相關(guān)聯(lián)的。而B相信A是活現(xiàn)的，新的會話密鑰SKEYID是的，新鮮的，并表5.5對IKE階段1圖 己和A一起成功執(zhí)行了一次IKE協(xié)議，并與A共享了一個新的會話密鑰SKEYIDA事實上對于和B建立密鑰的事情一無所知，A只是認為它和I之間的協(xié)議運行因為某種原因沒這個與其同伙一道同時對某個服務(wù)器展開，從而能有效地啟動服務(wù)[24]。5.3的 圖 [x表示內(nèi)容x是可選的，IKE階段1進取模式下的符號、前提和協(xié)議動作和主模式下的NB是新鮮的，但不。此時，B可以計算得到新會話密鑰SKEYIDprf2NA|NB|gxy，由引理4.2和引理4.3可得，B能夠確信SKEYID的 份在消息2中被明確，所以A能夠確信SKEYID和B之間的關(guān)聯(lián)性。類似的，在收到消息3后，由于B知道NB和SKEYIDprf2NA∣NB∣gxy)都鮮性，且只有A能夠用其私鑰對哈希值HASHAprf1SKEYID|gx|gy|CA|CB|SAA|IDA)進行簽名，由引理4.1可得，B能夠確信A的主體活現(xiàn)性。再由引理4.4，由于只有A能夠使用在協(xié)議成功的運行完成后，A認為B是主體活現(xiàn)的，即B真實參與了通信，且新會話密鑰SKEYID是的、新鮮的，并與主體B相關(guān)聯(lián)。而B也相信A是主體活現(xiàn)的，即A真實參與表 注意HASHA和HASHB都采用新會話密鑰SKEYID作為它們的偽隨機函數(shù)的，因此這兩個哈希值的簽名不可能被，而且這些簽名只有掌握了新會話密鑰的主體才能進行驗證。不幸的是，針對IKE主模式的（例5.9-1）對IKE進取模式仍然有效。例5.11（IKE階段2快速模式）圖 ] kprfSKEYID_d,gxy|protocol|SPI|N| HASH1=prf(SKEYID_a,IDAB∣SAA∣NA[∣gx][∣IDA∣IDB])IDAB是消息ID，用于標志對于一個特定的ISAKMPSA正在運行的快速模式，這個特定 gxy來源于階段1主模式中的Diffie-man交換，它在快速模式中是的。假設(shè)來自主模式的密鑰SKEYID_a是的，只有A和B知道SKEYID_a。其他前提和階段1主模式中的前類似的，在消息2中，由引理4.2和引理4.3可得，B能夠確信隨機數(shù)NB的新鮮性，也能所以B能夠確信NB,y和k是與A和B關(guān)聯(lián)。在收到消息2后，基于A信任的新鮮性A，由引理42、引理43和引理4可得，A相信k是的、新鮮的，且與A和B相關(guān)聯(lián)。基于A信任的新鮮性A，由引理41可得，因為只有B能使用共享密鑰SEYI_a來生成新鮮的哈希值S2prfSKYIa,B∣NA類似的，在收到消息3后，基于B信任的新鮮性標識符NB，由引理4.1，因為HASH3=,)表5.7對IKE階段2標--密鑰交換和認證。然而，我們應(yīng)該注意：如果來自主模式的gxy在快速模式中不是的，即如果gxy被攻擊者獲得，則者可以假裝主體A或B在任何時間發(fā)起運行一個快速模式，并與被的Kerberos的。因此，麻省理工學院研究人員提出了Kerberos系統(tǒng)，以作為開放網(wǎng)絡(luò)環(huán)境下安全問題的解決方案：Kerberos系統(tǒng)借助一個位于用戶和資源服務(wù)器之間的可信任第，在端服務(wù)器接收一個文件，Kerberos將不再需要與用戶直接進行交互操作，服務(wù)器就可以完成所需的認證。強大的認證，客戶端可以在非安全的分布式環(huán)境中證明自己的。當客戶端通過Kerberos向服務(wù)器證明了自己的后，在之后客戶端與服務(wù)器開展業(yè)務(wù)往來時，可以對他供認證，并為隨后的信息提供加密和簽名服務(wù)，這類系統(tǒng)也稱作被Kerberos化。Kerberos通常是使用傳統(tǒng)加密，即對稱。PKINIT協(xié)議[26]，它擴展了基礎(chǔ)Kerberos協(xié)議，將基于公--通常是個人用戶，與其他三種類同的應(yīng)用服務(wù)器進行認證（例如：服務(wù)器、文件服務(wù)器、打印服務(wù)器等）。為實現(xiàn)這一目標，客戶端首先從“Kerberos認證服務(wù)器”AS(KerberosAuthenticationServer)獲取一個“票據(jù)授予票據(jù)”TGT(Ticket-grantingticket)，然后客戶端將這個票據(jù)TGT展示給“票據(jù)授予服務(wù)器”TGS(Ticket-GrantingServer)來獲取一個“服務(wù)票據(jù)”ST(Serviceticket)。ST是一個，該是客戶端用來讓他自己和應(yīng)用服務(wù)器之間進行認證的。AS和TGS在一起組成“密鑰分配中心”KDC(KeyDistributionCenter)。Kerberos認證比LM認證（LANManager）和NTLM認證（NTLANManager）更安全，因為用戶的口令不會在網(wǎng)絡(luò)中傳輸，無論是加密的口令還是明文口令；Kerberos認證中的臨時會話密鑰以密文的形式在網(wǎng)絡(luò)上傳輸，客戶端和服務(wù)器端相互進行認證，并且在Windows2000中，56位的DES和128位的RC4在Kerberos中是最常用的；在WindowsServer2003中，普遍使用RC4-HMAC，DES-CBC-CRCDES-CBC-MD5；在WindowsXP中，常用RC4，其他的加密算法也被允許，尤其是使用DESWindowsVista中，常常使用256位的AES,3DES,SHA2等。（KDC）。KDC本身由兩個子服務(wù)組成：認證服務(wù)和票據(jù)授予服務(wù)。在Windows2000和WindowsServer2003中，這兩種服務(wù)都在KDC服務(wù)器上運行。然而在其他Kerberos實現(xiàn)中，注釋5.3密鑰分發(fā)中心KDC（KeyDistributionCenter）由認證服務(wù)器（AS）和票據(jù)授予他們在給定域上的密鑰。例如，KerberosKDC運行在每一個Windows2000域控務(wù)器和Windows2003域控務(wù)器上。注釋5.4認證服務(wù)器AS（AuthenticationServer）對客戶端的登錄進行認證，并為對客戶注釋5.5票據(jù)授予服務(wù)器TGS（TicketGrantingServer）負責受理和核實客戶端從AS獲得注釋5.6應(yīng)用服務(wù)器S（ApplicationServer）負責接收和驗證從TGS得來的服務(wù)票據(jù)ST，注釋5.7客戶端C（）是一個客戶端（一個用戶進程），它代表用戶U來使用網(wǎng)絡(luò)的注釋5.8票據(jù)（或者Kerberos票據(jù)）是協(xié)議中的加密消息，它用來確定終端參與者的，5.9認證元（或認證符）認證元是包含有時間戳的認證憑證，其中時間戳被客戶端和AS之間、或者客戶端和應(yīng)用服務(wù)器之間的共享會話密鑰加密。認證元在使用時，過注釋5.10票據(jù)授予票據(jù)TGT（TicketGrantingTicket）由認證服務(wù)器（AS），其中注釋5.11屬性PAC（PrivilegeAttribute）在Windows2000Kerberos注釋5.12服務(wù)票據(jù)ST（ServiceTicket）由票據(jù)授予服務(wù)器（TGS），它可為特定的圖 I階段1消息2：AS在數(shù)據(jù)庫中查找在AS_REQ請求中的客戶端和服務(wù)器的主體，分別提取II階段2（以檢測消息的重放）并恢復(fù)會話密鑰kc,tgskc,tgs創(chuàng)建一個認證元，這個認證會話密鑰kc,sKerberos數(shù)據(jù)庫被檢索，為請求的服務(wù)器恢復(fù)記錄，然后TGS創(chuàng)建一個III階段3客戶端/至此，應(yīng)用服務(wù)器S和客戶端C已經(jīng)認證了對宣稱的，并且完成了新加密密鑰Kerberosv5是在20世紀90年代初的版本，在這以后Kerberos沒有再做改變[6,27]，它可用于所有主流的操作系統(tǒng)：微軟的Windows2000，微軟的WindowsServer2003，和許多UNIX和類UNIX操作系統(tǒng)，包括BSD，蘋果的MacOSX，RedHatEnterpriseLinux4，Sun的Solaris，IBM的AIX，惠普的OpenVMSLinux[28]。特別的，微軟將它的Kerberos應(yīng)用建立在RFC1510標準的基礎(chǔ)上。Kerberosv5認證過程中的消息交換如圖5.21所示。圖 Realmc,Realmtgs和Rea：分別指客戶端用戶所在域，TGS服務(wù)器所在域和應(yīng)用服務(wù)Authenticatorc1，一個認證元，包含了用kc,tgs例5.12基于可信任新鮮性對Kerberosv5協(xié)議的安全性分析如圖5.22所示。為便于對Kerberos圖5.22KerberosT和_time表示客戶端為票據(jù)選擇的時間戳。Kas,tgs和Ks,tgs分別是AS和TGS之間，以及S和TGS之間的長期共享密鑰。CCAS和票據(jù)授予服務(wù)器TGS知道；Ks,tgs是的，且只有應(yīng)用服務(wù)器S和票據(jù)授予服務(wù)器TGS知道；N1和N2是一次隨機數(shù)，kc,tgs和kc,s是為這個協(xié)議的運行隨機生成的臨時密鑰。在消息2中，認證服務(wù)器AS為C和TGS之間隨后的通信隨機生成一個新的密鑰kc,tgs，然密鑰Kas,tgs加密的，用于向TGS證明這個TGT票據(jù)是由AS發(fā)送的。AS也將臨時密鑰kc,tgs發(fā)送給客戶端C，并使用長期密鑰Kc來保持kc,tgs的性。Kc通常由用戶的口令派生得KTGSkc,tgs,TN1，驗證N1的正確性，并得到臨時密鑰kc,tgsKk _time以證明客戶端C知道密鑰kc,tgs。k加密的時間戳可防止者通過記錄票據(jù)和認證元來重放信息。C也轉(zhuǎn)發(fā)了在消息2收到的票據(jù)TGS,kc,tgs, ?？蛻舳耸褂脮捗荑€kc,tgs來加密認證元 _timek

客戶端C的。 在收到消息3后，票據(jù)授予服務(wù)器TGS使用長期密鑰Kas,tgsTGS,k, K驗證時間戳T的正確性，并得到了臨時密鑰kc,tgsTGS同時還會驗證認證元 _ 在消息4中，TGS為S和C之間的應(yīng)用隨機選擇了新的會話密鑰kc,s，并生成服務(wù)票據(jù)K即S,kc,s, ，TGS使用長期密鑰Ks,tgs來加密這個服務(wù)票據(jù)，用于向S證明這個STKk kc,s,T,N2, kk在消息5中，客戶端C生成了新的認證元 _time，來證明客戶端C知道密鑰kc,sk C也將消息4中收到的服務(wù)票據(jù)S,kc,s, 在收到消息5后，應(yīng)用服務(wù)器S使用長期密鑰Ks,tgsS,k, Kk的正確性，并得到新的會話密鑰kc,s。S也會驗證認證元 _time的正確性kk _ k信N1是不的。由于從AS的角度來看，并不存在任何可信任的新鮮性標識符，因此在收到消息2后，由引理4.2可得，C認為kc,tgs的性是有保障的。由引理4.3可得，由于kc,tgs是和C信任的新鮮性標識符N1一并發(fā)出的，因此C認為臨時密鑰kc,tgs的新鮮性用C和AS之間的長期密鑰KC從加密包TGSkc,tgs,TN1K中得到kc,tgs。由引理4.4于TGS的在消息2的TGSkc,tgs,TN1K中被明確地來了，因此，C也認為N1和kc,tgs知道N2是不的。性和新鮮性是有保障的。由引理4.4可得，由于TGS和C的都在消息3中被明確地指TGS認為kc,tgs與TGS和C的關(guān)聯(lián)性都是有保障的?；跁r間戳_time，由引理4.1可元 _timek在收到消息4后，由引理4.2可得，C認為kc,s的性是有保障的。由引理4.3可得，由于kc,s是與C信任的新鮮性標識符N2一并發(fā)送給C的，因此，C認為臨時密鑰kc,s的新鮮性4中被明確地了，且加密包kcs,T,N2,Sk是由C和TGS之間的共享臨時密鑰kc,tgs生成的。由引理4.1可得，基于可信任新鮮性標識符N2，C認為TGS的主體活現(xiàn)性是有保障的，因為只有TGS能使用kc,tgs生成加密包kc,s,T,N2,Sk。在收到消息5后，基于時間戳T，由引理4.2和引理4.3可得，S認為臨時密鑰kc,s的性為C和S的都在消息5中被明確地了，且加密包S,kc,s,C,TK只能由TGS使用長期密鑰Ks,tgs來生成?；跁r間戳_time，由引理4.1可得，S認為C的主體活現(xiàn)性是有保障的，因為只能是C使用共享會話密鑰kc,s來生成認證元C, _timek。在收到消息6后，基于時間戳_time，由引理4.1可得，C認為S的主體活現(xiàn)性是有保障的，因為只有S能使用新共享會話密鑰kc,s生成認證元_timek。表 新鮮的，并與客戶C和應(yīng)用服務(wù)器S相關(guān)聯(lián)；而C相信S是存在的，且新的會話密鑰kc,s是PKINIT將公鑰引入Kerberos，建立一個新的信任模型，該模型中KDC不再是第一個鑒公鑰Kerberos即PKINIT[26，它包含在Windows2000和WindowsServer2003中，是Kerberosv5的一個擴展，使用公鑰加密進行初始認證。也就是說，PKINIT修改“認證服務(wù)服務(wù)器之間需事先共享的要求。在PKINIT系統(tǒng)中，用戶可以借助智能卡能登錄到Windows2000或其他的域，這里的認證過程不需要客戶端主密鑰，取而代之的是卡中的公在傳統(tǒng)的Kerberosv5協(xié)議中，認證服務(wù)交換的長期共享密鑰通常由口令派生而得，這 public-infrastructure）已經(jīng)到位，PKINIT將允許借助PKI管理整個系統(tǒng)的用戶公鑰，而不必付加密、數(shù)字簽名和相應(yīng)的。PKINIT旨在通過引入公鑰加密來增加認證的靈活性，安全 和CertS用來證明每個主體和他所擁有的公鑰之間是綁定的。此時，C或AS只需要PKI中在微軟的類Kerberos系統(tǒng)中都支持PKINIT，包括Windows2000專業(yè)版和Windowsserver需要的是，PKINIT至今尚未被MIT的相關(guān)應(yīng)用所支持。--I階段1客戶想從中獲取TGT的TGS的名稱，一個時間戳和一個隨機數(shù)。而CertC,tcn2由KKKK2Kerberos2 ,TGSkc,tgs,TN1與AS在基本的Kerberos中的消息2K口令派生出的共享密鑰票據(jù)授予票據(jù)TGT即TGS,kc,tgs,C,T K之間共享的長期密鑰Kas,tgs加密；TGT包含TGS的名稱，kc,tgsC的名稱，和AS的本地時間T。由新生成的對稱密鑰k加密的部分消息包括TGS的名字，kc,tgsAS的本地時間T，和請求的隨機數(shù)N1。為了確保從C處得到kPKINIT在消息2中加上了消息部分CertAS,k,n2K

。這個加密包是由Kc加密的，它包含AS的CertAS和AS的簽Kkn2，因此只有C可以得到新鮮生成的密鑰kK例5.13這里給出針對公鑰版Kerberos，即PKINIT的基于可信任新鮮性的安全性分析。圖 KcK1分別是C的公鑰和私鑰，KasK1分別是AS CertC和CertAS分別指客戶端的和認證服務(wù)器的每個主體都知道可信任機構(gòu)CA的公鑰，并能用其從CertC或CertAS處得到KcKas。每個主體知道自己的公私鑰對，即C知道KcK1AS知道KasK1 ccK名，然后C將C CertC，簽名tc,n2,，C和TGS KK tc,n2，驗證時K CertAS,k,n2K

在消息14.2和引理4.3C認為隨機選擇的一次隨機數(shù)N1和n2的新鮮性是有保障的，C也認為N1和n2是不的。TGS不能從消息1中得到任何有用的安全性在收到消息2后，由引理4.2可得，C認為k和kc,tgs的性是有保障的，因為只有C能夠使用C的私鑰K1 K 2K關(guān)聯(lián)，因為如果一個者是一個合法用戶，它將能C并使用Kc生成加密包CertAS,k,n2K

在收到消息4后，由引理4.2可得，C認為臨時密鑰kc,s的性是有保障的，因為它是由鑰，因此C不能確定新鮮消息_timek是來自S的。5.9公鑰加密PKINIT模式下Kerberos表5.9是公鑰加密PKINIT模式下Kerberos協(xié)議的安全性分析結(jié)果。在協(xié)議運行結(jié)束后，S 圖 ii K在消息1中，客戶端C開始運行一個新的協(xié)議。者I消息1，將CertC用CertI替K在收到消息2’后，I使用I的私鑰和AS的公鑰得到kn2和k，因此I將能夠使用kKK在消息2中，I使用C的公鑰構(gòu)建了CertAS,k,n2KK

在消息3中，C照?；貜?fù)。I消息3，并將{C,time}中C的替換為I，然后 在消息4中，I將消息4’中I的替換為C，然后轉(zhuǎn)發(fā)消息4在這個針對公鑰加密PKINIT模式下Kerberos的結(jié)束后，者I使得C產(chǎn)生錯誤的信C與S成功地完成了協(xié)議的運行，并且與S共享了新的會話密鑰kc,s。然而事實上，S對于在隨后發(fā)送敏感信息時，C將使用kc,s加密信息，然而這是者I也知道的密鑰kc,s，因而I能PKINITDiffie-man模在Diffie man（DH）模式中，密鑰對(Kc和K1是C的公私鑰，Kas和K1是AS的 者可參閱文獻[26]。簡化的Diffie manPKINIT-26認證服務(wù)的消息交換如下： 圖5.25KerberosPKINITDiffie 表5.10是KerberosPKINITDiffie-man的安全性分析結(jié)果，有的讀者可給出分析TanenbaumAS(2001)ComputerNetworks,3rdedn.PrenticeHall,NewFreierAO,KarltonP,KocherPC(1996)TheSSLProtocolVersion.Accessed9JulyDierksT,AllenC(1999)theTLSProtocolVersion1.0,RFC.Accessed9JulyKaufmanC(2005)InternetKeyExchange(IKEv2)Protocol,RFC.Accessed9JulyMeadowsC(1999) ysisoftheInternetKeyExchangeProtocolUsingtheNRLProtocolyzer.In:Proceedingsof1999IEEESymposiumonSecurityandPrivacy,Oakland,9–12MayanC(1993)TheKerberosNetworkAuthenticationService(V5),RFC.Accessed9JulyanBC,Ts’oT(1994)Kerberos:anAuthenticationServiceforComputerIEEECommunicationsMagazine32(9):33–YlonenT(1995)TheSSH(secure )RemoteLoginProtocol,Internet-.Accessed9JulyYlonenT(2002)SSHAuthenticationProtocol,RFC4252.Accessed5MayYlonenT(2002)SSHConnectionProtocol,RFC4254.Accessed9JulyYlonenT(2002)SSHProtocolArchitecture,RFC4251.Accessed9JulyYlonenT(2002)SSHTransportLayerPro