第4章-密碼技術(shù)應(yīng)用-課件

第4章密碼技術(shù)應(yīng)用4.1IPSec4.2SSL4.3S-HTTP4.4SMIME4.5SET

4.6PGP習(xí)題

第4章密碼技術(shù)應(yīng)用4.1IPSec14.1IPSec1.IPSec概述傳統(tǒng)的TCP/IP協(xié)議，IP數(shù)據(jù)包在傳輸過程中并沒有過多的安全需求，人們很容易偽造IP地址，篡改數(shù)據(jù)包內(nèi)容，重放以前的包并在傳輸途中截獲并查看包內(nèi)信息。因此不能保證自己收到的數(shù)據(jù)包來自正確的發(fā)送端，不能肯定數(shù)據(jù)是發(fā)送端的原始數(shù)據(jù)，也不能防止原始數(shù)據(jù)在傳輸過程中未被竊聽，所以本質(zhì)上說這種協(xié)議是不安全的。為了有效保護(hù)IP數(shù)據(jù)包的安全，IPSec應(yīng)運而生，它隨著Ipv6的制定而產(chǎn)生，鑒于Ipv4應(yīng)用的廣泛性，IPSec也提供對Ipv4的支持，不過在Ipv6中它是必須支持的，而在Ipv4中是可選的。

4.1IPSec1.IPSec概述2圖4-1IPSec結(jié)構(gòu)框架

圖4-1IPSec結(jié)構(gòu)框架3

2．IPSec的結(jié)構(gòu)(1)AH為IP數(shù)據(jù)包提供3種服務(wù)，即無連接的數(shù)據(jù)完整性驗證、數(shù)據(jù)源身份認(rèn)證和防重放攻擊。數(shù)據(jù)完整性驗證通過哈希函數(shù)產(chǎn)生的校驗來保證；數(shù)據(jù)源身份認(rèn)證通過在計算驗證碼時加入一個共享密鑰來實現(xiàn)；AH報頭中的序列號可以防止重放攻擊。

2．IPSec的結(jié)構(gòu)4(2)ESP除了為IP數(shù)據(jù)包提供AH已有的3種服務(wù)外，還提供另外兩種服務(wù)，即數(shù)據(jù)包加密、數(shù)據(jù)流加密。加密是ESP的基本功能，而數(shù)據(jù)源身份認(rèn)證、數(shù)據(jù)完整性驗證以及防重放攻擊都是可選的。數(shù)據(jù)包加密是指對一個IP包進(jìn)行加密，可以是對整個IP包，也可以只加密IP包的負(fù)荷部分，一般用于客戶端計算機(jī)；數(shù)據(jù)源加密一般用于支持IPSec的路由器，源端路由器并不關(guān)心IP包的內(nèi)容，對整個IP包進(jìn)行加密后傳輸，目的端路由器將該包解密后把原始包繼續(xù)轉(zhuǎn)發(fā)。在實際進(jìn)行IP通信中，可以根據(jù)實際安全需求同時使用這兩種協(xié)議或選擇其中的一種。AH和ESP都可以提供驗證服務(wù)，不過，AH提供的驗證服務(wù)要強(qiáng)于ESP。

(2)ESP除了為IP數(shù)據(jù)包提供AH已有的3種服務(wù)外5(3)IKE協(xié)議負(fù)責(zé)密鑰管理，定義了通信實體間進(jìn)行身份認(rèn)證、協(xié)商加密算法以及生成共享的會話密鑰的方法。IKE將密鑰協(xié)商的結(jié)果保留在安全聯(lián)盟(SA)中，供AH和ESP以后通信時使用。最后，解釋域(DOI)為使用IKE進(jìn)行協(xié)商SA的協(xié)議統(tǒng)一分配標(biāo)識符。共享一個DOI的協(xié)議從一個共同的命名空間中選擇安全協(xié)議和變換、共享密碼以及交互協(xié)議的標(biāo)識等，DOI將IPSec的這些RFC文檔聯(lián)系到一起。

(3)IKE協(xié)議負(fù)責(zé)密鑰管理，定義了通信實體間進(jìn)行身63．IPSec的運行模式IPSec有兩種運行模式，即傳輸模式(TransportMode)和隧道模式(TunnelMode)。這兩種模式的主要區(qū)別是它們所保護(hù)的內(nèi)容不同，傳輸模式保護(hù)的只是IP的有效負(fù)載，而隧道模式保護(hù)的是整個IP數(shù)據(jù)包。AH和ESP都支持這兩種模式，共存在四種形式，即AH傳輸模式、ESP傳輸模式、AH隧道模式、ESP隧道模式。這些傳輸模式如圖4-2所示。

3．IPSec的運行模式7圖4-2IPSec傳輸模式(a)AH傳輸模式；(b)AH隧道模式；(c)ESP傳輸模式；(d)ESP隧道模式

圖4-2IPSec傳輸模式81)AH傳輸模式在該模式中，AH被插入到IP頭部之后，在傳輸層協(xié)議(如TCP、UDP)或者其他IPSec協(xié)議之前。因為AH驗證的區(qū)域覆蓋整個IP包，包括IP包頭部，所以源/目的IP地址是不能修改的，否則會被檢測出來。如果數(shù)據(jù)包在傳送過程中經(jīng)過網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT，NetworkAddressTranslation)網(wǎng)關(guān)，其源/目的IP地址將發(fā)生改變，會造成到達(dá)目的地址后的完整性驗證識別失敗。因此，AH在傳輸模式下和NAT是沖突的，不能同時使用。或者說AH不能穿越NAT。

1)AH傳輸模式92)AH隧道模式在該模式中，AH插入到原始IP頭部字段之前，再在AH之前增加一個新的IP頭部。在隧道模式下，AH驗證的區(qū)域也將覆蓋整個IP包，所以也存在AH與NAT的沖突。

2)AH隧道模式103)ESP傳輸模式在該模式中，ESP插入到IP頭部之后，ESP頭部包含SPI和序列號字段，ESP尾部包含填充、填充長度和下一個頭字段。在接收端，SPI字段用于和源IP地址、IPSec協(xié)議一起組成一個三元組來惟一確定一個SA，并利用該SA進(jìn)行驗證、解密，然后等待后續(xù)處理，所以SPI不能被加密。其次，序列號字段用于判斷包是否重復(fù)，從而防止重發(fā)攻擊。序列號不會泄漏明文中的任何機(jī)密，所以也沒有必要進(jìn)行加密。其尾部使用了ESP驗證，因為SA需要ESP的驗證服務(wù)，接收端會在任何后續(xù)處理(如檢查重放、解密)之前進(jìn)行驗證。數(shù)據(jù)包只有經(jīng)過驗證該包沒有經(jīng)過任何修改，才會被確認(rèn)為可信任的，才會進(jìn)行候選處理。

3)ESP傳輸模式114)ESP隧道模式在該模式中，ESP插入到IP頭部之前，在ESP之前再插入新的IP頭部。與傳輸模式一樣，ESP頭部含有SPI和序列號字段，ESP尾部包含填充、填充長度和下一個頭字段。如果選用了驗證，ESP的驗證數(shù)據(jù)字段中包含了驗證數(shù)據(jù)。同樣ESP頭部和ESP驗證數(shù)據(jù)字段不會被加密。內(nèi)部的IP頭部被加密和驗證，而外部的IP頭部既沒有被加密也沒有被驗證，不被加密是因為路由器需要這些信息為其尋找路由，不被驗證是為了能適應(yīng)NAT等情形。

4)ESP隧道模式124.2SSL

1．SSL概述SSL(SecureSocketLayer)是由Netscape公司開發(fā)的，用于提供Internet通信的安全協(xié)議，目前已經(jīng)廣泛用于Web瀏覽器與服務(wù)器之間的身份認(rèn)證和加密數(shù)據(jù)傳輸。SSL協(xié)議位于網(wǎng)絡(luò)層協(xié)議(如TCP/IP)與各種應(yīng)用層協(xié)議(如HTTP等)之間，如圖4-3所示。在發(fā)送端，SSL層接收應(yīng)用層的數(shù)據(jù)，然后將加了密的數(shù)據(jù)發(fā)往TCP端口。在接收端，SSL從TCP端口讀取數(shù)據(jù)，解密后將數(shù)據(jù)交給應(yīng)用層。所以它為客戶端與服務(wù)器之間提供安全通信，允許雙方相互認(rèn)證、通過加密提供消息保密。

4.2SSL1．SSL概述13圖4-3SSL在TCP/IP協(xié)議棧中的位置

圖4-3SSL在TCP/IP協(xié)議棧中的位置14

2．SSL的結(jié)構(gòu)SSL被設(shè)計成使用TCP來提供一種可靠的端到端的安全服務(wù)。SSL由多個協(xié)議組成，并采用兩層體系結(jié)構(gòu)，如圖4-4所示。

圖4-4SSL協(xié)議體系結(jié)構(gòu)

