信息安全原理與技術(shù)ch07-網(wǎng)絡(luò)安全協(xié)議

信息平安原理與技術(shù)郭亞軍宋建華李莉清華大學(xué)出版社2023/8/81第7章網(wǎng)絡(luò)平安協(xié)議主要知識(shí)點(diǎn)：--簡(jiǎn)單的平安認(rèn)證協(xié)議--Kerberos協(xié)議--SSL協(xié)議--IPSec協(xié)議--PGP2023/8/82網(wǎng)絡(luò)平安協(xié)議按照其完成的功能可以分為:〔1〕密鑰交換協(xié)議:一般情況下是在參與協(xié)議的兩個(gè)或者多個(gè)實(shí)體之間建立共享的秘密，通常用于建立在一次通信中所使用的會(huì)話密鑰。〔2〕認(rèn)證協(xié)議:認(rèn)證協(xié)議中包括實(shí)體認(rèn)證〔身份認(rèn)證〕協(xié)議、消息認(rèn)證協(xié)議、數(shù)據(jù)源認(rèn)證和數(shù)據(jù)目的認(rèn)證協(xié)議等，用來(lái)防止假冒、篡改、否認(rèn)等攻擊。〔3〕認(rèn)證和密鑰交換協(xié)議：這類協(xié)議將認(rèn)證和密鑰交換協(xié)議結(jié)合在一起，是網(wǎng)絡(luò)通信中最普遍應(yīng)用的平安協(xié)議。該類協(xié)議首先對(duì)通信實(shí)體的身份進(jìn)行認(rèn)證，如果認(rèn)證成功，進(jìn)一步進(jìn)行密鑰交換，以建立通信中的工作密鑰，也叫密鑰確認(rèn)協(xié)議。2023/8/83網(wǎng)絡(luò)層的平安協(xié)議：IPSec傳輸層的平安協(xié)議：SSL/TLS應(yīng)用層的平安協(xié)議：SHTTP〔Web平安協(xié)議〕PGP(電子郵件平安協(xié)議)S/MIME(電子郵件平安協(xié)議)MOSS(電子郵件平安協(xié)議)PEM(電子郵件平安協(xié)議)SSH〔遠(yuǎn)程登錄平安協(xié)議〕Kerberos(網(wǎng)絡(luò)認(rèn)證協(xié)議)等。常見的網(wǎng)絡(luò)平安協(xié)議2023/8/847.1簡(jiǎn)單的平安認(rèn)證協(xié)議Needham-Schroeder認(rèn)證協(xié)議是最為著名的早期的認(rèn)證協(xié)議，許多廣泛使用的認(rèn)證協(xié)議都是以Needham-Schroeder協(xié)議為根底而設(shè)計(jì)的。

Otway-Rees協(xié)議Otway-Rees協(xié)議的主要功能是完成身份的雙向認(rèn)證，使用對(duì)稱密碼。2023/8/85

Needham-Schroeder認(rèn)證協(xié)議Needham--Schroder協(xié)議的目的是使得通訊雙方能夠互相證實(shí)對(duì)方的身份并且為后續(xù)的加密通訊建立一個(gè)會(huì)話密鑰(sessionkey)。協(xié)議涉及三個(gè)主體：A和B，以及A，B信賴的可信第三方，也叫認(rèn)證效勞器(authenticationserver)S。2023/8/86Needham和Schroeder于1978年提出的基于共享密鑰體系的協(xié)議過(guò)程：圖7.1Needham-Schroeder認(rèn)證過(guò)程其中，Kas是A與S之間的共享密鑰，Kbs是B與S之間的共享密鑰。Kab是認(rèn)證效勞器臨時(shí)生成的密鑰，用于A、B雙方認(rèn)證之后的加密通訊，稱為會(huì)話密鑰。Na和Nb分別是A和B生成的隨機(jī)量(nonce)。ABS13452(1)AS：A,B,Na(2)S

A：{Na,B,Kab,{Kab,A}Kbs}Kas(3)A

B：{Kab,A}Kbs(4)B

A：{Nb}Kab(5)A

B：{Nb-1}Kab2023/8/87Needhaul-Scllroeder共享密鑰協(xié)議的漏洞假定有攻擊者H記錄下A與B之間執(zhí)行Needham-Schroeder共享密鑰協(xié)議的一輪消息，并且進(jìn)而破獲了其會(huì)話密鑰Kab〔如經(jīng)過(guò)蠻力攻擊等〕，攻擊者可以在第3步冒充A利用舊的會(huì)話密鑰欺騙B。在這個(gè)攻擊中，攻擊者H首先向B發(fā)送一個(gè)他記錄的從A發(fā)出的舊消息，此消息用于向B說(shuō)明是A在與B通訊并且Kab是會(huì)話密鑰。B無(wú)法知道這是不是一個(gè)A發(fā)送的正常通訊請(qǐng)求，也不記得他過(guò)去曾經(jīng)用過(guò)Kab作為會(huì)話密鑰。遵循協(xié)議，B將向A發(fā)送一個(gè)加密的新隨機(jī)量作為挑戰(zhàn)。H截獲之，并用Kab解密得到此隨機(jī)量，然后向B返回一個(gè)響應(yīng)消息，使得B相信他正在用會(huì)話密鑰Kab與A通訊，而實(shí)際上A根本沒有參加這一輪協(xié)議的運(yùn)行。除非B記住所有以前使用的與A通信的會(huì)話密鑰，否那么B無(wú)法判斷這是一個(gè)重放攻擊，攻擊者由此可以隨意冒充A與B進(jìn)行通訊了!2023/8/88Denning協(xié)議使用時(shí)間戳修正了這個(gè)漏洞，改進(jìn)的協(xié)議如下：其中T表示時(shí)間戳。T記錄了認(rèn)證效勞器S發(fā)送消息(2)時(shí)的時(shí)間，A、B根據(jù)時(shí)間戳驗(yàn)證消息的“新鮮性〞，從而防止了重放攻擊。(1)AS：A,B(2)SA：{B,Kab,T,{Kab,A,T}Kbs}Kas(3)A

