第六章實用安全系統(tǒng)

第六章實用安全系統(tǒng)目錄6.1PGP6.2S/MIME6.3SecureShell6.4SFTP6.1PGP

PGP是美國菲利普·齊默曼（PhilipR.Zimmermann）提出來的。他創(chuàng)造性地把RSA公鑰體系的方便和傳統(tǒng)加密體系的高速度結(jié)合起來，并且在數(shù)字簽名和密鑰認證管理機制上進行巧妙的設計，從而使PGP成為流行的公鑰加密軟件包。PGP是一個基于RSA公鑰加密體系的郵件加密軟件，可以用于郵件保密，防止非授權(quán)者閱讀，還能對郵件加上數(shù)字簽名，從而使收信人可以確信郵件是誰發(fā)來的。它讓用戶可以安全地和用戶從未見過的人通信，事先并不需要任何保密的渠道來傳遞密鑰。6.1.1PGP原理PGP加密由一系列散列、數(shù)據(jù)壓縮、對稱密鑰加密，以及公鑰加密的算法組合而成。每個步驟支持幾種算法，可以選擇其中一種使用。基本上包含了4個密碼單元：單鑰密碼IDEA、雙鑰密碼RSA、單向散列算法MD5、一個隨機數(shù)生成算法。這些密碼單元在本書第2章中都有相關(guān)介紹。

需要注意的是，隨機數(shù)生成是指PGP提供兩個偽隨機數(shù)發(fā)生器（PRNG）：一個是ANSIX9.17發(fā)生器，采用IDEA算法，以CFB（密碼反饋模式）生成；另一個是從用戶擊鍵的時間和序列中計算熵值，從而引入隨機性。PGP在安全上的業(yè)務有：認證、加密、壓縮、Base-64變換、分段和重組。

1．認證PGP可以只簽名而不加密。這適用于公開發(fā)表聲明、聲明人為了證實自己的身份，可以用自己的私鑰簽名，這樣就可以讓收件人確認發(fā)信人的身份，也可以防止發(fā)信人抵賴自己的聲明。PGP認證流程如圖6.1所示。

圖6.1PGP認證流程

送信人編制消息M準備發(fā)出，用MD5算法產(chǎn)生一個128位的散列值H，并且用送信人的RSA密鑰對H簽字，然后將M和H合成壓縮發(fā)送出去，接收端對收到的數(shù)據(jù)進行解壓，并用發(fā)送人公鑰解出H，用接收的M計算散列值得H'，與H值進行比較簽字。2．加密

加密過程如圖6.2所示，密鑰管理模塊根據(jù)用戶輸入的收信人標識信息，找到收件人的公鑰。隨機數(shù)生成器產(chǎn)生僅使用一次的128位會話密鑰，IDEA算法利用這個會話密鑰對經(jīng)壓縮后的明文信件進行加密，生成密文信件。同時，RSA算法模塊利用收件人的公鑰對會話密鑰再加密。最后，PGP把RSA加密后的會話密鑰與IDEA加密后的密文信件合并在一起，形成一個新的文件并輸出在磁盤中。由于PGP在調(diào)用IDEA算法模塊加密文件之前，已對文件做了壓縮處理，因此，輸出的文件的容量不會增大。圖6.2加密過程

由于PGP每次加密都使用一個隨機的128位會話密鑰，因此同一個文件兩次加密后的結(jié)果是截然不同的。圖6.2中的randseed.bin文件就是用來構(gòu)造這個隨機會話密鑰的。由于每次使用不同的會話密鑰，因此，進一步增加了PGP加密的可靠性，也防止了竊取者獲悉雙方是否在傳送同一內(nèi)容的文件的可能性。

如圖6.3所示是PGP接收加密郵件之后的解密過程。

首先，PGP把接收到的密文分成兩部分：第一部分是經(jīng)RSA算法加密的會話密鑰，另一部分是經(jīng)IDEA算法和會話密鑰加密的原文件內(nèi)容。接著，PGP接收來自用戶的口令。口令經(jīng)過SHA-1報文分解函數(shù)產(chǎn)生一個128位的IDEA解密密鑰。PGP的密鑰管理模塊取出密鑰環(huán)文件中經(jīng)加密的RSA解密密鑰，用IDEA解密鑰匙和IDEA解密算法恢復出明文的RSA秘密密鑰。最后，PGP用RSA秘密密鑰和RSA解密模塊恢復出明文的會話密鑰，再用會話密鑰和IDEA解密算法一起解密加密的原文件內(nèi)容。此外，PGP需要恢復被壓縮的文件。圖6.3解密過程3．壓縮

壓縮可以節(jié)省通信時間和存儲空間，而且在加密前進行壓縮可以降低明文的冗余度，增強機密效果。PGP中采用ZIP算法進行壓縮。4．Base64編碼變換Base64編碼變換是為了提高電子郵件的兼容性而設置的。因為許多電子郵件系統(tǒng)只允許使用ASCII文本串，所以PGP提供了將8位組串轉(zhuǎn)換為ASCII字符的功能。轉(zhuǎn)換方法是將每3個8位組串的二元數(shù)據(jù)映射為4個ACSII字符。雖然轉(zhuǎn)換后消息長度有所擴展，但壓縮的效果足以彌補擴展帶來的影響。實例表明，總體壓縮和擴展抵消后大約仍有1/3的壓縮。

同時它還具有以下特點：不限于某一特定的字符集編碼；字符集有65個可以打印的字符，每個字符表示6位輸入，一個字符作為填充；字符集中不含控制字符，故可通行于E-mail系統(tǒng)；不要使用“_”符號，此符號在RFC832中有特定意義，應避免使用。5．分段和重組E-mail對消息長度都有限制。當消息大于長度限度時，PGP將對其自動分段。分段是在所有處理之后進行的，故會話密鑰和簽字只在第一段開始部分出現(xiàn)。在接收端，PGP將各段自動重組為原來的消息。

PGP的開發(fā)是密碼學應用的一個重要的里程碑，它是第一個將公鑰密碼服務于大眾的工具。PGP主要針對電子郵件加密，從計算角度來看，PGP是足夠安全的，但是不恰當?shù)男湃渭僭O往往是PGP的隱患，最終導致秘密的泄露。理解PGP的信任模型，正當使用軟件，是獲得PGP安全性的重要前提。6.1.2PGP信任模型

信任模型是指建立在信任關(guān)系和驗證證書時尋找和遍歷信任路徑的模型。信任模型分為三種：1、直接信任（DirectTrust）：

指兩個實體之間曾經(jīng)有過直接的交易，它們之間建立了一種直接信任關(guān)系，信任值來源于根據(jù)雙方的交易情況得出的直接經(jīng)驗。2、等級信任（HierarchicalTrust）：