2．SSL的結(jié)構(gòu)圖4-4SSL協(xié)議體系結(jié)構(gòu)15SSL中有兩個重要的概念(SSL連接和SSL會話)，具體定義如下：(1)SSL連接：連接是提供恰當(dāng)類型服務(wù)的傳輸。SSL是一種點對點連接，每次連接與一個會話相聯(lián)系。(2)SSL會話：SSL會話是客戶與服務(wù)器之間的關(guān)聯(lián)，會話通過握手協(xié)議來創(chuàng)建。會話定義了一組被多個連接共享的加密安全參數(shù)集。會話可以用來避免為每個連接進(jìn)行昂貴的新安全參數(shù)的協(xié)商。

SSL中有兩個重要的概念(SSL連接和SSL會話)，具體16

3．SSL協(xié)議1)SSL記錄協(xié)議SSL協(xié)議的底層是記錄協(xié)議層，SSL記錄協(xié)議在客戶機(jī)和服務(wù)器之間傳輸應(yīng)用數(shù)據(jù)和SSL控制數(shù)據(jù)，期間有可能需要進(jìn)行分段或把多個高層協(xié)議數(shù)據(jù)組合成單個數(shù)據(jù)單元。圖4-5描述了SSL記錄協(xié)議操作的整個過程。

3．SSL協(xié)議17圖4-5SSL記錄協(xié)議

圖4-5SSL記錄協(xié)議18(1)分段：其中每個分片報文最大不能超過16KB。(2)壓縮：該操作是可選的。目前的版本還沒有指定壓縮算法，默認(rèn)的缺省算法為空。壓縮必須是無損的，而且增加的內(nèi)容長度不會超過1024B。(3)計算MAC碼：這一步需要用到客戶機(jī)與服務(wù)器共享的密鑰。(4)加密：使用加密算法對壓縮報文和MAC碼進(jìn)行加密。加密對內(nèi)容長度的增加不可超過1024B。(5)增加記錄協(xié)議頭部，該頭部包含以下幾個部分：

(1)分段：其中每個分片報文最大不能超過16KB。19*內(nèi)容類型(8bit)：所封裝分段的高層協(xié)議類型。*主版本(8bit)：使用SSL協(xié)議的主要版本號，對SSLv3值為3。*次版本(8bit)：使用SSL協(xié)議的次要版本號，對SSLv3值為0。*壓縮長度(16bit)：分段的字節(jié)長度，不超過16KB＋2KB。圖4-6描述了SSL記錄頭部格式。

*內(nèi)容類型(8bit)：所封裝分段的高層協(xié)議類型。20圖4-6SSL記錄頭部格式

圖4-6SSL記錄頭部格式212)SSL修改密碼規(guī)格協(xié)議SSL修改密碼規(guī)格協(xié)議是SSL協(xié)議體系中最簡單的一個，它由單個報文構(gòu)成，該報文由值為1的單個字節(jié)組成。這個報文的惟一目的是使得未決狀態(tài)被復(fù)制為當(dāng)前狀態(tài)，從而改變這個連接將要使用的密碼規(guī)格。

2)SSL修改密碼規(guī)格協(xié)議223)SSL告警協(xié)議告警協(xié)議通過SSL記錄協(xié)議把有關(guān)警告?zhèn)魉偷礁鱾€實體。它由兩個字節(jié)組成，分別表示告警級別和告警信息。其中告警級別有兩個：第一是代表警告，表明是一個一般警告信息；第二是代表致命錯誤，它將終止當(dāng)前鏈接，同一個會話的其他鏈接也許可以繼續(xù)，但肯定不會再生成新的連接。告警信息則相對較多，它用告警代碼標(biāo)識。例如，0代表close_notify，表示通知接收方發(fā)送方已經(jīng)關(guān)閉本鏈接，不再發(fā)任何信息；10代表unexpected_message，表示接收到不合適的報文。

3)SSL告警協(xié)議234)SSL握手協(xié)議握手協(xié)議是SSL中最復(fù)雜的部分。這個協(xié)議使得服務(wù)器與客戶機(jī)能相互鑒別對方的身份、協(xié)商加密和MAC算法以及保護(hù)SSL記錄中發(fā)送數(shù)據(jù)的加密密鑰等。在傳輸任何應(yīng)用數(shù)據(jù)前，都必須使用握手協(xié)議。握手協(xié)議由一系列在客戶端與服務(wù)器之間交換的報文組成。所有這些報文具有三個字段：類型(指示10種報文中的一個)、長度(以字節(jié)為單位的報文長度)、內(nèi)容(和這個報文有關(guān)的參數(shù))。SSL握手協(xié)議包含兩個階段：第一個階段用于建立私密性通信信道；第二個階段用于客戶認(rèn)證。

4)SSL握手協(xié)議24第一階段是通信的初始化階段，通信雙方都發(fā)出HELLO消息。當(dāng)雙方都接收到HELLO消息時，就有足夠的信息確定是否需要一個新的密鑰。若不需要新的密鑰，雙方立即進(jìn)入握手協(xié)議的第二階段。否則，此時服務(wù)器方的SERVER-HELLO消息將包含足夠的信息使客戶方產(chǎn)生一個新的密鑰。這些信息包括服務(wù)器所持有的證書、加密規(guī)約和連接標(biāo)識。若密鑰產(chǎn)生成功，客戶方發(fā)出CLIENT-MASTER-KEY消息，否則發(fā)出錯誤消息。最終當(dāng)密鑰確定以后，服務(wù)器方向客戶方發(fā)出SERVER-VERIFY消息。因為只有擁有合適的公鑰的服務(wù)器才能解開密鑰。需要注意的一點是，每一通信方向上都需要一對密鑰，所以一個連接需要四個密鑰，分別為客戶方的讀密鑰、客戶方的寫密鑰、服務(wù)器方的讀密鑰、服務(wù)器方的寫密鑰。

第一階段是通信的初始化階段，通信雙方都發(fā)出HELLO消息25第二階段的主要任務(wù)是對客戶進(jìn)行認(rèn)證，此時服務(wù)器已經(jīng)被認(rèn)證了。服務(wù)器方向客戶發(fā)出認(rèn)證請求消息：REQUEST-CERTIFICATE。當(dāng)客戶收到服務(wù)器方的認(rèn)證請求消息時，發(fā)出自己的證書，并且監(jiān)聽對方回送的認(rèn)證結(jié)果。而當(dāng)服務(wù)器收到客戶的認(rèn)證時，若認(rèn)證成功，則返回SERVER-FINISH消息，否則返回錯誤消息。到此為止，握手協(xié)議全部結(jié)束。

第二階段的主要任務(wù)是對客戶進(jìn)行認(rèn)證，此時服務(wù)器已經(jīng)被認(rèn)證264．OpenSSL的安裝與應(yīng)用1)OpenSSL簡介OpenSSL是基于SSLeay庫的軟件包，它是由EricA.Young和TimJ.Hudson于1995年共同開發(fā)成功的。其OpenSSL工具箱是經(jīng)過Apache型認(rèn)證認(rèn)可的，也就是說，這是一個沒有太多限制的開放源代碼的軟件包。到目前為止，用戶已經(jīng)可以從免費下載OpenSSL0.9.7g及其補(bǔ)丁程序。

4．OpenSSL的安裝與應(yīng)用27OpenSSL采用C語言作為開發(fā)語言，這使得OpenSSL具有優(yōu)秀的跨平臺性能，這對于廣大技術(shù)人員來說是一件非常美妙的事情，可以在不同的平臺使用同樣熟悉的東西。OpenSSL支持Linux、Windows、BSD、Mac、VMS等平臺，這使得OpenSSL具有廣泛的適用性。OpenSSL的算法已經(jīng)非常完善，提供對SSL2.0、SSL3.0以及TLS1.0的支持。OpenSSL整個軟件包大概可以分成三個主要的功能部分：密碼算法庫、SSL協(xié)議庫以及應(yīng)用程序。

OpenSSL采用C語言作為開發(fā)語言，這使得Open282)OpenSSL安裝下載OpenSSL免費軟件經(jīng)解壓縮，安裝方法可以參考INSTALL.*文件。OpenSSL是支持跨平臺的，它支持UNIX、DOS、Windows、OpenVMS和MacOS各類操作系統(tǒng)，具體安裝手冊可以分別查閱INSTALL、INSTALL.DJGPP、INSTALL.W32、INSTALL.VMS和INSTALL.MacOS文件。這里只講述基于UNIX和Windows下的OpenSSL安裝工作。

2)OpenSSL安裝29(1)在UNIX平臺安裝OpenSSL。在安裝OpenSSL前必須具備以下工具：make，Perl5，ANSIC編譯器，類庫和C頭文件開發(fā)環(huán)境，可支持UNIX操作系統(tǒng)。安裝過程比較簡單，可以在控制臺輸入以下命令：$./config$make$maketest$makeinstall(1)在UNIX平臺安裝OpenSSL。在安裝Ope30前面的操作將在系統(tǒng)默認(rèn)位置/usr/local/ssl下創(chuàng)建并安裝OpenSSL。如果想指定安裝位置，可以輸入：$./config--prefix=/usr/local--openssldir=/usr/local/openssl更多有關(guān)./config(或./Configure)的配置可以查看相關(guān)幫助。