B：{Kab,A,T}Kbs(4)B

A：{Nb}Kab(5)A

B：{Nb-1}Kab2023/8/897.1.2Otway-Rees協(xié)議

圖7.2Otway-Rees認(rèn)證過(guò)程標(biāo)號(hào)1表示A產(chǎn)生一消息，包括用和S共享的密鑰Kas加密的一個(gè)索引號(hào)R、A的名字、B的名字和一隨機(jī)數(shù)Ra。標(biāo)號(hào)2表示B用A消息中的加密局部構(gòu)造一條新消息。包括用和S共享的密鑰Kbs加密的一個(gè)索引號(hào)R、A的名字、B的名字和一新隨機(jī)數(shù)Rb。ABS12342023/8/810標(biāo)號(hào)3表示S檢查兩個(gè)加密局部中的索引號(hào)R是否相同，如果相同，就認(rèn)為從B來(lái)的消息是有效的。S產(chǎn)生一個(gè)會(huì)話密鑰Ks用Kb和Ka分別加密后傳送給B，每條消息都包含S接收到的隨機(jī)數(shù)。標(biāo)號(hào)4表示B把用A的密鑰加密的消息連同索引號(hào)R一起傳給A。2023/8/8117.2Kerberos協(xié)議

在一個(gè)開放的分布式網(wǎng)絡(luò)環(huán)境中，用戶通過(guò)工作站訪問(wèn)效勞器上提供的效勞時(shí)，一方面，工作站無(wú)法可信地向網(wǎng)絡(luò)效勞證實(shí)用戶的身份，可能存在著以下三種威脅：①用戶可能訪問(wèn)某個(gè)特定工作站，并假裝成另一個(gè)用戶在操作工作站。②用戶可能會(huì)更改工作站的網(wǎng)絡(luò)地址，使從這個(gè)已更改的工作站上發(fā)出的請(qǐng)求看似來(lái)自偽裝的工作站。③用戶可能竊聽他人的報(bào)文交換過(guò)程，并使用重放攻擊來(lái)獲得對(duì)一個(gè)效勞器的訪問(wèn)權(quán)或中斷效勞器的運(yùn)行。

2023/8/812另一方面，在開放的網(wǎng)絡(luò)環(huán)境中，客戶也必須防止來(lái)自效勞端的欺騙。以自動(dòng)取款機(jī)ATM為例，如果存在欺騙，那么客戶將泄漏自己的帳戶信息。如何使用一個(gè)集中的認(rèn)證效勞器，提供用戶對(duì)效勞器的認(rèn)證以及效勞器對(duì)用戶的認(rèn)證，這就是Kerberos要解決的問(wèn)題。2023/8/8137.2.1Kerberos概述Kerberos是由美國(guó)麻省理工學(xué)院(MIT)提出的基于可信賴的第三方的認(rèn)證系統(tǒng)，它是基于Needham-Schroeder協(xié)議設(shè)計(jì)的，采用對(duì)稱密碼體制。Kerberos一詞源自希臘神話，在希臘神話故事中，Kerberos是一種長(zhǎng)有三個(gè)頭的狗，還有一個(gè)蛇形尾巴，是地獄之門的守衛(wèi)者?，F(xiàn)代取Kerberos這個(gè)名字意指要有三個(gè)“頭〞來(lái)守衛(wèi)網(wǎng)絡(luò)之門，這“三頭〞包括：-認(rèn)證(authentication)-清算(accounting)-審計(jì)(audit)2023/8/814Kerberos協(xié)議中的一些概念Principal(平安個(gè)體)被鑒別的個(gè)體，有一個(gè)名字(name)和口令(password)。KDC(Keydistributioncenter，密鑰分配中心)可信的第三方，即Kerberos效勞器，提供ticket和臨時(shí)的會(huì)話密鑰。Ticket〔訪問(wèn)許可證〕是一個(gè)記錄憑證，客戶可以用它來(lái)向效勞器證明自己的身份，其中包括客戶的標(biāo)識(shí)、會(huì)話密鑰、時(shí)間戳，以及其他一些信息。Ticket中的大多數(shù)信息都被加密，密鑰為效勞器的密鑰。2023/8/815Authenticator〔認(rèn)證符〕是另一個(gè)記錄憑證，其中包含一些最近產(chǎn)生的信息，產(chǎn)生這些信息需要用到客戶和效勞器之間共享的會(huì)話密鑰。Credentials〔證書〕由一個(gè)ticket加上一個(gè)秘密的會(huì)話密鑰組成。2023/8/8167.2.2Kerberos協(xié)議的工作過(guò)程Kerberos根本思想采用對(duì)稱密鑰體制對(duì)信息進(jìn)行加密，能正確對(duì)信息進(jìn)行解密的用戶就是合法用戶。用戶在對(duì)應(yīng)用效勞器進(jìn)行訪問(wèn)之前，必須先從第三方〔Kerberos效勞器〕獲取該應(yīng)用效勞器的訪問(wèn)許可證〔ticket〕。認(rèn)證效勞器AS(AuthenticationServer)許可證頒發(fā)效勞器TGS(TicketGrantingServer)2023/8/8177.2.2Kerberos協(xié)議的工作過(guò)程①②③④⑤⑥認(rèn)證服務(wù)器AS許可證頒發(fā)服務(wù)器TGS用戶C應(yīng)用服務(wù)器V圖7.3Kerberos的認(rèn)證過(guò)程

