安全協(xié)議-第7章-上

安全協(xié)議分析與設(shè)計

第七章（上）衛(wèi)劍釩實用安全協(xié)議設(shè)計KerberosX.509TLS（SSL）IKEPPP&RADIUSWEP&WPAGSM&3G2KerberosKerberos是一項認(rèn)證服務(wù)，是MIT為Athena項目而開發(fā)的。它提供了一種驗證用戶身份的方法。它的實現(xiàn)不依賴于主機操作系統(tǒng)的認(rèn)證，不基于主機的地址，也不需要有主機物理安全性的保證，并假設(shè)網(wǎng)絡(luò)上傳輸?shù)陌伎梢员蝗我獾刈x取、修改和插入。Kerberos提供一個集中的認(rèn)證服務(wù)器來實現(xiàn)服務(wù)器和客戶之間的相互認(rèn)證，即通過使用常規(guī)的密碼算法，在上述條件下作為一個可信第三方進行認(rèn)證服務(wù)。Kerberos假定了一個分布式的客戶端/服務(wù)器結(jié)構(gòu)，使用一個或多個Kerberos服務(wù)器來提供認(rèn)證服務(wù)。3基本概念Kerberos的實現(xiàn)由客戶（C）、服務(wù)器（V）、認(rèn)證服務(wù)器（AS）以及票據(jù)提供服務(wù)器（TGS）組成?？蛻糇罱K從服務(wù)器（本節(jié)中的服務(wù)器指的都是應(yīng)用服務(wù)器）獲得所需的服務(wù)，AS和TGS是Kerberos服務(wù)器的主要內(nèi)容，AS提供對客戶的認(rèn)證，TGS頒發(fā)客戶所需服務(wù)的一個服務(wù)許可證，也即服務(wù)票據(jù)，記作TicketV。值得注意的是，AS也頒發(fā)票據(jù)，名為TGS票據(jù)，記作Tickettgs，客戶可以拿著這個Tickettgs向TGS索取TicketV。4認(rèn)證過程客戶登錄工作站所位于的域（realm，每個組織或機構(gòu)所擁有的網(wǎng)絡(luò)范圍）后，首先向AS認(rèn)證自己（這個過程要求用戶輸入口令），AS會返回一個Tickettgs給客戶，票據(jù)被AS和TGS共享的密鑰加密，這個認(rèn)證過程在整個登錄期間（從登入到登出）只發(fā)生一次。客戶需要服務(wù)時，向TGS發(fā)送這個TGS票據(jù)，以從TGS獲得一個服務(wù)票據(jù)TicketV，這個過程在登錄期間，根據(jù)所需服務(wù)種類的需要，每種服務(wù)會發(fā)生一次，如客戶需要郵件服務(wù)，會向TGS要一張郵件服務(wù)票據(jù)；需要FTP服務(wù)時，會向TGS要一張FTP服務(wù)票據(jù)。5認(rèn)證過程最后，客戶向服務(wù)器發(fā)送票據(jù)TicketV，服務(wù)器查看票據(jù)，確認(rèn)無誤后，向客戶提供服務(wù)。這個過程在登錄期間會發(fā)生多次，每次提供服務(wù)前都要發(fā)生一次，如客戶一天中多次檢查收取郵件時，每次都會提供票據(jù)TicketV。整個過程中，除了登錄時需要客戶輸入口令外，剩下的認(rèn)證過程都不需要客戶了解和參與。上述過程中省略了一個重要的內(nèi)容，即認(rèn)證符。它的作用是驗證客戶的身份，客戶不僅要傳輸票據(jù)，還需要發(fā)送額外的信息來證明自己確實是票據(jù)的合法擁有者，這個信息就是認(rèn)證符（authenticator），它使用會話密鑰加密，并包含了用戶名和時間戳。6過程的加密AS發(fā)給C票據(jù)的同時，還發(fā)送客戶C和TGS之間的會話密鑰Kc-tgs，這個會話密鑰本身由客戶口令衍生而得的密鑰加密；C發(fā)給TGS的認(rèn)證符則由Kc-tgs加密，TGS發(fā)給C票據(jù)的同時，還發(fā)送C和V之間的會話密鑰KCV，這個會話密鑰也由Kc-tgs加密，C發(fā)給V的認(rèn)證符由KCV加密。7跨域操作Kerberos協(xié)議被設(shè)計為可用來跨組織邊界進行操作。一個組織中（如一個部門或一個單位）的客戶可以被授權(quán)獲得另一個組織中服務(wù)器的服務(wù)。從網(wǎng)絡(luò)角度講，每一個運行Kerberos服務(wù)器的子網(wǎng)都是一個域。通過建立“域間密鑰”，一個客戶不僅可以從他本地域的TGS獲得TicketV，還可獲得一個遠(yuǎn)程域的Tickettgsrem。然后客戶在需要使用遠(yuǎn)程域的服務(wù)時，將Tickettgsrem發(fā)送給遠(yuǎn)程域的TGS，遠(yuǎn)程的TGS使用域間密鑰來解密Tickettgsrem，驗證它是否是由客戶所在域的TGS頒發(fā)的。如果驗證通過，遠(yuǎn)程TGS頒發(fā)遠(yuǎn)程服務(wù)票據(jù)TicketVrem。域通常是分層組織的。每個域分別和它的每個子域共享不同的密鑰，而和它的父域共享一個密鑰。如果一個域間密鑰不是被兩個域直接共享，那么分層組織允許一個認(rèn)證路徑很簡單地被建立起來。如果沒有使用分層組織，就有必要考慮采用某種方式來在域間建立認(rèn)證路徑。8環(huán)境假設(shè)Kerberos所運行的環(huán)境是基于以下假設(shè)的。（1）Kerberos不能解決“拒絕服務(wù)”攻擊。（2）Kerberos不能解決“口令猜測”攻擊。（3）網(wǎng)絡(luò)中的任何一臺主機必須擁有一個和其他主機時間“松同步”的時鐘，時鐘同步協(xié)議本身必須是安全的。9報文交換Kerberos（v5）認(rèn)證過程的報文交換有6條，分為3個階段。10第1階段第1階段由Msg1和Msg2組成，是C和AS之間的交互。Msg1是客戶請求報文，其中options包括一些與票據(jù)相關(guān)的細(xì)節(jié)信息，RealmC指明客戶所屬的域，Times用于客戶請求票據(jù)中的時間設(shè)置，Nonce1是C提供的一個現(xiàn)時值。Msg2是AS返回的內(nèi)容，主要包含了票據(jù)Tickettgs，F(xiàn)lags反映這張票據(jù)的一些屬性，如該票據(jù)是否有效、是否可更新等，KC-tgs是客戶與TGS之間的會話密鑰。Times是Msg1中請求的時間，Kas-tgs是AS和TGS共享的密鑰，TGS（嚴(yán)格地講，應(yīng)該是IDtgs）指明TGS的標(biāo)識，表示這張票據(jù)是為該TGS生成的。KC是基于用戶口令衍生的密鑰（如口令的散列值），使得AS和客戶能驗證口令，并保護Msg2的內(nèi)容。11第2階段第2階段由Msg3和Msg4組成，是C和TGS之間的交互。C發(fā)出Msg3，請求服務(wù)票據(jù)TicketV。Msg3中的Options指明了一些選項，V表明C希望訪問的服務(wù)器，Nonce2是C產(chǎn)生的第2個Nonce，Tickettgs是C在Msg2中得到的票據(jù)，用來告知TGS這個客戶已經(jīng)經(jīng)過AS的認(rèn)證。AuthenticatorC-tgs是由C產(chǎn)生用來證明票據(jù)合法性的認(rèn)證符，其中TS1表明了這個認(rèn)證符發(fā)出的時間，KC-tgs是C和TGS之間的會話密鑰，由AS創(chuàng)建，C由Msg2中獲取該密鑰。C和TGS無須共享一個永久密鑰。Msg4是TGS返回給C的TicketV，其中KC-V是C和服務(wù)器V共享的會話密鑰，Ktgs-V是TGS和服務(wù)器V共享的密鑰，Nonce2是Msg3中攜帶的現(xiàn)時。12第3階段第3階段由Msg5和Msg6組成，是C和V之間的交互。Msg5是客戶請求服務(wù)報文，它主要包括TicketV和認(rèn)證符AuthenticatorC-V，TicketV是客戶C用來訪問服務(wù)器V的票據(jù)，C向V證明這個用戶已經(jīng)經(jīng)過AS和TGS的認(rèn)證，AuthenticatorC-V由C產(chǎn)生用來證明票據(jù)的合法性，其中的TS2表明這個認(rèn)證符發(fā)出的時間。Subkey是C選擇的一個加密密鑰，用來保護一個特定的應(yīng)用會話（如郵件內(nèi)容的加密），如果這個字段被省略，則使用票據(jù)中的KC-V作為應(yīng)用的加密密鑰。Seq#是一個可選字段，用來通知此次會話中服務(wù)器向客戶發(fā)送報文的起始序號，以達(dá)到防重放的效果。Msg6是服務(wù)器V的響應(yīng)，它用客戶C和服務(wù)器V之間共享的會話密鑰KC-V加密了Msg5中攜帶的TS2、Subkey和Seq#。13Kerberos協(xié)議特點用戶從登錄到退出系統(tǒng)的全過程中，其間可能獲取了多種服務(wù)，但只需輸入一次口令，而且口令本身并不被傳輸，對口令的驗證是看能否解開Msg2。另外，協(xié)議設(shè)計中使用了票據(jù)的概念，使得復(fù)用成為可能，減少了服務(wù)獲取時所需的消息交互次數(shù)，提高了整體效率。協(xié)議在版本4中，加密方法采用的是DES的非標(biāo)準(zhǔn)模式PCBC，這種模式容易遭受攻擊[Kohl89]，版本5中使用標(biāo)準(zhǔn)的CBC模式。Kerberos使用集中式的AS和TGS進行管理，容易造成瓶頸效應(yīng)；Kerberos全程采用對稱加密算法來達(dá)到認(rèn)證的目的，這也是它的一個顯著特點。14X.509標(biāo)準(zhǔn)X.509是關(guān)于證書結(jié)構(gòu)和認(rèn)證協(xié)議的一個重要標(biāo)準(zhǔn)，是X.500系列中關(guān)于目錄服務(wù)（Directoryservice）的一部分。目錄服務(wù)的一個作用是提供公鑰證書，每個證書包含用戶的公開密鑰和權(quán)威機構(gòu)對其的簽名。X.509標(biāo)準(zhǔn)的核心是公鑰證書，證書由認(rèn)證中心（CA）創(chuàng)建，并被存放在目錄服務(wù)器中。X.509還提供了3個使用公鑰證書的認(rèn)證協(xié)議。15證書證書一般包括如下字段:版本（Version）：區(qū)分證書的不同版本，默認(rèn)是第1版；如果提供了頒發(fā)者唯一標(biāo)識符或主體唯一標(biāo)識符，那么版本必須是第2版；如果存在一個或多個擴展，那么版本必須是第3版。證書序列號（Certificateserialnumber）：在發(fā)布證書中的一個有唯一性的整數(shù)值。簽名算法標(biāo)識符（Signaturealgorithmidentifier）：用來簽名證書的算法以及一些相關(guān)的參數(shù)。頒發(fā)者名字（Issuername）：創(chuàng)建和簽名這個證書的CA的X.500名字。有效期（Periodofvalidity）：包含兩個日期，由證書的生效時間和終止時間組成。主體名（Subjectname）：公鑰擁有者的用戶名。16證書主體的公鑰信息（Subject'spublic-keyinformation）：主體的公鑰以及這個密鑰對應(yīng)算法（即這個公鑰會用在什么算法中）的標(biāo)識符，以及算法的相關(guān)參數(shù)。簽名（Signature）：對所有字段（不含本字段）的散列碼的簽名，簽名使用的是CA的私鑰。頒發(fā)者的唯一標(biāo)識符（Issueruniqueidentifier）：可選，用來唯一標(biāo)識CA，僅用于第2版和第3版。主體的唯一標(biāo)識符（Subjectuniqueidentifier）：可選，用于唯一標(biāo)識主體，僅用于第2版和第3版。擴展（Extensions）：包含一個或多個擴展字段的集合，僅用于第3版。17X.509認(rèn)證協(xié)議X.509提供了3個認(rèn)證協(xié)議，這些協(xié)議都使用公鑰進行簽名，消息的條數(shù)分別為1條、2條和3條，每個協(xié)議都是對前一個協(xié)議附加一條消息。對于第1個協(xié)議，協(xié)議的目標(biāo)是由A傳遞給B一個會話密鑰，后兩個協(xié)議中，B也傳遞給A一個會話密鑰。18X.509單消息認(rèn)證協(xié)議報文中包括一個時間戳Ta、一個現(xiàn)時Na、用戶數(shù)據(jù)Xa和Ya。時間戳由產(chǎn)生時間（可選）和過期時間組成，可用于防止報文的延遲傳遞?，F(xiàn)時在報文的起止時間內(nèi)是唯一的，這樣，B可以存儲這個現(xiàn)時直到它過期，并在這個時間內(nèi)拒絕有相同現(xiàn)時的報文。該協(xié)議被[AN96]認(rèn)為是違反了先簽名后加密的原則，但事實上這很難說是一個攻擊。如果要避免這種“攻擊”，可以將{Ya}Kb改為{A,Ya}Kb。19X.509雙消息認(rèn)證協(xié)議雙消息協(xié)議和單消息協(xié)議的區(qū)別在于發(fā)起方也可以認(rèn)證響應(yīng)方了，也即實現(xiàn)了雙向身份認(rèn)證。20X.509三消息認(rèn)證協(xié)議比起雙消息協(xié)議，新增了最后一條從A發(fā)往B的報文，主要是為了讓B確認(rèn)它發(fā)送的消息已經(jīng)被A收到。

