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

析。這將有助讀者深度理解可信任新鮮性方法，并應用該方法對實際的協(xié)議進行安全I（OI模型級，從分為：應層，示，會話層傳輸層網(wǎng)絡層數(shù)據(jù)鏈 net/ftp:ssh, net/ftp:ssh,http:https,(IPSec,IKE)(IEEE802.1x/IEEE(Spread-Spectrum,quantumcrypto,圖5.1時應該保持系統(tǒng)向后兼容性，協(xié)議的改變應該對系統(tǒng)影響盡量的小[13]。例如：SSL協(xié)議避免了修改”TCP?！鼻覍弥灰鲎钚〉母淖?，因此被認證服務器所廣泛使用。IPSec在本章，討論網(wǎng)絡工業(yè)標準（或事實的標準）中幾個常用的協(xié)議，包括SSL協(xié)議[2]以及它的變體TLS協(xié)議[3](IKE)[4,5]，Kerberos認證協(xié)議[6,7]看到中，要設計出一個好的協(xié)議，既適合應用又具有強安全屬性是非常有性的工SSLTLS接協(xié)議L（cueocetayr）網(wǎng)公司（eap）研發(fā)技術通過在T層之上數(shù)據(jù)加，以?；ヂ?lián)網(wǎng)應用數(shù)據(jù)的傳安全。L的一重要應用就是在Hp和L相結合為瀏覽提供數(shù)性和整性服，例如在網(wǎng)上購物網(wǎng)上銀等敏感用的場，選擇L保其安全是普遍用的做，最近的一個版是L3.0，于196年推[2。1999，聯(lián)網(wǎng)工程務組ET（IneretEnginerngak ）對L3.0行標準，推傳輸層安協(xié)議TL1.版（ansportLaercury，成為絡端到加密工業(yè)標（C2246）[3。在此后，ET又對TL作了修完善，別在 年和 年推TL1.1（4346，TL1.（C5246SSL協(xié)議的主要目的是為兩個互相通信的應用提供安全連接。除了學的安全考慮，SSL還有考慮互操作性，可擴展性以及相關的效率等。SSL協(xié)議允許客戶端/服務器端在一定的方式下通信，能夠防范、竄改、等。SSL握手協(xié)議可以被認為是警協(xié)議，以及記錄協(xié)議。較低的那層協(xié)議位于TCP協(xié)議之上，被稱作SSL記錄協(xié)議。SSL記錄協(xié)議為通信信道提供安全的加密封裝，供上層的應用協(xié)議使用。SSL協(xié)議在較上一層個密鑰交換協(xié)議，能夠在兩個應用端初始化密鑰，并同步其狀態(tài)。在執(zhí)行完密鑰交換協(xié)議可以被透明地在SSL協(xié)議之上執(zhí)行，無需用戶參與。用來加密以及SSL記錄完整性的操作，是通過一個套件所決定。一個典型的例子是，使用DES算法加密數(shù)據(jù)，8 8 8 16 16384字對于SL3.0TS對SL3.TS1.0SL31TS1.1SL3，TS1.2記錄長度用字節(jié)表示，最大過214（16384）。如果對數(shù)據(jù)進行壓縮，可以允許SSL握手協(xié)議是SSL記錄協(xié)議之上的一個高端協(xié)議。SSL握手協(xié)議允許服務器和客戶出相應的密鑰，從而為應用協(xié)議建立一個安全的通信連接。SSL握手協(xié)議的結構如下所示：8 245.1SSL5.2所示步驟展開。圖5.2完整的SSL(Server)是C（或S）的書，且對應的公鑰KC(或KS)由一可 消息1（o消息連接失敗?？蛻舳艘灿锌赡苤貑⒁粋€已經(jīng)存在的會話。o消息包含如下數(shù)據(jù)：32位的UNIX格式的時間戳和一個由客戶端生成的28字節(jié)隨機數(shù)套件，o.cipher_suites是一系列客戶端支持的選項，這些選項按照客戶端最想用的順序排列。每一個套件為密鑰交換定義了算法，包含一個套件實際上定義了加密規(guī)范。這些結構是SSL會話狀態(tài)的一部分，enum{stream,block}CipherType;enum{true,false}I enum{null,rc4,rc2,des,3des,des40,fortezza}enum{null,md5,sha}MACAlgorithm;struct{BulkCipherAlgorithmbulkcipheralgorithm;MACAlgorithmmacalgorithm;CipherTypecipher portableisexportable;uint8hashsize;uint8keymaterial;uint8IVsize;}消息 o消息服務器使用Servero消息回復o消息。Servero消息可能有以下的新的SessionID來會話沒有被因此也不能被恢復。服務器選擇的套件，服務器為每一個必要的操作選擇一個單一的算如果服務器不能找到一個可接受的（1）Server消息：如果密鑰交換方法不是的，當服務器需要被認證時(通常情況是這樣)，服務器在發(fā)送出Servero后馬上發(fā)送一個。通常是一個X.509中包含了足夠的關于、所有者的公鑰以及簽發(fā)機構的信息。服務器發(fā)送系列是為了方便客戶選擇客戶端計算機支持的相應，并使用規(guī)定的公鑰算法。這意味著，服務器發(fā)送的系列當中需要至少包含一個能被客戶所完全相信的一個。這些的排列是有順序的，每一個應能保證它前面的那個有效。ServerKeyExchange ⑶Request消 Request消息給客戶，向客戶端要求一個。這條消息將直接接在Server 消息之后，或者在ServerKeyExchange消息。 o階段消息的數(shù)據(jù)傳送，客戶端應該立即核實已經(jīng)收到的和諸如此類的東西。消息3（消息如果用戶曾接收到“Request”消息，那么在收到“Server KeyExchange man,此時將會送出公鑰參數(shù)⑵Verify消在大多數(shù)的例子中，如果客戶端發(fā)送出了一個，則它在此時也將發(fā)送一個VerifyServerKeyMessage消息中格式相同的簽名，ChangeCipherSpecFinished至此，用戶端和服務器已經(jīng)協(xié)商好一個只有他們雙方知道的信息。這是一個48字master_secret。master_secretMD5(pre_master_secret+SHA(‘A’++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.2SSLSSL中使用主密鑰可用來生成加密和MAC計算的密鑰和值。要生成密鑰材料，需要計算key_block值，直到足夠多的輸出值生成。KeyMD5(mastersecret+SHA(‘A’+mastersecret+Servero.random++MD5(mastersecret+SHA(‘BB’+mastersecret+ o.random++MD5(mastersecret+SHA(‘CCC’+mastersecret+ o.random++[.._write_IV[CipherSpec.IV_size]/*non-exportciphers*/server_write_IV[CipherSpec.IV_size]/*non-exportciphers*/SLSLL給出針SL協(xié)的另外針對TS再協(xié)協(xié)議的也作要介。例5.1（完整的帶雙方認證的SSL握手協(xié)議）。當一個新的會話開始后，SSL中的加5.3給出SSL握手協(xié)議中與認證及密鑰建立相關的圖5.3完整的帶雙方認證的SSL握手協(xié)C表示一個客戶端（例如客戶端的Web瀏覽器），S表示一個WebVerC戶端發(fā)送的o消息中所要求的協(xié)議版本VerS表示被使用的協(xié)議版（即服務器所絕對時間相關的時間戳，在這里時鐘并不需要由基本的SSL協(xié)議來設定正確，但是協(xié)不對pre_master_secret,master_secret和其他的為加密和MAC計算所設置的密鑰和信息進SC別是S的公鑰和私鑰，KCK1分別是C的公鑰和私鑰。SC鑰對，即C擁有KCK1S擁有KSK1 CNS，并發(fā)送C,NC,NSK1C

SSCC,NC,NSK1C

k S，生成的隨機數(shù)NC和NS一并加密，并將密文S,NS,NCkk 密文S,NS,NC k由于只有C能使用它的私鑰K1對消息進行簽名N,N，且C S明確

K1后，由引理4.1KCSC認為NS是新鮮的。由引理4，由于只有SK1從密文S

CSKSK

kCS，且S的在消息4中被明確地了，將相信、S、kCS和主體S是相關聯(lián)表 鑰kCS是的、新鮮的，并與主體C相關聯(lián)的。例5.2（1-對完整的帶雙方認證的SSL握手協(xié)議的）從S的角度看，kCS與S主體之間缺乏關聯(lián)性，因此可以構造如圖5.4所示的1。圖5.4對完整的帶雙方認證的SSL握手協(xié)議的用來II表示者，I(C)表示成C的者I。CertI表示I的，對應的公鑰是KI，它們由機構CAKIK1分別是ISSL握手協(xié)議完I 在消息1中，客戶端C與I一起開始運行一個協(xié)議。在消息1’中，者I(C)將向S重放消息1，并成C與S開始在（的）C和S之間運行協(xié)議。代CertS，并將消息2即VerS,TSNSSIDS,CertI發(fā)送給C。后，

,N

C是真正的C，并發(fā)送了消息C,NC,NSK1C

。

SII加密kCS，生成了消息3’kCSK,CertC,NCNSK1和C,NC,NSK1

C在收到消息3’后，SK1得到了kCS，并且在驗證完NNS認為與 S新的會話密鑰的通信方一定是CI將正常地完成它與C之間的協(xié)議在這整個結束后，者I使得S產(chǎn)生了錯誤的信任：S錯誤的認為自己與C完成了一次成功的協(xié)議運行，且與C共享了一個新的會話密鑰kCSC對于I(C)和S之間的這次密鑰建立一無所知，C只知道自己和I新協(xié)商了一個會話密鑰kCS。自此，S錯誤例5.3（針對完整的帶雙方認證的SSL握手協(xié)議的）從C的角度來看，kCS與C圖5.5對完整的帶雙方認證的SSL握手協(xié)議的用來II表示者，I(C)，I(S)分別表示成C或S的者I。CertI表示I的，對應的公鑰是KI，它們都由機構CA簽發(fā)。KI和K1分別是I的公鑰和私鑰。其他的符號和I知道它自己的密鑰對，如C知道KCK1，S知道KSK1，I知道KIK1 在消息1中，客戶端C發(fā)起了一個C和S之間的協(xié)議運行。者I截獲了消息1，并把在收到消息1’后，S回復包含S的消息2’給I(C)。收到消息2’后，I把消息2’中的CertS替換成CertI，并把消息2VerS,TSNSSIDS,CertI發(fā)送給了C。K ,CertC,NCNSK1,C,NCNSK1K II在這個對于完整的帶有雙邊認證的SSL握手協(xié)議進行以C完成后，者I使得S和CC和S均認為他們和對方成功地完成了協(xié)議運行，并與對方了新的會話密鑰kCS，然而，事實上C和S之間的共享密鑰kCS已經(jīng)被I所掌握。在SSL握手協(xié)議的一次運行中，客戶端可能會選擇，從而客戶端不需要被服務器端認證。因此，服務器單方面的被客戶端所驗證（即客戶端驗證了服務器的身的通道。這是基于互聯(lián)網(wǎng)的電子商務應用上使用SSL協(xié)議的典型方式，例如，從一個書店購書，這個信道保證只有被認證的服務器才能收到客戶端發(fā)出的相針對SSLSSL會話，恢復一個已找匹配的ID。如果一個相應的匹配被找到了，則服務器將會使用相應的會話狀態(tài)建立一個新的連接，服務器將會向客戶端回復相同的ID，即與客戶端o消息中提供的ID相同。這表明會話恢復正在進行中，并會話雙方必須直接運行接下來的finished消息，且忽略所有的可選消息及KeyExchange消息。SSL握手協(xié)議再協(xié)商過程的消息交圖5.6SSL再協(xié)商握手中的消息交換應的會話狀態(tài)重建連接，并且將同樣的會話ID附在Servero中發(fā)送給客戶端。否kS，然后將之前發(fā)送的握手信息用kCS加密即C,NC,NS kSSkCNCNS kk在消息4中，將它 與隨機數(shù)、S一起加密，并發(fā)送S,NS,NC kk S,NS,NC k協(xié)議的成功運行將會使得C和S相信：kCS在消息1中，由引理4.2和引理4.3C認為隨機數(shù)NC是新鮮的，且C也認為NC是不SS

CSKSK中得到kCS，且S的在消息4中被明確地了，S認為NC,NS,kCS與S是相關聯(lián)的。 在協(xié)議運行結束后，C認為S是真實參與通信的，且新的會話密鑰kCS是的和新鮮的，并與S相關聯(lián)。然而S只能相信新會話密鑰kCS是的和新鮮的，但是S并不知道kCS是例5.4（針對SSL再協(xié)商協(xié)議的）從S的角度來看，C通信的真實性是缺失的，因此可圖5.7對SSL再協(xié)商協(xié)議的用來在消息1中，者I通過成C開始了SSL再協(xié)商的過程，它想要恢復一個與C的已在收到消息后，()為實際上I）和間重建的話隨機成了新會話密鑰kkS用SS。()k加密后發(fā)送給S。在收到消息3后，S使用它的私鑰K1得到新的會話密鑰kCS，并驗證C,N,N S

S在這個對于SSL再協(xié)商協(xié)議的結束后，者I使得S產(chǎn)生了錯誤的信任：S與完成了一次成功的協(xié)議運行，且與C了一個新的會話密鑰kCS。事實上，C對于此（建立C和S之間的會話密鑰）一無所知，只是S是與I了新會話密鑰kCS。此外，S認為以上的可以由者I直接成合法客戶端C所啟動，甚至并不需要C。這個例子對于者來說或許很有，因為它允許者在任何時間發(fā)起一次，TLS（包含RFC5246以及之前版本，SSLV3以及之前的版本）在現(xiàn)實世界中容易與再協(xié)商相關的中間人[14]。TLS標準允許通信的任意一方在任何時候請求再協(xié)商TLS會話。與再協(xié)商相關的中間人很普遍，不僅在HTTPS中，而且存在于其他在TLS之上的有三種針對HTTPS協(xié)議再協(xié)商的一般，這三種之間有細微的不同。但這三種攻擊都能達成一個結果：者有能力執(zhí)行一個HTTP，并被合法的用戶（即中間人攻例5.5（針對客戶端認證的再協(xié)商）服務器無法確定客戶端是否提供了一個有效的認證，除非它收到了客戶端的請求，并且通過它的認證規(guī)則將其過濾。對于需要客戶端認證的請求，HTTPS服務器必須通過重建TLS信道來獲取客戶端的并使其生效。不幸的是，由于HTTPS缺乏特定的回復代碼來告知客戶端重發(fā)一個帶有新的擊的主要弱點。大部分依賴于客戶端認證的設施容易遭到這種客戶端認證再協(xié)商例5.6（針對不同服務器需求差異的再協(xié)商）管理資源的HTTPS服務器有不同的套件需求，可能在另一種再協(xié)商下很脆弱。由于對套件安全強度的需求不同，Web服務器常常在協(xié)商TLS連接時選擇支持一個最基本的強度。只有在看到客戶端的URL請求后，服務器才能準確的決定采用哪一種套件。如果當前的套件并不行為，將導致與客戶端再協(xié)商例子中相同的缺陷，即服務器被強制要求重放緩沖區(qū)的請求，在這個例子中包含可能者進行選擇性明文的內(nèi)容。這個行為將會例（針對戶端發(fā)再協(xié)商）L同樣許連接的戶端發(fā)一個協(xié)的再協(xié)haerHTT請求的開部分，騙得所供的認和息注意，這不需要道一直在或者HTTTT協(xié)商”。據(jù)認證，數(shù)據(jù)完整性和密鑰管理。IPSec提供了網(wǎng)絡的層，即TCP/IP層的安全通信，因此將地址信息和內(nèi)容一起保護是非常有效率的。通常來說，IP層的安全可以為更的擬私有網(wǎng)絡（）中，都采用對密鑰的自動管理，IPSec已經(jīng)成為了世界上絕大多數(shù)基于IP的技術的默認標準。,,（ESP,EncapsulatingSeurityPayload,RFC2406[18]）和互聯(lián)網(wǎng)密鑰交換協(xié)議（IKE,InternetKeyExchangeProtocol,RFC2409[19]）。AH提供完整性保護，ESP提供性服務和可選的認證頭作“認證頭”(AH)的附加域[17,20]。認證保護（事實上是指帶有源的數(shù)據(jù)完整數(shù)據(jù)包中，（見圖5.8和圖5.9）AH的長度是可變的，但必須是32位數(shù)據(jù)報長的倍數(shù)。AH域細分為圖5.8AH的結構及其在傳輸模式下在IP圖5.9AH的結構及其在隧道模式下在IPAHS）2數(shù)據(jù)包的認證務所使的法。而名為“序號”的域能夠來防止AHV）包含了由息發(fā)送為消息收成的認數(shù)，能夠用接收方證數(shù)據(jù)整性。SV（KE封裝安全載荷圖5.10ESP及其在傳輸模式下在IP圖5.11ESP及其在隧道模式下在IP圖5.12封裝安全載荷ESPESP中被稱之為“安全參數(shù)索引”(SecurityParametersIndex,SPI)的子域是32位長的某個任意值，它指定了這個IP數(shù)據(jù)包性服務所使用的加密算法。第二個子域被稱作“序列號”（SequenceNumber），它可以用于防止對IP包的重放。(v6)3（adng）其中，‘xy’是16進制的數(shù)值，且‘01’<‘xy<‘FF’。因此，填充字節(jié)的最大數(shù)值為‘FF’，即255(10)。填充數(shù)據(jù)的字節(jié)長度稱為“填充長度”（PadLength）。HESHSSP中的密文ES）如圖和圖5.11），A數(shù)據(jù)包提互聯(lián)網(wǎng)密鑰交換（nenetKeyExcane,KE（KE）IKEIPsec（SecurityAssociation,SA），而且可以為SNMPv3、RIPv2、OSPFv2等任何要求的協(xié)議協(xié)商安全參數(shù)。（SAKM）AKEYSME組成。K創(chuàng)建在AKMAKEYSEE建立和管理安全關聯(lián)（SecurityAssociation,SA,包括密鑰、算法和參數(shù)），認證證了。為了有能力進行簽名的驗證，公鑰（即）應該是受到信任的和可核實的。SA注釋1安全關聯(lián)，）ASASSAA（S）（當前的或過期的SA個S網(wǎng)安全關聯(lián)和密鑰交換協(xié)議”（InternetSecurityAssociationandKeyManagementProtocol,ISAKMP）[RFC2408][21]，“Oakley密鑰確定協(xié)議”（OakleyKeyDeterminationProtocol,OAKLEY[RFC（VersatileMechanismforInternet,SKEME）[23]。密鑰材料。OAKLEY協(xié)議支持完善前向、在管理安全關聯(lián)上與ISAKMP協(xié)議兼容，支鑰。其中最基本的是Diffie-man密鑰交換算法。SKEME描述了認證的密鑰交換技術，該技術支持通信各方對于連接的可特性和快K交換特，KE中的多數(shù)協(xié)都使Dfe-an鑰交體制。KE參與雙方提供許多選，允許方通過的方協(xié)和達成認會話密。IKEIKE階段鑰。對于IKE階段1，IKE有幾種密鑰交換模式，包括主模式、進取模式、基本模式和新組階段1假設參與密鑰交換的雙方中的任意一方都能夠驗證另一方的能力，這種能力在對稱體制下可以通過預共享密鑰獲得，在公鑰體制下可以通過與可信公鑰IKE階段樣能夠讓用戶建立多個具有不同安全屬性的連接，分別用于“僅數(shù)據(jù)完整性”、“僅性”、“用短密鑰加密”或“用強密鑰加密”等不同安全需求。5.2（IKE密鑰材料）SKEYID是一個字符串，它來源于消息交換中僅被活現(xiàn)的參與是生成其他密鑰的密鑰，也就是這里所說的密鑰材料。對于簽名公鑰：SKEYIDprf(noncesgxymod對于加密公鑰：SKEYID=prf 對于預共享的密鑰：SKEYIDprf(pre-sharedsecretkey對于生成其他密鑰的：SKEYID_d=prf(SKEYID,gxy∣ 對于完整性密鑰：SKEYID_a=prf(SKEYID, 對于加密密鑰：SKEYID_e=prf(SKEYID, IKE對于每種密鑰類型，在IKE階段1都有兩種密鑰交換模式：主模式和進取模式，因此IKE階，IKE階段1IKE階段1被用于執(zhí)行交互認證，交換關于的提案，特定信息和。IKE階段1的結果可以有多種稱謂：Phase-1SA,ISAKMPSA,IKESA等。他們都意味著同樣的東西。圖5.13IKE階段1別支持的安全屬性。密鑰交換（KeyExchange,KE）負載是Diffie-man公共值，它用于交換Diffie-man公鑰發(fā)起者和響應者的隨機數(shù)負載NONCE都用于在IKE中計算Phase-1SA中的數(shù)據(jù)。CR負載表示請求，它包含了CA（機構）的名字。ID負載是用而且可能用來發(fā)送撤銷表CRL簽名負載SIG是其他方必須驗證的數(shù)字簽名*表示該內(nèi)在消息1發(fā)起者發(fā)了一個含發(fā)起者的D。D一個SAM頭，其換模式定義了KE的模。一個AKM頭含了發(fā)者，響應者和消息D。在階段1協(xié)商期間發(fā)起者響應者的決了SAMPA。消息D一個獨的消息識，在KE階段22DSA負載是強制性的，它用于列出發(fā)起者所支持的安全屬性。它包括、哈希算法、在消息2 在消息3IKE協(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書。ID可以是IP地址，完全合格（FQDN）、郵件地址，或者其他類似的東西。發(fā)起者可以發(fā)送零（0）或者負載（CERT），且每個都包含了一個（或負載中發(fā)送CRL。CERT負載是可選的，因為終端很可能已將公鑰在本地進行了，因此它并不需要在協(xié)商中接收CERT負載。通常情況下，公鑰并不會在本地，所以未能發(fā)送CERT負載也會導致IKE協(xié)商。簽名負載S）是其他參方必須實的數(shù)簽。S負載包含私所計算的數(shù)字簽名這個私所對應公鑰通在ET負中發(fā)送S負載為其他參者提供了認證。當有的參方都成地驗證其它參方S負載，則他們互相被證的。他們用中的公來核實名，這公鑰通從T負載中收，也可來自其途徑（如本，量 協(xié)議等）。核簽名之前他們也實遠端，即核實的（機構，A）是可，也核實是否效（并被撤銷的），等。在消息6注意消息5和消息6是被完全加密的，因為在消息3和消息4之后Phase-1SA即被建立， 1as-1KE1圖5.14IKE階段1在消息1 數(shù)據(jù)，并表明它的。在消息2man公共值和交換中所需的附屬數(shù)據(jù)，并表明它的。除此之外，消息2還認證響應在消息3階段2也提供了一個關于技術的提案，這個提案定義了實際使用的，HMAC，哈希算法和其他能保護IP通信的安全屬性。階段1的提案僅僅只是為了保護Phase-1SA圖5.15IKE階段2HASH負載表示交換的密鑰材料。SA負載是階段2中關于技術的提案列表，這個提案指在消息1發(fā)起者將SAHASHNONCE和ID負載發(fā)送給響應者，以便為IP通信生成新會話密鑰。ID負載，標記為IDI和IDR,分別表示發(fā)起者的ID和響應者的ID。ID負載在階段2中是可者類似的東西，IDR是響應者的ID，通常是IP地址，IP范圍或者IP子網(wǎng)。無論是發(fā)起者還是為“人ID”（ID），“偽ID”（pseudoID）或其他類似稱呼，因為他們并不一定在消息2響應者從階段2有關技術的提案列表中選擇加密技術，并將HASH，NONCE（在在消息3在發(fā)送完最后一個數(shù)據(jù)包消息3后，IKE階段2就完成了，階段2的運行結果是形成了例5.8（IKE階段1主模式）IKE階段1主模式中與認證和密鑰建立圖5.16基于公鑰簽名的IKE階段1，分別是,x和y分別是由發(fā)起者A和響應者B隨機選擇的私有值。gx,gy分別表示A和B的IDA和IDB分別是A和B的終端。HASHA=prf1HASHB=prf1SKEYID是A和B之間的新會話密鑰，可以通過SKEYID=prf2(NA∣NB∣gxy)計算得到。CA和CB分別是發(fā)起者和響應者的，B通過CA來A的會話狀態(tài)信息，CB的作用亦A和B都信任CertA和CertB的機構CA,而且他們能夠核實是否有效（如是否是撤銷的等等）。這意味著他們知道CA的公鑰，即都能得到A的KA和B的KB。每一, 消息ID和發(fā)起者的CA；SAA詳細列出了所建議使用的安全屬性，包括加密算在消息2中，響應者B將一個包括響應者回應CB和發(fā)起者CA的HDRB發(fā)送回給A。響應者同時也將一個SAB包含在它的回復中，用于B選擇的某一種安全屬在消息4中，B也隨機選擇了一個Diffie-man私有值y和一個隨機數(shù)NB。然后B計算隨機數(shù)）。此時，A和B都能計算出新會話密鑰。SKEYID=prf2(NA∣NB∣gxy)。在消息5A計算整個ID負載的哈希值：HASHAprf1AA

prfSKEYIDgxgy

CSAIDKA K

中， 隨機數(shù)NA的新鮮性，且A也認為x是的而NA是不的。 私有值y的性和新鮮性，并確信隨機數(shù)NB是新鮮的和不的。此時，B還計算了新會話密鑰SKEYID=prf2(NA∣NB∣gxy)，由引理4.2和引理4.3可得，B能確信SKEYID的性和新鮮性。新會話密鑰SKEYIDprf2(NA∣NB∣gxy)，且由引理4.2和引理4.3可得，A能確信SKEYID的性和新鮮性。在收到消息5后，由引理4.1可得，基于NB和SKEYID=prf2(NA∣NB∣gxy)的可信任新鮮性，由于只有A能使用A的私鑰對新鮮的哈希值HASHAprf1(SKEYID∣gx∣gy∣CA∣CB的了，B能確信新會話密鑰SKEYID與A之間有關聯(lián)性。在這整個協(xié)議運行結束后，A相信主體B是活現(xiàn)的，新的會話密鑰SKEYID是的，表5.5對IKE階段1例5.9（針對基于簽名的IKE階段1主模式的）。從B的角度來看，新會話密鑰SKEYID和B之間缺乏關聯(lián)性，從而存在針對IKE階段1主模式的以B[5,24,25]，如圖5.17所圖5.17針對基于簽名的IKE階段1主模式的在這個對于IKE階段1主模式的結束后，者I使得B產(chǎn)生了錯誤的信任：B認為自己和A一起成功執(zhí)行了一次IKE協(xié)議，并與A共享了一個新的會話密鑰SKEYIDA事實上對于和B建立密鑰的事情一無所知，A只是認為它和I之間的協(xié)議運行因為某種原因的這一會話狀態(tài)信息，以便在IKE階段2的通信時使用這個會話密鑰SKEYID。者I可以利用這個與其同伙一道同時對某個服務器展開，從而能有效地啟動服務例5.10（IKE階段1進取模式）IKE階段1主模式的一個簡化版，最開始的兩條信息用來協(xié)商策略，交換Diffie-man密鑰交換所需的成分和必要的附圖5.18基于簽名的IKE階段1是的，而NA是不的。NBBSKEYIDprf2NA|NB|gxy，在收到消息2后，由于A知道NA和SKEYID=prf2(NA∣NB∣gxy)都具有可信任的新鮮性，且類似的，在收到消息3后，由于B知道NB和SKEYID=prf2(NA∣NB∣gxy)都有可信任的新鮮性，且只有A能夠用其私鑰對哈希值HASHA=prf1(SKEYID|gx|gy|CA|CB|SAA|IDA)進4.1B能夠確信A的主體活現(xiàn)性。再由引理4.4，由于只有A能夠在協(xié)議成功的運行完成后，A認為B是主體活現(xiàn)的，即B真實參與了通信，且新會話密鑰SKEYID是的、新鮮的，并與主體B相關聯(lián)。而B也相信A是主體活現(xiàn)的，即A真實參與了通信，且新會話密鑰SKEYID是的、新鮮的，并與主體A相關聯(lián)。對IKE階段1進取模表 注意HASHA和HASHB都采用新會話密鑰SKEYID作為它們的偽隨機函數(shù)的，因此這兩個哈希值的簽名不可能被，而且這些簽名只有掌握了新會話密鑰的主體才能進行驗證。不幸的是，針對IKE主模式的（例5.9-1）對IKE進取模式仍然有效。例5.11（公鑰簽名，IKE階段2快速模式）每一個快速模式的實例都使用一個唯一的初始化向量（例如，消息ID），因此，基于單一的ISAKMPSA，多個階段2快速模式能夠同進行重放?；究焖倌Ｊ剑ú话↘E負載）更新了由階段1取冪得到的密鑰材料。與圖5.19基于簽名的IKE階段2 kprfSKEYID_d,gxy|protocol|SPI|N| gxy是雙方共享的信息，來自快速模式中的 HASH1=prf(SKEYID_a,IDAB∣SAA∣NA[∣gx][∣IDA∣IDB])HASH2=prf(SKEYID_a,IDAB∣NA∣SAB∣NBHASH3=prf(SKEYID_a,IDAB是消息ID，用于標志對于一個特定的ISAKMPSA正在運行的快速模式，這個特定 man交換，它在快速模式中是的。假設來自在消息1中，由引理4.2和引理4.3A能夠確信隨機數(shù)NA的新鮮性以及值x的類似的，在消息2中，由引理4.2和引理4.3B能夠確信隨機數(shù)NB的新鮮性，也能SKEYID_a，所以B能夠確信NB,y和k是與A和B關聯(lián)。B能使用共享密鑰SKEYID_a來生成新鮮的哈希值HASH2=prf(SKEYID_a,IDAB∣NA∣SAB類似的，在收到消息3后，基于B信任的新鮮性標識符NB，由引理4.1，因為HASH3prf(SKEYID_a0∣IDAB∣NA∣NB)，所以B能夠確信A表5.7對IKE階段2表5.7給出了K階段2KE階段模式中的提下，議達成如安全目標A相信體B是在的，且新會話密k是的、鮮的，與主體和B聯(lián)；B相主體A存在的且新會話密鑰k的新鮮的并與A關聯(lián)。此KE段2快速模達成了原本所置的安全目標擊者獲得，則者可以假裝主體A或B在任何時間發(fā)起運行一個快速模式，并與被的受害者共享新會話密鑰，即者將能獲得新會話密鑰。Kerberos機文件服務器服務或其他的互聯(lián)網(wǎng)服務當一個用戶請求使用某項網(wǎng)絡服務時，面對一個非物理安全的網(wǎng)絡，服務提供者通常要求用戶提供證明其的。然而，要求用戶多種不同的來證明比如記住各種不同的口令或者持有多個智能卡，令的。因此，麻省理工學院研究人員提出了Kerberos系統(tǒng)，以作為開放網(wǎng)絡環(huán)境下安全問題的解決方案：Kerberos系統(tǒng)借助一個位于用戶和資源服務器之間的可信任第，透明地所需的各種網(wǎng)絡資源。也就是，每當合法用戶想要某個信息資源，例如從終端服務器接收一個文件，Kerberos將不再需要與用戶直接進行交互操作， 強大的認證，客戶端可以在非安全的分布式環(huán)境中證明自己的。當客戶端通過：在基礎ereroereros進行交互?？蛻舳撕蚭rers管理主體之間的初始認證一般是基于用服務進行認例如服器文件服務器打印服器等實現(xiàn)rbrosAKebrosAuenaonSrvr獲取一TTTice-ranngkeTTTSTice-anngSrerS(ervecet)S是一個該是客戶用來讓自己和用服務之間進行證S和TS一起組成DCKeyDsrbuonne)。：。網(wǎng)絡服務的有效用戶，即基于用戶的認證、用戶要求的服務和當前的系統(tǒng)狀態(tài)，給予用戶指定類型的服務。計費，即用戶的網(wǎng)絡資源消費情況。。在Windows2000中，56位的DES和128位的RC4在Kerberos中是最常用的；在WindowsServer2003中，普遍使用RC4-HMAC，DES-CBC-CRCDES-CBC-MD5；在WindowsXP中，常用RC4，其他的加密算法也被允許，尤其是使用DESWindowsVista中，常常使用256位的AES,3DES,SHA2等。Kerberos服務器，是一個可信第，或者用Kerberos術語來說，是一個密鑰分發(fā)中（KC）。DC本身由兩個子服務組成：認證服務和票據(jù)授予服務。在Wndows200和WndowsSrvr2003DKrbros實現(xiàn)中，（S（T采用S和TSereoTSAS所有客戶端都應該在Kerberos服務器KDC上，以便使用網(wǎng)絡中的信息資源和服務注釋5.3密鑰分發(fā)中心KDC（KeyDistributionCenter）由認證服務器（AS）和票據(jù)授予及他們在給定域上的密鑰。例如，KerberosKDC運行在每一個Windows2000域控務器和Windows2003域控務器上。注釋5.4認證服務器AS（AuthenticationServer）對客戶端的登錄進行認證，并為對客戶注釋5.5票據(jù)授予服務器TGS（TicketGrantingServer）負責受理和核實客戶端從AS獲得注釋5.6應用服務器S（ApplicationServer）負責接收和驗證從TGS得來的服務票據(jù)ST，注釋5.7客戶端C（）是一個客戶端（一個用戶進程），它代表用戶U來使用網(wǎng)絡的服務當客戶端C提示用戶輸入時用戶就把用戶的證件提供給客戶端C請注意，注釋5.8票據(jù)（或者Kerberos票據(jù)）是協(xié)議中的加密消息，它用來確定終端參與者的身5.9認證元（或認證符）認證元是包含有時間戳的認證憑證，其中時間戳被客戶端和AS之間、或者客戶端和應用服務器之間的共享會話密鑰加密。認證元在使用時，過注釋5.10票據(jù)授予票據(jù)TGT（TicketGrantingTicket）由認證服務器（AS），其注釋5.11屬性PAC（PrivilegeAttribute）在Windows2000注釋5.12服務票據(jù)ST（ServiceTicket）由票據(jù)授予服務器（TGS），它可為特定的注釋圖5.20Kerberos協(xié)議I階段1消息2：S在據(jù)庫查找在S_Q請中客戶端和務器的體，分提kctg)，TS之間通STTTS部分。TTkctgTTTSkctg是用S和TSII階段2（以檢測消息的重放）并恢復會話密鑰kc,tgskc,tgs創(chuàng)建一個認證元，這個認TGS，請求對應用服務器S的權限。消息4：T對TT進行，然使用TT內(nèi)的kcg來驗證認元內(nèi)的戶名、TSkc。ereroTS創(chuàng)建一STIII階段3客戶端/至此，應用服務器S和客戶端C已經(jīng)認證了對宣稱的，并且完成了新加密密鑰所有主流的操作系統(tǒng)：微軟的Windows2000，微軟的WindowsServer2003，和許多UNIX和類UNIXBSDMacOSXRedHatEnterpriseLinux4Sun的Solaris，準的基礎上。Kerberosv5認證過程中的消息交換如圖5.21所示。圖5.21基于Kerberos Realmc,Realmtgs和Rea：分別指客戶端用戶所在域，TGS服務器所在域和應用服務from：期望的票據(jù)啟動時間till：請求的票據(jù)到期時間rtimeNonce2的加密回復中包含了與之相同的隨機數(shù)則證明KDC的回復是新鮮的而不是來自者的[]可能的序列號空間內(nèi)，因此者無法猜到這個序列號。例5.12基于可信任新鮮性對Kerberosv5協(xié)議的安全性分析如圖5.22所示。為便于對Kerberos圖5.22KerberosCAS表示認證服務器，TGS表示票據(jù)授予服務器，S表示應用服務器。T和_time表示客戶端為票據(jù)選擇的時間戳。Kas,tgs和Ks,tgs分別是AS和TGS之間，以及S和TGS之間的長期共享密鑰。kc,s是一個新的會話密鑰，由票據(jù)授予服務器TGS為客戶C和應用服務器SCCAS和票據(jù)授予服務器TGS知道；Ks,tgs是的，且只有應用服務器S和票據(jù)授予服務器TGS知道；N1和N2是一次隨機數(shù)，kc,tgs和kc,s是為這個協(xié)議的運行隨機生成的臨時密鑰。在消息1中，客戶端C通過發(fā)送客戶端C和票據(jù)授予服務器TGS，時間戳T和一在消息2中，認證服務器AS為C和TGS之間隨后的通信隨機生成一個新的密鑰kc,tgs，然密鑰Kas,tgsTGS證明這個TGT票據(jù)是由ASAS也將臨時密鑰kc,tgs發(fā)K密TGSkc,tgs,TN1，驗證N1的正確性，并得到臨時密鑰kc,tgsKk在消息3中客戶端C生成了認證元 t_k

t K Kk證時間戳T的正確性，并得到了臨時密鑰kc,tgs。TGS同時還會驗證認證元Ct_kKSkc,sC,T，TGS使用長期密鑰Ks,tgs來加密這個服務票據(jù)，用于向S證明這個STKk在收到消息4后，C使用kc,tgskc,s,T,N2, k在消息5中，客戶端C生成了新的認證元

_ KC也將消息4中收到的服務票據(jù)S,kc,s, KK在收到消息5后，應用服務器S使用長期密鑰Ks,tgsS,kc,s, ，同時驗證時間戳K的正確性，并得到新的會話密鑰kc,sS也會驗證認證元

_

_ 在收到消息2后，由引理4.2可得，C認為kc,tgs的性是有保障的。由引理4.3可得，由于kc,tgs是和C信任的新鮮性標識符N1一并發(fā)出的，因此C認為臨時密鑰kc,tgs的新鮮性KKKKK 只能由認證服務器使用長期共享密鑰Kas,tgs生成因此KTGS認為kc,tgs與TGS和C的關聯(lián)性都是有保障的。基于時間戳_time，由引理4.1可k元 t_ kkc,s是與C信任的新鮮性標識符N2一并發(fā)送給C的，因此，C認為臨時密鑰kc,s的新鮮性是k中被明確 了且加密包kc,s,T,N2, 是由C和TGS之間的共享臨時密鑰kc,tgs生kk的由引理4.1可得基于可信任新鮮性標識符N2，C認為TGS的主體活現(xiàn)性是有保障的，因為只有TGS能使用kc,tgs生成加密包kc,s,T,N2,S kKC和S的都在消息5中被明確地了，且加密包S,kc,s, 只能由TGS使用長Kk密鑰Ks,tgs來生成。基于時間戳_time，由引理4.1可得，S認為C的主體活現(xiàn)性是有保障的，因為只能是C使用共享會話密鑰kc,s來生成認證元C t_time k 對Kerberosv5協(xié)議的安全性分析

_ 新鮮的，并與客戶C和應用服務器S相關聯(lián)；而C相信S是存在的，且新的會話密鑰kc,s是公鑰并被授予。在這種新模式下，用戶和KDC顯然都需要信任相同的CA。公鑰Kerberos即PKINIT[26，它包含在Windows2000和WindowsServer2003中，是在傳統(tǒng)的Kerberosv5協(xié)議中，認證服務交換的長期共享密鑰通常由口令派生而得，這（pubc-eyfasrcue）已到位，KNT將借助K管理個系統(tǒng)用戶公Krerosebros卻是非稱加密數(shù)字簽和相應。KNT旨在通過引公鑰加來 和CertS用來證明每個主體和他所擁有的公鑰之間是綁定的。此時，C或AS只需要PKI中在微軟的類Kerberos系統(tǒng)中都支持PKINIT，包括Windows2000專業(yè)版和Windowsserver2000版，WindowsXP，和WindowsServer2003[29]，另外支持PKINIT還有包括Heimdal系統(tǒng)[30]。需要的是，PKINIT至今尚未被MIT的相關應用所支持。I階段1消息1C,TGS,T,N1Kerberosv5客戶想從中獲取TGT的TGSCertC,tcn2由KKK CertC和基于時間戳tc的客戶端的簽名tc,n2和另K消息2比基本的Kerberos2 C,TGSkc,tgs ,TGSkc,tgs,TN1與AS在基本的Kerberos中的消息 K K，K隨機數(shù)N1C處得到k，PKINIT在消息2中加上了消息部分CertAS,kn2KKK這個加密包是由Kc加密的，它包含AS CertAS和AS的簽名k,n2，因此只有CK例5.13這里給出針對公鑰版Kerberos，即PKINIT的基于可信任新鮮性的安全性分析。圖5.23公鑰加密PKINIT模式下KerberosKcK1分別是C的公鑰和私鑰，KasK1分別是AS CertC和CertAS分別指客戶端的和認證服務器的每個主體都知道可信任機構CA的公鑰，并能用其從CertC或CertAS處得到KcKas。每個主體知道自己的公私鑰對，即C知道KcK1AS知道KasK1 ccK名，然后C將C CertC，簽名tc,n2,，C和TGS ，時間戳T和N1一并發(fā)出KK K ，以找到CertC對應后TGS和C之間的通信，ASK1將k和n2簽名。AS用C的公鑰Kc加密后的密文KCertAS,k,n2KK

在消息14.2和引理4.3C認為隨機選擇的一次隨機數(shù)N1和n2的新鮮性是有保障的，C也認為N1和n2是不的。TGS不能從消息1中得到任何有用的安全性用C的私鑰K

,k,n

2Kkk是和n2于kctg是與的可信任新鮮性標識符一并發(fā)送給C的，C也認為臨時密鑰kctg的新鮮性是有保障的。由引理4.4可得，k和n2與AASK關聯(lián)，因為如果一個者是一個合法用戶，它將能C并使用Kc生成加密包KCertAS,k,n2KK

鑰，因此C不能確定新鮮消息

_ 是來自S5.9公鑰加密PKINIT模式下Kerberos表5.9是公鑰加密PKINIT模式下Kerberos協(xié)議的安全性分析結果。在協(xié)議運行結束后，S是的和新鮮的，但C不能確定kc,s是否與C和S都相關聯(lián)。 存在如圖5.24的[31]。圖5.24對公鑰加密PKINIT模式下KerberosiiKTGTTGSkc,tgsI K在消息1中，客戶端C開始運行一個新的協(xié)議。者I消息1，將CertC用CertI替KKK在消息2中，I使用C的公鑰構建了CertAS,k,n2KK

，并將I的替換成了C在消息3中，C照?；貜汀消息3，并將{C,time}中C的替換為I，然后 _ k在消息4中，I將消息4’中I的替換為C，然后轉發(fā)消息4在這個針對公鑰加密PKINIT模式下Kerberos的結束后，者I使得C產(chǎn)生錯誤的信任：C與S成功地完成了協(xié)議的運行，并且與S共享了新的會話密鑰kc,s。然而事實上，S對于在隨后發(fā)送敏感信息時，C將使用kc,s加密信息，然而這是者I也知道的密鑰kc,s，因而I能PKINITDiffie-man模 者可參閱文獻[26]。簡化的Diffie manPKINIT-26認證服務的消息交換如下：例 圖5.25KerberosPKINITDiffie 表5.10是KerberosPKINITDiffie-man的安全性分析結果，有的讀者可給出分析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(secures)RemoteLoginProtocol,Int