2023/8/818①用戶想要獲取訪問(wèn)某一應(yīng)用效勞器的許可證時(shí)，先以明文方式向認(rèn)證效勞器AS發(fā)出請(qǐng)求，要求獲得訪問(wèn)TGS的許可證。②AS以證書〔credential〕作為響應(yīng)，證書包括訪問(wèn)TGS的許可證和用戶與TGS間的會(huì)話密鑰。會(huì)話密鑰以用戶的密鑰加密后傳輸。③用戶解密得到TGS的響應(yīng)，然后利用TGS的許可證向TGS申請(qǐng)應(yīng)用效勞器的許可證，該申請(qǐng)包括TGS的許可證和一個(gè)帶有時(shí)間戳的認(rèn)證符〔authenticator〕。認(rèn)證符以用戶與TGS間的會(huì)話密鑰加密。2023/8/819④TGS從許可證中取出會(huì)話密鑰、解密認(rèn)證符，驗(yàn)證認(rèn)證符中時(shí)間戳的有效性，從而確定用戶的請(qǐng)求是否合法。TGS確認(rèn)用戶的合法性后，生成所要求的應(yīng)用效勞器的許可證，許可證中含有新產(chǎn)生的用戶與應(yīng)用效勞器之間的會(huì)話密鑰。TGS將應(yīng)用效勞器的許可證和會(huì)話密鑰傳回到用戶。⑤用戶向應(yīng)用效勞器提交應(yīng)用效勞器的許可證和用戶新產(chǎn)生的帶時(shí)間戳的認(rèn)證符〔認(rèn)證符以用戶與應(yīng)用效勞器之間的會(huì)話密鑰加密〕。⑥應(yīng)用效勞器從許可證中取出會(huì)話密鑰、解密認(rèn)證符，取出時(shí)間戳并檢驗(yàn)有效性。然后向用戶返回一個(gè)帶時(shí)間戳的認(rèn)證符，該認(rèn)證符以用戶與應(yīng)用效勞器之間的會(huì)話密鑰進(jìn)行加密。據(jù)此，用戶可以驗(yàn)證應(yīng)用效勞器的合法性。2023/8/820Kerberos的主要優(yōu)點(diǎn)：通過(guò)對(duì)實(shí)體和效勞的統(tǒng)一管理實(shí)現(xiàn)單一注冊(cè)，也就是說(shuō)用戶通過(guò)在網(wǎng)絡(luò)中的一個(gè)地方的一次登錄就可以使用網(wǎng)絡(luò)上他可以獲得的所有資源。Kerberos存在的問(wèn)題：①Kerberos效勞器的損壞將使得整個(gè)平安系統(tǒng)無(wú)法工作；②AS在傳輸用戶與TGS間的會(huì)話密鑰時(shí)是以用戶密鑰加密的，而用戶密鑰是由用戶口令生成的，因此可能受到口令猜測(cè)的攻擊；③Kerberos使用了時(shí)間戳，因此存在時(shí)間同步問(wèn)題；④要將Kerberos用于某一應(yīng)用系統(tǒng)，那么該系統(tǒng)的客戶端和效勞器端軟件都要作一定的修改。2023/8/8217.3SSL協(xié)議

SSL〔平安套接字層，SecureSocketLayer〕協(xié)議是網(wǎng)景〔Netscape〕公司提出的基于WEB應(yīng)用的平安協(xié)議，是一種用于傳輸層平安的協(xié)議。傳輸層平安協(xié)議的目的是為了保護(hù)傳輸層的平安，并在傳輸層上提供實(shí)現(xiàn)保密、認(rèn)證和完整性的方法。SSL指定了一種在應(yīng)用程序協(xié)議(例如、telnet、NNTP、FTP)和TCP/IP之間提供數(shù)據(jù)平安性分層的機(jī)制。它為TCP/IP連接提供數(shù)據(jù)加密、效勞器認(rèn)證、消息完整性以及可選的客戶機(jī)認(rèn)證。2023/8/8227.3.1SSL協(xié)議概述圖7.4SSL的體系結(jié)構(gòu)

SSL握手協(xié)議SSL修改密文協(xié)議SSL告警協(xié)議HTTPSSL記錄協(xié)議TCPIP2023/8/823SSL中有兩個(gè)重要概念：SSL連接：連接是提供恰當(dāng)類型效勞的傳輸。SSL連接是點(diǎn)對(duì)點(diǎn)的關(guān)系，每一個(gè)連接與一個(gè)會(huì)話相聯(lián)系。SSL會(huì)話：SSL會(huì)話是客戶和效勞器之間的關(guān)聯(lián)，會(huì)話通過(guò)握手協(xié)議(在SSL協(xié)議的高層)來(lái)創(chuàng)立。會(huì)話定義了加密平安參數(shù)的一個(gè)集合，該集合可以被多個(gè)連接所共享。會(huì)話可以用來(lái)防止為每個(gè)連接進(jìn)行昂貴的新平安參數(shù)的協(xié)商。2023/8/8247.3.2SSL記錄協(xié)議