又稱推薦信任，指兩個實體之間沒有進行直接的交易，而是根據(jù)其他實體的推薦建立的一種信任關(guān)系，它們之間的信任值是根據(jù)其他實體的評估得出的結(jié)果。在PGP中，等級信任分為4個等級：絕對信任（用戶本人）、完全信任、一般信任以及不信任。3、網(wǎng)絡信任（AWebofTrust）：

網(wǎng)絡信任模型是PGP所用到的信任模型，它包含了其他兩種模型，另外增加了第三方監(jiān)督者的概念。

在PGP中，存在兩種密鑰環(huán)：私鑰環(huán)和公鑰環(huán)。其中，公鑰環(huán)為PGP信任模型提供了實現(xiàn)方式，形成了信任網(wǎng)（WebofTrust）結(jié)構(gòu)。在信任網(wǎng)中，沒有大家都信任的中心權(quán)威機構(gòu)，而是用戶以各自為中心，相互認證公鑰，相互簽名公鑰證書。這些簽名使得用戶的公鑰彼此相連，形成自然的網(wǎng)狀結(jié)構(gòu)，就是信任網(wǎng)[4]。為了更好地理解信任網(wǎng)，我們假設Alice和Bob是兩個同事，他們彼此熟悉，通過某種方式，Alice獲得了Bob的公鑰，并且確認Bob的公鑰是真實的，因此，Alice就在Bob的公鑰證書上簽名。此時，Alice認為Bob的公鑰是有效的，并可以利用Bob的公鑰將加密后的信息傳給Bob，加密后的信息只有Bob能夠解讀。這種信任關(guān)系用實線箭頭表示，如圖6.4所示。相互信任的用戶之間分別為對方的公鑰簽名，使他們之間建立了某種聯(lián)系，這種聯(lián)系就是信任網(wǎng)的基礎結(jié)構(gòu)。圖6.4信任網(wǎng)的基礎結(jié)構(gòu)

假設David和Bob并不認識，David想與Bob進行安全通信，必須要解決的問題是：David如何獲得Bob的有效公鑰？在PGP中是這樣解決的：假設David知道Alice，并有Alice的有效公鑰。David相信Alice不會欺騙她，就將Alice設為可信介紹人，并從Alice那里得到Bob的公鑰（或者由Bob傳給David）。因為Bob的公鑰證書中有Alice的簽名，所以David可以相信Bob的公鑰是有效的。圖6.4中用虛線箭頭來表示David對Alice的信任。

如果David在Bob傳給他的公鑰中找不到一個可信的介紹人，則不能相信Bob的公鑰，Bob的公鑰將被認為是無效的。因此，為了使他們之間能夠相互信任，Bob必須找到David的一個可信介紹人為其證書簽名。其中，PGP證書由以下三部分組成：①用戶ID：由用戶名及其郵箱地址組成。②公鑰：由公鑰ID（全局唯一）、公鑰數(shù)據(jù)和創(chuàng)建時間組成。③若干簽名：由一些對前兩項關(guān)系認同的中間人的簽名組成。PGP為公鑰附加信任和開發(fā)信任信息提供了一種方便的方法來使用信任。公鑰環(huán)的每個實體都是一個公鑰證書。與每個實體相聯(lián)系的是密鑰合法性字段，用來指示PGP信任“這是這個用戶合法的公鑰”的程度。信任程度越高，這個用戶ID與這個密鑰的綁定越緊密。這個字段由PGP計算。與每個實體相聯(lián)系的還有用戶收集的多個簽名。反過來，每個簽名都帶有簽名信任字段，用來指示該PGP用戶信任簽名者對這個公鑰證書的程度。PGP公鑰環(huán)結(jié)構(gòu)如圖6.5所示。圖6.5PGP公鑰環(huán)結(jié)構(gòu)圖6.5說明如下：TimeStamp：公鑰生成的時間。KeyID：用戶公鑰標識，它由公鑰的最低64位組成（KUimod264），這個長度足以使密鑰ID的重復概率非常小。PublicKey：公鑰值。UserID：用戶標識。二元組（KeyID、UserID）唯一確定一個公鑰項。Signature：用戶收集的對該PGP公鑰進行的一個或多個簽名。OwnerTrust、SignatureTrust、KeyLegitimacy：與用戶公鑰相關(guān)的三個信任指示字段。每個信任指示字段用一個TrustFlag字節(jié)表示，分別為OWNER-TRUSTField、SIGTRUSTField、KEYLEGITField，并加上1位警示位。這三個指示字段共同決定一種PGP信任關(guān)系。OwnerTrust字段表明PGP用戶對“公鑰主人對其他公鑰簽名”的信任程度。信任程度越高，該公鑰主人簽名的密鑰越可信。這個信任程度是由用戶給出的。SignatureTrust字段表明PGP用戶信任簽名者對這個公開密鑰證明的程度。信任程度越高，該公鑰越可信。

而KeyLegitimacy字段用來指示PGP信任“這是這個用戶合法的公鑰”的程度。信任程度越高，這個用戶ID（UserID）與這個密鑰的綁定越緊密。這個字段值由PGP計算出來。假定正在處理用戶YOU的公鑰環(huán)，上述三個指示字段的值按如下方式確定：

（1）OwnerTrust字段：當YOU向公鑰環(huán)中插入一個新公鑰時，如果公鑰主人是YOU，則OwnerTrust字段對應的OWNER-TRUSTField的值為終極信任（UltimateTrust）。否則，PGP詢問用戶，讓用戶給出信任級別：未知（Unknown）、不可信任（Untrusted）、通常可信（UsuallyTrusted）和總是可信（AlwaysTrusted）等。

（2）SignatureTrust字段：當新公鑰有一個或多個簽名時，以后的多個簽名需要逐個加入。當插入一個簽名時，PGP將查找公鑰環(huán)，看該簽名人是否是已知公鑰的主人。如果是，則該簽名對應的SIGTRUSTField的值為該已知公鑰主人對應的OWNER-TRUSTField的值。否則，為UnknownUser，表示PGP不認識簽名人。因此可以把SignatureTrust字段看成是來自于其他OwnerTrust字段的副本。

（3）KeyLegitimacy字段：KEYLEGITField的值基于該條目中SignatureTrust字段來計算。如果至少一個Signature對應的SIGTRUSTField的值為UltimateTrust，則KEYLEGITField的值設為CompleteTrust。否則，PGP計算SIGTRUSTField的值的加權(quán)和。

假設對于AlwaysTrusted值的簽名賦以權(quán)值1/x，對于UsuallyTrusted值的簽名賦以權(quán)值1/y，當密鑰用戶ID綁定的權(quán)重總和達到1時，綁定被認為是值得信任的，則KEYLEGITField的值被設置為CompleteTrust。因此，在沒有UltimateTrust的情況下，需要至少有x個SignatureTrust字段為AlwaysTrusted，或者至少有y個SignatureTrust字段為UsuallyTrusted，或者是上述兩種情況的某種組合。PGP信任模型圖如圖6.6所示。圖6.6PGP信任模型圖