前面的操作將在系統(tǒng)默認(rèn)位置/usr/local/ssl31(2)在Windows平臺安裝OpenSSL。在安裝OpenSSL中，如果你的系統(tǒng)是基于Win32的，你需要安裝Perl工具；如果系統(tǒng)是基于Cygwin的，你需要安裝ActiveStatePerl。

另外，你必須具備一種C編譯器(如VisualC++，BorlandC或GNUC)。

(2)在Windows平臺安裝OpenSSL。在安裝32下面給出安裝過程：*使用VisualC++編譯器。創(chuàng)建一個OpenSSL的FIPS-certified變量并添加到選項“fips”。*運行Configure：>perlConfigureVC-WIN32*組建Makefiles和可選的匯編語言文件；如果使用MASM，運行>ms\do_masm；如果使用NASM，運行>ms\do_nasm；如果不使用任何匯編語言文件，運行>ms\do_ms。

下面給出安裝過程：33*最后運行>nmake-fms\ntdll.mak。如果所有操作都成功，你將獲得一些DLL文件，它們可以在out32dll上運行。如果你想測試這些文件，可以輸入>cdout32dll>..\ms\test*使用BorlandC++builder5編譯器。*配置BorlandBuilder：>perlConfigureBC-32*最后運行>nmake-fms\ntdll.m34*創(chuàng)建合適的makefile：>ms\do_nasm*運行：>make-fms\bcb.mak*使用GNUC(Cygwin)編譯器。Cygwin提供了一種在NT4.0，Windows9x，WindowsME，Windows2000，andWindowsXP的bashshell和GNU工具環(huán)境。所以用Cygwin安裝OpenSSL與在GNUbash環(huán)境下(如Linux)接近。Cygwin執(zhí)行一個Posix/Unix運行時系統(tǒng)(cygwin1.dll)。它也可以使用MinGW創(chuàng)建Win32類庫(msvcrt.dll或crtdll.dll)，或者使用下面的步驟安裝。

*創(chuàng)建合適的makefile：35*安裝Cygwin(詳見/)。*安裝Perl并確信Cygwin與perl(5.6.1-2或更高)和ActivePerl工作在同個路徑。*運行Cygwinbashshell。*在控制臺輸入：$tarzxvfopenssl-x.x.x.tar.gz$cdopenssl-x.x.x*安裝Cygwin(詳見http://cygwin36如果創(chuàng)建Cygwin版的OpenSSL，運行：$./config[...]$make[...]$maketest$makeinstall如果在Cygwin上創(chuàng)建MinGW版(nativeWindows)OpenSSL，運行：$./Configuremingw[...]$make[...]$maketest$makeinstall如果創(chuàng)建Cygwin版的OpenSSL，運行：373)OpenSSL應(yīng)用OpenSSL的應(yīng)用一般可以分為兩種不同的方式：基于OpenSSL指令的應(yīng)用和基于OpenSSL加密庫及協(xié)議庫的應(yīng)用。前者簡單，而后者相對復(fù)雜。這兩種應(yīng)用不一定是截然分離的，可以相互結(jié)合使用，比如使用SSL協(xié)議的API，但是證書使用OpenSSL的指令簽發(fā)?；贠penSSL指令的應(yīng)用很容易，只要安裝好了OpenSSL就可以開始使用。最簡單的應(yīng)用就是使用Req、CA以及X509指令來簽發(fā)一個證書，該證書可以用于各種目的，比如很多Apache服務(wù)器就是使用OpenSSL的指令生成的證書作為服務(wù)器證書的。此外，作為測試目的，使用OpenSSL指令生成一個證書也是不錯的選擇。

3)OpenSSL應(yīng)用38單純依靠OpenSSL指令的成功應(yīng)用要數(shù)OpenCA，它是一個完全基于OpenSSL指令開發(fā)的證書認(rèn)證中心(CA)程序，沒有使用任何OpenSSL的API。當(dāng)然，它不僅僅使用了OpenSSL一個軟件包，它還使用了諸如OpenLDAP等軟件包。OpenCA從一個側(cè)面證明了OpenSSL指令的作用是很全面的?；贠penSSL函數(shù)庫的應(yīng)用相對于基于OpenSSL指令的應(yīng)用開發(fā)的工作量會大很多，但這并不意味著其應(yīng)用會更少。事實上，基于OpenSSL的應(yīng)用大部分是這種方式的，這種方式使得開發(fā)者能夠根據(jù)自己的需求靈活地進(jìn)行選擇，而不必受OpenSSL有限指令的限制。

單純依靠OpenSSL指令的成功應(yīng)用要數(shù)OpenCA39Mod_SSL是一個基于OpenSSL指令應(yīng)用的范例，Apache和Mod_SSL結(jié)合起來實現(xiàn)了HTTPS在Linux和Windows等平臺的運行。Stunnel是另外一個成功應(yīng)用OpenSSL函數(shù)庫的程序，該程序提供了一種包含客戶端和服務(wù)器的安全代理服務(wù)器功能，事實上就是在客戶端和服務(wù)器使用OpenSSL來建立一條安全的SSL通道。除了這些廣為人知的項目外，有很多公司的商業(yè)密碼產(chǎn)品都是基于OpenSSL的函數(shù)庫開發(fā)的，在OpenSSL提供了Engine機(jī)制后，這種勢頭會更加明顯。當(dāng)然，出于各種目的，相當(dāng)一部分公司在自己的產(chǎn)品中不會聲明這一點。

Mod_SSL是一個基于OpenSSL指令應(yīng)用的范例，404.3S-HTTP1．安全超文本傳輸協(xié)議(S-HTTP)簡介安全超文本傳輸協(xié)議(S-HTTP)是一種面向安全信息通信的協(xié)議，它可以和HTTP結(jié)合起來使用。S-HTTP能和HTTP信息模型共存并易于與HTTP應(yīng)用程序相整合。S-HTTP協(xié)議為HTTP客戶機(jī)和服務(wù)器提供了多種安全機(jī)制，提供安全服務(wù)選項是為了適用于萬維網(wǎng)上各類潛在用戶。S-HTTP為客戶機(jī)和服務(wù)器提供了相同的性能(同等對待請求和應(yīng)答，也同等對待客戶機(jī)和服務(wù)器)，同時維持了HTTP的事務(wù)模型和實施特征。