SSL從應(yīng)用層取得的數(shù)據(jù)需要重定格式〔分片、可選的壓縮、應(yīng)用MAC、加密等〕后才能傳給傳輸層進(jìn)行發(fā)送。同樣，當(dāng)SSL協(xié)議從傳輸層接收到數(shù)據(jù)后需要對(duì)其進(jìn)行解密等操作后才能交給上層的應(yīng)用層。這個(gè)工作是由SSL記錄協(xié)議完成的。2023/8/825上層報(bào)文分片1分片2分片n壓縮(可選）加密增加MAC增加SSL記錄首部圖7.6SSL記錄協(xié)議的發(fā)送方執(zhí)行的操作步驟2023/8/826SSL記錄協(xié)議中發(fā)送方執(zhí)行的操作步驟：①?gòu)纳蠈咏邮軅鬏數(shù)膽?yīng)用報(bào)文；②分片：將數(shù)據(jù)分片成可管理的塊，每個(gè)上層報(bào)文被分成16KB或更小的數(shù)據(jù)塊；③進(jìn)行數(shù)據(jù)壓縮(可選)：壓縮是可選的，壓縮的前提是不能喪失信息，并且增加的內(nèi)容長(zhǎng)度不能超過(guò)1024字節(jié)，缺省的壓縮算法為空；④應(yīng)用MAC：參加信息認(rèn)證碼〔MAC〕，這一步需要用到共享的密鑰；⑤加密：利用IDEA、DES、3DES或其他加密算法對(duì)壓縮報(bào)文和MAC碼進(jìn)行數(shù)據(jù)加密；⑥增加SSL首部：增加由內(nèi)容類型、主要版本、次要版本和壓縮長(zhǎng)度組成的首部。⑦將結(jié)果傳輸?shù)较聦印?023/8/827SSL記錄協(xié)議中接收方接收數(shù)據(jù)的工作過(guò)程①?gòu)牡蛯咏邮軋?bào)文；②解密；③用事先商定的MAC碼校驗(yàn)數(shù)據(jù)；④如果是壓縮的數(shù)據(jù)，那么解壓縮；⑤重裝配數(shù)據(jù)；⑥傳輸信息到上層。2023/8/8287.3.3SSL修改密文規(guī)約協(xié)議SSL修改密文規(guī)約協(xié)議用來(lái)發(fā)送修改密文規(guī)約協(xié)議信息。任何時(shí)候客戶都能請(qǐng)求修改密碼參數(shù)，比方握手密鑰交換。在修改密文規(guī)約的通揭發(fā)出以后，客戶方就發(fā)出一個(gè)握手密鑰交換信息〔如果可得到的話〕，鑒定認(rèn)證信息，效勞器那么在處理了密鑰交換信息之后發(fā)送一個(gè)修改密文規(guī)約信息。此后，新的雙方約定的密鑰就將一直使用到下次提出修改密鑰規(guī)約請(qǐng)求為止。2023/8/8297.3.4SSL告警協(xié)議SSL告警協(xié)議是用來(lái)將SSL有關(guān)的告警傳送給對(duì)方實(shí)體的。和其他使用SSL的情況一樣，告警報(bào)文按照當(dāng)前狀態(tài)說(shuō)明被壓縮和加密。SSL告警協(xié)議的每個(gè)報(bào)文由兩個(gè)字節(jié)組成。第一個(gè)字節(jié)的值用來(lái)說(shuō)明警告的的級(jí)別，第二個(gè)字節(jié)表示特定告警的代碼。如果在通信過(guò)程中某一方發(fā)現(xiàn)任何異常，就需要給對(duì)方發(fā)送一條警示消息通告。警示消息有兩種:一種是Fatal錯(cuò)誤,如傳遞數(shù)據(jù)過(guò)程中，發(fā)現(xiàn)錯(cuò)誤的MAC，雙方就需要立即中斷會(huì)話，同時(shí)消除自己緩沖區(qū)相應(yīng)的會(huì)話記錄；第二種是Warning消息，這種情況，通信雙方通常都只是記錄日志，而對(duì)通信過(guò)程不造成任何影響。2023/8/8307.3.5SSL握手協(xié)議一個(gè)SSL會(huì)話工作在不同的狀態(tài)，即會(huì)話狀態(tài)和連接狀態(tài)。會(huì)話狀態(tài)：①會(huì)話標(biāo)識(shí)符②對(duì)方的證書③壓縮方法④密文規(guī)約⑤主密鑰⑥可重新開始標(biāo)志連接狀態(tài)：①效勞器和客戶隨機(jī)數(shù)②效勞器寫MAC密鑰③客戶寫MAC密鑰④效勞器寫密鑰⑤客戶寫密鑰⑥初始化向量⑦序號(hào)2023/8/831SSL握手協(xié)議用于鑒別初始化和傳輸密鑰，它使得效勞器和客戶能相互鑒別對(duì)方的身份，并保護(hù)在SSL記錄中發(fā)送的數(shù)據(jù)。因此在傳輸任何應(yīng)用數(shù)據(jù)前，都必須使用握手協(xié)議。2023/8/832圖7.7SSL握手過(guò)程SSL客戶端SSL服務(wù)器端發(fā)送”hello”消息傳送數(shù)據(jù)回復(fù)”hello”消息,發(fā)出服務(wù)器證書,服務(wù)器密鑰交換信息,證書請(qǐng)求,服務(wù)器HELLODONE發(fā)送證書,客戶密鑰交換信息,證書驗(yàn)證信息,結(jié)束發(fā)修改密文規(guī)約信息結(jié)束發(fā)修改密文規(guī)約信息傳送數(shù)據(jù)214352023/8/833SSL握手的詳細(xì)過(guò)程第一步：客戶發(fā)出一個(gè)帶有客戶HELLO信息的連接請(qǐng)求。這信息包括：①想要使用的SSL版本號(hào)。②時(shí)間信息，以標(biāo)準(zhǔn)的UNIX32位格式標(biāo)識(shí)的現(xiàn)時(shí)和日期。③會(huì)話標(biāo)識(shí)〔可選〕，如果沒有指定的話，那么效勞器便重用上一次的會(huì)話標(biāo)識(shí)或返回一個(gè)錯(cuò)誤信息④密文組〔客戶方所支持的各種加密算法選項(xiàng)清單。包括認(rèn)證碼、密鑰交換方法、加密和MAC算法〕。⑤客戶方所支持的壓縮算法。⑥隨機(jī)數(shù)。2023/8/834SSL握手的詳細(xì)過(guò)程第二步：效勞器評(píng)估客戶方發(fā)來(lái)的HELLO信息中的各項(xiàng)參數(shù)，并且返回一個(gè)效勞器方的HELLO信息，其中含有效勞器選來(lái)用于SSL會(huì)話的各項(xiàng)參數(shù)〔版本號(hào)、時(shí)間信息、以標(biāo)準(zhǔn)的UNIX32位格式標(biāo)識(shí)的現(xiàn)時(shí)和日期、會(huì)話標(biāo)識(shí)、密文組、壓縮方法、隨機(jī)數(shù)〕。在效勞器HELLO信息之后，效勞器發(fā)出如下信息：①效勞器證書，如果效勞器需要被鑒別的話。②效勞器密鑰交換信息，如果得不到證書或證書僅僅用作簽名的話。③證書請(qǐng)求，如果客戶要求被鑒別的話。最后，效勞器發(fā)出一個(gè)效勞器HELLODONE信息，開始等待客戶的回音。2023/8/835SSL握手的詳細(xì)過(guò)程第三步：客戶發(fā)送以下信息：①如果效勞器發(fā)出了一個(gè)證書請(qǐng)求，那么客戶方必須發(fā)送一個(gè)證書或非證書信息。②如果效勞器發(fā)送了一個(gè)效勞器密鑰交換信息，那么客戶方就發(fā)送一個(gè)基于公鑰算法的由HELLO信息決定的密鑰交換信息。③如果客戶方已經(jīng)發(fā)送了一個(gè)證書，那么客戶方就需驗(yàn)證效勞器方的證書并且發(fā)出一個(gè)證書驗(yàn)證信息指明結(jié)果。然后，客戶方發(fā)出一個(gè)結(jié)束信息，指出協(xié)商過(guò)程已經(jīng)完成。客戶方還發(fā)送一個(gè)修改密文規(guī)約信息來(lái)產(chǎn)生共享的常規(guī)密鑰。應(yīng)該注意這局部工作不是由握手協(xié)議控制，是由修改密文規(guī)約協(xié)議管理的。2023/8/836SSL握手的詳細(xì)過(guò)程第四步：效勞器發(fā)出一個(gè)結(jié)束信息指出協(xié)商協(xié)商階段完成。然后效勞器發(fā)出一個(gè)密文修改規(guī)約信息。第五步：會(huì)話雙方分別產(chǎn)生一個(gè)加密密鑰，然后他們?cè)俑鶕?jù)這些密鑰導(dǎo)出會(huì)話主密鑰。握手協(xié)議改變狀態(tài)至連接狀態(tài)。所有從應(yīng)用層的來(lái)的數(shù)據(jù)傳輸作為特定信息傳輸給對(duì)方。2023/8/8377.3.6TLS協(xié)議傳輸層平安TLS(TransportLayerSecurity)協(xié)議是IETF正在定義一種新的協(xié)議。它建立在Netscape所提出的SSL3.0協(xié)議標(biāo)準(zhǔn)根底上。兩個(gè)互相不知其代碼的應(yīng)用程序可用TLS來(lái)平安地通信。