保證公鑰的真實有效，是正確應用PGP的基礎。證書為保證公鑰的真實性提供了一種有效的機制，而在PGP中缺乏有效的證書管理體系，證書的管理完全由用戶自己完成。錯誤的信任假設和管理的不當，會影響到PGP的安全性。PGP推薦用兩種方式來保證證書的有效性：一是直接從所有者那里獲得磁盤拷貝，二是通過中間人獲取。磁盤拷貝的方式不適用于地理范圍較大的場合，對中間人沒有任何信任等級認定，很容易造成安全隱患。在公鑰系統(tǒng)中，證書吊銷是使公鑰無效的有效方式。

在PGP中提供了兩種吊銷證書的方式：中間人吊銷和擁有者自行吊銷，二者具有同等的效力，均被認為使相關(guān)的密鑰對無效。但證書吊銷問題的真正難點不在于吊銷本身，而在于將吊銷信息通知每個潛在的使用者。用戶使用被吊銷的證書是一件很危險的事情，很有可能造成泄密，

因此在每次使用證書前都應該確信該證書沒有被吊銷。

PGP中雖然提供了吊銷證書的功能，但沒有提供任何將吊銷信息通知其他用戶的方式，這是PGP的一個致命弱點。

通過PGP的介紹，可以看出PGP在信息加密之前都會進行數(shù)據(jù)壓縮，這樣可以大大減少數(shù)據(jù)的冗余度和加/解密所花費的時間。PGP不是去推廣一個全局的PKI，而是讓用戶自己建立自己的信任網(wǎng)，即在PGP系統(tǒng)中，信任是雙方直接的關(guān)系，或者是通過第三方、第四方的間接關(guān)系，但任意兩方之間是對等的，整個信任關(guān)系構(gòu)成網(wǎng)狀結(jié)構(gòu)。這樣的結(jié)構(gòu)既有利于系統(tǒng)的擴展，又有利于其他系統(tǒng)安全模式的兼容并存。

但這種信任模型中，沒有建立完備的信任體系，不存在完全意義上的信任權(quán)威，缺乏有效的信任表達方式，所以它只適合小規(guī)模的用戶群體。當用戶數(shù)量逐漸增多時，管理將變得非常困難，用戶也會發(fā)現(xiàn)其不易使用的一面。6.1.3PGP安全分析PGP也有其固有的缺點，從保密強度來看，PGP的安全薄弱環(huán)節(jié)是對加密算法IDEA的加密密鑰的保護，對其采用郵件接收方的公鑰加密、私鑰解密的方法。所以，整個郵件內(nèi)容的保密完全依賴于郵件接收方私鑰的安全，而非發(fā)送方所能控制。一旦其他人得到此加密密鑰，就可以得到郵件明文。另外，已經(jīng)有人發(fā)現(xiàn)一種欺詐手段，即截獲郵件后，對郵件重新包裝并發(fā)給收件人，收件人得到的是一堆亂碼，當收件人攜帶原件回信詢問時，就可以破譯加密的電子郵件。應對的方法是避免在回信詢問時包含完整的原郵件。6.2S/MIME

目前，主流的電子郵件加密技術(shù)除了PGP外，還有S/MIME，兩者都沿用IETF的標準，但彼此不兼容。下面詳細介紹S/MIME。6.2.1MIME簡介

早期的Internet電子郵件有兩個核心協(xié)議：由RFC821定義的簡單郵件傳輸協(xié)議（SMTP）和由RFC822定義的郵件格式文件。SMTP是一種TCP協(xié)議支持的提供可靠且有效電子郵件傳輸?shù)膽脤訁f(xié)議。SMTP是建立在TCP協(xié)議上的一種郵件服務，主要用于傳輸系統(tǒng)之間的郵件信息并提供來信有關(guān)的通知，并且獨立于特定的傳輸子系統(tǒng)，只需要可靠有序的數(shù)據(jù)流信道支持。SMTP的重要特性之一是，其能跨越網(wǎng)絡傳輸郵件，即“SMTP郵件中繼”。SMTP規(guī)定了在Internet節(jié)點間的傳送或接力傳送電子郵件的協(xié)議，TCP端口25就是為此保留的。SMTP簡單而且高效，從1982年RFC821發(fā)布至今，不曾有任何改動。RFC822定義了一種十分簡單的郵件格式，這種格式的郵件只能包含純文本信息，而且只能是ASCII字符，這顯然影響了電子郵件的用途。

RFC822明確地把郵件分為兩部分：第一部分為郵件頭，其作用是標識郵件；第二部分是郵件體。郵件頭中包含若干數(shù)據(jù)字段，可以在需要附加信息時使用。郵件頭字段應出現(xiàn)在郵件體之前，兩部分之間使用一個空行分隔。

郵件頭最常用的字段是：From、To、Subject和Date。From標識發(fā)信人的電子郵箱地址，To標識收信人的電子郵箱地址，Subject標識郵件的主題，Date用來給郵件加上時間戳。如圖6.7所示為一封RFC822兼容郵件的格式。圖6.7RFC822兼容郵件的格式

由于SMTP和RFC822模式都只能傳輸ASCII文本信息，因此在運用時存在一定的局限性，MIME（MultipurposeInternetMailExtensions，多用途互聯(lián)網(wǎng)郵件擴展）就是針對這一點對RFC822進行擴充，并且約定二進制數(shù)據(jù)進行編碼的協(xié)議。

表6.1可以看出關(guān)于RFC822郵件和MIME郵件的對比。

RFC822郵件MIME郵件可以攜帶的內(nèi)容純文本信息HTML、圖像、聲音、文件可采用的字符US-ASCII多種字符集其他應用場合無可應用于HTTP協(xié)議表6.1RFC822郵件和MIME郵件的對比MIME協(xié)議定義了5個新的可以包含在RFC822報文首部的字段，分別是：MIME-Version、Content-Type、Content-Transfer-Encoding、Content-ID和Content-Description。MIME-Version（MIME版本）：其值必須為1.0，表明該消息符合RFC2045和RFC2046。Content-Type（內(nèi)容類型）：描述正文中包含的數(shù)據(jù)類型，使得接收方代理可以選擇合適的代理或機制來表示數(shù)據(jù)或正確處理數(shù)據(jù)。Content-Transfer-Encoding（內(nèi)容轉(zhuǎn)換編碼）：描述將消息正文轉(zhuǎn)換為可以傳輸?shù)念愋娃D(zhuǎn)換方式。Content-ID（內(nèi)容ID）：在多重上下文中唯一地標識MIME實體。Content-Description（內(nèi)容描述）：正文對象的文本描述，在該對象不可讀時使用（如音頻數(shù)據(jù)）。圖6.8顯示了新的字段同標準郵件中RFC822字段是如何結(jié)合在一起的。

圖6.8新的字段同標準郵件中RFC822字段結(jié)合在一起