4.3S-HTTP1．安全超文本傳輸協(xié)議(S-HT41S-HTTP客戶機(jī)和服務(wù)器能與某些加密信息格式標(biāo)準(zhǔn)相結(jié)合。S-HTTP支持多種兼容方案并且與HTTP相兼容。使用S-HTTP的客戶機(jī)能夠與沒有使用S-HTTP的服務(wù)器連接，反之亦然，但是這樣的通信明顯地不會利用S-HTTP的安全特征。S-HTTP不需要客戶端公用密鑰認(rèn)證(或公用密鑰)，但它支持對稱密鑰的操作模式，這點很重要，因為這意味著即使沒有要求用戶擁有公用密鑰，私人交易也會發(fā)生。雖然S-HTTP可以利用大多現(xiàn)有的認(rèn)證系統(tǒng)，但S-HTTP的應(yīng)用并不必依賴這些系統(tǒng)。

S-HTTP客戶機(jī)和服務(wù)器能與某些加密信息格式標(biāo)準(zhǔn)相結(jié)合42S-HTTP支持端對端的安全事務(wù)通信?？蛻魴C(jī)可能“首先”啟動安全傳輸(使用報頭的信息)，例如它可以用來支持已填表單的加密。使用S-HTTP，敏感的數(shù)據(jù)信息不會以明文形式在網(wǎng)絡(luò)上發(fā)送。S-HTTP提供了完整且靈活的加密算法、模態(tài)及相關(guān)參數(shù)。選項談判用來決定客戶機(jī)和服務(wù)器在事務(wù)模式、加密算法(用于簽名的RSA和DSA、用于加密的DES和RC2等)及證書選擇方面取得一致意見。

S-HTTP支持端對端的安全事務(wù)通信?？蛻魴C(jī)可能“首先”43雖然S-HTTP的設(shè)計者承認(rèn)他有意識地利用了多根分層的信任模型和許多公鑰證書系統(tǒng)，但S-HTTP仍努力避開對某種特定模型的濫用。S-HTTP與摘要驗證(在[RFC-2617]中有描述)的不同之處在于，它支持公鑰加密和數(shù)字簽名，并具有保密性。HTTPS作為另一種安全Web通信技術(shù)，是指HTTP運行在TLS和SSL上面的實現(xiàn)安全Web事務(wù)的協(xié)議。

雖然S-HTTP的設(shè)計者承認(rèn)他有意識地利用了多根分層的信44

2．協(xié)議結(jié)構(gòu)在語法上，S-HTTP報文與HTTP相同，由請求或狀態(tài)行組成，后面是信頭和主體。顯然信頭各不相同并且主體密碼設(shè)置更為精密。正如HTTP報文一樣，S-HTTP報文由從客戶機(jī)到服務(wù)器的請求和從服務(wù)器到客戶機(jī)的響應(yīng)組成。請求報文的格式如下：

2．協(xié)議結(jié)構(gòu)45為了和HTTP報文區(qū)分開來，S-HTTP需要特殊處理，請求行使用特殊的“安全”途徑和指定協(xié)議“S-HTTP”。因此S-HTTP和HTTP可以在相同的TCP端口混合處理(例如端口80)。為了防止敏感信息的泄漏，URI請求必須帶有“*”。S-HTTP響應(yīng)采用指定協(xié)議“S-HTTP”。響應(yīng)報文的格式如下：

為了和HTTP報文區(qū)分開來，S-HTTP需要特殊處理，請464.4SMIME

1．多用途的網(wǎng)際郵件擴(kuò)充協(xié)議(MIME/S-MIME)多用途網(wǎng)際郵件擴(kuò)充協(xié)議(MIME，MultipurposeInternetMailExtensions)說明了如何安排消息格式使消息在不同的郵件系統(tǒng)內(nèi)進(jìn)行交換。MIME的格式靈活，允許郵件中包含任意類型的文件。MIME消息可以包含文本、圖像、聲音、視頻及其他應(yīng)用程序的特定數(shù)據(jù)。具體來說，MIME允許郵件包括：單個消息中可含多個對象；文本文檔不限制一行長度或全文長度；可傳輸ASCII以外的字符集，允許非英語語種的消息；多字體消息；二進(jìn)制或特定應(yīng)用程序文件；圖像、聲音、視頻及多媒體消息。

4.4SMIME1．多用途的網(wǎng)際郵件擴(kuò)充協(xié)議(MI47MIME復(fù)合消息的目錄信息頭設(shè)有分界標(biāo)志，這個分界標(biāo)志絕不可出現(xiàn)在消息的其他位置，而只能是在各部之間以及消息體的開始和結(jié)束處。MIME的安全版本S/MIME(Secure/MultipurposeInternetMailExtensions)設(shè)計用來支持郵件的加密?；贛IME標(biāo)準(zhǔn)，S/MIME為電子消息應(yīng)用程序提供如下加密安全服務(wù)：認(rèn)證、完整性保護(hù)、鑒定及數(shù)據(jù)保密等。

MIME復(fù)合消息的目錄信息頭設(shè)有分界標(biāo)志，這個分界標(biāo)志絕48傳統(tǒng)的郵件用戶代理(MUA)可以使用S/MIME來加密發(fā)送郵件及解密接收郵件。S/MIME并不限于郵件的使用，它也能應(yīng)用于任何可以傳送MIME數(shù)據(jù)的傳輸機(jī)制，例如HTTP。同樣，S/MIME利用MIME的面向?qū)ο筇卣髟试S在混合傳輸系統(tǒng)中交換安全消息。此外，S/MIME還可應(yīng)用于消息自動傳送代理，它們使用不需任何人為操作的加密安全服務(wù)，例如軟件文檔簽名、發(fā)送到網(wǎng)上的FAX加密等。

傳統(tǒng)的郵件用戶代理(MUA)可以使用S/MIME來加密發(fā)492．協(xié)議結(jié)構(gòu)MIME定義了許多新的RFC822頭域用于描述一個MIME實體的內(nèi)容。這些頭域有兩種情形(一種作為常規(guī)RFC822消息頭的一部分，一種是多個結(jié)構(gòu)中的MIME主體部分頭)。這些正規(guī)頭域的定義如下：entity-headers:=[contentCRLF][encodingCRLF][idCRLF][descriptionCRLF]2．協(xié)議結(jié)構(gòu)50*(MIME-extension-fieldCRLF)MIME-message-headers:=entity-headers[fields]versionCRLF;TheorderingoftheheaderfieldsimpliedbythisBNFdefinitionshouldbeignored.MIME-part-headers:=entity-headers[fields];Anyfieldnotbeginningwith"content-"canhavenodefinedmeaningandmaybeignored.;TheorderingoftheheaderfieldsimpliedbythisBNFdefinitionshouldbeignored.*(MIME-extension-fieldCRLF)51MIME加入安全特性就是S/MIME，它是MIME的延伸，RFC1847就是S/MIME的標(biāo)準(zhǔn)。當(dāng)一篇MIME加入電子簽章或編碼后，S/MIME會把整個MIME郵件視作一個不可分割的主體，對這個主體實施PKI安全操作(加密或簽名等)，并加入必需的S/MIME頭信息，這樣就產(chǎn)生了S/MIME格式的郵件。

MIME加入安全特性就是S/MIME，它是MIME的延伸52(1)經(jīng)過數(shù)字簽名的郵件結(jié)構(gòu)如圖4-7所示。

圖4-7經(jīng)過數(shù)字簽名的郵件結(jié)構(gòu)

(1)經(jīng)過數(shù)字簽名的郵件結(jié)構(gòu)如圖4-7所示。圖4-753(2)經(jīng)過加密的郵件如圖4-8所示。

圖4-8經(jīng)過加密的郵件

(2)經(jīng)過加密的郵件如圖4-8所示。圖4-8經(jīng)過加密544.5SET1．SET簡介電子商務(wù)是在開放的Internet環(huán)境中實現(xiàn)交易應(yīng)用。電子商務(wù)涉及資金流和物流信息的傳送，因此安全至關(guān)重要。

4.5SET1．SET簡介55針對電子商務(wù)的要求，目前最有影響力的安全協(xié)議是安全電子交易協(xié)議(SET，SecureElectronicTransaction)。該協(xié)議是由VISA和MasterCard兩大信用卡公司于1997年5月聯(lián)合推出的。SET采用公鑰密碼體制和X.509數(shù)字證書標(biāo)準(zhǔn)，它主要是為了解決用戶、商家和銀行之間通過信用卡支付的交易而設(shè)計的，以保證支付信息的機(jī)密、支付過程的完整、商戶及持卡人的合法身份以及可操作性。SET協(xié)議中的核心技術(shù)主要有公鑰加密、數(shù)字簽名、電子信封、電子安全證書等。SET協(xié)議是PKI框架下的一個典型實現(xiàn)，也是一個基于可信的第三方認(rèn)證中心的方案，它不僅加密兩個端點間的單個會話，還可以加密和認(rèn)定三方間的多個信息。

針對電子商務(wù)的要求，目前最有影響力的安全協(xié)議是安全電子交56SET協(xié)議的目標(biāo)：(1)信息在Internet上的安全傳輸，保證網(wǎng)上傳輸?shù)臄?shù)據(jù)不被黑客竊聽。(2)訂單信息和個人賬號信息的隔離，在將包括消費者賬號信息的訂單送到商家時，商家只能看到訂貨信息，而看不到消費者的賬戶信息。(3)消費者和商家的相互認(rèn)證，以確定通信雙方的身份，一般由第三方機(jī)構(gòu)負(fù)責(zé)為在線通信雙方提供信用擔(dān)保。

SET協(xié)議的目標(biāo)：57(4)要求軟件遵循相同的協(xié)議和消息格式，使不同廠家開發(fā)的軟件具有兼容和互操作功能，并且可以運行在不同的硬件和操作系統(tǒng)平臺上。在一次完整的電子商務(wù)交易中，SET涉及到持卡人、商家、收單銀行、發(fā)卡機(jī)構(gòu)、認(rèn)證中心(CA)、支付網(wǎng)關(guān)等實體，具體關(guān)系如圖4-9所示。

(4)要求軟件遵循相同的協(xié)議和消息格式，使不同廠家開發(fā)58圖4-9SET協(xié)議的電子商務(wù)模型

圖4-9SET協(xié)議的電子商務(wù)模型59圖4-9電子商務(wù)模型中各實體的具體含義如下：*持卡人：在電子商務(wù)環(huán)境中，消費者和團(tuán)體購買者通過計算機(jī)與商家交流，持卡人通過由發(fā)卡機(jī)構(gòu)頒發(fā)的付款卡(例如信用卡、借記卡)進(jìn)行結(jié)算。在持卡人和商家的會話中，SET可以保證持卡人的個人賬號信息不被泄漏。*商家：提供商品或服務(wù)，使用SET就可以保證持卡人個人信息的安全。接收卡的商家必須和銀行有關(guān)系。

圖4-9電子商務(wù)模型中各實體的具體含義如下：60*收單銀行：在線交易的商家在銀行開立賬號，并且處理支付卡的認(rèn)證和支付。*發(fā)卡機(jī)構(gòu)：它是一個金融機(jī)構(gòu)，為每一個建立了賬戶的顧客頒發(fā)付款卡，發(fā)卡機(jī)構(gòu)根據(jù)不同品牌卡的規(guī)定和政策，保證對每一筆認(rèn)證交易的付款。*認(rèn)證中心(CA)：通常是由一些發(fā)卡機(jī)構(gòu)共同委托，并負(fù)責(zé)向持卡人、電子商家發(fā)行公開密鑰證書的機(jī)構(gòu)。*支付網(wǎng)關(guān)：是由銀行操作的，將Internet上的傳輸數(shù)據(jù)轉(zhuǎn)換為金融機(jī)構(gòu)內(nèi)部數(shù)據(jù)的設(shè)備，或由指派的第三方處理商家支付信息和顧客的支付指令。