21協(xié)議特點在雙消息和三消息協(xié)議中，同時使用時間戳和現(xiàn)時是一個冗余，事實上，時間戳和現(xiàn)時的目的都是為了保證新鮮性，同時使用沒有必要，所以標(biāo)準(zhǔn)也指出，對于后兩個協(xié)議，Tb可以設(shè)為零，Ta可以不加檢驗。在協(xié)議的第1版中（1988年版本），三消息認(rèn)證協(xié)議的最后一條消息中，簽名部分是{Nb}Ka?1而不是{Nb，B}Ka?1，這會導(dǎo)致一個攻擊。攻擊者C可以冒充A來欺騙B，C先發(fā)送給B一個舊的Msg1冒充A（標(biāo)準(zhǔn)允許不檢查時間戳），然后只要能做出Msg3就可以了，Msg3中要求C能夠做出{Nb}Ka?1。C此時立即開始一次和A的會話，新的會話中A是發(fā)起方，C在第2條消息中給出Nb，從而得到所期望的Msg3，完成攻擊。22傳輸層安全協(xié)議SSL協(xié)議是由網(wǎng)景公司（Netscape）于1993年提出的，被設(shè)計成使用TCP來提供可靠的端到端安全服務(wù)。1994年網(wǎng)景公司推出了SSLv2.0，1996年推出了SSLv3.0。IETF于1999年1月推出傳輸層安全（TLS）協(xié)議，TLS作為一個Internet標(biāo)準(zhǔn)（RFC2246），是建立在SSLv3.0基礎(chǔ)上的，所以TLS又被稱為SSLv3.1。TLS協(xié)議位于應(yīng)用層和傳輸層之間，主要目的是在兩個通信應(yīng)用之間保障數(shù)據(jù)的機密性和完整性。TLS協(xié)議本身可以被看成是一個兩層協(xié)議，即TLS高層協(xié)議和TLS低層協(xié)議。23TLS協(xié)議的層次TLS高層協(xié)議包括握手協(xié)議、告警協(xié)議和修改密文規(guī)約協(xié)議。其中的握手協(xié)議允許服務(wù)器和客戶進行相互認(rèn)證，并且可以在應(yīng)用層協(xié)議傳輸數(shù)據(jù)之前協(xié)商加密算法和密鑰。TLS低層協(xié)議就是TLS記錄協(xié)議，它完成的功能是：接收需要傳輸?shù)纳蠈訁f(xié)議消息、將消息分片、可選地壓縮消息片、添加MAC、加密、添加記錄首部，最終形成一個記錄（record），然后將記錄傳輸給TCP層。24TLS協(xié)議的層次結(jié)構(gòu)TLS記錄協(xié)議位于TCP之上，它為不同的上層協(xié)議提供安全連接，連接的保密性是通過加密來實現(xiàn)的，并且可以使得每個連接使用的加密密鑰都不同。要做到這一點，需要通過位于TLS高層協(xié)議中的握手協(xié)議來完成。修改密文規(guī)約協(xié)議（changecipherspecprotocol）的作用是更改連接使用的密文規(guī)約（密碼算法及密碼參數(shù)）。協(xié)議由單個報文組成，報文為單個字節(jié)，用于握手協(xié)議結(jié)束后進行新密文規(guī)約的啟用，當(dāng)客戶和服務(wù)器在協(xié)商好新的密文規(guī)約后，都發(fā)送這條報文，以通知對方采用新協(xié)商好的密文規(guī)約（如加密算法、MAC算法、加密參數(shù)等）。25TLS協(xié)議的層次結(jié)構(gòu)每個連接正在使用的密文規(guī)約稱為當(dāng)前狀態(tài)，剛協(xié)商好的密文規(guī)約稱為準(zhǔn)備狀態(tài)（pendingstate）。收到修改密文規(guī)約報文后，接收方立即將準(zhǔn)備狀態(tài)（也就是剛協(xié)商好的密文規(guī)約）復(fù)制到當(dāng)前狀態(tài)，連接開始使用新的密文規(guī)約。同樣地，發(fā)送方在發(fā)出這個報文之后，也立即將準(zhǔn)備狀態(tài)復(fù)制給當(dāng)前狀態(tài)。告警協(xié)議包括若干個告警報文，告警報文的作用是當(dāng)握手出錯時、加密出錯時或發(fā)生異常情況時，向?qū)Ψ桨l(fā)出警告或終止當(dāng)前連接。和其他報文一樣，告警報文也采用當(dāng)前狀態(tài)中的算法和參數(shù)進行加密及壓縮。26會話和連接TLS有兩個重要概念，分別是TLS會話和TLS連接。它們是通過握手協(xié)議建立起來的，建立好TLS連接以后，才可能在這個連接上傳輸應(yīng)用層數(shù)據(jù)。TLS會話包括以下參數(shù)。●會話標(biāo)識符：一個字節(jié)序列，用來標(biāo)識一個活動的會話?！駥Ψ降淖C書：對方的X.509第3版證書，可以為空?！駢嚎s方法：在加密前用來壓縮數(shù)據(jù)的算法?！衩芪囊?guī)約：對稱加密算法（如DES或者空加密等）、MAC算法（如MD5或SHA），以及其他一些密碼參數(shù)?！裰髅孛埽嚎蛻艉头?wù)器之間共享的秘密（master_secret），48字節(jié)長?！袷欠窨蓮?fù)用（isresumable）：用來指示該會話是否可被用來初始化一個新的連接。27會話和連接“是否可復(fù)用”參數(shù)表明一個會話是否可以初始化新的連接，即多個連接可以共享一個會話的參數(shù)，每個連接都是一個會話的實例。這樣做的目的是節(jié)省資源，避免為每個連接協(xié)商全部的安全參數(shù)，因為協(xié)商需要大量的密碼運算和消息交互，代價往往是昂貴的。TLS連接的參數(shù)除了會話參數(shù)外，還包括服務(wù)器和客戶端各自的隨機數(shù)，服務(wù)器和客戶端各自的MAC密鑰（該密鑰用于生成MAC），各自的加密密鑰（也稱各自的寫密鑰，指服務(wù)器的加密密鑰和客戶端的加密密鑰，等同于客戶的解密密鑰和服務(wù)器的解密密鑰），CBC模式加密時所使用的初始化向量、報文序號等。28握手協(xié)議29交互過程客戶發(fā)出Msg1，包含了一個隨機數(shù)、一個會話ID（零值表示客戶希望開始一個新的會話，非零值表示客戶希望重用一個會話）、一個密碼算法列表（列表中的每一項都說明了客戶所支持的密鑰交換方法、密碼算法和Hash算法，這些項按照客戶所希望的優(yōu)先級排序）、一個壓縮算法列表（也是按照客戶希望的優(yōu)先級排序，算法中可以包含一個NULL算法，表明不壓縮）。服務(wù)器收到Msg1后，回復(fù)Msg2，其中包含服務(wù)器產(chǎn)生隨機數(shù)；如果會話ID非零，會在自己的會話緩沖里尋找這個會話，如果找到，就回這個ID，表示可以重用這個會話，如果找不到，則回一個零值表明無法重用；如果客戶給的會話ID為零，服務(wù)器會產(chǎn)生一個新值用來標(biāo)識這個新的會話。然后服務(wù)器按照客戶端的優(yōu)先級選擇自己支持的密碼算法和壓縮算法，如果是重用會話，則使用那個會話的密碼算法和壓縮算法作為回應(yīng)。30交互過程只要密鑰交換算法不是匿名DH交換，Msg3（certificate報文）就需要被發(fā)出，通常是一個X.509證書，含有一個用于密鑰交換的密鑰，如RSA公鑰或固定DH交換需要的公開參數(shù)。如果沒有發(fā)出Msg3或者Msg3提供的密鑰信息不夠，就需要發(fā)出Msg4（server_key_exchange報文），主要是臨時DH交換或匿名DH交換的公開參數(shù)，或者是未能在證書中提供的RSA公鑰。如果需要認(rèn)證客戶，Msg5（certificate_request報文）需要被發(fā)出，以使得服務(wù)器獲得客戶的證書，然后Msg6（server_hello_done報文）表明服務(wù)器發(fā)送的相關(guān)參數(shù)結(jié)束，該報文本身不帶任何參數(shù)。31交互過程如果服務(wù)器已經(jīng)發(fā)出過Msg5，那么客戶端就必須響應(yīng)一個certificate報文，即Msg7，如果客戶沒有證書可用，就會發(fā)出一個no_alert告警報文（這屬于TLS告警協(xié)議）。客戶接著發(fā)送Msg8（client_key_exchange報文），這個報文的內(nèi)容依賴于在client_hello和server_hello之間選擇出來的密鑰交換類型。如果是RSA方法，客戶生成48字節(jié)的預(yù)先主秘密（pre_master_secret），并使用Msg3或者Msg4提供的RSA密鑰對其進行加密作為報文內(nèi)容。如果是臨時DH或匿名DH交換，則發(fā)送客戶的DH公開參數(shù)，如果是固定DH交換，由于該參數(shù)已經(jīng)在Msg7中發(fā)送了，此時報文內(nèi)容為空。服務(wù)器收到Msg8以后，就有能力算出主秘密（master_secret）了，當(dāng)然客戶端也可以算出相同的這個主秘密。其他密文參數(shù)也可依次由主秘密算出，32主秘密的生成方法主秘密的生成方法：master_secret=PRF(pre_master_secret, "mastersecret",ClientHello.random+

ServerHello.random)[0..47];PRF是偽隨機函數(shù)，有3個輸入?yún)?shù)，用法為PRF（secret,label,seed），可以通過迭代的方法產(chǎn)生任意長度的隨機數(shù)，這里，只需要產(chǎn)生出48字節(jié)就足夠了，故用[0..47]表示PRF產(chǎn)生的序列的前48字節(jié)。secret參數(shù)是雙方交換而得的預(yù)先主秘密pre_master_secret；label在這里是“mastersecret”，是一個字符串，13個字節(jié)；ClientHello.random是Msg1中客戶給出的隨機數(shù);ServerHello.random是Msg2中服務(wù)器給出的隨機數(shù);它們的連接作為第3個參數(shù)。33生成其他秘密材料使用主秘密可以進一步生成其他材料，首先生成key_block：

