網絡安全協(xié)議北京大學計算機系信息安全室_第1頁
網絡安全協(xié)議北京大學計算機系信息安全室_第2頁
網絡安全協(xié)議北京大學計算機系信息安全室_第3頁
網絡安全協(xié)議北京大學計算機系信息安全室_第4頁
網絡安全協(xié)議北京大學計算機系信息安全室_第5頁
已閱讀5頁,還剩73頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1

信息安全原理與應用第十一章網絡安全協(xié)議本章由王昭主寫2內容提要網絡協(xié)議安全簡介網絡層安全傳輸層安全3TCP/IP協(xié)議棧

4Internet安全性途徑網絡層——IP安全性(IPsec)傳輸層——SSL/TLS應用層——S/MIME,PGP,PEM,SET,Kerberos,SHTTP,SSH5應用層安全應用層安全必須在終端主機上實施,優(yōu)點以用戶為背景執(zhí)行,更容易訪問用戶憑據(jù)對用戶想保護的數(shù)據(jù)具有完整的訪問權應用可以自由擴展應用程序對數(shù)據(jù)有著充分的理解缺點針對每個應用須設計一套安全機制6傳輸層安全優(yōu)點不會強制要求每個應用都在安全方面作出相應改進缺點由于要取得用戶背景,通常假定只有一名用戶使用系統(tǒng),與應用級安全類似,只能在端系統(tǒng)實現(xiàn)應用程序仍需要修改,才能要求傳輸層提供安全服務7網絡層安全優(yōu)點密鑰協(xié)商的開銷被大大削減了需要改動的應用程序要少得多能很容易構建VPN缺點很難解決“抗抵賴”之類的問題8數(shù)據(jù)鏈路層最大的好處在于速度不易擴展在ATM上得到廣泛應用9網絡層安全

10傳輸層安全