*收單銀行：在線交易的商家在銀行開立賬號，并且處理支付61

2．SET交易流程SET的交易流程分為以下幾個步驟：(1)卡用戶向商家發(fā)送訂購和支付信息，其中支付信息被加密，商家無從得知。(2)商家將支付信息發(fā)送到收單銀行，收單銀行解密信用卡號，并通過認(rèn)證驗證簽名。(3)收單銀行向發(fā)卡銀行查詢，確認(rèn)用戶信用卡是否屬實。(4)發(fā)卡銀行認(rèn)可并簽證該筆交易。(5)收單銀行認(rèn)可商家并簽證此交易。

2．SET交易流程62(6)商家向用戶傳送貨物和收據(jù)。(7)交易成功后，商家向收單銀行請求支付。(8)收單銀行按合同將貨款劃給商家。(9)發(fā)卡銀行定期向用戶寄去信用卡消費賬單。

(6)商家向用戶傳送貨物和收據(jù)。633．雙重簽名雙重簽名是為了保證消費者的賬號等重要信息不被商家知道。SET中采用了雙重簽名技術(shù)，它是SET推出的數(shù)字簽名的新應(yīng)用。首先生成兩條消息的摘要，將兩個摘要連接起來，生成一個新的摘要(稱為雙重簽名)，然后用簽發(fā)者的私有密鑰加密，為了讓接收者驗證雙重簽名，還必須將另外一條消息的摘要一起傳送過去。這樣，任何一個消息的接收者都可以通過以下方法驗證消息的真實性：生成消息摘要，將它和另外一個消息摘要連接起來，生成新的摘要，如果它與解密后的雙重簽名相等，就可以確定消息是真實的。

3．雙重簽名644.6PGP1．PGP簡介PGP(PrettyGoodPrivacy)是美國的PhilZimmermann在1995年開發(fā)的，它是一個基于RSA公鑰加密體系的郵件加密軟件包。它可以保密郵件以防止非授權(quán)者閱讀，它還能對郵件加上數(shù)字簽名從而使收信人可以確信郵件的發(fā)送者。PGP可以使得用戶和他從未見過的人安全通信，而事先并不需要任何保密的渠道用來傳遞私鑰。4.6PGP1．PGP簡介65圖4-10PGP加密和認(rèn)證過程

圖4-10PGP加密和認(rèn)證過程662．PGP的應(yīng)用PGP既是一個特定的安全E-mail應(yīng)用，又是一個安全E-mail標(biāo)準(zhǔn)。盡管標(biāo)準(zhǔn)委員會并沒有把它規(guī)定為安全E-mail的標(biāo)準(zhǔn)，但PGP在全球的廣泛應(yīng)用已經(jīng)使它成為一個事實上的標(biāo)準(zhǔn)。目前，PGP在Windows下發(fā)布的最高版本是7.0.3。雖然它在網(wǎng)絡(luò)上是免費的，但應(yīng)用程序是相對獨立的，與郵件的結(jié)合依賴于Outlook等郵件客戶機(jī)。所有的郵件傳遞都是后臺工作，基本不需要用戶直接干預(yù)。在PGP算法的基礎(chǔ)上，依照它的模型實現(xiàn)郵件的安全傳輸。

2．PGP的應(yīng)用67當(dāng)文件以收件人的公鑰加密后，只有持有私鑰的收件人才能解讀，即使文件被竊取也不怕資料外泄；再者，送件人以個人私鑰加簽于文件上，收件人取得后，以送件人的公鑰加以核算，若一致就表示這份文件確實是由對方發(fā)出而且沒有遭到篡改，基本上可達(dá)到文件加密及電子簽章的功能。

當(dāng)文件以收件人的公鑰加密后，只有持有私鑰的收件人才能解讀68習(xí)

題

4.1IPSec協(xié)議的隧道模式與傳輸模式有何區(qū)別？如何實現(xiàn)？4.2簡述ESP和AH在IPSec中的作用，它們能否同時使用？4.3描述SSL結(jié)構(gòu)，并介紹相關(guān)協(xié)議的功能。4.4簡述SSL記錄協(xié)議操作的整個過程。4.5簡述S-HTTP相對于HTTP的特性。4.6SET如何在電子商務(wù)流程中實現(xiàn)安全保密功能？4.7簡述PGP的加密和認(rèn)證過程。

習(xí)題4.1IPSec協(xié)議的隧道模式與傳輸模式有69第4章密碼技術(shù)應(yīng)用4.1IPSec4.2SSL4.3S-HTTP4.4SMIME4.5SET

4.6PGP習(xí)題

第4章密碼技術(shù)應(yīng)用4.1IPSec704.1IPSec1.IPSec概述傳統(tǒng)的TCP/IP協(xié)議，IP數(shù)據(jù)包在傳輸過程中并沒有過多的安全需求，人們很容易偽造IP地址，篡改數(shù)據(jù)包內(nèi)容，重放以前的包并在傳輸途中截獲并查看包內(nèi)信息。因此不能保證自己收到的數(shù)據(jù)包來自正確的發(fā)送端，不能肯定數(shù)據(jù)是發(fā)送端的原始數(shù)據(jù)，也不能防止原始數(shù)據(jù)在傳輸過程中未被竊聽，所以本質(zhì)上說這種協(xié)議是不安全的。為了有效保護(hù)IP數(shù)據(jù)包的安全，IPSec應(yīng)運而生，它隨著Ipv6的制定而產(chǎn)生，鑒于Ipv4應(yīng)用的廣泛性，IPSec也提供對Ipv4的支持，不過在Ipv6中它是必須支持的，而在Ipv4中是可選的。

4.1IPSec1.IPSec概述71圖4-1IPSec結(jié)構(gòu)框架

圖4-1IPSec結(jié)構(gòu)框架72

2．IPSec的結(jié)構(gòu)(1)AH為IP數(shù)據(jù)包提供3種服務(wù)，即無連接的數(shù)據(jù)完整性驗證、數(shù)據(jù)源身份認(rèn)證和防重放攻擊。數(shù)據(jù)完整性驗證通過哈希函數(shù)產(chǎn)生的校驗來保證；數(shù)據(jù)源身份認(rèn)證通過在計算驗證碼時加入一個共享密鑰來實現(xiàn)；AH報頭中的序列號可以防止重放攻擊。

2．IPSec的結(jié)構(gòu)73(2)ESP除了為IP數(shù)據(jù)包提供AH已有的3種服務(wù)外，還提供另外兩種服務(wù)，即數(shù)據(jù)包加密、數(shù)據(jù)流加密。加密是ESP的基本功能，而數(shù)據(jù)源身份認(rèn)證、數(shù)據(jù)完整性驗證以及防重放攻擊都是可選的。數(shù)據(jù)包加密是指對一個IP包進(jìn)行加密，可以是對整個IP包，也可以只加密IP包的負(fù)荷部分，一般用于客戶端計算機(jī)；數(shù)據(jù)源加密一般用于支持IPSec的路由器，源端路由器并不關(guān)心IP包的內(nèi)容，對整個IP包進(jìn)行加密后傳輸，目的端路由器將該包解密后把原始包繼續(xù)轉(zhuǎn)發(fā)。在實際進(jìn)行IP通信中，可以根據(jù)實際安全需求同時使用這兩種協(xié)議或選擇其中的一種。AH和ESP都可以提供驗證服務(wù)，不過，AH提供的驗證服務(wù)要強(qiáng)于ESP。

(2)ESP除了為IP數(shù)據(jù)包提供AH已有的3種服務(wù)外74(3)IKE協(xié)議負(fù)責(zé)密鑰管理，定義了通信實體間進(jìn)行身份認(rèn)證、協(xié)商加密算法以及生成共享的會話密鑰的方法。IKE將密鑰協(xié)商的結(jié)果保留在安全聯(lián)盟(SA)中，供AH和ESP以后通信時使用。最后，解釋域(DOI)為使用IKE進(jìn)行協(xié)商SA的協(xié)議統(tǒng)一分配標(biāo)識符。共享一個DOI的協(xié)議從一個共同的命名空間中選擇安全協(xié)議和變換、共享密碼以及交互協(xié)議的標(biāo)識等，DOI將IPSec的這些RFC文檔聯(lián)系到一起。