key_block=PRF(master_secret,"keyexpansion",ClientHello.random+ServerHello.random);然后將key_block劃分為所需的各密碼參數(shù)，依次為：客戶寫MAC秘密（client_write_MAC_secret）服務(wù)器寫MAC秘密（server_write_MAC_secret）客戶寫密鑰（client_write_key）服務(wù)器寫密鑰（server_write_key）客戶寫初始化向量（client_write_IV）服務(wù)器寫初始化向量（server_write_IV）。34交互過程如果客戶端已經(jīng)在Msg7中發(fā)送了具有簽名能力的證書，那么Msg9（certificate_verify報文）將被發(fā)出，這個報文中，客戶對前面已經(jīng)交換了的報文的散列進行了簽名?？蛻舸藭r發(fā)送Msg10（change_cipher_spec報文），并立刻將連接的準(zhǔn)備狀態(tài)復(fù)制到當(dāng)前狀態(tài)，在發(fā)送Msg11（client_finished報文）時，就已經(jīng)使用新的密文規(guī)約加密了。收到Msg10和Msg11后，服務(wù)器發(fā)出Msg12（change_cipher_spec報文），改變自己的密文規(guī)約狀態(tài)，然后使用新的密文規(guī)約發(fā)送Msg13（server_finished報文）作為結(jié)束報文。35結(jié)束報文結(jié)束報文長度為12個字節(jié)，計算方法如下：PRF(master_secret,finished_label,MD5(handshake_messages)+SHA-1(handshake_messages))[0..11];其中，finished_label對客戶和服務(wù)器是不同的，對于Msg11為“clientfinished”，對于Msg13為“serverfinished”。handshake_messages是到目前為止，所有已經(jīng)交換了的報文（不包括當(dāng)前這個正在生成的finished報文）。36會話重用當(dāng)客戶希望重用一個已存在的會話，而不想重新協(xié)商新的密文規(guī)約時，在Msg1中包含有一個非零的會話ID，服務(wù)器如果能在會話緩沖中找到這個ID，并且愿意使用這個舊的會話參數(shù)時，就會在Msg2中告訴客戶可以重用該會話。此時，從Msg3到Msg9都不會產(chǎn)生，雙方的交互只有Msg1、Msg2、Msg10、Msg11、Msg12和Msg13。由于重用的只是會話參數(shù)，連接的參數(shù)需要重新被計算，這將使用舊的pre_master_secret和新的ClientHello.random、ServerHello.random生成新的master_secret和新的密鑰材料。37協(xié)議特點TLS協(xié)議擁有3種認(rèn)證模式，分別是客戶端和服務(wù)器互相認(rèn)證；只認(rèn)證服務(wù)器，不認(rèn)證客戶端；客戶端和服務(wù)器均不認(rèn)證，即完全匿名模式。在應(yīng)用時，要注意謹(jǐn)慎使用完全匿名模式，這種模式使用不帶認(rèn)證的DH交換算法，對中間人攻擊沒有防范能力。該協(xié)議以及SSL協(xié)議被很多人分析過，如文獻[Paul99a]、[Paul99b]、[WS96]、[MS98]等，均未發(fā)現(xiàn)嚴(yán)重的安全問題（在完善加密假設(shè)的前提下）。38謹(jǐn)慎的設(shè)計者協(xié)議的設(shè)計者很謹(jǐn)慎，在certificate_verify報文、client_finished報文、server_finished報文中，都使用了已交換報文的散列，以防止攻擊者對消息的擾亂；在散列算法的使用上也很謹(jǐn)慎，MD5和SHA算法常常被同時使用，以防范單個散列算法被攻破后造成的風(fēng)險；協(xié)議還規(guī)定必須先使用pre_master_secret生成master_secret，然后再通過master_secret生成其他密文素材，這是因為在使用固定DH交換時，pre_master_secret總是相同。39Internet密鑰交換協(xié)議InternetKeyExchange（IKE）協(xié)議[RFC2409]是IETF（InternetEngineeringTaskForce）制定的密鑰交換協(xié)議標(biāo)準(zhǔn)，用來在通信雙方之間建立安全關(guān)聯(lián)（SA）以及經(jīng)過認(rèn)證的密鑰材料。它建立在ISAKMP（InternetSecurityAssociationandKeyManagementProtocol）定義的通用密鑰交換框架之上[RFC2408]。在介紹IKE之前，有必要先了解一下IPSec（IPSecurity，IP層安全）。40IPSecTLS可以對應(yīng)用層的協(xié)議加密，并傳遞給傳輸層，但在IP層并不做任何安全性處理。IP作為其他高層協(xié)議的載體，本身并未考慮安全性問題。IPSec的推出就是用來在IP層進行安全處理，對于高層數(shù)據(jù)，只要是通過IP傳輸，都會在IP層進行安全防護，實現(xiàn)IP數(shù)據(jù)包的機密性、完整性等安全特性，為上層協(xié)議提供“透明”的安全服務(wù)。41IPSecIPsec是怎么實現(xiàn)對IP層的安全防護呢？主要是通過對IP包的加密和添加MAC完成的。為了不影響IP包的傳輸，安全處理后的IP包仍然是一個IP包的形式，這就要求不改變IP包的結(jié)構(gòu)，而是通過在原始IP數(shù)據(jù)包做數(shù)據(jù)處理并插入數(shù)據(jù)頭來完成。IPSec有兩種數(shù)據(jù)頭，一種是ESP頭（可實現(xiàn)機密性和完整性保護），另一種是AH頭（可實現(xiàn)完整性保護）?？筛鶕?jù)需要，使用其中的一種頭或者兩種都使用。IPSec有兩種協(xié)議模式，一種是傳輸（transport）模式，另一種是隧道（tunnel）模式。傳輸模式是在IP頭和IP數(shù)據(jù)部分之間插入IPSec頭，并對IP包進行處理，IP頭部不進行加密。隧道模式則保護整個IP包，在原IP包外部添加IPSec頭，對整個原IP包進行處理，然后產(chǎn)生一個新的IP頭來封裝IPSec頭及處理過的原IP包。42SA及IKEIPSec中一個重要概念是安全關(guān)聯(lián)（SecurityAssociation，SA），這是指兩個實體間維護的一些安全參數(shù)，它經(jīng)過協(xié)議（如IKE協(xié)議）的協(xié)商或配置，存放在每個IPSec的實體里。每當(dāng)一個實體需要和另一個實體使用IPSec處理數(shù)據(jù)時，會查找相應(yīng)的SA，然后用這個SA里規(guī)定的安全參數(shù)對實體間的IP數(shù)據(jù)進行安全處理。IPSecSA的產(chǎn)生有賴于IKE協(xié)議（可以把IKE可看做IPSec實現(xiàn)的一部分）的運行。IKE是在ISAKMP框架下實現(xiàn)的，ISAKMP為Internet通信雙方的SA建立和密鑰交換提供了通用的框架，但它并不是一個具體的密鑰交換技術(shù)，而只是作為框架來支持各種密鑰交換協(xié)議（如IKE）。IKE標(biāo)準(zhǔn)在RFC2409里被詳細(xì)地描述。43IKE包括兩個階段IKE協(xié)議分為兩個階段。第1階段，通信雙方經(jīng)過協(xié)商，生成ISAKMPSA；ISAKMPSA主要包括加密算法、散列算法、認(rèn)證方法、DH交換的組信息、SA生命周期等；第2階段，在ISAKMPSA的保護下為安全服務(wù)（如IPSec）協(xié)商用于該安全服務(wù)的SA（如IPSecSA）。而IPSecSA的內(nèi)容主要包括驗證算法、加密算法、生存期、序列號、協(xié)議模式（如傳輸模式或隧道模式）等實施AH和ESP處理所需的信息。44第1階段的模式IKE第1階段有主模式（mainmode）和積極模式（aggressivemode）兩種工作模式。主模式對應(yīng)于ISAKMP框架的身份保護交換模式，雙方共交換6條消息：頭兩條消息協(xié)商策略，中間兩條消息交換Diffie-Hellman（DH）的公開值和必要的輔助數(shù)據(jù)（如Nonce），最后兩條消息認(rèn)證Diffie-Hellman交換。積極模式對應(yīng)于ISKAMP框架的積極模式，這種模式速度較快，但通常不能提供身份保護功能，積極模式下雙方交換3條消息，前兩條消息里完成協(xié)商和DH交換，第3條消息完成交換數(shù)據(jù)的認(rèn)證。主模式和積極模式均可使用4種認(rèn)證方式：預(yù)共享密鑰方式、數(shù)字簽名方式、標(biāo)準(zhǔn)公鑰加密方式和修訂的公鑰加密方式（后兩者統(tǒng)稱公鑰加密方式）。45其他模式第2階段的消息在第1階段產(chǎn)生的SA的保護下，為IPsec協(xié)議或者其他需要安全參數(shù)的應(yīng)用層協(xié)議協(xié)商SA。第2階段只有一種模式，稱為快速模式（quickmode）。IKE除了上面3種模式外，還有一種新組模式（newgroupmode），新組模式既不在階段1也不在階段2，而位于階段1之后，用來建立一個可供將來DH協(xié)商使用的新組。46使用數(shù)字簽名認(rèn)證的IKE第一階段I表示發(fā)起方，R

