【網(wǎng)絡通信安全管理員認證-中級】IPSEC[詳細]

1、虛擬專用網(wǎng)2,VPN核心技術(shù),一、VPN中的關(guān)鍵技術(shù),隧道 訪問控制 密碼算法 密鑰管理 用戶鑒別 網(wǎng)絡管理,隧道技術(shù),VPN系統(tǒng)被設計成通過Internet提供安全的點到點(或端到端) 的“隧道”。隧道是在公共通信網(wǎng)絡上構(gòu)建的一條數(shù)據(jù)路徑，可以提供與專用通信線路等同的連接特性。 VPN隧道對要傳輸?shù)臄?shù)據(jù)用隧道協(xié)議進行封裝，這樣可以使數(shù)據(jù)穿越公共網(wǎng)絡(通常是指Internet)。 整個數(shù)據(jù)包的封裝和傳輸過程稱為挖隧道。數(shù)據(jù)包所通過的邏輯連接稱為一條隧道。 在VPN中, 數(shù)據(jù)包流由一個LAN上的路由器發(fā)出, 通過共享IP網(wǎng)絡上的隧道進行傳輸,再達到另一個LAN上的路由器。,隧道協(xié)議-數(shù)據(jù)封裝,隧

2、道使用隧道協(xié)議來封裝數(shù)據(jù)。一種協(xié)議X的數(shù)據(jù)報被封裝在協(xié)議Y中，可以實現(xiàn)協(xié)議X在公共網(wǎng)絡的透明傳輸。這里協(xié)議X稱作被封裝協(xié)議，協(xié)議Y稱為封裝協(xié)議。隧道的一般封裝格式為(協(xié)議Y(隧道頭(協(xié)議X)。,隧道協(xié)議,第二層（鏈路層）：PPTP、L2F、L2TP 第三層（網(wǎng)絡層）：IPSec,訪問控制,一般而言，對資源的訪問應在訪問策略的控制下進行。 訪問控制決定了主體是否被授權(quán)對客體執(zhí)行某種操作。 它依賴鑒別對主體的身份認證，將特權(quán)與主體對應起來。 只有經(jīng)鑒別的主體，才允許訪問特定的網(wǎng)絡資源。,密碼算法,VPN中的安全機制本質(zhì)上依托于密碼系統(tǒng)，如各種加密算法、鑒別算法。密碼系統(tǒng)中各種算法的特性、密鑰長度、

3、應用模式不同，直接影響在VPN提供的安全服務的強度。安全強度更高的新算法、各種算法的硬件實現(xiàn)自然代表VPN技術(shù)發(fā)展的趨勢。,密鑰管理,VPN技術(shù)的開放性預示著必須采用各種公開密碼算法，這樣算法的安全強度不能依賴于算法本身，只能依靠密鑰的機密性。大規(guī)模部署VPN，也離不開自動密鑰管理協(xié)議的支持。 VPN系統(tǒng)中常用的幾種密鑰管理協(xié)議包括：IKE協(xié)議、SKIP協(xié)議、Kerberos協(xié)議,用戶鑒別,一種典型的VPN應用是遠程用戶撥號接入（VDPN），與普通的撥號接入不同，VDPN通常需要“二次撥號”：一次接入到當?shù)豂SP的普通撥號，一次完成接入到內(nèi)部網(wǎng)絡的VPN “撥號”。 第二次撥號因為涉及對敏感的

4、內(nèi)部資源的訪問，因此必須采用AAA機制對用戶進行嚴格控制，控制的核心是對用戶的身份鑒別。,網(wǎng)絡管理,作為網(wǎng)絡技術(shù)一個分支， VPN系統(tǒng)無論采用哪種實現(xiàn)形式（軟件/硬件/軟硬結(jié)合），均涉及網(wǎng)絡化管理問題。而且VPN對網(wǎng)管安全提出了更高要求，目前經(jīng)常采用標準的網(wǎng)管協(xié)議SNMP V2一方面安全機制不健全，另一方面缺乏對VPN系統(tǒng)的內(nèi)在支持。從某種意義上講，網(wǎng)管技術(shù)的發(fā)展直接制約著VPN技術(shù)的大規(guī)模應用。,二、VPN的隧道技術(shù),1、隧道的相關(guān)知識 2、隧道協(xié)議類型 3、第二層隧道：PPTP 4、第二層隧道：L2TP 5、第三層隧道技術(shù)：IPSec 6、幾種隧道技術(shù)的比較,1、隧道的相關(guān)知識,隧道的定義

5、：實質(zhì)上是一種封裝，將一種協(xié)議（協(xié)議X）封裝在另一種協(xié)議（協(xié)議Y）中傳輸，從而實現(xiàn)協(xié)議X對公用傳輸網(wǎng)絡(采用協(xié)議Y)的透明性 隧道協(xié)議內(nèi)包括以下三種協(xié)議 乘客協(xié)議（Passenger Protocol） 封裝協(xié)議（Encapsulating Protocol） 運載協(xié)議（Carrier Protocol） 隧道協(xié)議例子,2、隧道協(xié)議類型,分類依據(jù)：被封裝的數(shù)據(jù)在OSI/RM的層次 第二層隧道：以PPTP，L2TP為代表 第三層隧道：IPSec,3、第二層隧道：PPTP（1）,PPTP由微軟公司設計，用于將PPP分組通過IP網(wǎng)絡封裝傳輸（PPTP: Point to Point Tunnelin

6、g Protocol點對點隧道協(xié)議）,3、第二層隧道：PPTP（2）,PPTP的數(shù)據(jù)封裝：,PPTP客戶機或PPTP服務器在接收到PPTP數(shù)據(jù)包后，將做如下處理： 處理并去除數(shù)據(jù)鏈路層報頭和報尾； 處理并去除IP報頭； 處理并去除GRE和PPP報頭； 如果需要的話，對PPP有效載荷即傳輸數(shù)據(jù)進行解密或解壓縮； 對傳輸數(shù)據(jù)進行接收或轉(zhuǎn)發(fā)處理。,（GRE: Generic Routing Encapsulation） 通用路由封裝（GRE）定義了在任意一種網(wǎng)絡層協(xié)議上封裝另一個協(xié)議的規(guī)范。,4、第二層隧道：L2TP,數(shù)據(jù)封裝格式： 特點： 它綜合了第二層轉(zhuǎn)發(fā)協(xié)議（L2F）和PPTP兩種協(xié)議各自的優(yōu)

7、點 協(xié)議的額外開銷較少,5、第三層隧道技術(shù)：IPSec,IPSec：即IP層安全協(xié)議，是由Internet組織IETF的IPSec工作組制定的IP網(wǎng)絡層安全標準。它通過對IP報文的封裝以實現(xiàn)TCP/IP網(wǎng)絡上數(shù)據(jù)的安全傳送。 數(shù)據(jù)封裝格式：,6、幾種隧道技術(shù)的比較,應用范圍： PPTP、L2TP：主要用在遠程客戶機訪問局域網(wǎng)方案中； IPSec主要用在網(wǎng)關(guān)到網(wǎng)關(guān)或主機方案中，不支持遠程撥號訪問。 安全性： PPTP提供認證和加密功能，但安全強度低 L2TP提供認證和對控制報文的加密，但不能對傳輸中的數(shù)據(jù)加密。 IPSec提供了完整的安全解決方案。 QoS（quality of service）

8、保證：都未提供 對多協(xié)議的支持：IPSec不支持,三、基于IPSec的VPN的體系結(jié)構(gòu),1、IPSec體系結(jié)構(gòu) 2、IPSec協(xié)議框架 3、AH協(xié)議 4、ESP協(xié)議 5、IPSec傳輸模式 6、IPSec隧道模式 7、安全策略數(shù)據(jù)庫(SPD) 8、安全聯(lián)盟數(shù)據(jù)庫(SADB) 9、數(shù)據(jù)包輸出處理 10、數(shù)據(jù)包輸入處理 11、包處理組件實現(xiàn)模型,1、IPSec體系結(jié)構(gòu),2、IPSec協(xié)議框架（1）,綜合了密碼技術(shù)和協(xié)議安全機制，IPSec協(xié)議的設計目標是在IPV4和IPV6環(huán)境中為網(wǎng)絡層流量提供靈活的安全服務。IPSec協(xié)議提供的安全服務包括：訪問控制、無連接完整性、數(shù)據(jù)源鑒別、攻擊保護、機密性、

9、有限的流量保密等。IPSec協(xié)議主要內(nèi)容包括： 協(xié)議框架RFC2401； 安全協(xié)議：AH協(xié)議RFC2402、ESP協(xié)議RFC2406；,密鑰管理協(xié)議：IKE RFC2409 、ISAKMPRFC2408、OAKLEY協(xié)議RFC2412。 密碼算法：HMACRFC2104/2404、CASTRFC2144、ESP加密算法RFC2405/2451等。 其他：解釋域DOIRFC2407、IPCompRFC2393、RoadmapRFC2411。,2、IPSec協(xié)議框架（2）,2、IPSec協(xié)議框架（3）,ike定義了安全參數(shù)如何協(xié)商,以及共享密鑰如何建立,但它沒有定義的是協(xié)商內(nèi)容.這方面的定義是由解

10、釋域(doi)文檔來進行的,3、AH協(xié)議,4、ESP協(xié)議,5、IPSec傳輸模式,6、IPSec隧道模式,7、安全策略數(shù)據(jù)庫(SPD)（1）,SP是一個描述規(guī)則，定義了對什么樣的數(shù)據(jù)流實施什么樣的安全處理，至于安全處理需要的參數(shù)在SP指向的一個結(jié)構(gòu)SA中存儲。 SP描述：對本地子網(wǎng)和遠程網(wǎng)關(guān)后的子網(wǎng)間的通信流，實施ESP通道保護，采用3DES加密算法和HMAC-SHA1驗證算法。,7、安全策略數(shù)據(jù)庫(SPD)（2）,系統(tǒng)中的安全策略組成了SPD,每個記錄就是一條SP, 一般分為應用IPSec處理、繞過、丟棄。 從通信數(shù)據(jù)包中，可以提取關(guān)鍵信息填充到一個稱為“選擇符”的結(jié)構(gòu)中去，包括目標IP、源

11、IP、傳輸層協(xié)議、源和目標端口等等。然后利用選擇符去搜索SPD，找到描述了該通信流的SP。,8、安全聯(lián)盟數(shù)據(jù)庫(SADB)（1）,SA(Security Association)是兩個IPSec通信實體之間經(jīng)協(xié)商建立起來的一種共同協(xié)定，它規(guī)定了通信雙方使用哪種IPSec協(xié)議保護數(shù)據(jù)安全、應用的算法標識、加密和驗證的密鑰取值以及密鑰的生存周期等等安全屬性值。,8、安全聯(lián)盟數(shù)據(jù)庫(SADB)（2）,安全聯(lián)盟常用參數(shù) 加密及驗證密鑰。 密碼算法在系統(tǒng)中的標識。 序列號，32位的字段，在處理外出的數(shù)據(jù)包時，一個SA被應用一次，它的序列號號字段就遞增一，并被填充到數(shù)據(jù)包的IPSec頭中，接收方可以利用此

12、字段進行抗重播攻擊。 抗重播窗口。接收方使用滑動窗口算法來進行對惡意主機重復發(fā)出的數(shù)據(jù)包進行檢測。 生存周期。規(guī)定了該SA的有效使用周期，可以按照建立至今的時間或者處理的流量來計算。 實施模式。即通道模式還是傳輸模式。 IPSec隧道目的地址。 安全參數(shù)索引(SPI)。參與唯一標識某SA。,9、數(shù)據(jù)包輸出處理,數(shù)據(jù)包被從網(wǎng)絡設備發(fā)送出去之前，截取到 IP包，然后從中提取選擇符信息，依據(jù)之搜索 SPD，產(chǎn)生如下可能結(jié)果： SP決定丟棄此包，于是直接丟棄，或者還可 以向源主機發(fā)送ICMP信息； SP決定通過此包，直接將數(shù)據(jù)包投放到網(wǎng)絡設備的發(fā)送隊列； SP決定應用IPSec，此時SP指向一個SA,

13、可以根據(jù)它進行安全處理（需要的SA不存在，則觸發(fā)IKE模塊協(xié)商建立SA，協(xié)商周期內(nèi)數(shù)據(jù)包進入等待隊列等待協(xié)商完成，若協(xié)商超時，也會丟棄該包。）,10、數(shù)據(jù)包輸入處理,系統(tǒng)收到IP包后，判斷如果是IPSec包，則從頭部取到，搜索SADB。 若找不到SA，觸發(fā)IKE或丟棄包； 若找到，根據(jù)其進行解封裝，得到去通道 化后的原始IP包，再從原始IP包中提取選擇符， 搜索到SPD中某一條目，檢查收到包的安全處理 是否符合描述規(guī)則，不符合則丟棄包，符合則轉(zhuǎn) 入系統(tǒng)IP協(xié)議棧進行后繼處理。,11、包處理組件實現(xiàn)模型,四、互聯(lián)網(wǎng)密鑰交換(Internet Key Exchange),1、IKE功能 2、密鑰交

14、換包格式(ISAKMP)- 3、安全聯(lián)盟的協(xié)商 4、密鑰交換的兩個階段 5、Diffie-Hellman密鑰交換 6、交換流程,1、IKE功能,用IPSec保護數(shù)據(jù)包，必須首先建立一個IPSec的安全聯(lián)盟，這個安全聯(lián)盟可以手工建立，也可以動態(tài)由特定進程來創(chuàng)建。這個特定的進程就是Internet Key Exchange,即IKE。IKE的用途就是在IPSec通信雙方之間通過協(xié)商建立起共享安全參數(shù)及驗證過的密鑰，也就是建立安全聯(lián)盟。 IKE協(xié)議是Oakley和SKEME協(xié)議的混合，在由ISAKMP規(guī)定的一個框架內(nèi)運作，可以為多種需要安全服務的協(xié)議進行策略磋商和密鑰建立，比如SNMPv3,OSPF

15、v2,IPSec等。,2、密鑰交換包格式(ISAKMP)1因特網(wǎng)安全關(guān)聯(lián)和密鑰管理協(xié)議（ISAKMP,Internet Security Association and Key Management Protocol),2、密鑰交換包格式(ISAKMP)-2,安全聯(lián)盟載荷， 轉(zhuǎn)碼載荷表示協(xié)商時供對方選擇的一組安全屬性字段的取值，比如算法，安全聯(lián)盟的存活期，密鑰長度等等。 密鑰交換載荷，表示了實施密鑰交換必需的信息。散列載荷，是一個散列函數(shù)的運算結(jié)果值。 nonce載荷，是一串偽隨機值，用以衍生加密材料。 證書載荷，在身份驗證時向?qū)Ψ教峁┳C書。 證書請求載荷。,3、安全聯(lián)盟的協(xié)商,通信雙方要建立