同時，MIME中有大量關(guān)于內(nèi)容類型定義的說明，體現(xiàn)了在多媒體環(huán)境下需要提供多種信息表示方法的需求，表6.2列出了RFC2046中說明的內(nèi)容類型，主要有7種不同類型和15種子類型。一般來說，用內(nèi)容類型來描述數(shù)據(jù)的通用類型，用子類型描述該數(shù)據(jù)類型的特殊格式。類

型子

類

型描

述TextPlain無格式文本，為ASCII碼或ISO8859碼Enriched提供豐富的文檔信息MultipartMixed各部分相互獨立但一起傳送。接收方看到的形式與郵件消息中的形式相同Parallel除了在傳送時各部分無序外，其余與Mixed相同Alternative不同部分是同一消息的不同表現(xiàn)形式，按增序排列，接收方系統(tǒng)將按照最佳方式顯示Digest與Mixed相似，但每部分默認的類型/子類型為Message/rfc822Messagerfc822封裝消息的正文與RFC822一致Partial允許按接收方透明的方式對大郵件分段Extended-body包含指向存在于某個其他地方對象的指針I(yè)magejpegJFIF編碼的JPEG圖像gif圖像為GIF格式VideompegMPEG格式的視頻AudioBasic單通道8bitISDN編碼的音頻，采樣率為8kHzApplicationPostScriptAdobePostScriptOctet-stream一般8bit組成的二進制數(shù)據(jù)表6.2RFC2046中說明的內(nèi)容類型

對于報文主體的Text（正文）類型，除了需要對指定字符集的支持外，不需要專門的軟件來獲得正文的含義。主要的子類型是Plain（純文本），就是簡單的由ASCII字符或ISO8859字符組成的字符串。Enriched子類型允許更大的格式靈活性。

Multipart類型指示報文主體包含多個獨立的部分。content-type首部字段包含稱為boundary（邊界）的參數(shù)，定義了在報文的不同部分之間的分隔符，這個邊界不應該出現(xiàn)在報文的任何一個部分內(nèi)。每個邊界開始于一個新行，由兩個字符后跟著一個分隔符組成，用于指示最后一個部分結(jié)束的最后一個邊界還有兩個連字符作為后綴。在報文主體的每個部分，可以存在可選的普通的MIME首部。

Message類型提供了MIME的一個重要功能。Message/rfc822子類型指示報文主體是完整的報文，包括首部和主體。盡管使用了這種子類型名，但包裝的報文可以不僅僅是簡單的RFC822報文，而是任何MIME報文。

Application類型指的是其他類型的數(shù)據(jù)，典型的是郵件應用程序不理解的二進制數(shù)據(jù)或信息。S/MIME（SecureMultipurposeInternetMailExtension，安全的多用途互聯(lián)網(wǎng)郵件擴展）是基于RSA數(shù)據(jù)安全技術(shù)的MIMEInternet電子郵件格式的安全擴展，是一種用于發(fā)送和接收安全MIME數(shù)據(jù)的協(xié)議。

在MIME協(xié)議的基礎上，S/MIME增加了以下兩類安全特性：

①通過數(shù)字簽名，可以驗證數(shù)據(jù)來源的真實性、檢查數(shù)據(jù)的完整性，并且簽名具有不可抵賴的特點。

②通過加密，可以保證數(shù)據(jù)的保密性。S/MIME也支持以上兩種安全特性的復合。6.2.2S/MIME基本概念S/MIME是通過在RFC1847中定義的多部件媒體類型在MIME中打包安全服務的一種技術(shù)，可以提供驗證、信息完整性、數(shù)字簽名和加密服務。S/MIME是在PEM（PrivacyEnhancedMail，保密增強郵件）的基礎上建立起來的，它選擇RSA實驗室開發(fā)的PKCS（Public-keyCryptographyStandard，公共密鑰加密標準）作為它的數(shù)據(jù)加密和簽名的基礎，它使用PKCS#7數(shù)據(jù)格式作為數(shù)據(jù)報文，并使用X.509v3的數(shù)字證書。MIME允許對其content-type進行擴充，而S/MIME在其基礎上增加了三種新的MIME子類型[5]：multipart/signed、application/x-pkcs7-signature、application/x-pkcs7-mime。前兩種類型的組合支持簽名郵件，后一種類型支持加密郵件。如果將簽名郵件再進行一次加密，封裝成后一種類型，就生成了簽名加密郵件，理論上這種封裝是沒有限制的。因此，僅依靠這種對MIME類型的簡單擴充，便可以實現(xiàn)復雜的安全應用。MIME協(xié)議的良好擴展性使得新特性的引入對原有結(jié)構(gòu)的影響很小，事實上，雖然不支持S/MIME的系統(tǒng)不能處理安全電子郵件，但是MIME協(xié)議要求它的實現(xiàn)能夠預見到可能出現(xiàn)的新的MIME類型，并且在處理時應盡量靈活。因此，當使用舊的郵件系統(tǒng)處理S/MIME郵件時，如簽名電子郵件，雖然無法驗證簽名，但是被簽名的內(nèi)容還是可以閱讀的。

圖6.9是加密和簽名的S/MIME電子郵件的格式示意圖。當MIME類型為application/x-pkcs7-mime;mime-type=enveloped-data時，表示加密郵件；當MIME類型為multipart/signed時，表示簽名郵件。

需要說明的是，上述安全電子郵件的格式并不是S/MIME給出的唯一格式，實際上S/MIME定義了一種加密郵件的格式，以及多種簽名和加密簽名郵件的格式。例如簽名郵件的另一種格式是使用參數(shù)為smime-type=signed-data的application/x-pkcs7-mime類型，不過更普遍的情況使用multipart/signed類型。兩者的區(qū)別是，在使用非S/MIME系統(tǒng)處理郵件時，前一種完全無法識別，后一種至少可以識別出被簽名的內(nèi)容，盡管系統(tǒng)不知道加在后面的簽名是什么東西。這就是S/MIME系統(tǒng)喜歡采用這兩種格式的原因。圖6.9加密和簽名的S/MIME電子郵件的格式S/MIME提供了以下的功能：

加密數(shù)據(jù)：這一功能允許用對稱密碼加密一個MIME消息中的任何內(nèi)容類型，從而支持保密性服務，然后用一個或多個接收者的公鑰加密對稱密鑰，接著將加密的數(shù)據(jù)和加密后的對稱密鑰以及任何必要的接收者標識符和算法標識符一起附加在數(shù)據(jù)結(jié)構(gòu)的后面。

簽名數(shù)據(jù)：這一功能提供完整性服務。發(fā)送者對選定的內(nèi)容計算消息摘要，然后用簽名者的私鑰加密，初始的內(nèi)容以及它的相應簽名用Base64編碼。

透明簽名的數(shù)據(jù)：和簽名數(shù)據(jù)一樣形成內(nèi)容的數(shù)字簽名。但是這種情況只有數(shù)字簽名部分使用Base64進行編碼，因此沒有S/MIME功能的接收者也可以看到報文的內(nèi)容，盡管他不能驗證簽名。