表示響應(yīng)方。每條消息都是一個ISAKMP消息包，ISAKMP消息可以經(jīng)由TCP或者UDP傳輸，端口號為500。消息由報頭（header）和載荷（payload）構(gòu)成。HDR表示ISAKMP報頭，HDR*表示消息中ISAKMP報頭后的部分是加密的。47ISAKMP報頭報頭的前兩個域是cookie，分別由發(fā)起方和響應(yīng)方在Msg1和Msg2中生成，長度均為8字節(jié)，一旦確定，在交換中，雙方檢查消息報頭中cookie域的值是否發(fā)生改變，如果被改變，則拋棄掉該消息，這可以用來防范DoS攻擊。在第2階段交換中，cookie域的值則標(biāo)識了用于保護消息的ISAKMPSA。48ISAKMP報頭“下一個載荷”域指明了消息中下一個載荷的類型，如SA載荷的類型為1，密鑰交換載荷的類型為4，身份載荷的類型為5，簽名載荷的類型為9等等，每個載荷有一個載荷頭，載荷頭中又指示了下一個載荷的類型，沒有下一個載荷則該域填0。“主版本號”和“次版本號”分別表示了所使用的ISAKMP的版本號。“交換類型”表明了交換的模式，如主模式或積極模式等等?！跋D”用于第2階段，由發(fā)起者產(chǎn)生，用于標(biāo)識不同的會話。因為這些會話可能是在同一個ISAKMPSA的保護下運行的（該ISAKMPSA由報頭中的cookie域標(biāo)識）?！伴L度”域標(biāo)明了整個消息的長度，它包括頭部和所有載荷的長度。49Msg1和Msg2在Msg1和Msg2中，SAi

