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

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

C 送給Ck k上，這個(gè)協(xié)議并沒有達(dá)到事先所期望的安全密鑰交換和認(rèn)證的目標(biāo)。于只有C能使用它的私鑰K1對(duì)消息進(jìn)行簽名N,N，且C的 C SKCK確 了，S將會(huì)相信kCS是和C相關(guān)聯(lián)的。S在收到NC,NS1后，由引理4.1可得KC認(rèn)為NS是新鮮的。由引理4，由于只有S可以使用它的私鑰K1從密文k CS且S的在消息4中被明確地了，將相信、S、kCS和主體S是相關(guān)聯(lián)的。 例5.2（1-對(duì)完整的帶雙方認(rèn)證的SSL握手協(xié)議的）從S的角度看，kCS與S圖5.4對(duì)完整的帶雙方認(rèn)證的SSL握手協(xié)議的用來II 己的密鑰對(duì)，如C知道KCK1，S知道KSK1，I知道KIK 消息1，并成C與S開始在（的）C和S之間運(yùn)行協(xié)議。代CertS，并將消息2即VerS,TSNSSIDSCertI發(fā)送給C。C在收到消息2后，C為C和I之間的協(xié)議運(yùn)行隨機(jī)選擇了一個(gè)新的會(huì)話密鑰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，并且在驗(yàn)證完NNS認(rèn)為與C SKC在這整個(gè)結(jié)束后，者I使得S產(chǎn)生了錯(cuò)誤的信任：S錯(cuò)誤的認(rèn)為自己與C完成了一次成功的協(xié)議運(yùn)行，且與C共享了一個(gè)新的會(huì)話密鑰kCS。事實(shí)上，C對(duì)于I(C)和S之間的這次密鑰建立一無所知，CI新協(xié)商了一個(gè)會(huì)話密鑰kCSS錯(cuò)誤地認(rèn)例5.3（針對(duì)完整的帶雙方認(rèn)證的SSL握手協(xié)議的）從C的角度來看，kCS與C主圖5.5對(duì)完整的帶雙方認(rèn)證的SSL握手協(xié)議的用來IKI，它們都由機(jī)構(gòu)CA簽發(fā)。KI和K1分別是I的公鑰和私鑰。其他的符號(hào)和原I 道它自己的密鑰對(duì)，如C知道KCK1，S知道KSK1，I知道KIK 在消息1中，客戶端C發(fā)起了一個(gè)C和S之間的協(xié)議運(yùn)行。者I截獲了消息1，并把它替換成CertI，并把消息2VerS,TS,NSSIDSCertI發(fā)送給了C。kCS

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

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

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

HASHAK

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

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

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

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

在收到消息4后，由引理4.2可得，C認(rèn)為臨時(shí)密鑰kc,s的性是有保障的，因?yàn)樗怯设€，因此C不能確定新鮮消息_timek是來自S的。5.9公鑰加密PKINIT模式下Kerberos表5.9是公鑰加密PKINIT模式下Kerberos協(xié)議的安全性分析結(jié)果。在協(xié)議運(yùn)行結(jié)束后，S 圖 ii K在消息1中，客戶端C開始運(yùn)行一個(gè)新的協(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在這個(gè)針對(duì)公鑰加密PKINIT模式下Kerberos的結(jié)束后，者I使得C產(chǎn)生錯(cuò)誤的信C與S成功地完成了協(xié)議的運(yùn)行，并且與S共享了新的會(huì)話密鑰kc,s。然而事實(shí)上，S對(duì)于在隨后發(fā)送敏感信息時(shí)，C將使用kc,s加密信息，然而這是者I也知道的密鑰kc,s，因而I能PKINITDiffie-man模在Diffie man（DH）模式中，密鑰對(duì)(Kc和K1是C的公私鑰，Kas和K1是AS的 者可參閱文獻(xiàn)[26]。簡(jiǎn)化的Diffie manPKINIT-26認(rèn)證服務(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