2023/8/838

SSL協(xié)議應(yīng)用一個(gè)使用WEB客戶機(jī)和效勞器的范例WEB客戶機(jī)通過(guò)連接到一個(gè)支持SSL的效勞器，啟動(dòng)一次SSL會(huì)話。支持SSL的典型WEB效勞器在一個(gè)與標(biāo)準(zhǔn)HTTP請(qǐng)求〔默認(rèn)為端口80〕不同的端口〔默認(rèn)為443〕上接受SSL連接請(qǐng)求。當(dāng)客戶機(jī)連接到這個(gè)端口上時(shí)，它將啟動(dòng)一次建立SSL會(huì)話的握手。當(dāng)握手完成之后，通信內(nèi)容被加密，并且執(zhí)行消息完整性檢查，直到SSL會(huì)話過(guò)期。SSL創(chuàng)立一個(gè)會(huì)話，在此期間，握手必須只發(fā)生過(guò)一次。2023/8/839步驟1：SSL客戶機(jī)連接到SSL效勞器，并要求效勞器驗(yàn)證它自身的身份。步驟2：效勞器通過(guò)發(fā)送它的數(shù)字證書證明其身份。這個(gè)交換還可以包括整個(gè)證書鏈，直到某個(gè)根證書權(quán)威機(jī)構(gòu)(CA)。通過(guò)檢查有效日期并確認(rèn)證書包含有可信任CA的數(shù)字簽名，來(lái)驗(yàn)證證書。步驟3：效勞器發(fā)出一個(gè)請(qǐng)求，對(duì)客戶端的證書進(jìn)行驗(yàn)證。但是，因?yàn)槿狈€體系結(jié)構(gòu)，當(dāng)今的大多數(shù)效勞器不進(jìn)行客戶端認(rèn)證。2023/8/840步驟4：協(xié)商用于加密的消息加密算法和用于完整性檢查的哈希函數(shù)。通常由客戶機(jī)提供它支持的所有算法列表，然后由效勞器選擇最強(qiáng)健的加密算法。步驟5：客戶機(jī)和效勞器通過(guò)以下步驟生成會(huì)話密鑰：a.客戶機(jī)生成一個(gè)隨機(jī)數(shù)，并使用效勞器的公鑰〔從效勞器的證書中獲得〕對(duì)它加密，發(fā)送到效勞器上。b.效勞器用更加隨機(jī)的數(shù)據(jù)〔從客戶機(jī)的密鑰可用時(shí)那么使用客戶機(jī)密鑰；否那么以明文方式發(fā)送數(shù)據(jù)〕響應(yīng)。c.使用哈希函數(shù)，從隨機(jī)數(shù)據(jù)生成密鑰。2023/8/841SSL協(xié)議的優(yōu)點(diǎn)機(jī)密性即連接是私有的。在初始握手階段，雙方建立對(duì)稱密鑰后，信息即用該密鑰加密。完整性在信息中嵌入信息鑒別碼〔MAC〕來(lái)保證信息的完整性。其中使用了平安哈希函數(shù)〔例如SHA和MD5〕來(lái)進(jìn)行MAC計(jì)算。鑒別在握手階段，客戶鑒別效勞器用不對(duì)稱密鑰或公開密鑰。2023/8/842SSL協(xié)議的缺乏SSL要求對(duì)每個(gè)數(shù)據(jù)進(jìn)行加密和解密操作，因而在帶來(lái)高性能的同時(shí)，對(duì)系統(tǒng)也要求高資源開銷。SSL協(xié)議主要是使用公開密鑰體制和X.509數(shù)字證書技術(shù)保護(hù)信息傳輸?shù)臋C(jī)密性和完整性，它不能保證信息的不可抵賴性，主要適用于點(diǎn)對(duì)點(diǎn)之間的信息傳輸，常用WebServer方式。SSL為帶有平安功能的TCP/IP套接字應(yīng)用程序接口提供了一個(gè)替代的方法，理論上，在SSL之上可以平安方式運(yùn)行任何原有TCP/IP應(yīng)用程序而不需修改，但實(shí)際上，SSL目前還只是用在HTTP連接上。2023/8/8437.4IPSec協(xié)議由于協(xié)議IPv4最初設(shè)計(jì)時(shí)沒有過(guò)多地考慮平安性，缺乏對(duì)通信雙方真實(shí)身份的驗(yàn)證能力，缺乏對(duì)網(wǎng)上傳輸?shù)臄?shù)據(jù)的完整性和機(jī)密性保護(hù)，并且由于IP地址可軟件配置等靈活性以及基于源IP地址的認(rèn)證機(jī)制，使IP層存在著網(wǎng)絡(luò)業(yè)務(wù)流易被監(jiān)聽和捕獲、IP地址欺騙、信息泄漏和數(shù)據(jù)項(xiàng)被篡改等多種攻擊，而IP是很難抵抗這些攻擊的。為了實(shí)現(xiàn)平安IP，因特網(wǎng)工程任務(wù)組IETF于1994年開始了一項(xiàng)IP平安工程，專門成立了IP平安協(xié)議工作組IPSEC，來(lái)制定和推動(dòng)一套稱為IPSec的IP平安協(xié)議標(biāo)準(zhǔn)。