16、共享的安全聯(lián)盟，必須進行協(xié)商。 雙方根據(jù)本方的實際安全需求，制定采用的算法，密鑰刷新頻率，密鑰的長度等等策略。發(fā)起方在發(fā)送的安全聯(lián)盟載荷中，根據(jù)策略的優(yōu)先級順序，將計劃采用的安全參數(shù)的組合以提案載荷和轉(zhuǎn)碼載荷的形式級聯(lián)表示出來，響應方收到后，依據(jù)策略選擇最合適的一種，再構(gòu)建應答的安全聯(lián)盟，此時應答方只包含了選中的一種安全參數(shù)組合。這樣，一個共享的安全聯(lián)盟就可以獲得了。 在協(xié)商的進程中，雙方也通過計算得到共享的密鑰。,4、密鑰交換的兩個階段,1.階段一交換(phase1 exchange):在“階段一”周期里，兩個IKE實體建立一個安全的，經(jīng)驗證的信道進行后續(xù)通信，要建立這樣的安全信道，雙方會建

17、立一對ISAKMP安全聯(lián)盟。階段一交換可以用身份保護模式(也叫主模式)或野蠻模式來實現(xiàn)，而這兩種模式也僅用于階段一中。 2.階段二交換(phase2 exchange): “階段二”周期里，IKE實體會在階段一建立起來的安全信道中，為某種進程協(xié)商和產(chǎn)生需要的密鑰材料和安全參數(shù)，在VPN實現(xiàn)中，就是建立IPSec安全聯(lián)盟?？焖倌Ｊ浇粨Q可用來實現(xiàn)階段二交換并且僅用于此階段中。,5、Diffie-Hellman密鑰交換,D-H交換的安全性源于在有限域上計算離散對數(shù)比計算指數(shù)更為困難。,6、交換流程（1）（階段一身份保護模式）,6、交換流程（2）階段一說明,在消息(1)中，發(fā)起者生成他認為適當?shù)陌踩?/p>