(3)IKE協(xié)議負(fù)責(zé)密鑰管理，定義了通信實體間進(jìn)行身753．IPSec的運行模式IPSec有兩種運行模式，即傳輸模式(TransportMode)和隧道模式(TunnelMode)。這兩種模式的主要區(qū)別是它們所保護(hù)的內(nèi)容不同，傳輸模式保護(hù)的只是IP的有效負(fù)載，而隧道模式保護(hù)的是整個IP數(shù)據(jù)包。AH和ESP都支持這兩種模式，共存在四種形式，即AH傳輸模式、ESP傳輸模式、AH隧道模式、ESP隧道模式。這些傳輸模式如圖4-2所示。

3．IPSec的運行模式76圖4-2IPSec傳輸模式(a)AH傳輸模式；(b)AH隧道模式；(c)ESP傳輸模式；(d)ESP隧道模式

圖4-2IPSec傳輸模式771)AH傳輸模式在該模式中，AH被插入到IP頭部之后，在傳輸層協(xié)議(如TCP、UDP)或者其他IPSec協(xié)議之前。因為AH驗證的區(qū)域覆蓋整個IP包，包括IP包頭部，所以源/目的IP地址是不能修改的，否則會被檢測出來。如果數(shù)據(jù)包在傳送過程中經(jīng)過網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT，NetworkAddressTranslation)網(wǎng)關(guān)，其源/目的IP地址將發(fā)生改變，會造成到達(dá)目的地址后的完整性驗證識別失敗。因此，AH在傳輸模式下和NAT是沖突的，不能同時使用?；蛘哒fAH不能穿越NAT。

1)AH傳輸模式782)AH隧道模式在該模式中，AH插入到原始IP頭部字段之前，再在AH之前增加一個新的IP頭部。在隧道模式下，AH驗證的區(qū)域也將覆蓋整個IP包，所以也存在AH與NAT的沖突。

2)AH隧道模式793)ESP傳輸模式在該模式中，ESP插入到IP頭部之后，ESP頭部包含SPI和序列號字段，ESP尾部包含填充、填充長度和下一個頭字段。在接收端，SPI字段用于和源IP地址、IPSec協(xié)議一起組成一個三元組來惟一確定一個SA，并利用該SA進(jìn)行驗證、解密，然后等待后續(xù)處理，所以SPI不能被加密。其次，序列號字段用于判斷包是否重復(fù)，從而防止重發(fā)攻擊。序列號不會泄漏明文中的任何機(jī)密，所以也沒有必要進(jìn)行加密。其尾部使用了ESP驗證，因為SA需要ESP的驗證服務(wù)，接收端會在任何后續(xù)處理(如檢查重放、解密)之前進(jìn)行驗證。數(shù)據(jù)包只有經(jīng)過驗證該包沒有經(jīng)過任何修改，才會被確認(rèn)為可信任的，才會進(jìn)行候選處理。

3)ESP傳輸模式804)ESP隧道模式在該模式中，ESP插入到IP頭部之前，在ESP之前再插入新的IP頭部。與傳輸模式一樣，ESP頭部含有SPI和序列號字段，ESP尾部包含填充、填充長度和下一個頭字段。如果選用了驗證，ESP的驗證數(shù)據(jù)字段中包含了驗證數(shù)據(jù)。同樣ESP頭部和ESP驗證數(shù)據(jù)字段不會被加密。內(nèi)部的IP頭部被加密和驗證，而外部的IP頭部既沒有被加密也沒有被驗證，不被加密是因為路由器需要這些信息為其尋找路由，不被驗證是為了能適應(yīng)NAT等情形。

4)ESP隧道模式814.2SSL

1．SSL概述SSL(SecureSocketLayer)是由Netscape公司開發(fā)的，用于提供Internet通信的安全協(xié)議，目前已經(jīng)廣泛用于Web瀏覽器與服務(wù)器之間的身份認(rèn)證和加密數(shù)據(jù)傳輸。SSL協(xié)議位于網(wǎng)絡(luò)層協(xié)議(如TCP/IP)與各種應(yīng)用層協(xié)議(如HTTP等)之間，如圖4-3所示。在發(fā)送端，SSL層接收應(yīng)用層的數(shù)據(jù)，然后將加了密的數(shù)據(jù)發(fā)往TCP端口。在接收端，SSL從TCP端口讀取數(shù)據(jù)，解密后將數(shù)據(jù)交給應(yīng)用層。所以它為客戶端與服務(wù)器之間提供安全通信，允許雙方相互認(rèn)證、通過加密提供消息保密。

4.2SSL1．SSL概述82圖4-3SSL在TCP/IP協(xié)議棧中的位置

圖4-3SSL在TCP/IP協(xié)議棧中的位置83

2．SSL的結(jié)構(gòu)SSL被設(shè)計成使用TCP來提供一種可靠的端到端的安全服務(wù)。SSL由多個協(xié)議組成，并采用兩層體系結(jié)構(gòu)，如圖4-4所示。

圖4-4SSL協(xié)議體系結(jié)構(gòu)

2．SSL的結(jié)構(gòu)圖4-4SSL協(xié)議體系結(jié)構(gòu)84SSL中有兩個重要的概念(SSL連接和SSL會話)，具體定義如下：(1)SSL連接：連接是提供恰當(dāng)類型服務(wù)的傳輸。SSL是一種點對點連接，每次連接與一個會話相聯(lián)系。(2)SSL會話：SSL會話是客戶與服務(wù)器之間的關(guān)聯(lián)，會話通過握手協(xié)議來創(chuàng)建。會話定義了一組被多個連接共享的加密安全參數(shù)集。會話可以用來避免為每個連接進(jìn)行昂貴的新安全參數(shù)的協(xié)商。

SSL中有兩個重要的概念(SSL連接和SSL會話)，具體85

3．SSL協(xié)議1)SSL記錄協(xié)議SSL協(xié)議的底層是記錄協(xié)議層，SSL記錄協(xié)議在客戶機(jī)和服務(wù)器之間傳輸應(yīng)用數(shù)據(jù)和SSL控制數(shù)據(jù)，期間有可能需要進(jìn)行分段或把多個高層協(xié)議數(shù)據(jù)組合成單個數(shù)據(jù)單元。圖4-5描述了SSL記錄協(xié)議操作的整個過程。

3．SSL協(xié)議86圖4-5SSL記錄協(xié)議

圖4-5SSL記錄協(xié)議87(1)分段：其中每個分片報文最大不能超過16KB。(2)壓縮：該操作是可選的。目前的版本還沒有指定壓縮算法，默認(rèn)的缺省算法為空。壓縮必須是無損的，而且增加的內(nèi)容長度不會超過1024B。(3)計算MAC碼：這一步需要用到客戶機(jī)與服務(wù)器共享的密鑰。(4)加密：使用加密算法對壓縮報文和MAC碼進(jìn)行加密。加密對內(nèi)容長度的增加不可超過1024B。(5)增加記錄協(xié)議頭部，該頭部包含以下幾個部分：

(1)分段：其中每個分片報文最大不能超過16KB。88*內(nèi)容類型(8bit)：所封裝分段的高層協(xié)議類型。*主版本(8bit)：使用SSL協(xié)議的主要版本號，對SSLv3值為3。*次版本(8bit)：使用SSL協(xié)議的次要版本號，對SSLv3值為0。*壓縮長度(16bit)：分段的字節(jié)長度，不超過16KB＋2KB。圖4-6描述了SSL記錄頭部格式。

*內(nèi)容類型(8bit)：所封裝分段的高層協(xié)議類型。89圖4-6SSL記錄頭部格式

圖4-6SSL記錄頭部格式902)SSL修改密碼規(guī)格協(xié)議SSL修改密碼規(guī)格協(xié)議是SSL協(xié)議體系中最簡單的一個，它由單個報文構(gòu)成，該報文由值為1的單個字節(jié)組成。這個報文的惟一目的是使得未決狀態(tài)被復(fù)制為當(dāng)前狀態(tài)，從而改變這個連接將要使用的密碼規(guī)格。

2)SSL修改密碼規(guī)格協(xié)議913)SSL告警協(xié)議告警協(xié)議通過SSL記錄協(xié)議把有關(guān)警告?zhèn)魉偷礁鱾€實體。它由兩個字節(jié)組成，分別表示告警級別和告警信息。其中告警級別有兩個：第一是代表警告，表明是一個一般警告信息；第二是代表致命錯誤，它將終止當(dāng)前鏈接，同一個會話的其他鏈接也許可以繼續(xù)，但肯定不會再生成新的連接。告警信息則相對較多，它用告警代碼標(biāo)識。例如，0代表close_notify，表示通知接收方發(fā)送方已經(jīng)關(guān)閉本鏈接，不再發(fā)任何信息；10代表unexpected_message，表示接收到不合適的報文。

3)SSL告警協(xié)議924)SSL握手協(xié)議握手協(xié)議是SSL中最復(fù)雜的部分。這個協(xié)議使得服務(wù)器與客戶機(jī)能相互鑒別對方的身份、協(xié)商加密和MAC算法以及保護(hù)SSL記錄中發(fā)送數(shù)據(jù)的加密密鑰等。在傳輸任何應(yīng)用數(shù)據(jù)前，都必須使用握手協(xié)議。握手協(xié)議由一系列在客戶端與服務(wù)器之間交換的報文組成。所有這些報文具有三個字段：類型(指示10種報文中的一個)、長度(以字節(jié)為單位的報文長度)、內(nèi)容(和這個報文有關(guān)的參數(shù))。SSL握手協(xié)議包含兩個階段：第一個階段用于建立私密性通信信道；第二個階段用于客戶認(rèn)證。