2023/8/844IPSec協(xié)議組網(wǎng)絡(luò)認(rèn)證協(xié)議AuthenticationHeader〔AH〕封裝平安載荷協(xié)議EncapsulatingSecurityPayload〔ESP〕密鑰管理協(xié)議InternetKeyExchange〔IKE〕網(wǎng)絡(luò)認(rèn)證及加密算法2023/8/845IPSec平安體系結(jié)構(gòu)圖7.8IPSec平安體系結(jié)構(gòu)IPSec體系結(jié)構(gòu)ESP協(xié)議AH協(xié)議加密算法DOI密鑰管理認(rèn)證算法2023/8/846ESP協(xié)議規(guī)定了為通信提供機(jī)密性和完整性保護(hù)的具體方案，包括ESP載荷的格式、語(yǔ)義、取值以及對(duì)進(jìn)入分組和外出分組的處理過(guò)程等。DOI〔InterpretationofDomain，DOI〕規(guī)定了每個(gè)算法的參數(shù)要求和計(jì)算規(guī)那么，如算法的密鑰長(zhǎng)度要求、算法強(qiáng)度要求以及初始向量的計(jì)算規(guī)那么等。AH協(xié)議定義了認(rèn)證的應(yīng)用方法，提供數(shù)據(jù)源認(rèn)證和完整性保證。IKE協(xié)議是IPSec目前唯一的正式確定的密別交換協(xié)議，為AH和ESP提供密鑰交換支持，同時(shí)也支持其他機(jī)制，如密鑰協(xié)商。2023/8/847平安關(guān)聯(lián)〔SecurityAssociation，SA〕為了正確封裝及提取IPSec數(shù)據(jù)包，有必要采取一套專門的方案，將平安效勞/密鑰與要保護(hù)的通信數(shù)據(jù)聯(lián)系到一起；同時(shí)要將遠(yuǎn)程通信實(shí)體與要交換密鑰的IPSec數(shù)據(jù)傳輸聯(lián)系到一起。換言之，要解決如何保護(hù)通信數(shù)據(jù)、保護(hù)什么樣的通信數(shù)據(jù)以及由誰(shuí)來(lái)實(shí)行保護(hù)的問(wèn)題。這樣的構(gòu)建方案稱為平安關(guān)聯(lián)〔SecurityAssociation，SA〕。2023/8/848SA是單向的，要么對(duì)數(shù)據(jù)包進(jìn)行“進(jìn)入〞保護(hù)，要么進(jìn)行“外出〞保護(hù)。也就是說(shuō)，在一次通信中，IPSec需要建立兩個(gè)SA，一個(gè)用于入站通信，另一個(gè)用于出站通信。假設(shè)某臺(tái)主機(jī)，如文件效勞器或遠(yuǎn)程訪問(wèn)效勞器，需要同時(shí)與多臺(tái)客戶機(jī)通信，那么該效勞器需要與每臺(tái)客戶機(jī)分別建立不同的SA。

2023/8/8497.4.2AH〔AuthenticationHeader〕協(xié)議AH協(xié)議規(guī)定了AH頭在AH實(shí)現(xiàn)中應(yīng)插入IP頭的位置、AH頭的語(yǔ)法格式、各字段的語(yǔ)義及取值方式，以及實(shí)施AH時(shí)進(jìn)入和外出分組的處理過(guò)程。AH機(jī)制涉及到密碼學(xué)中的核心組件——鑒別算法。

AH的功能AH的兩種模式AH的格式