簽名且加密的數(shù)據(jù)：這一功能允許簽名已加密的數(shù)據(jù)或者加密已簽名的數(shù)據(jù)來提供保密性和完整性服務。

6.2.3S/MIME功能S/MIME中使用表6.3中列出的術(shù)語（來源于RFC2119）來說明需求級別。功

能要

求創(chuàng)建用于數(shù)字簽名的數(shù)字摘要必須支持SHA-1，接收方應該支持MD5，以便以后兼容加密數(shù)字摘要形成數(shù)字簽名發(fā)送代理和接收代理必須支持DSS發(fā)送代理應該支持RSA加密接收代理應該支持驗證密鑰大小在512～1024位之間的RSA簽名為傳送消息加密會話密鑰發(fā)送代理和接收代理必須支持Diffie-Hellman發(fā)送代理應該支持密鑰大小在512～1024位之間的加密接收代理應該支持RSA解密用一次性會話密鑰加密消息發(fā)送代理應該支持3DES和RC2/40加密接收代理必須支持用3DES解密，應該支持RC2/40解密表6.3S/MIME中的需求級別MUST：在規(guī)格說明書中表示一定要滿足的需求。實現(xiàn)時，必須包括其修飾的特性或與規(guī)格說明中的功能一致。SHOULD：如果在特定條件下有合理的理由，則可以忽略其修飾的特性或功能，但推薦其實現(xiàn)包含其特性或功能。S/MIME組合三種公鑰算法。DSS（DigitalSignatureStandard）是其推薦的數(shù)字簽名算法。Diffie-Hellman是其推薦的密鑰交換算法，實際上，在S/MIME中使用的是其能加密/解密的變體ElGamal。RSA既可以用作簽名，也可以加密回話密鑰。規(guī)格說明推薦使用160位的SHA-1算法作為數(shù)字簽名的Hash函數(shù)，但要求接收方能支持128位的MD5算法。S/MIME規(guī)格說明包括如何決定采用何種加密算法。從本質(zhì)上說，一個發(fā)送方代理需要進行如下兩個抉擇：發(fā)送方代理必須確定接收方代理是否能夠解密該加密算法。如果接收方代理只能接收弱加密的內(nèi)容，那么發(fā)送方代理必須確定弱加密方式是否可以接受。

為達到上述要求，發(fā)送方代理可以在它發(fā)送消息之前先宣布它的解密能力，由接收方代理將該消息存儲，留給將來使用。

發(fā)送方代理必須按照如下順序遵守如下規(guī)則：

如果發(fā)送方代理有一個接收方解密性能表，則它應該選擇表中的第一個（即優(yōu)先級最高的）性能。

如果發(fā)送方代理沒有接收方的解密性能表，但曾經(jīng)接收到一個或多個來自于接收方的消息，則應該使用與最近接收到的消息一樣的加密算法，對將要發(fā)送給接收方的消息進行加密。

如果發(fā)送方代理沒有接收方的任何解密性能方面的知識，并且想冒險一試（接收方可能無法解密消息），則應該選擇3DES。

如果發(fā)送方代理沒有接收方的任何解密性能方面的知識，并且不想冒險，則發(fā)送方代理必須使用RC2/40。

如果消息需要發(fā)給多個接收方，并且它們沒有一個可以接受的、共同的加密算法，則發(fā)送方代理需要發(fā)送兩條消息。此時，該消息的安全性將由于安全性低的一份拷貝而易受到攻擊。S/MIME使用符合X.509版本3標準的公開密鑰證書。S/MIME使用的密鑰管理方法是嚴格的X.509證明層次和PGP的信任網(wǎng)絡的混合。S/MIME的管理者必須為用戶配置可信任的密鑰表和廢除證書的列表。證書是由認證機構(gòu)簽名的。

6.2.4S/MIME證書的處理

S/MIME用戶可以完成如下密鑰管理功能：

①密鑰的生成：與管理有關(guān)的使用程序的用戶必須能夠生成單獨的Diffie-Hellman和DSS密鑰對，并且應該能夠生成RSA密鑰對。每個密鑰對必須從一個好的不確定的隨機輸入源生成并且采用安全的方式進行保護。用戶代理應該生成768～1024位之間的密鑰對，并且一定不能生成小于512位的密鑰對。

②注冊：用戶的公開密鑰和認證一起注冊獲得X.509公開密鑰證書。

③證書的存儲和查詢：用戶需要訪問證書的本地列表來驗證進入的簽名和輸出的報文加密，這張表可以讓用戶進行維護。X.509是一個重要的標準，基于公開密鑰加密和數(shù)字簽名，這個標準沒有專門指定使用的加密算法，但推薦使用RSA。其核心部分是與每個用戶聯(lián)系的公開密鑰證書，實際上X.509證書是一種有發(fā)布者數(shù)字簽名的用于綁定某種公開密鑰和其持有者身份的數(shù)據(jù)結(jié)構(gòu)。證書、數(shù)字證書、電子證書等都是X.509證書的同義詞，有時也稱為公鑰證書，是一種權(quán)威性的電子文檔，由具有權(quán)威性、可信任性及公正性的第三方機構(gòu)（CA）頒發(fā)。

目前，可以使用三種可選的增強的安全服務來擴展當前的S/MIMEv3安全以及證書處理服務。

1．簽名收據(jù)

簽名收據(jù)是一種可選的服務，它考慮的是消息發(fā)送的證明。收據(jù)為發(fā)送者提供了一種向第三方出示證明的手段：接收者不僅收到了消息，而且驗證了初始消息的數(shù)字簽名。最后，接收者對整個消息以及相應的簽名進行簽名作為接收的證明。該服務僅僅用于簽名的數(shù)據(jù)。6.2.5S/MIME增強的安全服務

2．安全標簽

安全標簽可以通過兩種方式來使用。第一種方式，也可能是最容易識別的方式，就是描述數(shù)據(jù)的敏感級。這可以使用一個分級的標簽列表（機密、秘密，限制等）。第二種方式是使用標簽來控制授權(quán)和訪問，描述哪類接收者可以訪問數(shù)據(jù)。

3．安全郵件列表

當S/MIME協(xié)議提供它的服務時，發(fā)送代理必須為每個接收者創(chuàng)建特定于接收者的數(shù)據(jù)結(jié)構(gòu)。隨著某個特定消息的接收者的數(shù)目的增加，這一處理可能會削弱發(fā)送消息的性能。這樣，郵件列表代理可以接收一個單獨的消息并針對每個接收者完成特定于接收者的加密。