4)SSL握手協(xié)議93第一階段是通信的初始化階段，通信雙方都發(fā)出HELLO消息。當(dāng)雙方都接收到HELLO消息時，就有足夠的信息確定是否需要一個新的密鑰。若不需要新的密鑰，雙方立即進(jìn)入握手協(xié)議的第二階段。否則，此時服務(wù)器方的SERVER-HELLO消息將包含足夠的信息使客戶方產(chǎn)生一個新的密鑰。這些信息包括服務(wù)器所持有的證書、加密規(guī)約和連接標(biāo)識。若密鑰產(chǎn)生成功，客戶方發(fā)出CLIENT-MASTER-KEY消息，否則發(fā)出錯誤消息。最終當(dāng)密鑰確定以后，服務(wù)器方向客戶方發(fā)出SERVER-VERIFY消息。因為只有擁有合適的公鑰的服務(wù)器才能解開密鑰。需要注意的一點是，每一通信方向上都需要一對密鑰，所以一個連接需要四個密鑰，分別為客戶方的讀密鑰、客戶方的寫密鑰、服務(wù)器方的讀密鑰、服務(wù)器方的寫密鑰。

第一階段是通信的初始化階段，通信雙方都發(fā)出HELLO消息94第二階段的主要任務(wù)是對客戶進(jìn)行認(rèn)證，此時服務(wù)器已經(jīng)被認(rèn)證了。服務(wù)器方向客戶發(fā)出認(rèn)證請求消息：REQUEST-CERTIFICATE。當(dāng)客戶收到服務(wù)器方的認(rèn)證請求消息時，發(fā)出自己的證書，并且監(jiān)聽對方回送的認(rèn)證結(jié)果。而當(dāng)服務(wù)器收到客戶的認(rèn)證時，若認(rèn)證成功，則返回SERVER-FINISH消息，否則返回錯誤消息。到此為止，握手協(xié)議全部結(jié)束。

第二階段的主要任務(wù)是對客戶進(jìn)行認(rèn)證，此時服務(wù)器已經(jīng)被認(rèn)證954．OpenSSL的安裝與應(yīng)用1)OpenSSL簡介OpenSSL是基于SSLeay庫的軟件包，它是由EricA.Young和TimJ.Hudson于1995年共同開發(fā)成功的。其OpenSSL工具箱是經(jīng)過Apache型認(rèn)證認(rèn)可的，也就是說，這是一個沒有太多限制的開放源代碼的軟件包。到目前為止，用戶已經(jīng)可以從免費下載OpenSSL0.9.7g及其補(bǔ)丁程序。

4．OpenSSL的安裝與應(yīng)用96OpenSSL采用C語言作為開發(fā)語言，這使得OpenSSL具有優(yōu)秀的跨平臺性能，這對于廣大技術(shù)人員來說是一件非常美妙的事情，可以在不同的平臺使用同樣熟悉的東西。OpenSSL支持Linux、Windows、BSD、Mac、VMS等平臺，這使得OpenSSL具有廣泛的適用性。OpenSSL的算法已經(jīng)非常完善，提供對SSL2.0、SSL3.0以及TLS1.0的支持。OpenSSL整個軟件包大概可以分成三個主要的功能部分：密碼算法庫、SSL協(xié)議庫以及應(yīng)用程序。

OpenSSL采用C語言作為開發(fā)語言，這使得Open972)OpenSSL安裝下載OpenSSL免費軟件經(jīng)解壓縮，安裝方法可以參考INSTALL.*文件。OpenSSL是支持跨平臺的，它支持UNIX、DOS、Windows、OpenVMS和MacOS各類操作系統(tǒng)，具體安裝手冊可以分別查閱INSTALL、INSTALL.DJGPP、INSTALL.W32、INSTALL.VMS和INSTALL.MacOS文件。這里只講述基于UNIX和Windows下的OpenSSL安裝工作。

2)OpenSSL安裝98(1)在UNIX平臺安裝OpenSSL。在安裝OpenSSL前必須具備以下工具：make，Perl5，ANSIC編譯器，類庫和C頭文件開發(fā)環(huán)境，可支持UNIX操作系統(tǒng)。安裝過程比較簡單，可以在控制臺輸入以下命令：$./config$make$maketest$makeinstall(1)在UNIX平臺安裝OpenSSL。在安裝Ope99前面的操作將在系統(tǒng)默認(rèn)位置/usr/local/ssl下創(chuàng)建并安裝OpenSSL。如果想指定安裝位置，可以輸入：$./config--prefix=/usr/local--openssldir=/usr/local/openssl更多有關(guān)./config(或./Configure)的配置可以查看相關(guān)幫助。

前面的操作將在系統(tǒng)默認(rèn)位置/usr/local/ssl100(2)在Windows平臺安裝OpenSSL。在安裝OpenSSL中，如果你的系統(tǒng)是基于Win32的，你需要安裝Perl工具；如果系統(tǒng)是基于Cygwin的，你需要安裝ActiveStatePerl。

另外，你必須具備一種C編譯器(如VisualC++，BorlandC或GNUC)。

(2)在Windows平臺安裝OpenSSL。在安裝101下面給出安裝過程：*使用VisualC++編譯器。創(chuàng)建一個OpenSSL的FIPS-certified變量并添加到選項“fips”。*運行Configure：>perlConfigureVC-WIN32*組建Makefiles和可選的匯編語言文件；如果使用MASM，運行>ms\do_masm；如果使用NASM，運行>ms\do_nasm；如果不使用任何匯編語言文件，運行>ms\do_ms。

下面給出安裝過程：102*最后運行>nmake-fms\ntdll.mak。如果所有操作都成功，你將獲得一些DLL文件，它們可以在out32dll上運行。如果你想測試這些文件，可以輸入>cdout32dll>..\ms\test*使用BorlandC++builder5編譯器。*配置BorlandBuilder：>perlConfigureBC-32*最后運行>nmake-fms\ntdll.m103*創(chuàng)建合適的makefile：>ms\do_nasm*運行：>make-fms\bcb.mak*使用GNUC(Cygwin)編譯器。Cygwin提供了一種在NT4.0，Windows9x，WindowsME，Windows2000，andWindowsXP的bashshell和GNU工具環(huán)境。所以用Cygwin安裝OpenSSL與在GNUbash環(huán)境下(如Linux)接近。Cygwin執(zhí)行一個Posix/Unix運行時系統(tǒng)(cygwin1.dll)。它也可以使用MinGW創(chuàng)建Win32類庫(msvcrt.dll或crtdll.dll)，或者使用下面的步驟安裝。

*創(chuàng)建合適的makefile：104*安裝Cygwin(詳見/)。*安裝Perl并確信Cygwin與perl(5.6.1-2或更高)和ActivePerl工作在同個路徑。*運行Cygwinbashshell。*在控制臺輸入：$tarzxvfopenssl-x.x.x.tar.gz$cdopenssl-x.x.x*安裝Cygwin(詳見http://cygwin105如果創(chuàng)建Cygwin版的OpenSSL，運行：$./config[...]$make[...]$maketest$makeinstall如果在Cygwin上創(chuàng)建MinGW版(nativeWindows)OpenSSL，運行：$./Configuremingw[...]$make[...]$maketest$makeinstall如果創(chuàng)建Cygwin版的OpenSSL，運行：1063)OpenSSL應(yīng)用OpenSSL的應(yīng)用一般可以分為兩種不同的方式：基于OpenSSL指令的應(yīng)用和基于OpenSSL加密庫及協(xié)議庫的應(yīng)用。前者簡單，而后者相對復(fù)雜。這兩種應(yīng)用不一定是截然分離的，可以相互結(jié)合使用，比如使用SSL協(xié)議的API，但是證書使用OpenSSL的指令簽發(fā)?；贠penSSL指令的應(yīng)用很容易，只要安裝好了OpenSSL就可以開始使用。最簡單的應(yīng)用就是使用Req、CA以及X509指令來簽發(fā)一個證書，該證書可以用于各種目的，比如很多Apache服務(wù)器就是使用OpenSSL的指令生成的證書作為服務(wù)器證書的。此外，作為測試目的，使用OpenSSL指令生成一個證書也是不錯的選擇。

3)OpenSSL應(yīng)用107單純依靠OpenSSL指令的成功應(yīng)用要數(shù)OpenCA，它是一個完全基于OpenSSL指令開發(fā)的證書認(rèn)證中心(CA)程序，沒有使用任何OpenSSL的API。當(dāng)然，它不僅僅使用了OpenSSL一個軟件包，它還使用了諸如OpenLDAP等軟件包。OpenCA從一個側(cè)面證明了OpenSSL指令的作用是很全面的。基于OpenSSL函數(shù)庫的應(yīng)用相對于基于OpenSSL指令的應(yīng)用開發(fā)的工作量會大很多，但這并不意味著其應(yīng)用會更少。事實上，基于OpenSSL的應(yīng)用大部分是這種方式的，這種方式使得開發(fā)者能夠根據(jù)自己的需求靈活地進(jìn)行選擇，而不必受OpenSSL有限指令的限制。