認(rèn)證算法2023/8/850AH的功能AH協(xié)議為IP通信提供數(shù)據(jù)源認(rèn)證、數(shù)據(jù)完整性和反重播保證，它能保護(hù)通信免受篡改，但不能防止竊聽，適合用于傳輸非機(jī)密數(shù)據(jù)。AH的工作原理是在每一個(gè)數(shù)據(jù)包上添加一個(gè)身份驗(yàn)證報(bào)頭。此報(bào)頭包含一個(gè)帶密鑰的hash散列〔可以將其當(dāng)作數(shù)字簽名，只是它不使用證書〕，此hash散列在整個(gè)數(shù)據(jù)包中計(jì)算，因此對(duì)數(shù)據(jù)的任何更改將致使散列無(wú)效——這樣就提供了完整性保護(hù)。AH不能提供加密效勞，這就意味著分組將以明文的形式傳送。由于AH的速度比ESP稍微快一點(diǎn)，因此僅當(dāng)需要確保分組的源和完整性而不考慮機(jī)密性的時(shí)候，可以選擇使用AH。2023/8/851AH的兩種模式傳輸模式：傳輸模式用于兩臺(tái)主機(jī)之間，只對(duì)上層協(xié)議數(shù)據(jù)〔傳輸層數(shù)據(jù)〕和IP頭中的固定字段提供認(rèn)證，主要保護(hù)傳輸層協(xié)議頭，實(shí)現(xiàn)端到端的平安；隧道模式：隧道模式對(duì)整個(gè)IP數(shù)據(jù)項(xiàng)提供認(rèn)證保護(hù)，把需要保護(hù)的IP包封裝在新的IP包中，既可用于主機(jī)也可用于平安網(wǎng)關(guān)，并且當(dāng)AH在平安網(wǎng)關(guān)上實(shí)現(xiàn)時(shí)，必須采用隧道模式。2023/8/852圖7.9AH傳輸模式圖7.10AH隧道模式2023/8/853AH的格式圖7.11AH報(bào)頭格式

下一個(gè)報(bào)頭長(zhǎng)度安全參數(shù)索引(SPI)序列號(hào)認(rèn)證數(shù)據(jù)(hash檢查和)AH報(bào)頭2023/8/854NextHeader〔下一個(gè)報(bào)頭，占8字節(jié)〕：識(shí)別下一個(gè)使用IP協(xié)議號(hào)的報(bào)頭，例如，NextHeader值等于6時(shí)，表示緊接其后的是TCP報(bào)頭。對(duì)于UDP，它的值將是17。Length〔長(zhǎng)度，占8字節(jié)〕：AH報(bào)頭長(zhǎng)度。SecurityParametersIndex(SPI，平安參數(shù)索引，占32字節(jié))：這是一個(gè)為數(shù)據(jù)報(bào)識(shí)別平安關(guān)聯(lián)的32位偽隨機(jī)值。其中，SPI值0被保存，用來(lái)說(shuō)明“沒有平安關(guān)聯(lián)存在〞。2023/8/855SequenceNumber〔序列號(hào)，占32字節(jié)〕：這是一個(gè)無(wú)符號(hào)單調(diào)遞增的計(jì)數(shù)器，從1開始的32位單增序列號(hào)，不允許重復(fù)，唯一地標(biāo)識(shí)了每一個(gè)發(fā)送數(shù)據(jù)包，為平安關(guān)聯(lián)提供反重播保護(hù)。接收端校驗(yàn)序列號(hào)為該字段值的數(shù)據(jù)包是否已經(jīng)被接收過(guò)，假設(shè)是，那么拒收該數(shù)據(jù)包。對(duì)于一個(gè)特定的SA，它實(shí)現(xiàn)反重傳效勞。這些信息不被接收對(duì)等實(shí)體使用，但是發(fā)送方必須包含這些信息。當(dāng)建立一個(gè)SA時(shí)，這個(gè)值被初始化為0。如果使用反重傳效勞重傳，那么這個(gè)值決不允許重復(fù)。由于發(fā)送方并不知道接受方是否使用了反重傳功能，該字段中的值不能被重復(fù)的事實(shí)就要求終止SA，并且在傳送第23個(gè)分組之前建立一個(gè)新的SA。2023/8/856AuthenticationData〔AD，認(rèn)證數(shù)據(jù)，可變長(zhǎng)〕：包含完整性檢查和。接收端接收數(shù)據(jù)包后，首先執(zhí)行hash計(jì)算，再與發(fā)送端所計(jì)算的該字段值比較，假設(shè)兩者相等，表示數(shù)據(jù)完整，假設(shè)在傳輸過(guò)程中數(shù)據(jù)遭修改，兩個(gè)計(jì)算結(jié)果不一致，那么丟棄該數(shù)據(jù)包。通過(guò)這個(gè)值，通信雙方能實(shí)現(xiàn)對(duì)數(shù)據(jù)的完整性保護(hù)、分組級(jí)數(shù)據(jù)源鑒別以及通信的抗重放攻擊。2023/8/857認(rèn)證算法用于計(jì)算完整性校驗(yàn)值(ICV)的認(rèn)證算法由SA指定，對(duì)于點(diǎn)到點(diǎn)通信，適宜的認(rèn)證算法包括基于對(duì)稱密碼算法(如DES)或基于單向Hash函數(shù)(如MD5或SHA-1)的帶密鑰的消息認(rèn)證碼(MAC)。2023/8/8587.4.3ESP〔EncapsulatingSecurityPayload〕協(xié)議ESP涉及到密碼學(xué)中的核心組件——加密和鑒別算法。