18、案列表，提交給響應方。消息(2)中，響應者與本地策略進行匹配和選擇之后，將最終決定的安全聯(lián)盟內(nèi)容同樣用相應載荷回送發(fā)起者。 在消息(3)、(4)中，發(fā)起者和響應者交換DH公開值，和隨機信息串nonce，在第四步完成時，雙方已經(jīng)可以經(jīng)計算得出共享的DH公共值，以及各自計算出SKEYID和相關(guān)衍生密鑰。 消息(5)和消息(6)中，雙方使用前兩步得出的加密、驗證算法和密鑰保護傳輸?shù)臄?shù)據(jù)。 當采用數(shù)字簽名的身份驗證方法時，消息(5)和(6)可以包含證書載荷，將自己的公鑰證書發(fā)給對方，驗證數(shù)據(jù)AUTH DATA就是數(shù)字簽名的運算結(jié)果，在這里數(shù)字證書也可以是從有效的遠程有效的認證中心通過LDAP、DNSS

19、EC等協(xié)議獲得。,6、交換流程（3）（階段二快速模式）,6、交換流程（4）階段二說明,所有消息從ISAKMP頭之后都是加密傳輸?shù)模⑶以谙㈩^之后緊跟了散列值進行驗證。如果使用了完美向前加密(PFS)，則消息交換中還包含一次DH交換的公開值載荷KE,身份載荷表示的是要保護的通信流的源和目的，通常是子網(wǎng)內(nèi)的主機或主機的集合。 在前兩個消息交換完成后，雙方可以計算出共享的密鑰材料，這將是最終提供給IPSec模塊的密鑰信息。,五、IPSec的安全性評價及其改進,1、IPSec VPN的優(yōu)勢 2、IPSec過于復雜 3、IPSec 協(xié)議存在的問題 4、對IKE協(xié)議的改進 5、IPSec與NAT的共處

