計(jì)算機(jī)系統(tǒng)安全-資料下載頁(yè)
2025-08-01 14:04本頁(yè)面
【正文】 輸出處理 四、認(rèn)證頭 創(chuàng)建一個(gè)外出 SA時(shí)可通過手工或 IKE將序列號(hào)計(jì)算器初始化成 0。 在利用這個(gè) SA構(gòu)建一個(gè) AH頭之前 ， 計(jì)算器就開始遞增 。 這樣保證了每個(gè) AH頭中的序列號(hào)都是一個(gè)獨(dú)一無(wú)二的 、 非零的和單向遞增的數(shù) 。 AH頭的其余字段都將填滿恰當(dāng)?shù)闹?。 SPI字段分配的值是取自 SA的 SPI； 下一個(gè)頭字段分配的是跟在 AH頭之后的數(shù)據(jù)類型值；載荷長(zhǎng)度分配的是“ 32位字減二 ” ； “ 身份認(rèn)證數(shù)據(jù) ” 字段設(shè)成 0。 52 輸出處理 四、認(rèn)證頭 和 ESP不一樣 ， AH將安全保護(hù)擴(kuò)展到外部 IP頭的原有的或預(yù)計(jì)有的字段 。 因此 ， 要將完整性檢查值 (ICV)之前的不定字段調(diào)成零 。 對(duì)沒有包含在身份認(rèn)證 ICV中的 IPv4頭來(lái)說(shuō) ， 它的不定字段包括 Type of service（ 服務(wù)類型 ） 、 Flags（ 標(biāo)志 ） 、 Fragment offset(分段偏移 )、 Time to live(存活時(shí)間 )和 Header checksum(頭校驗(yàn)和 )。 對(duì) IPv4選項(xiàng)或 IPv6擴(kuò)展頭來(lái)說(shuō) ， 如果它們是固定的或預(yù)定的 ， 都會(huì)包含在 ICV計(jì)算之中 。 否則 ，必需在計(jì)算 ICV之前 ， 把它們調(diào)成零 。 53 輸出處理 四、認(rèn)證頭 身份認(rèn)證可能要求進(jìn)行適當(dāng)?shù)奶畛?。 對(duì)有些 MAC來(lái)說(shuō) ，比如 DESCBCMAC， 要求在其上面應(yīng)用 MAC的數(shù)據(jù)必須是算法的塊尺寸的倍數(shù) 。 因此 ， 必須進(jìn)行填充 ， 以便正確地使用 MAC（ 注 :兩種強(qiáng)制算法均無(wú)此要求 ） 。 這個(gè)填充項(xiàng)是隱式添加的 。 它必須一概為零 ， 其大小不包括在載荷長(zhǎng)度中 ， 并且不隨數(shù)據(jù)包一起傳送 。 對(duì)于 IPv4， AH頭必須是 32個(gè)字節(jié)的一倍 ， IPv6則是 64個(gè)字節(jié)的一倍 。 若 MAC的輸出和這項(xiàng)要求不符 ， 就必須添加 AH頭 。 對(duì)于填充項(xiàng)的值 ， 必須包括在 ICV計(jì)算中 ，并在載荷長(zhǎng)度中反映出填充項(xiàng)的大小 。 如果強(qiáng)制實(shí)施身份認(rèn)證程序正確對(duì)齊了 ， 在用 HMACMD596或 HMACSHA96時(shí) ， 就不再需要填充項(xiàng) 。 54 輸出處理 四、認(rèn)證頭 通過把密鑰從 SA和整個(gè) IP包 （ 包括 AH頭 ） 傳到特定的算法 （ 它被認(rèn)作 SA中的身份認(rèn)證程序 ）這一方式 ， 對(duì) ICV進(jìn)行計(jì)算 。 由于不定字段已設(shè)成零 ， 不會(huì)包括在 ICV計(jì)算中 。 接下來(lái) ， ICV值被復(fù)制到 AH的 “ 身份認(rèn)證數(shù)據(jù) ” 字段中 ， IP頭中的不定字段就可根據(jù) IP處理的不同得以填充 。 現(xiàn)在 ， AH處理結(jié)束 ， AH保護(hù)的 IP包可以輸出了 。根據(jù)包的大小 ， 在放到線上之前 ， 可將它分段 ，或在兩個(gè) IPSec同級(jí)之間的傳送過程中 ， 由路由器進(jìn)行分段 。 55 輸入處理 四、認(rèn)證頭 如果一個(gè)受安全保護(hù)的包在被收到之前分成了幾段 ， 就要在 AH輸入處理前對(duì)這些分段進(jìn)行重組 。 接收 IPSec包首先要找出用來(lái)保護(hù)這個(gè)包的 SA。然后 ， IP頭的目的地址 、 特定協(xié)議 （ 這里是 51）和取自 AH頭的 SPI這三者再對(duì) SA進(jìn)行識(shí)別 。 如果沒有找到合適的 SA， 這個(gè)包就會(huì)被丟棄 。 找到 SA之后 ， 進(jìn)行序列號(hào)檢查 。 抗重播檢查會(huì)決定這個(gè)包是新收的還是以前收到的 。 如果檢查失敗 ， 這個(gè)包就會(huì)被丟棄 。 56 輸入處理 四、認(rèn)證頭 現(xiàn)在必須檢查完整性檢查值 （ ICV） 了 。 對(duì)整個(gè)數(shù)據(jù)包應(yīng)用 “ 身份認(rèn)證器 ” 算法 ， 并將獲得的摘要同保存下來(lái)的 ICV值進(jìn)行比較 。 如相符 ， IP包就通過了身份認(rèn)證；如不符 ， 便丟棄該包 。 57 Inter密鑰交換 五、 Inter密鑰交換 IKE的用途是在 IPSec通信雙方之間 ， 建立起共享安全參數(shù)及認(rèn)證過的密鑰 （ 即建立 “ 安全關(guān)聯(lián) ” ） 。 IKE協(xié)議是 Oakley和 SKEME協(xié)議的混合 ， 并在由ISAKMP規(guī)定的一個(gè)框架內(nèi)運(yùn)作 。 ISAKMP是“ Inter安全關(guān)聯(lián)和密鑰管理協(xié)議 ” 的簡(jiǎn)稱 ，即 Inter Security Association and Key Management Protocol。 ISAKMP定義了包格式 、重發(fā)計(jì)數(shù)器以及消息構(gòu)建要求 。 它定義了整套加密通信語(yǔ)言 。 58 Inter密鑰交換 IKE的用途 Oakley和 SKEME定義了通信雙方建立共享密鑰的步驟 。 IKE利用 ISAKMP語(yǔ)言描述這些步驟以及其它信息交換措施 。 59 建立 IKE的兩個(gè)階段 五、 Inter密鑰交換 階段 1：協(xié)商創(chuàng)建并認(rèn)證一個(gè)通信信道 (IKE SA)， 為雙方下一步通信提供保密 、 完整以及數(shù)據(jù)源認(rèn)證服務(wù) 。 本階段有兩種運(yùn)行模式：Main mode和 aggressive模式 。 階段 2：對(duì) Sa可提供的服務(wù)及所需密鑰進(jìn)行協(xié)商 。 IKE支持四種認(rèn)證方式：基于數(shù)字簽名的認(rèn)證 、 兩種基于公鑰的認(rèn)證 、 基于共享密鑰的認(rèn)證 。 IKE使用 UDP協(xié)議和 500端口 。 60 六、 IPSec的應(yīng)用 ? IPSec是 IPv6必須支持的功能，它與防火墻、安全網(wǎng)關(guān)結(jié)合可形成各種安全解決方案；與其他協(xié)議相結(jié)合將使安全性更高；能使企業(yè)將其 Extra擴(kuò)展到貿(mào)易伙伴進(jìn)行電子商務(wù)，而不用擔(dān)心安全協(xié)議的兼容性。 ? IPSec的典型應(yīng)用是構(gòu)建虛擬專用網(wǎng) VPN VPN通過保密隧道在非信任公共網(wǎng)絡(luò)上產(chǎn)生安全私有連接。它能把遠(yuǎn)程用戶、分支機(jī)構(gòu)和商業(yè)伙伴連接組成一個(gè)自治網(wǎng)絡(luò)，達(dá)到與專用網(wǎng)同樣的安全、可靠、可擴(kuò)充、可管理、服務(wù)質(zhì)量。 IPSec為VPN的互操作性、管理、通信提供了有力手段。
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1