ESP的功能ESP的兩種模式ESP的格式加密算法和認(rèn)證算法ESP處理2023/8/859ESP的功能ESP為IP數(shù)據(jù)包提供完整性檢查、認(rèn)證和加密，可以看作是“超級(jí)AH〞，因?yàn)樗峁C(jī)密性并可防止篡改。ESP效勞依據(jù)建立的平安關(guān)聯(lián)〔SA〕是可選的。一些限制：·完整性檢查和認(rèn)證一起進(jìn)行?！H當(dāng)與完整性檢查和認(rèn)證一起時(shí)，“重播〔Replay〕〞保護(hù)才是可選的。·“重播〞保護(hù)只能由接收方選擇。ESP的加密效勞是可選的，但如果啟用加密，那么也就同時(shí)選擇了完整性檢查和認(rèn)證。因?yàn)槿绻麅H使用加密，入侵者就可能偽造包以發(fā)動(dòng)密碼分析攻擊。ESP可以單獨(dú)使用，也可以和AH結(jié)合使用。2023/8/860ESP的兩種模式圖7.12ESP傳輸模式圖7.13ESP隧道模式2023/8/861ESP的格式ESP協(xié)議包括ESP報(bào)頭、ESP報(bào)尾、ESP認(rèn)證報(bào)尾三個(gè)局部。圖7.14ESP報(bào)頭、報(bào)尾和認(rèn)證報(bào)尾

2023/8/862加密算法和認(rèn)證算法ESP所采用的加密算法由SA指定。為了提高加密效率，ESP設(shè)計(jì)使用的是對(duì)稱密碼算法。由于IP包可能會(huì)失序到達(dá)，因此每個(gè)IP包必須攜帶接收者進(jìn)行解密所要求的密碼同步數(shù)據(jù)(如初始化向量IV)。這個(gè)數(shù)據(jù)可以在有效負(fù)載字段中明確攜帶，也可以從包頭中推導(dǎo)出來(lái)。由于機(jī)密性是可選擇的，因此加密算法可以是“空〞。ESP中的認(rèn)證算法同AH的認(rèn)證算法一樣。由于認(rèn)證算法是可選的，因此認(rèn)證算法也可以是“空〞。雖然加密和認(rèn)證算法都可為空，但二者不能同時(shí)為空。因?yàn)檫@樣做不僅毫無(wú)平安保證可言，而且也為系統(tǒng)帶來(lái)了無(wú)謂的負(fù)擔(dān)。2023/8/863ESP處理

ESP的處理過(guò)程發(fā)生在發(fā)送時(shí)的IP分割之前以及接受時(shí)的IP重新組合之后。發(fā)送時(shí)的處理①ESP頭定位：在傳輸模式下，ESP頭插在IP頭和上一層協(xié)議頭之間；在隧道模式下，ESP頭在整個(gè)源IP數(shù)據(jù)項(xiàng)之前。②查找：只有當(dāng)與此會(huì)話相關(guān)的有效的SA存在時(shí)，才進(jìn)行ESP處理。③包加密：把數(shù)據(jù)封裝到ESP的有效負(fù)載字段，在傳輸模式下，只封裝上層協(xié)議數(shù)據(jù)；在隧道模式下、封裝整個(gè)原IP數(shù)據(jù)項(xiàng)。應(yīng)使用由SA指定的密鑰和加密算法對(duì)上述結(jié)果加密。2023/8/864接受時(shí)的處理過(guò)程當(dāng)接收方收到一個(gè)IP數(shù)據(jù)項(xiàng)時(shí)，先根據(jù)包中目的IP地址、平安協(xié)議ESP和SPI查找SA，假設(shè)沒有用于此會(huì)話的SA存在，那么接收者必須丟棄此包，并記入日志，否那么就按SA中指定的算法進(jìn)行解密并重新構(gòu)造原IP數(shù)據(jù)項(xiàng)格式。2023/8/8657.4.4IKE〔InternetKeyExchange〕協(xié)議IKE主要完成兩個(gè)作用：①平安關(guān)聯(lián)的集中化管理，減少連接時(shí)間；②密鑰的生成和管理。IKE協(xié)議是IPSec目前唯一的正式確定的密鑰交換協(xié)議，它為AH和ESP提供密鑰交換支持，同時(shí)也支持其他機(jī)制，加密鑰協(xié)商。IKE是由另外三種協(xié)議〔ISAKMP、Oakley和SKEME〕混合而成的一種協(xié)議。2023/8/866PGP——PrettyGoodPrivacy(相當(dāng)好的保密)是由MIT的P.R.Zimmerrmann提出的，主要用于平安電子郵件，它可以對(duì)通過(guò)網(wǎng)絡(luò)進(jìn)行傳輸?shù)臄?shù)據(jù)創(chuàng)立和檢驗(yàn)數(shù)字簽名、加密、解密以及壓縮。

7.5PGP2023/8/867表7.1PGP的功能

功能使用的算法解釋說(shuō)明保密性IDEA、CAST或三重DES，Diffie-Hellman或RSA發(fā)送者產(chǎn)生一次性會(huì)話密鑰，用會(huì)話密鑰以IDEA或CAST或三重DES加密消息，并用接收者的公鑰以Diffie-Hellman或RSA加密會(huì)話密鑰簽名RSA或DSS，MD5或SHA用MD5或SHA對(duì)消息散列并用發(fā)送者的私鑰加密消息摘要壓縮ZIP使用ZIP壓縮消息，以便于存儲(chǔ)和傳輸E-mail兼容性Radix64交換對(duì)E-mail應(yīng)用提供透明性，將加密消息用Radix64變換成ASCII字符串分段功能-為適應(yīng)最大消息長(zhǎng)度限制，PGP實(shí)行分段并重組2023/8/8687.5.1鑒別

圖7.15〔a〕PGP的操作過(guò)程——只進(jìn)行鑒別其中，圖7.15記號(hào)的含義為：Ks:會(huì)話密鑰EP:公鑰加密Kra:用戶A的私鑰DP:公鑰解密KUa:用戶A的公鑰EC:常規(guī)加密H:散列函數(shù)DC:常規(guī)解密||:連接

Z:用ZIP算法進(jìn)行數(shù)據(jù)壓縮R64:用radix64轉(zhuǎn)換到ASCII格式Z-1：解壓縮MMHEPH||ZZ-1DP比較EKRa[H(M)]KRaKUa發(fā)送者A接收者B2023/8