20、6、遠程撥號接入 7、支持組播 8、對先加密后認證順序的評價 9、對IPSec的總體評價,1、IPSec VPN的優(yōu)勢（1）,VPN技術(shù)雖然種類眾多，但IETF下的IPSec工作組推出的IPSec協(xié)議是目前工業(yè)界IP VPN標準，以IPSec協(xié)議構(gòu)建虛擬專用網(wǎng)已成為主流。 基于IPSec構(gòu)建IP VPN是指利用實現(xiàn)IPsec協(xié)議的安全網(wǎng)關(guān)（Security Gateway）充當邊界路由器，完成安全的遠程接入和在廣域網(wǎng)上內(nèi)部網(wǎng)絡的“虛擬”專線互聯(lián)等。,1、IPSec VPN的優(yōu)勢（2）,為數(shù)據(jù)的安全傳輸提供了身份鑒別、數(shù)據(jù)完整性、機密性保證等措施，并且其提供的安全功能與密鑰管理系統(tǒng)松散耦合。 端

21、到端的IPSec VPN專線租費比PVC等物理專線的租用費低很多。 遠程接入IPSec VPN接入成本比長途電話費用低（只考慮本地撥號和VPN隧道占用費）。,2、IPSec過于復雜（1）,舉例說明。比如在IPSec中，存在兩種模式，兩種協(xié)議AH和ESP。若要對兩臺主機之間的數(shù)據(jù)包進行認證，存在以下六種方案： 傳送模式AH； 隧道模式AH； 傳送模式ESP（無加密）； 隧道模式ESP（無加密）； 傳送模式ESP（加密）； 隧道模式ESP（加密）；,2、IPSec過于復雜（2）建議去掉傳送模式,去掉傳送模式； 去掉AH協(xié)議； 在ESP中，數(shù)據(jù)源認證是必須的，而加密功能是可選的； 先加密后認證的順序

