GM-T 0022-2023 IPSec VPN技術(shù)標(biāo)準(zhǔn)規(guī)范

中華人民共和國密碼行業(yè)標(biāo)準(zhǔn)代替GM/T0022—2014IPSecVPNtechnicalspe國家密碼管理局發(fā)布I Ⅲ 1 1 1 24.1符號(hào) 24.2縮略語 3 3 3 4 4 46.2安全報(bào)文協(xié)議 7.1產(chǎn)品功能要求 7.2產(chǎn)品性能參數(shù) 7.3安全管理要求 8.1產(chǎn)品功能檢測 428.2產(chǎn)品性能檢測 8.3安全管理檢測 9判定規(guī)則 附錄A(資料性)IPSecVPN簡要介紹 49Ⅲb)增加]術(shù)語和定義“可鑒別的加密機(jī)制(見-3.6)d)增加了與GCM加密模式相關(guān)的舶密密鉬選取說明(見6133e)更敢了與GCM加密模式相笑的快速模式中消言的數(shù)據(jù)位格式(見6.1.68,204年版的的數(shù)據(jù)包格式(見61610s2014年版的1.5.9f)更改了“封裝安全載行ESP實(shí)格式”6.2.2.2,2014年版的52.2-22時(shí)裝安全載荷ESP的處理”中與6CME相關(guān)的數(shù)據(jù)包封裝和解封操作的詳細(xì)說明(6.2.23-,2011年版的52.9.30請(qǐng)注意本文件的某些內(nèi)容可能涉及專利。本文件的發(fā)布機(jī)構(gòu)不承擔(dān)識(shí)別專利的責(zé)任——2014年首次發(fā)布為GM/T0022—2014;12規(guī)范性引用文件下列文件中的內(nèi)容通過文中的規(guī)范性引用而構(gòu)成本文件必不可少的條款。其中，注日期的引用文信息安全技術(shù)公鑰基確設(shè)施數(shù)學(xué)證書格式隨租性檢測規(guī)范GM/T0062—2018密碼產(chǎn)品隨機(jī)數(shù)檢測要求RFC2408互聯(lián)網(wǎng)安全聯(lián)盟與密鑰管理協(xié)議(InternetsecurityassociationandkeymanagementRFC3947密鑰交換過程中NAT穿越協(xié)商(NegotiationofNATtraversatintheIKE)RFC4304互聯(lián)網(wǎng)安全關(guān)聯(lián)和密鑰管理協(xié)議(ISAKMP)IPsec解釋域(DOI)的擴(kuò)展序列號(hào)(ESN)附錄[Extendedsequencenumber(ESN安全聯(lián)盟securityassociation2用于提供IP數(shù)據(jù)包的機(jī)密性、數(shù)據(jù)完整性以及對(duì)數(shù)據(jù)源鑒別以及抗重放攻擊的功能的IPSec協(xié)議。具體實(shí)現(xiàn)IPSecVPN協(xié)議的軟硬件產(chǎn)品。下列符號(hào)適用于本文件。HDR:一個(gè)ISAKMP頭。IDi:發(fā)起方的標(biāo)識(shí)載荷。3Ni:發(fā)起方的nonce載荷。prv_i:發(fā)起方私鑰。AH:鑒別頭(AuthenticationHeader)1)包括沒有ISAKMP通用頭的載荷。4c)密碼雜湊算法應(yīng)支持SM3密碼雜湊算法，用于完整性校驗(yàn)。SM3算法的使用應(yīng)遵循Asymmetric_Sign(msg,priv_key):使用非對(duì)稱算法Asymmetr進(jìn)行加密，其輸出為msg的通用載荷頭和密文串接。如SM4_Encrypt(Ni,key)表示使用SM4算協(xié)議500或4500端口進(jìn)行傳輸。5之間的通信而使用的共享策略和密鑰。用這個(gè)安全聯(lián)盟來保護(hù)IPSec安全聯(lián)盟的協(xié)商過程。一個(gè)ISAKMP安全聯(lián)盟可以用于建立多個(gè)IPSec安全聯(lián)盟。SA載荷采用的載荷封裝形式為變換載荷封裝在建議載荷中，建主模式的交換過程由6個(gè)消息組成。雙方身份的鑒別采用數(shù)字證書的方式。主模式的交換過程見圖1。2<----HDR,SA3HDR,X4<----5HDR*,HASHi6消息2:響應(yīng)方發(fā)送一個(gè)SA載荷以及響應(yīng)方的簽名證書和加密證書，該載荷表明它所接受的發(fā)起消息3和消息4:發(fā)起方和響應(yīng)方交換數(shù)據(jù)，交換的數(shù)據(jù)內(nèi)容包括nonce、身份標(biāo)識(shí)(ID)載荷。Nonce是生成加密密鑰和認(rèn)證密鑰所必需的參數(shù)；ID是發(fā)起方或響應(yīng)方的標(biāo)識(shí)。這些數(shù)據(jù)使用臨時(shí)密6XCHi=Asymmetric_Encrypt(Ski,pub_r)|Symmetric_Encrypt(Ni,Ski)ISymmetric_Encrypt(IDi,Ski)|CERT_sig_iSIGi_b=Asymmetric_Sign(Ski_b|Ni_b|IDi_b|CERXCHr=Asymmetric_Encrypt(Skr,pub_i)ISymmetric_EncryptSIGr_b=Asymmetric_Sign(Skr_b|Nr_消息3和消息4交互完成后，參與通信的雙方生成基本密鑰參數(shù)SKEYID,以生成后續(xù)密鑰SKEYID_d=PRF(SKEYID,CKY-I|CKY-RSKEYID_e=PRF(SKEYI算法加密。對(duì)稱密碼算法由消息1和消息2確定，密鑰使用SKEYID_e。對(duì)稱密碼運(yùn)算使用CBC模式，初始化向量IV是消息3中的Ski和消息4中的Skr串連起來經(jīng)過HASH運(yùn)算得到的：HASH算法由消息1和消息2確定。7為了鑒別交換，發(fā)起方產(chǎn)生HASHi,響應(yīng)方產(chǎn)生HASHr,計(jì)算公式如下：HASHi=PRF(SKEYID,CKY-I|HASHr=PRF(SKEYID,CKY-I快速模式交換依賴于第一階段主模式交換，作為IPSecSA協(xié)商過程的一部分協(xié)商IPSecSA的安全策略并衍生會(huì)話密鑰。快速模式交換的信息由ISAKMPSA來保護(hù)，即除了ISAKMP頭外，所有的載荷都要加密。在快速模式中，一個(gè)HASH載荷應(yīng)緊跟在ISAKMP頭之后，這個(gè)HASH用于消息的完整性校驗(yàn)以及數(shù)據(jù)源身份驗(yàn)證。在第二階段，載荷的加密使用對(duì)稱密碼算法的CBC工作模式，第1個(gè)消息的IV是第一階段的最后一組密文和第二階段的MsgID進(jìn)行HASH運(yùn)算所得到的：IV=HASH(第一階段的最后一組密文|MsgID)后續(xù)的IV是前一個(gè)消息的最后一組密文。消息的填充和第一階段中的填充方式一樣。在ISAKMP頭中的MsgID唯一標(biāo)識(shí)了一個(gè)正在進(jìn)行中的快速模式，而該ISAKMPSA本身又由ISAKMP頭中的cookte來標(biāo)識(shí)。因?yàn)榭焖倌Ｊ降拿總€(gè)實(shí)例使用一個(gè)唯一的MsgID,這就有可能基于一個(gè)ISAKMPSA的多個(gè)快速模式在任一時(shí)間內(nèi)同時(shí)進(jìn)行。在快速模式協(xié)商中，身份標(biāo)識(shí)1D缺省定義為SARME雙方的TP地用沒有強(qiáng)制規(guī)定允許的協(xié)議或端口號(hào)。如果協(xié)商雙方應(yīng)指定D測雙方的身份應(yīng)作為前和1D被依次傳遞。響應(yīng)方的本地安全策略將決定是否接受對(duì)方的身份標(biāo)識(shí)ID發(fā)起方的身份標(biāo)識(shí)D山于安全策略或其他原因沒有被響應(yīng)方所接受，則響應(yīng)方應(yīng)發(fā)送一個(gè)通知息類型為ALID_1NFORMATION(8)的通知載荷。在通信雙方之間有多條隧道同時(shí)存在的情，身份標(biāo)識(shí)ID為對(duì)應(yīng)的DSecSA標(biāo)識(shí)并規(guī)定通信數(shù)據(jù)流進(jìn)入對(duì)應(yīng)的隧道。本階段涉及的消痣頭及載荷的具體內(nèi)容見快速模式的交換過程見圖2.23HDRt,HASH_3---->圖2快速模式的交換過程消息1:發(fā)起方向響應(yīng)方發(fā)送一個(gè)雜湊載荷、一個(gè)SA載荷(其中封裝了一個(gè)或多個(gè)建議載荷，而每個(gè)建議載荷中又封裝一個(gè)或多個(gè)變換載荷)、一個(gè)nonce載荷和標(biāo)識(shí)載荷。雜湊載荷中消息摘要的計(jì)算方法如下：HASH_1=PRF(SKEYID_a,MsgID|Ni_b消息2:響應(yīng)方向發(fā)起方發(fā)送一個(gè)雜湊載荷、一個(gè)SA載荷、一個(gè)nonce載荷和標(biāo)識(shí)載荷。雜湊載荷中消息摘要的計(jì)算方法如下：HASH_2=PRF(SKEYID_a,MsgID|Ni_b|S消息3:發(fā)起方向響應(yīng)方發(fā)送一個(gè)雜湊載荷，用于對(duì)前面的交換進(jìn)行鑒別。雜湊載荷中消息摘要的計(jì)算方法如下：HASH_3=PRF(SKEYID_a,0|MsgID|Ni_b|Nr_b)8用于加密的會(huì)話密鑰和用于完整性校驗(yàn)的會(huì)話密鑰按照算法要求的長度從KEYMAT中依次選如果IPSecSA協(xié)商過程中選擇的是GCM模式的可鑒別的加密機(jī)制，則加密算法所鑰和Salt值都按照各自長度要求從KEYMAT中依次選取。本文件規(guī)定，在為ESP協(xié)議協(xié)商IPSecSA時(shí)，如果雙方協(xié)商使用GCM模式的SM4加密算法(簡稱SM4_GCM),此時(shí)則先選取16字節(jié)長度啟動(dòng)變量S。GCM模式的可鑒別的加密機(jī)制應(yīng)遵守GB/T36624—2018的規(guī)定。當(dāng)PRF函數(shù)的輸出長度小于KEYMAT要求的密鑰素材長度時(shí)，應(yīng)利用反饋及連接方法加以擴(kuò)K1=PRF(SKEYID_d,protocolK2=PRF(SKEYID_d,K1IprotocolISPI|NiK3=PRF(SKEYID_d,K2IprotocolISPIINi_b方選擇)的不同的SPI保證了每個(gè)方向都有一個(gè)不同的KEYMAT。由SA的目的地選擇的SPI,被用圖3第二階段的ISAKMP信息交換HASH_1=PRF(SKEYID_a這個(gè)消息的加密使用對(duì)稱密碼算法的CBC工作模式，其密鑰使用SKEYID_e,初始化向量IV是最后一組密文和MsgID進(jìn)行Hash運(yùn)算所得到的，即IV=HASH(最后一組密文|MsgID)消息的填充和第一階段中的填充方式一樣。在第一階段密鑰交換過程中，如果一方要啟動(dòng)ISAKMP消息交換，則按照?qǐng)D4的消息交換格式進(jìn)行。如果雙方密鑰材料交換還未成功完成，則密所使用的對(duì)稱密碼算法、加密工作模式和加密密鑰跟第一階段中消息5和消息6中的加密工作機(jī)制完全一致。圖4第一階段的ISAKMP信息交換IPSec穿越NAT特性讓IPSec數(shù)據(jù)流能夠穿越網(wǎng)絡(luò)中的NAT設(shè)備。N9首先判斷通信的雙方是否支持NAT穿越，其次檢測雙方之間路徑上是否存在NAT,最后決定如何使用UDP封裝來處理NAT穿越。實(shí)現(xiàn)NAT穿越的NAT_D載荷分別添加在第一階段交換過程中消息3和消息4的載荷之后，這些載荷是獨(dú)立的，不參與交換過程的所有密碼運(yùn)算。支持NAT穿越的第一階段交換過程見圖5。消息序列發(fā)起方方向響應(yīng)方如果有必要，NAT_OA載荷分別添加在第二階段交換過程中消息1和消息2的載荷之后，同第二階段的消息載荷一起參與密碼運(yùn)算。實(shí)現(xiàn)NAT穿越的處理過程和消息格式應(yīng)按照RFC3947的規(guī)定發(fā)起務(wù)cookle下一個(gè)載荷交換類型Cookie的生成方法應(yīng)按照RFC2408的2.5.3要求生成。載荷類型的定義見表1。下一個(gè)載荷值無(None)0安全聯(lián)盟(Securityassociation)1下一個(gè)載荷值建議(Proposal)2變換(Transform)3密鑰交換(Keyexchange)4標(biāo)識(shí)(Identification)5證書(Certificate)6證書請(qǐng)求(CertificateRequest)7雜湊(HASH)8簽名(Signature)9通知(Notification)刪除(Delete)廠商(Vendor)對(duì)稱密鑰載荷(SK)保留(Reserved)私有使用(PrivateUse)交換類型無(None)0基本(Base)1身份保護(hù)(Identityprotection)2僅鑒別(Authenticationonly)3信息(Informational)5將來使用(Futureuse)DOI具體使用私有使用(Privateuse) 下一個(gè)載荷保留下一個(gè)載荷保留解釋域(DOI)值為1?！猄IT_IDENTITY_ONLY:其值為1,表明SA將由一個(gè)相關(guān)的標(biāo)識(shí)載荷中的源標(biāo)識(shí)信息來下一個(gè)載荷保留建議號(hào)變長的SPI值0ISAKMP的協(xié)議標(biāo)識(shí)符123IP壓縮的協(xié)議標(biāo)識(shí)符4變換載荷用于密鑰交換的發(fā)起方告知響應(yīng)方為一個(gè)指定的協(xié)議提供不同的型值為3。變換載荷的格式應(yīng)與圖10相符合。下一個(gè)載荷保留圖10變換載荷格式變換ID:這個(gè)字段的長度為1字節(jié)，用于表示建議協(xié)議的變換標(biāo)識(shí)符。在第一階段該字段的值為1,在第二階段根據(jù)不同的協(xié)議選用不同的變換ID。AH協(xié)議的變換ID的定義見表4。ESP協(xié)議的變換ID的定義見表5。表4AH協(xié)議的變換ID的定義值未使用值未使用0保留2:這個(gè)字段的長度為2字節(jié)，其值為0。當(dāng)為ESP協(xié)議選擇ESP_SM4_GCM變換時(shí)，由于SM4_GCM模式能同時(shí)為數(shù)據(jù)報(bào)文提供私密性和完整性校驗(yàn)服務(wù)，因此無需為ESP協(xié)議單獨(dú)協(xié)商完整性校驗(yàn)服務(wù)。本文件規(guī)定，當(dāng)為ES SM4_GCM變換時(shí)，SM4_GCM加密算法的輸入為啟動(dòng)變量S由IPSecSA協(xié)商時(shí)生成的4字節(jié)Salt 值和8字節(jié)初始化向量IV串接得到(啟動(dòng)變量S總長度為12字節(jié));額外可鑒別數(shù)據(jù)AAD為ESP頭中的4字節(jié)安全參數(shù)索引(SPI值)和序列號(hào)(如果雙方協(xié)商采用擴(kuò)展序列號(hào)屬性，則序列號(hào)為8字節(jié)，否則為4字節(jié))的串接，額外可鑒別數(shù)據(jù)AAD總長度為8字節(jié)或12字節(jié)。SM4_GCM加密算法的屬性類型0屬性類型為1,屬性值是定長的并且本載荷僅有2個(gè)字段，分別是屬性類型和屬性值。如果屬性類型是變長值123SA生存期(SALifeDuration)偽隨機(jī)函數(shù)(PRF)分組大小非對(duì)稱算法類型值SA生存期類型(SALifeType)1SA生存期(SALifeDuration)2封裝模式(EncapsulationMode)4鑒別算法(AuthenticationAlgorithm)5值密鑰長度(KeyLength)6密鑰輪數(shù)(KeyRounds)7壓縮字典長度(CompressDictionarySize)8私有壓縮算法(CompressPrivateAlgorithm)9擴(kuò)展序列號(hào)(ExtendedSequenceNumber)第一階段加密算法屬性值的定義見表8。表8第一階段加密算法屬性值的定義可選擇算法的名稱值名稱值SM3密碼雜湊算法第一階段鑒別方式屬性值的定義見表10。表10第一階段鑒別方式屬性值的定義名稱值公鑰數(shù)字信封鑒別方式適用于第一階段和第二階段的SA生存期類型屬性值的定義見表11。表11SA生存期類型屬性值的定義名稱值秒12第一階段公鑰算法類型屬性值的定義見表12。表12第一階段公鑰算法類型屬性值的定義名稱值2第二階段封裝模式屬性值的定義見表13。表13第二階段封裝模式屬性值的定義名稱值未使用0隧道模式1234第二階段鑒別算法屬性值的定義見表14。表14第二階段鑒別算法屬性值的定義名稱值未使用0當(dāng)為ESP協(xié)議協(xié)商的加密服務(wù)為SM4_GCM時(shí)，由于SM4_GCM可以同時(shí)提供加密和完整性校第二階段擴(kuò)展序列號(hào)屬性值的定義見表15。表15第二階段擴(kuò)展序列號(hào)屬性值的定義名稱值未使用01識(shí)載荷的格式應(yīng)與圖12相符合。一個(gè)，則該字段將被置為0。載荷類型由表1定義。荷長度。下一個(gè)載荷保留端口標(biāo)識(shí)類型：這個(gè)字段的長度為1字節(jié)，用于表示標(biāo)識(shí)數(shù)據(jù)字段中的身份信息類型。標(biāo)識(shí)類型的定義見表16。表16標(biāo)識(shí)類型的定義ID類型值未使用014個(gè)單班的(字節(jié)Ey?-地址5個(gè)帶有6字節(jié)子網(wǎng)掩碼的B?-地地一個(gè)的地址8一個(gè)1X.500的義本編碼于傳遞特定應(yīng)商信息的字菲流在第一階段可以使用的標(biāo)識(shí)類型ID_DER_ASN1_DN。在第二階段可以使用的標(biāo)識(shí)類型：協(xié)議ID:這個(gè)字段的長度為1字節(jié)，用于表示一個(gè)IP協(xié)議的上層協(xié)議號(hào)。值為0表明忽略這個(gè)字段，在第一階段這個(gè)值應(yīng)為0。在第二階段是用戶配置的安全策略五元組的協(xié)議，值為0表明忽略這個(gè)字段。端口：這個(gè)字段的長度為2字節(jié)，用于表示一個(gè)上層協(xié)議的端口。值為0表明忽略這個(gè)字段，在第一階段這個(gè)值應(yīng)為0。在第二階段是用戶配置的安全策略五元組的端口，值為0表明忽略這個(gè)字段。標(biāo)識(shí)數(shù)據(jù)：這個(gè)字段是變長的，用于表示與ID類型字段相對(duì)應(yīng)的標(biāo)識(shí)信息。證書載荷用于通信雙方交換證書以及證書相關(guān)信息，本載荷的類型值為6。下一個(gè)載荷保留見表17。值45下一個(gè)載荷保留下一個(gè)載荷保留與圖16相符合。下一個(gè)載荷保留圖16Nonce載荷格式下一個(gè)載荷保留解釋域(DOI)安全參數(shù)索引(SPI)通知類型值無效的載荷類型1不支持的DOI23456無效的交換類型7無效的標(biāo)志89無效的協(xié)議號(hào)無效的SPI無效的變換號(hào)ATTRIBUTES_NOT_SUPPOR無效的密鑰信息無效的ID信息無效的證書編碼無效的證書不支持的證書類型無效的證書機(jī)構(gòu)無效的HASH信息表18通知消息的錯(cuò)誤類型(續(xù))通知類型值失敗的鑒別無效的簽名地址通知安全聯(lián)盟生存周期通知證書不可用UNSUPPORTED_EXCHANGE不支持的交換類型保留值已連接保留(將來使用)私有(將來使用)保留(將來使用)下一個(gè)載荷保留解釋域(DOI)SPI數(shù)目安全參數(shù)索引(SPI表3所示。下一個(gè)載荷保留廠商ID(VID)圖19廠商ID載荷格式6.1.5.15NAT_D載荷下一個(gè)載荷保留圖20NAT_D載荷格式6.1.5.16NAT_OA載荷的類型值為21。NAT_OA載荷的載荷格式應(yīng)與圖21相符合。下一個(gè)載荷保留ID類型NAT_OA數(shù)據(jù)圖21NAT_OA載荷格式一個(gè)，則該字段將被置為0。載荷類型由表1定義。ID類型：這個(gè)字段的長度為1字節(jié)，其值為表16中的ID_IPV4_ADDR的值或ID_IPv6_ADDR保留2:這個(gè)字段的長度為3字節(jié)，其值為0。NAT_OA數(shù)據(jù)：這個(gè)字段的值是4字節(jié)IPv4地址或16字節(jié)IPv6地址。對(duì)稱密鑰載荷用于在密鑰交換第三階段時(shí)，傳遞數(shù)率信封中的風(fēng)稱密鑰本載荷的類型值為128。下一個(gè)載荷保留圖22對(duì)稱密鑰載荷格式下一個(gè)載荷這個(gè)字段的長度為1字節(jié)，標(biāo)識(shí)了本載荷后下一個(gè)載荷的類型。如果當(dāng)前載荷是最后一個(gè)，則該字段將被置為0。載荷類型由表1定義。密鑰交換消息是基于UDP傳輸?shù)?，使用UDP500端口或者4500端口。在UDP500端口上發(fā)送的密鑰交換消息直接跟在UDP報(bào)頭后面。在UDP4500端口上發(fā)送的密鑰交換消息，在UDP頭與密鑰交換消息之間插入4個(gè)全0的字節(jié)。每一條密鑰交換消息以消息頭HDR作為開始標(biāo)志。每個(gè)主模式消息1的數(shù)據(jù)包的格式應(yīng)與圖23相符合，其中SA載荷中應(yīng)支持SM4-SM3變換載荷。響應(yīng)方cookie版本號(hào)：0xll交換類型保留情形：1建議號(hào)1協(xié)議ID:1(ISAKMP)SPI長度0變換號(hào)1變換ID:1保留變換號(hào)2變換ID:1保留圖23主模式消息1的數(shù)據(jù)包格式發(fā)起方cookie響應(yīng)方cookie版本號(hào)：0xl1交換類型NP:6(證書)情形：1建議號(hào)1協(xié)議ID:1變換載荷數(shù)：1變換號(hào)1變換ID:1響應(yīng)方cookie版本號(hào)：0xl1交換類型受公鑰加密的對(duì)稱密鑰受對(duì)稱密鑰加密的Nonce數(shù)據(jù)受對(duì)稱密鑰加密的標(biāo)識(shí)數(shù)據(jù)證書編碼：5響應(yīng)方cookie版本號(hào)：0x11交換類型受公鑰加密的對(duì)稱密鑰受對(duì)稱密鑰加密的Nonce數(shù)據(jù)受對(duì)稱密鑰加密的標(biāo)識(shí)數(shù)據(jù)圖26主模式消息4的數(shù)據(jù)包格式6.1.6.6主模式消息5的數(shù)據(jù)包的格式主模式消息5的數(shù)據(jù)包格式應(yīng)與圖27相符合。發(fā)起方cookie響應(yīng)方cookie版本號(hào)：0x11交換類型標(biāo)志：1圖27主模式消息5的數(shù)據(jù)包格式6.1.6.7主模式消息6的數(shù)據(jù)的包格式主模式消息6的數(shù)據(jù)包的格式應(yīng)與圖28相符合發(fā)起方oieNP雜湊8版本號(hào)標(biāo)志?1消息ID:長度雜湊載荷圖28主模式消息6的數(shù)據(jù)包格式6.1.6.8快速模式消息1的數(shù)據(jù)包格式快速模式消息1的數(shù)據(jù)包的格式應(yīng)與圖29相符合，其中SA載荷中有一個(gè)ESP協(xié)議建議，建議中有兩種變換，其中一個(gè)為ESPSM4_CBC,另一個(gè)為ESP_SM4_GCM(并采用擴(kuò)展序列號(hào)機(jī)制)。發(fā)起方cookie響應(yīng)方cookie版本號(hào)：0xl1交換類型標(biāo)志：1情形：1建議號(hào)1協(xié)議ID:3(ESP)變換號(hào)1首選變換中各屬性載荷(包括擴(kuò)展序列號(hào)屬性載荷)ID類型ID類型圖29快速模式消息1的數(shù)據(jù)包格式發(fā)起方cookie響應(yīng)方cookie版本號(hào)：0xll1交換類型標(biāo)志：1情形：1建議號(hào)1協(xié)議ID:3(ESP)變換載荷數(shù)：1變換號(hào)1變換中各屬性載荷(包括擴(kuò)展序列號(hào)屬性載荷)ID類型ID類型圖30快速模式消息2的數(shù)據(jù)包格式響應(yīng)方cookie版本號(hào)：0xl1交換類型消息ID:隨機(jī)產(chǎn)生下一個(gè)頭保留安全參數(shù)索引(SPI)鑒別數(shù)據(jù)(變長的)圖32AH頭格式務(wù)。發(fā)送方的計(jì)數(shù)器和接收方的計(jì)數(shù)器在建立一個(gè)SA時(shí)被初始化為0,該序列號(hào)在一個(gè)SA生存期內(nèi)展序列號(hào)的使用方法可參考RFC4302的附錄B和RFC4303的附錄A。6.2.1.3鑒別頭AH的處理AH頭在傳輸模式和隧道模式中分別有不同的放置位置。在IPv4環(huán)境中使用傳輸模式，AH頭應(yīng)放在原IP頭之后，上層協(xié)IPvIPv4封裝前圖33IPv4的AH傳輸模式在IPv6環(huán)境中使用傳輸模式，AH頭被看作是一個(gè)端到端的載荷，因而應(yīng)出現(xiàn)在逐跳(Hop-by-Hop)、路由(Routing)和分片擴(kuò)展頭(FragmentationExtensionheadenationOptionsExtensionHeader)nationOptionsExtensionHeader)既可以出現(xiàn)在AH頭之前，也可以在AH頭之后(見圖34)。新IP報(bào)文中的認(rèn)證范圍擴(kuò)展頭新IP報(bào)文中的認(rèn)證范圍IPv6封裝前圖34IPv6的AH傳輸模式在隧道模式中，AH頭保護(hù)整個(gè)IP報(bào)文，包括整個(gè)原IP報(bào)文以及新建外部IP頭的部分字段。圖35和圖36分別表示了隧道模式中典型的IPv4和IPv6報(bào)文的AH頭的位置。(所有選項(xiàng))新建外部IP頭*IPv6封裝前圖35IPv4的AHIPv6封裝前(如果存在)IPv6封裝后IPvIPv4封裝前新IP報(bào)文中的認(rèn)證范圍6.2.1.3.2.2查找SA6.2.1.3.2.4.2IPv4中的ICV計(jì)算IPv4基本頭字段、IPv4頭的選項(xiàng)、AH頭和上層協(xié)議數(shù)據(jù)都參與ICV計(jì)算。IPv4頭的整個(gè)選項(xiàng)被看作一個(gè)單元，選項(xiàng)中的類型和長度字段在傳送中是不變的，但如果有一個(gè)字段是屬于可變的，則整個(gè)選項(xiàng)用于計(jì)算ICV時(shí)都要清“0”整個(gè)AH頭參與ICV計(jì)算，其中完整性校驗(yàn)值字段在計(jì)算ICV之前置Q”,在計(jì)算后，將計(jì)算得到的值賦于該字段。整個(gè)上層協(xié)議數(shù)據(jù)直接參與ICV計(jì)算。IPv6基本頭字段中，直接參與計(jì)算的字段為版本(Verston我確長度ayloadLength)、下一個(gè)極限(HopLinit)。選項(xiàng)包含有一位，該位指出透項(xiàng)有傳送過程期間是否會(huì)改變一劉工在路由過程中內(nèi)容可能改變的任何選項(xiàng)，整個(gè)選項(xiàng)數(shù)據(jù)(OptionData寧段在耳磨和校驗(yàn)1Cv畫應(yīng)被當(dāng)作零值的字節(jié)串對(duì)待。選項(xiàng)類型被包括進(jìn)ICV計(jì)算。整個(gè)AH頭參與ICV計(jì)算，其中鑒別數(shù)據(jù)字段在計(jì)算ICV之前置“0”在計(jì)算后，將計(jì)算得到的值賦于該字段。整個(gè)上層協(xié)議數(shù)據(jù)直接參與ICV計(jì)算。AH頭中的鑒別數(shù)據(jù)字段應(yīng)確保是4字節(jié)(IPv4)或8字節(jié)(IPv6)的整數(shù)倍，否則應(yīng)填充。填充應(yīng)放在鑒別數(shù)據(jù)字段的最末端，其內(nèi)容由發(fā)送方任意選擇，并且參與ICV計(jì)算。一個(gè)IPSec實(shí)現(xiàn)在AH處理之后，如果發(fā)現(xiàn)IP數(shù)據(jù)報(bào)文長度超過輸出接口的MTU值，則對(duì)處理后的數(shù)據(jù)報(bào)文進(jìn)行分片。入站報(bào)文的處理包括重組、查找SA、驗(yàn)證序列號(hào)和驗(yàn)證完整性校驗(yàn)值過程。6.2.1.3.3.3查找SA安全參數(shù)索引(SPI)載荷數(shù)據(jù)(變長)填充(變長)填充長度下一個(gè)頭鑒別數(shù)據(jù)(變長)圖37ESP-頭格式安全參數(shù)索引SPI是一個(gè)4字節(jié)值，它與目的IP地址和安全協(xié)議共同標(biāo)識(shí)了這個(gè)數(shù)據(jù)報(bào)文的安全方的計(jì)數(shù)器和接收方的計(jì)數(shù)器在建豆一個(gè)被初始內(nèi)0,該序列號(hào)在一個(gè)sA星存期內(nèi)不能循環(huán)IV應(yīng)置于載荷數(shù)據(jù)首部填充的方法和內(nèi)容應(yīng)由指定的加密算法規(guī)定。如果加密算法沒有規(guī)定，則附加在報(bào)文之后的第一個(gè)字節(jié)為1,后續(xù)的填充字節(jié)按單調(diào)遞增的順序拼湊。填充長度字段指出了填充字節(jié)的個(gè)數(shù)。有效值范圍是0～255,其中0表明沒有填充字節(jié)。下一個(gè)頭是一個(gè)1字節(jié)的字段，該字段指定了ESP頭后面下一個(gè)載荷的類型。這個(gè)字段的值是由在ESP協(xié)議選擇了完整性校驗(yàn)服務(wù)時(shí)，鑒別數(shù)據(jù)是對(duì)ESP報(bào)文去掉ICV外的其余部分進(jìn)行完整簽T,長度為16字節(jié)。ESP頭在傳輸模式和隧道模式中分別有不同的放置位置。在IPv4環(huán)境中使用傳輸模式，ESP應(yīng)放在IP頭和它包含的所有選項(xiàng)之后和上層協(xié)議之前(見(如UDP)原IP頭*原IP頭(如果存在)(如UDP)在IPv4和IPv6中使用隧道模式，ESP(所有選項(xiàng))(如UDP)IPv4封裝后IPv4封裝后新建外部IP頭*數(shù)據(jù)ESP尾ESP認(rèn)證數(shù)據(jù)原IP頭IPv6封裝前IPv6封裝前(如果存在)(如UDP)IPv6封裝后IPv6封裝后新建外部IP頭ESP原IP頭數(shù)據(jù)ESP尾ESP認(rèn)證數(shù)圖41IPv6的ESP隧道模式6.2.2.3.2.2查找SA接收窗口的大小默認(rèn)為64。算方法和參與計(jì)算的內(nèi)容與出站報(bào)文計(jì)算ICV的一致。計(jì)算的結(jié)果與報(bào)文中的ICV進(jìn)行比較。如果如果為ESP協(xié)議協(xié)商的是ESP_SM4_GCM變換，則驗(yàn)證完整性校驗(yàn)值的操作在執(zhí)行解密報(bào)文的如果為ESP協(xié)議協(xié)商的是ESP_SM4_GCM變換，則SM4_GCM解密算法輸入為：額外鑒別數(shù)據(jù)AAD為ESP頭中的安全參數(shù)索引(SPI值)和序列號(hào)(4字節(jié)或8字節(jié))的串接；啟動(dòng)變量S為SA協(xié)商時(shí)得到的4字節(jié)Salt值和8字節(jié)IV值的串接；T為ESP報(bào)文尾部的數(shù)據(jù)鑒別字段中獲取的ICV值。為了穿越NAT,在UDP報(bào)文中封裝和解封裝ESP報(bào)文的方法按RFC3948的要求實(shí)現(xiàn)。IPSecVPN產(chǎn)品使用的隨機(jī)數(shù)應(yīng)采用安全方式生成，隨機(jī)數(shù)質(zhì)量應(yīng)符合GM/T0005—2021要求。IPSecVPN產(chǎn)品應(yīng)支持ESP單獨(dú)使用時(shí)NAT穿越。IPSecVPN產(chǎn)品應(yīng)支持IPv4協(xié)議或IPv6協(xié)議。IPSecVPN產(chǎn)品應(yīng)具有根據(jù)時(shí)間周期和報(bào)文流量兩種條件進(jìn)行工作密鑰和會(huì)話密鑰的更新功加解密吞吐率是指分別在64字節(jié)以太幀長和1428字節(jié)(IPv6是1408字節(jié))以太幀長時(shí)，IPSecVPN產(chǎn)品在丟包率為0的條件下內(nèi)網(wǎng)口上達(dá)到的雙向數(shù)據(jù)最大流量。產(chǎn)品應(yīng)滿足用戶網(wǎng)絡(luò)環(huán)境對(duì)網(wǎng)絡(luò)數(shù)據(jù)加解密吞吐性能的要求。加解密時(shí)延是指分別在64字節(jié)以太幀長和1428字節(jié)(IPv6是1408字節(jié))以太幀長時(shí)，IPSecVPN產(chǎn)品在丟包率為0的條件下，一個(gè)明文數(shù)據(jù)流經(jīng)加密變?yōu)槊芪模儆擅芪慕饷苓€原為明文所消耗的平均時(shí)間。產(chǎn)品應(yīng)滿足用戶網(wǎng)絡(luò)環(huán)境對(duì)網(wǎng)絡(luò)數(shù)據(jù)加解密時(shí)延性能的要求。這里要注意，在計(jì)算加解密時(shí)延7.2.3加解密丟包率加解密丟包率是指分別在64字節(jié)以太幀長和1428字節(jié)(IPv6是08字節(jié))以太幀長時(shí)，在IPSecVPN產(chǎn)品內(nèi)網(wǎng)口處于線速情況下，單位時(shí)間內(nèi)錯(cuò)誤或丟失的數(shù)據(jù)包占總發(fā)數(shù)據(jù)包數(shù)量的百分比。產(chǎn)品應(yīng)滿足用戶網(wǎng)絡(luò)環(huán)境對(duì)網(wǎng)絡(luò)數(shù)據(jù)加解密丟包率性能的要求。7.2.4每秒新建連接數(shù)每秒新建連接數(shù)是指IPSccVPN彥品在上露的時(shí)間單位內(nèi)能夠建立隧道數(shù)目的最大值。產(chǎn)品應(yīng)滿足用戶網(wǎng)絡(luò)環(huán)境對(duì)每秒新建連接數(shù)作能的要求。7.3安全管理要求7.3.1.1設(shè)備密鑰設(shè)備密鑰是非對(duì)稱密鑰二包括簽名密鑰對(duì)和翅密密鑰對(duì)。于向CA認(rèn)證機(jī)構(gòu)申請(qǐng)證書加密密鑰對(duì)由CA的密鑰管理系統(tǒng)產(chǎn)生，并在申請(qǐng)簽名證書時(shí)由CA一并簽發(fā)加密證書，簽名證書、加密證書和用保護(hù)機(jī)制保護(hù)的加密私鑰應(yīng)能被導(dǎo)IPSecVPN產(chǎn)品中，其中私鑰保護(hù)應(yīng)遵循GM/T0016要求。簽名證書、加密證書和加密密鑰對(duì)的私鑰應(yīng)能被導(dǎo)入IPSecVPN產(chǎn)品中在IPSecVPN產(chǎn)品中，設(shè)備密鑰的私鑰應(yīng)有安全保護(hù)措施。設(shè)備密鑰應(yīng)按設(shè)定的安全策略進(jìn)行更新。設(shè)備密鑰可以安全形式進(jìn)行備份，并在有必要時(shí)能夠恢復(fù)。工作密鑰在密鑰交換的第一階段產(chǎn)生，產(chǎn)生后應(yīng)保存在易失性存儲(chǔ)器中，達(dá)到其更新條件后應(yīng)立即會(huì)話密鑰在密鑰交換的第二階段產(chǎn)生，產(chǎn)生后應(yīng)保存在易失性存儲(chǔ)器中，達(dá)到其更新條件后應(yīng)立即產(chǎn)品啟動(dòng)時(shí)，應(yīng)對(duì)密碼運(yùn)算部件或模塊關(guān)鍵部件或模塊進(jìn)行正確性檢查。應(yīng)對(duì)包括存儲(chǔ)密鑰在內(nèi)的敏感信息進(jìn)行完整性檢查。在檢查不通過時(shí)應(yīng)報(bào)警并停止工作。在工藝設(shè)計(jì)、硬件配置等方面要采取相應(yīng)的保護(hù)措施，保證設(shè)備基本的物理安全防護(hù)功能。8.1產(chǎn)品功能檢測8.1.1隨機(jī)數(shù)功能按照GM/T0005-2021的要求提取樣本，并按照該標(biāo)準(zhǔn)的相關(guān)要求進(jìn)行檢測，檢測結(jié)果應(yīng)合格。測試產(chǎn)品在出廠狀態(tài)下建立一條Sec配置，查著其密碼套件配置選項(xiàng)，默認(rèn)使用的算法應(yīng)為SM2、SM3SM等國家密碼算人將測試產(chǎn)晶與被測產(chǎn)品均沒為隧道模生應(yīng)能成功完成密鑰交換，建立IPSec隧道進(jìn)行通信。被測產(chǎn)品支持傳輸模式時(shí)平測試產(chǎn)品與被測產(chǎn)鼠均設(shè)置近存輸模式的應(yīng)能成功完成密鑰交換，進(jìn)行通信。將測試意品與被測產(chǎn)品一方設(shè)置為隧道模式方設(shè)置為傳輸模式，密鑰交換應(yīng)失敗，無法建立IPSec隧道進(jìn)行通信8.1.4密鑰交換密鑰交換的檢測按7.1.4的方法進(jìn)行。對(duì)密鑰交換過程進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)截獲，查看其過程應(yīng)符合6.1的要求，應(yīng)能正確進(jìn)行加解密通信。該項(xiàng)測試通過，可以間接證明設(shè)備采用的對(duì)稱密碼算法、非對(duì)稱密碼算法和密碼雜湊算法的實(shí)現(xiàn)正確性。將測試產(chǎn)品與被測產(chǎn)品的安全報(bào)文封裝協(xié)議均配置為ESP協(xié)議，對(duì)通信的報(bào)文進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)截獲，查看其封裝格式應(yīng)符合6.2的要求，應(yīng)能正確進(jìn)行加解密通信。將測試產(chǎn)品與被測產(chǎn)品的安全報(bào)文封裝協(xié)議均配置為AH協(xié)議嵌套ESP協(xié)議，對(duì)通信的報(bào)文進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)截獲，查看其封裝格式應(yīng)符合6.2的要求，應(yīng)能正確進(jìn)行加解密通信。將被測產(chǎn)品放在NAT下，與測試產(chǎn)