單純依靠OpenSSL指令的成功應(yīng)用要數(shù)OpenCA108Mod_SSL是一個基于OpenSSL指令應(yīng)用的范例，Apache和Mod_SSL結(jié)合起來實現(xiàn)了HTTPS在Linux和Windows等平臺的運行。Stunnel是另外一個成功應(yīng)用OpenSSL函數(shù)庫的程序，該程序提供了一種包含客戶端和服務(wù)器的安全代理服務(wù)器功能，事實上就是在客戶端和服務(wù)器使用OpenSSL來建立一條安全的SSL通道。除了這些廣為人知的項目外，有很多公司的商業(yè)密碼產(chǎn)品都是基于OpenSSL的函數(shù)庫開發(fā)的，在OpenSSL提供了Engine機(jī)制后，這種勢頭會更加明顯。當(dāng)然，出于各種目的，相當(dāng)一部分公司在自己的產(chǎn)品中不會聲明這一點。

Mod_SSL是一個基于OpenSSL指令應(yīng)用的范例，1094.3S-HTTP1．安全超文本傳輸協(xié)議(S-HTTP)簡介安全超文本傳輸協(xié)議(S-HTTP)是一種面向安全信息通信的協(xié)議，它可以和HTTP結(jié)合起來使用。S-HTTP能和HTTP信息模型共存并易于與HTTP應(yīng)用程序相整合。S-HTTP協(xié)議為HTTP客戶機(jī)和服務(wù)器提供了多種安全機(jī)制，提供安全服務(wù)選項是為了適用于萬維網(wǎng)上各類潛在用戶。S-HTTP為客戶機(jī)和服務(wù)器提供了相同的性能(同等對待請求和應(yīng)答，也同等對待客戶機(jī)和服務(wù)器)，同時維持了HTTP的事務(wù)模型和實施特征。

4.3S-HTTP1．安全超文本傳輸協(xié)議(S-HT110S-HTTP客戶機(jī)和服務(wù)器能與某些加密信息格式標(biāo)準(zhǔn)相結(jié)合。S-HTTP支持多種兼容方案并且與HTTP相兼容。使用S-HTTP的客戶機(jī)能夠與沒有使用S-HTTP的服務(wù)器連接，反之亦然，但是這樣的通信明顯地不會利用S-HTTP的安全特征。S-HTTP不需要客戶端公用密鑰認(rèn)證(或公用密鑰)，但它支持對稱密鑰的操作模式，這點很重要，因為這意味著即使沒有要求用戶擁有公用密鑰，私人交易也會發(fā)生。雖然S-HTTP可以利用大多現(xiàn)有的認(rèn)證系統(tǒng)，但S-HTTP的應(yīng)用并不必依賴這些系統(tǒng)。

S-HTTP客戶機(jī)和服務(wù)器能與某些加密信息格式標(biāo)準(zhǔn)相結(jié)合111S-HTTP支持端對端的安全事務(wù)通信。客戶機(jī)可能“首先”啟動安全傳輸(使用報頭的信息)，例如它可以用來支持已填表單的加密。使用S-HTTP，敏感的數(shù)據(jù)信息不會以明文形式在網(wǎng)絡(luò)上發(fā)送。S-HTTP提供了完整且靈活的加密算法、模態(tài)及相關(guān)參數(shù)。選項談判用來決定客戶機(jī)和服務(wù)器在事務(wù)模式、加密算法(用于簽名的RSA和DSA、用于加密的DES和RC2等)及證書選擇方面取得一致意見。

S-HTTP支持端對端的安全事務(wù)通信?？蛻魴C(jī)可能“首先”112雖然S-HTTP的設(shè)計者承認(rèn)他有意識地利用了多根分層的信任模型和許多公鑰證書系統(tǒng)，但S-HTTP仍努力避開對某種特定模型的濫用。S-HTTP與摘要驗證(在[RFC-2617]中有描述)的不同之處在于，它支持公鑰加密和數(shù)字簽名，并具有保密性。HTTPS作為另一種安全Web通信技術(shù)，是指HTTP運行在TLS和SSL上面的實現(xiàn)安全Web事務(wù)的協(xié)議。

雖然S-HTTP的設(shè)計者承認(rèn)他有意識地利用了多根分層的信113

2．協(xié)議結(jié)構(gòu)在語法上，S-HTTP報文與HTTP相同，由請求或狀態(tài)行組成，后面是信頭和主體。顯然信頭各不相同并且主體密碼設(shè)置更為精密。正如HTTP報文一樣，S-HTTP報文由從客戶機(jī)到服務(wù)器的請求和從服務(wù)器到客戶機(jī)的響應(yīng)組成。請求報文的格式如下：

2．協(xié)議結(jié)構(gòu)114為了和HTTP報文區(qū)分開來，S-HTTP需要特殊處理，請求行使用特殊的“安全”途徑和指定協(xié)議“S-HTTP”。因此S-HTTP和HTTP可以在相同的TCP端口混合處理(例如端口80)。為了防止敏感信息的泄漏，URI請求必須帶有“*”。S-HTTP響應(yīng)采用指定協(xié)議“S-HTTP”。響應(yīng)報文的格式如下：

為了和HTTP報文區(qū)分開來，S-HTTP需要特殊處理，請1154.4SMIME

1．多用途的網(wǎng)際郵件擴(kuò)充協(xié)議(MIME/S-MIME)多用途網(wǎng)際郵件擴(kuò)充協(xié)議(MIME，MultipurposeInternetMailExtensions)說明了如何安排消息格式使消息在不同的郵件系統(tǒng)內(nèi)進(jìn)行交換。MIME的格式靈活，允許郵件中包含任意類型的文件。MIME消息可以包含文本、圖像、聲音、視頻及其他應(yīng)用程序的特定數(shù)據(jù)。具體來說，MIME允許郵件包括：單個消息中可含多個對象；文本文檔不限制一行長度或全文長度；可傳輸ASCII以外的字符集，允許非英語語種的消息；多字體消息；二進(jìn)制或特定應(yīng)用程序文件；圖像、聲音、視頻及多媒體消息。

4.4SMIME1．多用途的網(wǎng)際郵件擴(kuò)充協(xié)議(MI116MIME復(fù)合消息的目錄信息頭設(shè)有分界標(biāo)志，這個分界標(biāo)志絕不可出現(xiàn)在消息的其他位置，而只能是在各部之間以及消息體的開始和結(jié)束處。MIME的安全版本S/MIME(Secure/MultipurposeInternetMailExtensions)設(shè)計用來支持郵件的加密?；贛IME標(biāo)準(zhǔn)，S/MIME為電子消息應(yīng)用程序提供如下加密安全服務(wù)：認(rèn)證、完整性保護(hù)、鑒定及數(shù)據(jù)保密等。

MIME復(fù)合消息的目錄信息頭設(shè)有分界標(biāo)志，這個分界標(biāo)志絕117傳統(tǒng)的郵件用戶代理(MUA)可以使用S/MIME來加密發(fā)送郵件及解密接收郵件。S/MIME并不限于郵件的使用，它也能應(yīng)用于任何可以傳送MIME數(shù)據(jù)的傳輸機(jī)制，例如HTTP。同樣，S/MIME利用MIME的面向?qū)ο筇卣髟试S在混合傳輸系統(tǒng)中交換安全消息。此外，S/MIME還可應(yīng)用于消息自動傳送代理，它們使用不需任何人為操作的加密安全服務(wù)，例如軟件文檔簽名、發(fā)送到網(wǎng)上的FAX加密等。

傳統(tǒng)的郵件用戶代理(MUA)可以使用S/MIME來加密發(fā)1182．協(xié)議結(jié)構(gòu)MIME定義了許多新的RFC822頭域用于描述一個MIME實體的內(nèi)容。這些頭域有兩種情形(一種作為常規(guī)RFC822消息頭的一部分，一種是多個結(jié)構(gòu)中的MIME主體部分頭)。這些正規(guī)頭域的定義如下：entity-headers:=[contentCRLF][encodingCRLF][idCRLF][descriptionCRLF]2．協(xié)議結(jié)構(gòu)119*(MIME-extension-fieldCRLF)MIME-message-headers:=entity-headers[fields]versionCRLF;TheorderingoftheheaderfieldsimpliedbythisBNFdefinitionshouldbeignored.MIME-part-headers:=entity-headers[fields];Anyfieldnotbeginningwith"content-"canhavenodefinedmeaningandmaybeignored.;TheorderingoftheheaderfieldsimpliedbythisBNFdefinitionshouldbeignored.*(