和SAr

分別表示I和R發(fā)送的安全關(guān)聯(lián)（SA）載荷；其中SAi中可能有多個SA建議，這通過多個變換載荷來做到，這些變換載荷被封裝在一個提議載荷中，而提議載荷又被封裝在一個SA載荷中。響應(yīng)者挑選并返回其中的一個建議（封裝在Msg2中的SA載荷里），響應(yīng)者不能修改建議中的屬性，如果發(fā)起者發(fā)現(xiàn)屬性值被修改了，或者有屬性在建議中被增加或刪除了，則Msg2將被廢棄。第1階段的交換不允許在一個SA載荷內(nèi)封裝多個提議載荷，也禁止多個SA載荷出現(xiàn)。第2階段無此限制。此外，除非有特殊說明，在任何消息中的ISAKMP載荷都沒有必要排成一個特定的順序。當(dāng)不能接受建議、簽名驗證失敗或解密失敗時，可以發(fā)送通知（Notify）載荷。50Msg3和Msg4在Msg3和Msg4中，Ni和Nr

分別表示I和R發(fā)送的現(xiàn)時（Nonce）載荷；

KEi和KEr分別表示I和R發(fā)送的密鑰交換（KE）載荷，其中分別含有Diffie-Hellman公開參數(shù)g^xi