通過這兩節(jié)的學習，可以大致了解PGP和S/MIME這兩種保護電子郵件的協(xié)議，它們也是目前電子郵件加密的兩大主流技術(shù)，都沿用IETF的標準，但兩者不兼容。PGP采用分布式的認證模式，使用比較方便，適合于公眾領域和內(nèi)部網(wǎng)絡用戶之間的安全信息交流；而S/MIME則采用基于CA的集中式認證模式，更適合于電子商務、政府機關(guān)、公司企業(yè)之間等對身份認證要求比較高的領域。PGP保留了用戶的個人電子郵件安全服務的選擇。國際電子郵件標準管理組織（IMC）希望形成安全郵件的統(tǒng)一標準，但IMC的成員意見并不一致，因此IMC只好同時發(fā)展這兩種標準，直到大家有了統(tǒng)一的迫切要求時，再考慮統(tǒng)一標準。6.2.6PGP和S/MIME的比較

但從實際應用情況來看，S/MIME幾乎是電子郵件廠商的首選協(xié)議，許多產(chǎn)品支持S/MIME，它能讓用戶很容易地發(fā)送和接收安全電子郵件。支持S/MIME的產(chǎn)品包括Microsoft的OutlookExpress、NetscapeCommunicator中的Messager郵件程序，Lotus開發(fā)的LotusDomino同樣支持S/MIME，它還能存儲數(shù)字證書，Notes客戶端可以發(fā)送和接收加密或簽過名的郵件等。因此S/MIME協(xié)議可能作為商業(yè)和組織使用的工業(yè)標準而出現(xiàn)。

相對來說，支持PGP的電子郵件廠商少一些。但PGP被廣大的個人用戶所支持和信賴，尤其是它的網(wǎng)狀信任模型，具有很大的靈活性和適應性，大大簡化了部署操作，因此對許多用戶來說仍然具有很大的吸引力。6.3SecureShell

為了克服傳統(tǒng)的Telnet、FTP、Rlogin等遠程服務存在的各種嚴重安全缺陷，SSH（SecureShell，安全外殼）協(xié)議1995年由TatuYlonen正式提出。2006年，RFC4250～RFC4254一系列文檔的推出標志著SSH成為標準化的網(wǎng)絡安全協(xié)議。SSH是一種應用層的安全通信協(xié)議。它通過建立一個加密的、安全的底層通道完成對雙方交互數(shù)據(jù)的保護，通過其認證協(xié)議提供的若干種認證方式，增加防止非授權(quán)用戶登錄的能力，并通過連接協(xié)議為各種應用層協(xié)議提供安全性保護，使得SSH加密的口令及數(shù)據(jù)可以在不安全的網(wǎng)絡中透明地提供強認證和安全通信。相對于Telnet而言，SSH提供的安全性服務主要包括以下幾個方面：

①密文傳輸：在SSH連接建立初期，雙方會通過協(xié)商的方式得出雙方通信的加密算法和會話密鑰，此后雙方的通信就以密文的方式進行，這樣非法用戶很難竊取到合法用戶的賬戶信息。

②支持基于公鑰的認證：極大地提高了認證的安全性。

③支持對服務器的認證：SSH協(xié)議可以通過驗證服務器端公鑰的方式來對服務器的身份進行認證，從而避免“偽服務器”這種方式的攻擊。

④支持對交互數(shù)據(jù)的校驗：SSH協(xié)議支持對數(shù)據(jù)的完整性和真實性的校驗，使用的校驗方法是CRC（SSH1.5）和基于MD5的MAC算法（SSH2.0）。使用數(shù)據(jù)校驗可以有效地防止類似于“中間人”的攻擊。

如圖6.10所示為SSH協(xié)議的結(jié)構(gòu)示意圖，從圖中可以看出SSH的協(xié)議層可以分成三層，即傳輸層、認證層和連接層。三層一起在底層TCP（或者其他類型）連接的基礎上為上層應用提供一條安全的通信鏈路。

6.3.1SSH協(xié)議結(jié)構(gòu)

圖6.10SSH協(xié)議結(jié)構(gòu)1．傳輸層協(xié)議（SSH-TRANS）

傳輸層協(xié)議是一種安全的底層的傳輸協(xié)議，它為SSH連接提供強大的基于密鑰的服務器認證以及數(shù)據(jù)完整性、真實性檢查。雙方通信所需要的密鑰交換方式、公鑰密碼算法、對稱密鑰密碼算法、消息認證算法和哈希算法等都可以進行協(xié)商。傳輸層協(xié)議的主要目標是實現(xiàn)兩臺主機間認證時和認證后安全與保密的通信，通常運行于TCP/IP之上。

傳輸層協(xié)議中的認證是基于主機的，并不涉及客戶端用戶的身份認證，傳輸層產(chǎn)生口令認證和其他服務需要的（共享）秘密數(shù)據(jù)。用戶認證可以通過基于該協(xié)議之上、單獨設計的協(xié)議來完成，這樣，既保證了通信的安全性，又提供了協(xié)議的靈活性和擴展性。SSH連接的可靠性由底層來保證，所以首先必須保證一個可靠的底層連接。TCP/IP連接就是一種可靠的連接，如果采用這種連接，服務器一般在22端口偵聽SSH連接。這個端口是IANA（theInternetAssignedNumbersAuthority，互聯(lián)網(wǎng)數(shù)字分配機構(gòu)）為SSH正式分配的端口號。2．用戶認證協(xié)議（SSH-USERAUTH）

在傳輸層構(gòu)建了一個安全隧道以在兩個系統(tǒng)間傳送信息后，服務器將告訴客戶機它所支持的認證算法，客戶機將用服務器支持的算法向服務器證明自己的身份。認證由服務器主導，客戶端可以根據(jù)服務器提供的方法列表自由地進行選擇，這樣一方面使服務器對認證有完全的控制權(quán)，另一方面也給客戶端足夠的靈活度。

3．連接層協(xié)議（SSH-CONNECT）

連接層協(xié)議主要的功能是完成用戶請求的各種具體的網(wǎng)絡服務，而這些服務的安全性是由底層的傳輸層協(xié)議和用戶認證協(xié)議實現(xiàn)的。在SSH傳輸層成功認證后，多個信道通過復用到兩個系統(tǒng)間的單個連接而打開，每個信道處理不同的終端會話。

客戶基于服務器可以建立新的信道，每個信道在每端被編排以不同的號碼。在一方試圖打開一個新的信道時，該信道在該端的號碼隨請求一起傳送，并被對方存儲，用于指示特定類型業(yè)務的通信給該信道。這樣做，可以使不同類型的會話不會彼此影響，而在關(guān)閉信道時也不會影響系統(tǒng)間建立的初始SSH連接。

利用連接層協(xié)議提供的信道，可以方便地擴展更廣范圍的應用。標準方法提供了安全的交互式Shell會話、任意TCP/IP（Tunneling）端口和X11連接轉(zhuǎn)發(fā)等。1．服務器主機密鑰

每臺服務器主機都應該有一個主機密鑰，也可以同時擁有多個采用不同密鑰算法的密鑰，多臺主機也可以共享（同時使用）一個密鑰。但SSH協(xié)議要求：如果一臺主機擁有密鑰（一個或者多個），則其中至少要有一個密鑰采用DSS公鑰算法。