22、存在問題,2、 IPSec過于復雜（3）建議去掉AH協(xié)議,AH和ESP在功能上重疊 AH的認證存在的問題 隧道模式ESP 提供和AH幾乎同樣強度的認證 通過壓縮機制來節(jié)省帶寬,網(wǎng)絡新技術(shù)不斷涌現(xiàn)，對IPSec協(xié)議提出了 新的挑戰(zhàn)；針對IPSec協(xié)議的各種不足，IETF 下的IPSec工作組正在醞釀IPSec協(xié)議的改進， 包括IKEV2。 國內(nèi)外研究發(fā)現(xiàn)，IPSec協(xié)議大致存在下列 問題： 1. IKE協(xié)議的安全性； 2. 與現(xiàn)有網(wǎng)絡機制的兼容性； 3. 缺乏對遠程撥號接入的支持； 4. 不支持組播、多協(xié)議；,3、IPSec 協(xié)議存在的問題,1. 網(wǎng)絡新技術(shù)不斷涌現(xiàn)，對IPSec協(xié)議提出 了新的

23、挑戰(zhàn)；針對IPSec協(xié)議的各種不足， IETF下的IPSec工作組正在醞釀對IPSec協(xié)議的 改進，即IKEV2。 2. J.Zhou在分析IKE協(xié)議基礎上，提出 HASH_I和HASH_R的計算公式存在安全隱患。 3. Bruce Schneier等人認為IKE協(xié)議過于復雜 ，某些細節(jié)描述不夠清楚，與ISAKMP協(xié)議有 沖突。,4、對IKE協(xié)議的改進（1）,4. J.M.Sierra等人提出利用新的協(xié)商模式- 發(fā)生器模式（Generator Mode）實現(xiàn)IKE SA的 快速更新。 5. Radia Perlman等研究發(fā)現(xiàn)，IKE協(xié)議提 供的用戶身份保密功能與采用的身份認證方 法直接相關(guān)，