11應用層安全12內容提要TCP/IP基礎網絡層安全傳輸層安全用戶數(shù)據(jù)經過過協(xié)議棧的封封裝過程IPv4數(shù)據(jù)報15IPv6分組16IPv6基本頭17IP協(xié)議IP是TCP/IP協(xié)議族中至關關重要的組成成部分,但它提供的是是一種不可靠靠、無連接的的的數(shù)據(jù)報傳傳輸服務。不可靠(unreliable):不能保證一一個IP數(shù)據(jù)報成功地地到達其目的的地。無連接(connectionless):IP并不維護關于于連續(xù)發(fā)送的的數(shù)據(jù)報的任任何狀態(tài)信息息。18IPv4的缺陷缺乏對通信雙雙方身份真實實性的鑒別能能力缺乏對傳輸數(shù)數(shù)據(jù)的完整性性和機密性保保護的機制IP的分組和重組組機制不完善善由于IP地址可軟件配配置,IP地址的表示不不需要真實并并確認真假,,以及基于源源IP地址的鑒別機機制,IP層存在:業(yè)務流被監(jiān)聽聽和捕獲、IP地址欺騙、信信息泄露和數(shù)數(shù)據(jù)項篡改等等攻擊、IP碎片攻擊,源源路由攻擊,,IP包偽造,PingFlooding和PingofDeath等大量的攻擊擊19IPsec網絡層安全性性需求:身份鑒鑒別、數(shù)據(jù)完完整性和保密密性好處:對于應應用層透明彌補IPv4在協(xié)議設計時時缺乏安全性性考慮的不足足20IPsec的歷史1994年IETF專門成立IP安全協(xié)議工作組,來制定和推動一一套稱為IPsec的IP安全協(xié)議標準準。1995年8月公布了一系系列關于IPSec的建議標準1996年,IETF公布下下一代代IP的標準準IPv6,把鑒鑒別和和加密密作為為必要要的特特征,,IPsec成為其其必要要的組組成部部分1999年底,,IETF安全工工作組組完成成了IPsec的擴展展,在在IPSec協(xié)議中中加上上ISAKMP(InternetSecurityAssociationandKeyManagementProtocol)協(xié)議,,密鑰鑰分配配協(xié)議議IKE、Oakley。ISAKMP/IKE/Oakley支持自自動建建立加加密、、鑒別別信道道,以以及密密鑰的的自動動安全全分發(fā)發(fā)和更更新。。2005年底,,對IPsec所采用用和支支持的的算法法等特特性又又進行行了新新的修修訂,,公布布了一一系列列新的的IPsec標準。。21IPsec的應用用方式式端到端端(end-end)::主機到到主機機的安安全通通信端到路路由((end-router)):主機到到路由由設備備之間間的安安全通通信路由到到路由由(router-router)::路由設設備之之間的的安全全通信信,常常用于于在兩兩個網網絡之之間建建立虛虛擬私私有網網(VPN)。IPsec的文檔檔IPsec包含三三個系系列的的文檔檔:第一系系列的的文檔檔重要要的有有1995年發(fā)布布的RFC1825、RFC1826、RFC1827、RFC1827、RFC1829。第二系系列的的文檔檔包括括1998年發(fā)布布的RFC2401~RFC2412,重要要的有有RFC2401、RFC2402、RFC2406和RFC2408。最新系系列的的文檔檔發(fā)布布于2005年,包包括RFC4301~RFC4309。22最新系系列IPsec文檔的的組成成24IPsec的內容容協(xié)議部部分,,分為為AH:AuthenticationHeaderESP:EncapsulatingSecurityPayload密鑰管管理(KeyManagement)SA(SecurityAssociation)IKEv2是目前前正式式確定定用于于IPsec的密鑰鑰交換換協(xié)議議25說明IPSec在IPv6中是強強制的的,在在IPv4中是可可選的的,這兩種種情況況下都都是采采用在在主IP報頭后后面接接續(xù)擴擴展報報頭的的方法法實現(xiàn)現(xiàn)的。。AH(AuthenticationHeader)是鑒別別的擴擴展報報頭ESPheader(EncapsulatingSecurityPayload)是實現(xiàn)現(xiàn)加密密和鑒鑒別(可選)的擴展展報頭頭26安全關關聯(lián)SA(SecurityAssociation)SA是IP鑒別和和保密密機制制中最最關鍵鍵的概概念。。一個關關聯(lián)就就是發(fā)發(fā)送與與接收收者之之間的的一個個單向向關系系,是與與給定定的一一個網網絡連連接或或一組組網絡絡連接接相關關聯(lián)的的安全全信息息參數(shù)數(shù)集合合如果需需要一一個對對等關關系,,即雙雙向安安全交交換,,則需需要兩兩個SA。每個SA通過三三個參參數(shù)來來標識識<spi,dst(src),protocol>安全參參數(shù)索索引SPI(SecurityParametersIndex)對方IP地址安全協(xié)協(xié)議標標識:AHorESP27SAD定義了了SA參數(shù)序號計計數(shù)器器:一一個64位值,,用于于生成成AH或ESP頭中的的序號號字段段;計數(shù)器器溢出出位::一個個標志志位表表明該該序數(shù)數(shù)計數(shù)數(shù)器是是否溢溢出,,如果果是,,將生生成一一個審審計事事件,,并禁禁止本本SA的的分分組繼繼續(xù)傳傳送。。抗重放放窗口口:用用于確確定一一個入入站的的AH或ESP包是否否是重重放AH信息::鑒別別算法法、密密鑰、、密鑰鑰生存存期以以及相相關參參數(shù)ESP信息::加密密和鑒鑒別算算法、、密鑰鑰、初初始值值、密密鑰生生存期期、以以及相關參數(shù)SA的生存存期::一個個時間間間隔隔或字字節(jié)計計數(shù),,到時時間后后,一個個SA必須用用一個個新的的SA替換或或終止止,并并指示示哪個個操作作發(fā)生生的指指示。。IPSec協(xié)議模模式::隧道道、傳輸路徑MTU:不經經分片片可傳傳送的的分組組最大大長度度和老老化變變量28AH(AuthenticationHeader)為IP包提供供數(shù)據(jù)據(jù)完整整性和和鑒別別功能能利用MAC碼實現(xiàn)現(xiàn)鑒別別,雙雙方必必須共共享一一個密密鑰鑒別算算法由由SA指定鑒別的的范圍圍:整整個包包兩種鑒鑒別模模式::傳輸模模式::不改改變IP地址,,插入入一個個AH隧道模模式::生成成一個個新的的IP頭,,把把AH和原原來來的的整整個個IP包放放到到新新IP包的的凈凈荷荷數(shù)數(shù)據(jù)據(jù)中中IPsecAuthenticationHeader2930AH處理理過過程程(1)AH定位位在IP頭之之后后,,在在上上層層協(xié)協(xié)議議數(shù)數(shù)據(jù)據(jù)之之前前鑒別別算算法法計算算ICV或者者MAC對于于發(fā)發(fā)出出去去的的包包(OutboundPacket)的處處理理,,構構造造AH查找找SA產生生序序列列號號計算算ICV(IntegrityCheckValue)內容容包包括括::IP頭中中部部分分域域、、AH自身身、、上上層層協(xié)協(xié)議議數(shù)數(shù)據(jù)據(jù)分片片31AH處理理過過程程(2)對于于接接收收到到的的包包(InboundPacket)的處處理理分片片裝裝配配查找找SA依據(jù)據(jù)::目目標標IP地址址、、AH協(xié)議議、、SPI檢查查序序列列號號(可選選,,針針對對重重放放攻攻擊擊)使用用一一個個滑滑動動窗窗口口來來檢檢查查序序列列號號的的重重放放ICV檢查查ICV/MAC計算算MAC計算算所所有有變變化化的的字字段段填填0后后參參與與運運算算源和和目目的的地地址址都都是是受受保保護護的的,,可可防防地地址址欺欺騙騙ICV/MAC算法法RFC4305規(guī)定定必必須須實實現(xiàn)現(xiàn)的的完完整整性性算算法法是是HMAC-SHA1-96[RFC2404],應應該該實實現(xiàn)現(xiàn)的的完完整整性性算算法法是是AES-XCBC-MAC-96[RFC3566],可可以以實實現(xiàn)現(xiàn)HMAC-MD5-96[RFC2403]。HMAC-SHA1-96和HMAC-MD5-96都使使用用了了基基于于SHA-1或者者MD5的HMAC算法法,,計計算算全全部部HMAC值,,然然后后取取前前96位。。AES-XCBC-MAC-96算法是使使用1個1和多個0填充的基基本CBC-MAC的變體,,AES-XCBC-MAC-96的計算使使用128位密鑰長長度的AES。3334AH兩種模式式示意圖圖IPv435AH兩種模式式示意圖圖IPv636ESP(EncapsulatingSecurityPayload)提供保密密功能,,包括報報文內容容的機密密性和有有限的通通信量的的機密性性,也可可以提供供鑒別服服務(可可選)將需要保保密的用用戶數(shù)據(jù)據(jù)進行加加密后再再封裝到到一個新新的IP包中,ESP只鑒別ESP頭之后的的信息加密算法法和鑒別別算法由由SA指定也有兩種種模式::傳輸模模式和隧隧道模式式37IPsecESP格式ESP的算法和和實現(xiàn)要要求3839ESP的傳輸模模式40ESP隧道模式式41ESP處理過程程(1)ESP頭定位加密算法法和鑒別別算法由由SA確定對于發(fā)出出去的包包(OutboundPacket)的處理查找SA加密封裝必要要的數(shù)據(jù)據(jù),放到到payloaddata域中不不同的模模式,封封裝數(shù)據(jù)據(jù)的范圍圍不同增加必要要的padding數(shù)據(jù)加密操作作產生序列列號計算ICV,注意,,針對加加密后的的數(shù)據(jù)進進行計算算分片42ESP處理過程程(2)對于接收收到的包包(InboundPacket)的處理分片裝配配查找SA依據(jù):目目標IP地址、ESP協(xié)議、SPI檢查序列列號(可選,針針對重放放攻擊)使用一個個滑動窗窗口來檢檢查序列列號的重重放ICV檢查解密根據(jù)SA中指定的的算法和和密鑰、、參數(shù),,對于被被加密部部分的數(shù)數(shù)據(jù)進行行解密去掉padding重構原始始的IP包43SA的組合(1)特定的的通信量量需要同同時調用用AH和ESP服務(2)特定的的通信量量需要主主機之間間和防火火墻之間間的服務務傳輸鄰接接:同一一分組應應用多種種協(xié)議,,不形成成隧道循環(huán)嵌套套:通過過隧道實實現(xiàn)多級級安全協(xié)協(xié)議的應應用44鑒別與機機密性的的組合帶有鑒別別選項的的ESP傳輸鄰接接使用兩個個捆綁的的傳輸SA,內部是是ESPSA(沒有鑒鑒別選項項),外外部是AHSA傳輸隧道道束加密之前前進行鑒鑒別更可可取內部的AH傳輸SA+外部的ESP隧道SA45IPsec密鑰管理包括密鑰的確確定和分配。。兩種方式:手工的自動的:Internet密鑰交換IKE(非IPSec專用)作用:在IPsec通信雙方之間間,建立起共共享安全參數(shù)數(shù)及驗證過的的密鑰(建立立“安全關聯(lián)聯(lián)”),IKE代表IPsec對SA進行協(xié)商,并并對SAD數(shù)據(jù)庫進行填填充46IPsec小結IPsec在網絡層上提提供安全服務務定義了兩個協(xié)協(xié)議AH和ESPIKE提供了密鑰交交換功能通過SA把兩部分連接接起來已經發(fā)展成為為Internet標準一些困難IPsec太復雜協(xié)議復雜性,,導致很難達達到真正的安安全性管理和配置復復雜,使得安安全性下降實現(xiàn)上的兼容容性攻擊:DOS,網絡層之下下的協(xié)議、之之上的協(xié)議的的弱點還在進一步完完善47內容提要TCP/IP基礎網絡層安全傳輸層安全48傳輸層安全傳輸層介紹傳輸層的安全全性49傳輸層介紹傳輸層存在兩兩個協(xié)議,傳傳輸控制協(xié)議議(TCP)和用戶數(shù)據(jù)報報協(xié)議(UDP)TCP是一個面向連連接的協(xié)議UDP是一個非面向向連接的協(xié)議議50TCP數(shù)據(jù)包格式TCP包頭TCP包頭的標記區(qū)區(qū)建立和中斷斷一個基本的的TCP連接有三個標記來來完成這些過過程SYN:同步序列號號FIN:發(fā)送端沒有有更多的數(shù)據(jù)據(jù)要傳輸?shù)男判盘朅CK:識別數(shù)據(jù)包包中的確認信信息5152建立一個TCP連接53結束一個TCP連接用戶數(shù)據(jù)報協(xié)協(xié)議(UDP)傳輸層協(xié)議,,為無確認的的數(shù)據(jù)報服務務,只是簡單單地接收和傳傳輸數(shù)據(jù)UDP比TCP傳輸數(shù)據(jù)快5455TCP和UDP的公認端口56傳輸層安全傳輸層介紹傳輸層的安全全性57傳輸層安全措措施依賴于應用(程序)對安全保密的的需求,以及及用戶自己的的需要.必須的安全服服務:密鑰管理機密性抗抵賴完整性/身份驗證授權58SSL/TLS協(xié)議1994年Netscape開發(fā)了SSL(SecureSocketLayer)安全套接層協(xié)協(xié)議,專門用用于保護Web通訊在互聯(lián)網上訪訪問某些網站站時也許你會會注意到在瀏瀏覽器窗口的的下方會顯示示一個鎖的小小圖標。這個個小鎖表示什什么意思呢??它表示該網網頁被SSL/TLS保護著。SSL/TLS被設計用來使使用TCP提供一個可靠靠的端到端安安全服務。為為兩個通訊個個體之間提供供保密性和完完整性(身份鑒別)版本和歷史1.0,不成熟2.0,基本上解決決了Web通訊的安全問問題Microsoft公司發(fā)布了PCT(PrivateCommunicationTechnology),并在IE中支持3.0,1996年發(fā)布,增加加了一些算法法,修改了一一些缺陷TLS1.0(TransportLayerSecurity傳輸層安全協(xié)協(xié)議,也被稱為SSL3.1),1997年IETF發(fā)布了Draft,同時,Microsoft宣布放棄PCT,與Netscape一起支持TLS1.01999年,發(fā)布RFC2246(TheTLSProtocolv1.0)2006年,發(fā)布了RFC4346(TheTLSProtocolv1.1)和RFC4366(TLSExtensions)以取代RFC2246。2008年8月發(fā)布了RFC5246(TheTLSProtocolv1.2)取代RFC3268、RFC4346和RFC4366。5960TLS體系結構61兩個主要的協(xié)協(xié)議TLS記錄協(xié)議建立在可靠的的傳輸協(xié)議(如TCP)之上它提供連接安安全性,有兩兩個特點保密性,使用用了對稱加密密算法完整性,使用用HMAC算法用來封裝高層層的協(xié)議TLS握手協(xié)議客戶和服務器器之間相互鑒鑒別協(xié)商加密算法法和密鑰它提供連接安安全性,有三三個特點身份鑒別,至至少對一方實實現(xiàn)鑒別,也也可以是雙向向鑒別協(xié)商得到的共共享密鑰是安安全的,中間間人不能夠知知道協(xié)商過程是可可靠的62TLS的兩個重要概概念TLS連接(connection))一個連接是一一個提供一種種合適類型服服務的傳輸((OSI分層的定義))。TLS的連接是點對點的關關系。連接是暫時的的,每一個連連接和一個會會話關聯(lián)。TLS會話(session)一個TLS會話是在客戶戶與服務器之之間的一個關關聯(lián)。會話由由HandshakeProtocol創(chuàng)建。會話定定義了一組可可供多個連接接共享的密碼碼安全參數(shù)。。會話用以避免免為每一個連連接提供新的的安全參數(shù)所所需昂貴的協(xié)協(xié)商代價。63會話話狀狀態(tài)態(tài)有多多個個狀狀態(tài)態(tài)與與每每一一個個會會話話相相關關聯(lián)聯(lián)一旦旦一一個個會會話話建建立立,,就就存存在在一一個個讀讀或或寫寫的的當當前前狀狀態(tài)態(tài)在握握手手協(xié)協(xié)議議中中,,創(chuàng)創(chuàng)建建了了掛掛起起的的讀讀寫寫狀狀態(tài)態(tài)成功功的的握握手手協(xié)協(xié)議議,,將將掛掛起起狀狀態(tài)態(tài)轉轉變變?yōu)闉楫敭斍扒盃顮顟B(tài)態(tài)64會話話狀狀態(tài)態(tài)參參數(shù)數(shù)連接接端端點點((connectionend)::一一個個連連接接中中的的客客戶戶端端或或者者服服務務器器端端。。PRF算法法::用用于于從從主主密密鑰鑰推推導導密密鑰鑰的的算算法法。??傮w體加加密密算算法法((bulkencryptionalgorithm)::用用于于加加密密的的算算法法,,須須說說明明算算法法的的密密鑰鑰長長度度、、是是分分組組還還是是流流密密碼碼,,分分組組密密碼碼的的分分組組大大小小。。MAC算法法::用用于于消消息息鑒鑒別別的的算算法法,,須須說說明明MAC算法法輸輸出出的的消消息息鑒鑒別別碼碼的的長長度度。。壓縮縮算算法法((compressionalgorithm)::用用于于數(shù)數(shù)據(jù)據(jù)壓壓縮縮的的算算法法。。主密密鑰鑰((mastersecret)::連連接接雙雙方方共共享享的的48字節(jié)節(jié)秘秘密密值值。??蛻魬舳硕穗S隨機機數(shù)數(shù)((clientrandom),,客客戶戶端端提提供供的的32字節(jié)節(jié)數(shù)數(shù)值值。。服務務器器端端隨隨機機數(shù)數(shù)((serverrandom),服服務器器端提提供的的32字節(jié)數(shù)數(shù)值。。65安全參參數(shù)客戶端端寫MAC秘密值值(clientwriteMACkey):一一個密密鑰,,用來來對client發(fā)送的的數(shù)據(jù)據(jù)進行行MAC操作。。服務器器端寫寫MAC秘密值值(serverwriteMACkey):一一個密密鑰,,用來來對server發(fā)送的的數(shù)據(jù)據(jù)進行行MAC操作。??蛻舳硕藢懨苊荑€((clientwriteencryptionkey):用用于client進行數(shù)數(shù)據(jù)加加密,,server進行數(shù)數(shù)據(jù)解解密的的對稱稱保密密密鑰鑰。服務器器端寫寫密鑰鑰(serverwriteencryptionkey):用用于server進行數(shù)數(shù)據(jù)加加密,,client進行數(shù)數(shù)據(jù)解解密的的對稱稱保密密密鑰鑰。客戶端端寫初初始向向量((clientwriteIV)。服務器器端寫寫初始始向量量(serverwriteIV)。66TLSRecordProtocol具體操操作67TLS記錄協(xié)協(xié)議中中的操操作第一步步,fragmentation上層消消息的的數(shù)據(jù)據(jù)被分分片成成214(16384)字節(jié)大大小的的塊,,或者者更小小第二步步,compression(可選)必須是是無損損壓縮縮,如如果數(shù)數(shù)據(jù)增增加的的話,,則增增加部部分的的長度度不超超過1024字節(jié)68第三步步,MAC計算::使用共共享的的密鑰鑰MAC_write_secretMAC(MAC_write_key,seq_num+TLSCompressed.type+TLSCompressed.version+TLSCompressed.length+TLSCompressed.fragment);其中::MAC_write_secret:共享的的保密密密鑰鑰seq_num:該消息息的序序列號號TLSCompressed.type:更高層層協(xié)議議用于于處理理本分分段TLSCompressed.length:壓縮分分段的的長度度TLSCompressed.fragment:壓縮的的分段段(無壓縮縮時為為明文文段)可供選選擇的的MAC算法有有HMAC-MD5、HMAC-SHA1、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512。69第四步步,加密,可供選選擇的的加密密算法法:BlockCipherStreamCipher128位的流流密碼碼RC4和分組組密碼碼3DES_EDE、128位和256位密鑰鑰的AES。分組組密碼碼采用用CBC模式進進行計計算。。采用CBC,算法法由cipherspec指定說明::如果果是流流密碼碼算法法,則則不需需要paddingTLS記錄格格式內容類類型((ContentType):一一個8位字節(jié)節(jié),封封裝上上層協(xié)協(xié)議的的類型型。協(xié)議主主從版版本號號:兩兩個8位字節(jié)節(jié),如如TLS的版本本號為為{3,3}壓縮長長度::16位,明明文段段的長長度。。70TLS的其他他協(xié)議議修改密密碼規(guī)規(guī)范協(xié)協(xié)議警報協(xié)協(xié)議握手協(xié)協(xié)議71握手消消息的的處理理過程程72TLS握手協(xié)協(xié)議步步驟交換Hello消息,,商定定算法法,交交換

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論