服務器主機密鑰用在客戶端與服務器端進行密鑰交換期間，用以驗證用戶所連接的服務器，為此，協(xié)議要求客戶端事先要知道服務器主機密鑰對中的公鑰。6.3.2SSH協(xié)議相關(guān)概念2．可擴展性

為了滿足擴展性的要求，協(xié)議規(guī)范了所采用的密碼算法、密鑰協(xié)商方式和認證方式等的命名規(guī)則，并統(tǒng)一協(xié)議中消息的格式。協(xié)議也允許在各個方向上充分協(xié)商加密、完整性、密鑰交換、壓縮及公鑰算法和格式等。新的算法、擴展協(xié)議等可以自由地添加，只要它們符合協(xié)議規(guī)定的命名規(guī)則以及消息格式。

3．安全性考慮

（1）SSH協(xié)議的主要目的是提高網(wǎng)絡應用的安全性，以容易部署和使用為原則來實現(xiàn)這個目標，而以犧牲一些絕對安全作為代價。

（2）所有的數(shù)據(jù)加密、身份認證、完整性校驗及公鑰算法都采用相對成熟的、經(jīng)過時間檢驗的且被人們廣泛使用的一些算法。

（3）所有的算法都選用目前普遍認為安全的密鑰長度，在相當長的一段時期內(nèi)能夠抵御很高強度的密碼分析。

（4）所有的算法都是可以協(xié)商的，這樣即使某種算法被攻破，也可以很容易地切換到另外一種算法而不用更改整個基礎協(xié)議。4．包長度和包頭開銷

因為引入了新的協(xié)議包頭、填充項以及完整性校驗碼，所以整個數(shù)據(jù)包的長度被加長了。最小的包長度為28位（與協(xié)商采用的算法有關(guān)），這種增加量對于大尺寸的數(shù)據(jù)包來說幾乎可以忽略，但是對于像Telnet那樣的單字節(jié)交互會話來說，這種開銷就顯得很不合適。

在連接層建立起來的邏輯信道中，每個信道上允許的最大數(shù)據(jù)包長度也是可以協(xié)商的。在傳輸層中傳輸?shù)乃袛?shù)據(jù)包的格式如下：Unit32 lengthByte typeUnit32 request-idByte[length?5] datapayload說明如下：length：包的總長度，包括包的長度域。即使包中沒有數(shù)據(jù)，報長度字段也為5（length字段本身和類型域）。

在實際應用中，最大數(shù)據(jù)包長度是由客戶端決定的。所有的服務器必須至少支持客戶端最大32768字節(jié)的數(shù)據(jù)讀/寫請求（由于還有包頭部分，因此需要支持的最大數(shù)據(jù)包長度應該是34000字節(jié)）。

type：包中的數(shù)據(jù)類型編碼。

request-id：每個從客戶端來的請求都有一個request-id域，服務器回應的報文中也有一個相應的request-id（有兩種類型的報文不需要使用request-id，即初始化的報文和攜帶版本信息的報文）。

數(shù)據(jù)段中數(shù)據(jù)內(nèi)容的格式解析都是基于數(shù)據(jù)包類型的，也就意味著各種數(shù)據(jù)包類型的解析都是相互獨立的。5．消息編號SSH的消息編號1～255，分配如：（1）傳輸層協(xié)議1～19：傳輸層常用消息（如斷開、忽略、調(diào)試等）。20～29：算法協(xié)商消息。30～49：與密鑰交換方法相關(guān)的消息（不同的認證方式可能會重用）。（2）用戶認證協(xié)議50～59：用戶認證常用消息。60～79：與用戶認證方法相關(guān)的消息（不同的認證方法可能會重用）。（3）連接層協(xié)議80～89：連接層常用消息。90～127：信道相關(guān)消息。128～191：為客戶協(xié)議保留。192～255：本地擴展用。SSH協(xié)議的通信流程如圖6.11所示，其中，版本協(xié)商和算法協(xié)商體現(xiàn)了SSH協(xié)議的靈活性和可擴展性，密鑰建立與服務器認證和用戶認證體現(xiàn)了SSH的可靠性和安全性。由于SSH是建立在TCP協(xié)議基礎上的，因此首先要建立TCP連接。1．版本協(xié)商

在目前實現(xiàn)的SSH中，比較普遍的版本是SSH2.0，當然也有一些網(wǎng)絡設備使用的是老的版本號。但是這兩類版本SSH1和SSH2并不兼容，通過表6.4可以看出兩類版本的區(qū)別。6.3.3SSH協(xié)議的通信流程圖6.11SSH協(xié)議的通信流程

SSH1SSH2認證方式（分先后順序）/etc/hosts.equiv及.rhosts認證.rhosts認證結(jié)合RSA主機認證RSA主機認證基于口令的認證基于公鑰的用戶認證傳統(tǒng)口令認證加密方法（1）3DES、BLOWFISH（2）客戶從服務器所提供的算法中選擇（1）3DES、BLOWFISH、CBC和ArcfourCAST128（2）客戶從服務器所提供的算法中選擇會話密鑰產(chǎn)生方式（1）客戶連接服務器，服務器返回公用主機密鑰和服務器密鑰（2）客戶方檢查該主機密鑰是否存在于本地數(shù)據(jù)文件中，若存在，則檢查是否改變過（3）客戶產(chǎn)生256位的隨機數(shù)，用主機密鑰和服務器密鑰加密，返回服務器（4）雙方將此隨機數(shù)作為會話密鑰加密后來的會話內(nèi)容通過Diffie-Hellman密鑰交換協(xié)議共享會話密鑰公鑰認證過程基于RSA算法的認證：（1）當用戶登錄后，SSH告訴服務器希望使用的公鑰服務器來檢查該密鑰是否存在于本地數(shù)據(jù)的文件中，若有，則向客戶端發(fā)送一個該公鑰加密過的質(zhì)詢隨機數(shù)（2）客戶方用自己的私鑰解開此隨機數(shù)并響應服務器，從而證明自己的身份是基于質(zhì)詢響應模式的基于DSA或RSA算法：（1）客戶使用ID-dsa簽名Diffie-Hellman密鑰交換產(chǎn)生的會話ID，將結(jié)果發(fā)給服務器（2）服務器檢查對應的公鑰是否存在本地數(shù)據(jù)文件中，若有，則檢查簽名正確性（3）會話ID從Diffie-Hellman產(chǎn)生的一個共享數(shù)據(jù)衍生而來，只有通信雙方知道主機密鑰（1）每臺主機擁有一個特別的RSA（1024位）密鑰，用于驗證主機（2）服務器每次啟動，都產(chǎn)生一個服務器RSA密鑰（768bit），每隔1小時重新產(chǎn)生，從不保存在硬盤中每臺主機擁有一個特別的DSA密鑰，用于驗證主機完整性校驗缺少足夠強度完整性校驗HMAC-SHA1HMAC-MD5表6.4SSH1和SSH2的區(qū)別