24、對激進模式進行適當?shù)男薷囊?能提供身份保護。J.Zhou提出采用數(shù)字簽名 認證方式的主模式可能導致發(fā)起方的身份信 息泄漏。,4、對IKE協(xié)議的改進（2）,網(wǎng)絡地址轉(zhuǎn)換NAT技術(shù)通過修改IP包 內(nèi)容實現(xiàn)包的正常傳輸；而IPSec協(xié)議通過采 用驗證技術(shù)保護IP包中數(shù)據(jù)完整性，因此 NAT與IPSec是一對矛盾。 IETF下的網(wǎng)絡工作組提出了在隧道模式下使用IPC-NAT( IPSec Control NAT) 的解決方案。 對于端到端的IPSec與NAT的共處，網(wǎng)絡工作組建議使用RSIP(Realm Specific IP) 協(xié)議。,5、IPSec與NAT的共處（1）,Balaji Sivasub

25、ramanian等提出適用于協(xié)作IP網(wǎng)絡的一種的端到端安全解決方案。該方案的巧妙之處在于IPSec處理預先使用NAT變換之后的數(shù)據(jù)（公共IP地址或端口），數(shù)據(jù)包經(jīng)過NAT設備時，NAT設備對它的修改正好與IPSec提供的數(shù)據(jù)完整性保護相吻合。 IPSec工作組提出利用UDP協(xié)議封裝IPSec處理后的數(shù)據(jù)包，則NAT設備最多需要涉及對UDP頭的數(shù)據(jù)修改。,5、IPSec與NAT的共處（2）,IPSec協(xié)議本身只提供IP層的安全服務，無 法在更高層實施更小顆粒的訪問控制，這樣 就有必要借鑒高層機制，幫助IPSec協(xié)議改進 對遠程接入的支持。 安全遠程接入解決方案大致有： 聯(lián)合L2TP協(xié)議 利用Mo