和g^xr。雙方完成Diffie-Hellman交換后，根據(jù)不同的認(rèn)證方式可以計算出用于衍生其他密鑰材料的SKEYID，對于數(shù)字簽名認(rèn)證方式，SKEYID的計算方法如下：SKEYID=prf(Ni|Nr,g^xixr)^表示冪運算，得到SKEYID后，繼而根據(jù)下頁的算法產(chǎn)生3個密鑰材料。513個密鑰材料|表示連接運算，prf（key,msg）表示雙方協(xié)商的以key和msg為參數(shù)的prf函數(shù)，如果未協(xié)商prf，則用協(xié)商的散列算法的HMAC運算作為prf；SKEYID_d用來衍生其他密鑰材料，SKEYID_a用于生成認(rèn)證密鑰，SKEYID_e用于生成加密密鑰。其中的0、1、2為單個字節(jié)的數(shù)值，CKYi和CKYr分別表示由I和R產(chǎn)生的包含在HDR中的Cookie。52Msg5和Msg6在Msg5和Msg6中，IDi

和IDr

分別表示I和R發(fā)送的身份（ID）載荷，CERTi和CERTr分別表示I和R的證書載荷，[]表明其中的內(nèi)容可選。HASHi=prf(SKEYID,g^xi|g^xr|CKYi|CKYr|SAi|IDi)HASHr=prf(SKEYID,g^xr|g^xi|CKYr|CKYi

|SAi

|IDr)SIGi=SigSKi(HASHi)SIGr=SigSKr(HASHr)Sig

key(msg)表示用私鑰key對msg的簽名運算，S