版本協(xié)商包括兩種情況：舊的客戶端和新的服務器端之間，以及新的客戶端和舊的服務器端之間。

新的服務器端實現(xiàn)時，必須有一個可以配置的兼容選項，用來控制是否兼容舊版本的客戶端登錄。如果兼容，則這個服務器端在版本協(xié)商階段向?qū)Χ税l(fā)送的協(xié)議版本號就是1.99。如果是2.0的客戶端登錄，則1.99和2.0的服務器端對于它來說應該是一致的，而對于1.5以及以下的客戶端來說，1.99意味著這臺服務器兼容1.5的版本，版本協(xié)商可以通過。如果服務器配置成不兼容2.0的協(xié)議，那么它向?qū)Χ税l(fā)送的協(xié)議版本號就是2.0，當1.5的客戶端登錄時，發(fā)現(xiàn)對端的協(xié)議版本號是2.0，版本協(xié)商不成功，雙方斷開TCP/IP連接。

當新的客戶端登錄舊的服務器時，由于客戶端不能去兼容服務器，因此遇到舊的服務器的時候，客戶端必須斷開連接，使用舊的版本再去登錄。

在版本協(xié)商階段，雙方交互的數(shù)據(jù)都是以明文方式傳輸?shù)摹?．算法協(xié)商

版本協(xié)商成功后，雙方就開始采用二進制數(shù)據(jù)包進行通信。由服務器向客戶端發(fā)送第一個包，內(nèi)容包括：自己的RSA主機密鑰（HostKey）的公鑰部分、RSA服務密鑰（ServerKey）的公鑰部分、支持的加密方法、支持的認證方法、此協(xié)議版本標志，以及一個64位的隨機數(shù)（Cookie）。這個包是沒有加密的，以明文方式發(fā)送。

客戶端選定各種算法的原則是，依次從自己支持的算法列表中取出一種算法，在服務器端發(fā)送過來的加密算法中進行匹配。如果匹配成功，這種算法就是協(xié)商出來的算法；如果匹配不成功，客戶端再取自己支持的算法列表中的下一個算法進行匹配。如果最后也沒有匹配成功，算法協(xié)商就失敗了。

3．密鑰建立與服務器認證

算法協(xié)商成功后雙方進入密鑰交換階段。密鑰交換的目的是生成一個雙方公鑰的密鑰，用于后續(xù)數(shù)據(jù)的加密。這個密鑰是經(jīng)過雙方協(xié)商產(chǎn)生的，雙方中的任意一方都不能單獨生成這個密鑰。目前支持的密碼交換算法屬Diffie-Hellman體系。同時，客戶端將完成對服務器的認證。

如圖6.12所示為“偽服務器欺騙”，當客戶端主機需要連接服務器時，第三方攻擊者冒充真正的服務器，與客戶端進行數(shù)據(jù)交互，竊取客戶端主機的安全信息，并利用這些信息去登錄真正的服務器，獲取服務器資源，或?qū)Ψ掌鬟M行攻擊。

圖6.12偽服務器欺騙示意圖

為了防止類似這樣的偽服務器欺騙，SSH協(xié)議支持對服務器端進行認證?？蛻舳藢崿F(xiàn)中一般都有一個可選選項，控制客戶端首次登錄時是否對服務器進行認證。如果設置成首次登錄不認證，客戶端自動將服務器的公鑰保存到本次，如果設置成首次登錄認證，在服務器發(fā)送自己的主機公鑰和服務器公鑰過來時，客戶端就需要提示用戶，是否認可對端，由用戶完成對服務器的合法性的檢查，以及決定是否保存對端的公鑰。

當客戶端以后再次進行登錄時，如果本地保存了服務器的公鑰，就需要用這個保存的公鑰來完成對對端服務器的驗證。具體的驗證過程如下：

首先，客戶端比較對端（服務器端）發(fā)送過來的主機公鑰與本地保存的主機公鑰的模數(shù)，如果模數(shù)不一致，則直接認為對端服務器不合法，退出登錄過程，并提示用戶。

如果驗證兩個公鑰的模數(shù)一致，則客戶使用服務器的主機公鑰將用于生成會話密鑰的32B隨機字符串加密發(fā)往對端（服務器端）。如果對端是合法的服務器，就能解密出這個32B的隨機字符串，并成功生成會話密鑰。從客戶端發(fā)送加密的32B隨機字符串開始，雙方的通信都是以密文的方式進行的。4．用戶認證

在一定的限度內(nèi)，客戶端可以選擇多種方法向服務器提供自己的身份證明直至成功為止。可以采用的方法有：公鑰認證、口令認證、基于主機的認證、鍵盤交互式認證。下面簡單介紹前三種用戶認證方法：

（1）公鑰認證：是SSH協(xié)議唯一要求的必須提供的認證方法。在這種方法中，用戶用私鑰來表明自己的身份。簡單說，就是用戶向服務器發(fā)送一個用自己私鑰處理過的數(shù)字簽名，服務器首先檢查該用戶的私鑰是否可以作為一個有效的認證憑證（通過檢查本地數(shù)據(jù)庫中是否存有與之對應的公鑰實現(xiàn)），然后檢查該簽名的有效性。如果兩個條件都滿足，用戶的認證請求就可以被接受，否則拒絕。

（2）口令認證：所有的應用都應該支持由服務器確定怎樣編譯口令以及根據(jù)口令數(shù)據(jù)庫驗證口令。在此過程中，客戶機和服務器都應該檢驗傳輸層所提供的機密性。如果沒有提供加密，則口令認證不能完成；如果沒有機密性或MAC，則不能改變口令。

（3）基于主機的認證：根據(jù)用戶來自的主機及遠端主機上的用戶名來認證。這種方法不適用于安全性要求較高的站點，但是可以選擇。

另外，可以混合使用幾種不同認證特征的用戶認證方法。由服務器的本地策略決定使用哪一種方法（或混合方法），使每個用戶都愿意接受。采用多種認證方法時，認證強度取決于最弱的方法。5．通信會話

用戶認證結(jié)束后，SSH連接基本完成，通信雙方可以開始正常的會話。在連接過程中，通信雙方相互發(fā)送的數(shù)據(jù)包內(nèi)容如圖6.13所示。圖6.13通信雙方相互發(fā)送的數(shù)據(jù)包內(nèi)容

注：根據(jù)Diffie-Hellman建立共享密鑰原理，客戶端和服務器分別計算共享密鑰SK。客戶端計算：SK=DH(pe,f)（pe是與e對應的私密大數(shù)）。

服務器計算：SK=DH(pf,e)（pf是與f對應的私密大數(shù)），雙方計算出的共享密鑰是一致的。

會話密鑰由共享密鑰派生出來。Diffie-Hellman的有效性在于計算離散對數(shù)的難度，而對于大數(shù)，計算出離散對數(shù)幾乎不可能，所以第三方幾乎不可能知道共享密鑰。SSH