26、bile IP協(xié)議； 修改IKE協(xié)議Xauth協(xié)議、Crack協(xié)議、Hybrid 鑒別協(xié)議 ； PIC協(xié)議；,6、遠程撥號接入,IPSec協(xié)議文件雖然指出協(xié)議支持使用組 播（Multicast）地址，但實質(zhì)上協(xié)議缺乏對組 播的完整支持。 將IPSec協(xié)議應用到組播環(huán)境中，迫切需 要解決的問題包括： SA的唯一性問題 ； 組機密性問題； 單個源鑒別問題； 防重傳攻擊服務失效；,7、支持組播（1）,組播源鑒別：G_R方案基于數(shù)字簽名技術(shù)和摘要技術(shù)，將對多個消息單個源鑒別分解為對第一個消 息的簽名和其他消息摘要的鏈式組合。 C.K.Wong等人提出多個包的一次簽名可等價轉(zhuǎn)化為對每個包的摘要的集中簽名

27、；為減少每個包的尺寸，可采用樹形鏈或星形鏈技術(shù)，安排每個包中攜帶的摘要。C.Canetti等提出利用MAC技術(shù)實現(xiàn)組播 源鑒別：發(fā)送方擁有K個密鑰，每個接收方只 與其共享L個密鑰（LK），發(fā)送方發(fā)送每個 包時同時附帶K個MAC值 。,7、支持組播（2）,組播密鑰管理方案 C.K.Wong等提出分級樹組密鑰方案，利 用密鑰服務器（KS）負責產(chǎn)生所有密鑰，并 按照虛擬的分級樹組織每個成員存儲的密鑰。 A.Ballardie、H.Harney等人分別提出可擴 展的組播密鑰分發(fā)協(xié)議（SMKD）和組密鑰 管理協(xié)議（GKMP），這兩種協(xié)議的共同缺 點是缺乏針對組成員關(guān)系變化的密鑰更新機 制，SMKD依賴特

28、殊的組播體系（CBT）。 在Iolus方案中，S.Mitra采用分級架構(gòu)將組 播組細分為若干個獨立的子組；組安全接口 （GSI）負責跨組通信的轉(zhuǎn)換。,7、支持組播（3）,8、對先加密后認證順序的評價,IPSec中的加密和認證順序； Horton定理：認證協(xié)議應當基于消息本身的含義進行認證； 如果出于效率考慮，應當認證解密密鑰,9、對IPSec的總體評價,優(yōu)點 安全性明顯優(yōu)于其它隧道協(xié)議 缺點 過于復雜 存在安全漏洞 安全性分析困難 根本的解決方案：對IPSec進行修補不能解決根本問題，必須徹底改變制定IPSec的委員會模式(committee process),六、移動VPN,1、無線局域網(wǎng)

29、2、移動IP 3、SKIP協(xié)議,1、無線局域網(wǎng),無線局域網(wǎng)（Wireless LANWLAN）、無線固定寬帶接入（Fixed Wireless Broad Band Access System）、藍牙（Bluetooth）等新的無線接入技術(shù)不斷涌現(xiàn)，對網(wǎng)絡安全提出了更高的挑戰(zhàn)。 典型的無線網(wǎng)絡標準IEEE 802.11b、IEEE 802.16、Bluetooth都采用了基于鏈路加密的安全技術(shù)。與網(wǎng)絡層安全技術(shù)相比，鏈路級安全機制作用范圍受限，嚴重依賴于鏈路接入機制。,2、移動IP（1）,根據(jù)OSI 參考模型，IEEE 802.11b、藍牙等無線接入技術(shù)工作在網(wǎng)絡層之下的數(shù)據(jù)鏈路層和物理層，雖然使用戶獲得近距離內(nèi)的移動性（Mobility），但不適用于廣域網(wǎng)接入環(huán)境中的移動性問題。 目前IP協(xié)議中IP地址與物理位置捆綁在一起，IP地址既用來標識網(wǎng)絡中特定的主機，也用于報