IKEv2协议关键知识点总结整理

文章目录

@[toc]1. IKEv2基本原理2. IKEv2协议重点注意事项2.1 情景一：==IKEv2协商密钥逻辑==①密钥协商流程②函数调用关系③流程简述 2.2 情景二：==使用IKEv2时，协商报文认证失败==①初步分析定位②函数调用关系③IKEv2的重点说明3.1 常用的加解密、认证算法：3.2 IKEv1与IKEv2在建议载荷上的区别3.3 关于配置参数问题 2.3 情景三：==与业务流量相关注意事项==①函数调用关系②重点说明3.1 PRF算法的使用3.2 关键名词

1. IKEv2基本原理

IKEv2基本原理介绍

2. IKEv2协议重点注意事项

2.1 情景一：IKEv2协商密钥逻辑

①密钥协商流程

pluto调试信息如下：

... ... 6.26 14:7:36 pluto(52881): KEY length: SK_d=0 SK_ai=0 SK_ar=0 SK_ei=0 SK_er=0 SK_pi=0 SK_pr=0 6.26 14:7:36 pluto(52881): shared: 12 16 4d 32 b8 3e 1e cb fe c4 08 29 dd 8d 14 31 6.26 14:7:36 pluto(52881): 07 29 0f 14 41 84 ea d3 50 9f ed 43 55 a7 e9 96 6.26 14:7:36 pluto(52881): a4 16 e6 47 a2 af ed 8b e4 1e 51 d2 bd 52 49 f0 6.26 14:7:36 pluto(52881): 18 1f d6 66 dd 8c 4e 43 52 78 4e 2a 1d 36 6d f8 6.26 14:7:36 pluto(52881): b2 2b e2 bd 1e c4 e4 bf cc 54 dd 99 1b 92 04 4e 6.26 14:7:36 pluto(52881): dd f5 b1 b3 43 84 df 22 bd e8 ef d3 05 c8 be bf 6.26 14:7:36 pluto(52881): skeyseed: 81 4d 5e 9f c1 7f 82 5b 75 73 f8 13 da f6 7b 20 6.26 14:7:36 pluto(52881): 3e a0 39 24 6.26 14:7:36 pluto(52881): SK_d: 6.26 14:7:36 pluto(52881): SK_ai: 6.26 14:7:36 pluto(52881): SK_ar: 6.26 14:7:36 pluto(52881): SK_ei: 6.26 14:7:36 pluto(52881): SK_er: 6.26 14:7:36 pluto(52881): SK_pi: 6.26 14:7:36 pluto(52881): SK_pr: 6.26 14:7:36 pluto(52881): ikev2 parent inI2outR2: calculating g^{xy}, sending R2 6.26 14:7:36 pluto(52881): processing connection IKEv1 6.26 14:7:36 pluto(52881): decrypting as RESPONDER, using INITIATOR keys

②函数调用关系

ikev2parent_inI2outR2 start_dh_v2 send_crypto_helper_request pluto_do_crypto_op case pcr_build_kenonce:case pcr_build_nonce:case pcr_compute_dh_iv:case pcr_compute_dh:case pcr_compute_dh_v2: calc_dh_v2 sharedskeyseedSK_dSK_aiSK_arSK_eiSK_erSK_piSK_pr ikev2_parent_inI2outR2_tail finish_dh_v2 st->st_sharedst->st_skey_dst->st_skey_aist->st_skey_arst->st_skey_eist->st_skey_erst->st_skey_pist->st_skey_pr

③流程简述

IKEv2协商使用四个报文两次交换便完成IPSec隧道的协商建立。前两个报文用来协商IKE-SA的策略，发起方在收到响应方的应答后进行密钥的计算，而响应方是在收到发起方第三个报文后再进行各个密钥的计算生成(也就是ikev2_parent_inI2outR2()中，最终调用calc_dh_v2()完成密钥生成)，之后在ikev2_parent_inI2outR2_tail()中通过finish_dh_v2()将生成的密钥存储在state上。

2.2 情景二：使用IKEv2时，协商报文认证失败

①初步分析定位

通过抓包发现是在收到第三个协商报文后，出现错误导致没有应答报文。打开pluto日志信息发现时由于认证失败导致的。而发起方在收到第四个报文后也会出现该问题。下面时发前方收到第四个报文后的信息。

7.1 9:33:7 pluto(49216): ikev2 parent inR2: calculating g^{xy} in order to decrypt I2 7.1 9:33:7 pluto(49216): decrypting as INITIATOR, using RESPONDER keys 7.1 9:33:7 pluto(49216): data being hmac: 65 d0 57 0a 93 0c 90 ac a9 d9 44 45 75 56 1a f2 7.1 9:33:7 pluto(49216): 2e 20 23 20 00 00 00 01 00 00 00 74 24 00 00 58 7.1 9:33:7 pluto(49216): ee 58 f5 c7 50 d4 6e 87 db 11 4f 36 b7 e7 92 0c 7.1 9:33:7 pluto(49216): a3 cb ff e5 54 c3 f1 47 f4 17 ca 2e 26 99 10 c0 7.1 9:33:7 pluto(49216): d0 90 5a aa 51 33 c0 27 53 6c 36 a3 d9 c0 b8 3b 7.1 9:33:7 pluto(49216): 0f 6c fa a9 4a 9a 7d f6 c3 12 eb 04 04 c6 7e fc 7.1 9:33:7 pluto(49216): bd 97 f6 4e 79 58 04 39 7.1 9:33:7 pluto(49216): R2 calculated auth: 05 e1 bf 2d 1a ba 0e ea 9a cd 1f 23 7.1 9:33:7 pluto(49216): R2 provided auth: f4 17 ca 2e 26 99 10 c0 50 d4 6e 87 7.1 9:33:7 pluto(49216): R2 failed to match authenticator

②函数调用关系

ikev2parent_inR2 ikev2_decrypt_msg 认证(就是报文的完整性检查) authkey = &pst->st_skey_ar; 认证密钥pst->st_oakley.integ_hasher；认证算法实际的报文认证部分； 认证数据计算哈希值；认证结果比较收到的认证数据与计算出的数据 解密 cipherkey = &pst->st_skey_er;pst->st_oakley.encrypter从报文中获取初始向量：IV… … ikev2_process_encrypted_payloads 解析每一个载荷

---

ikev2parent_inR1outI2 或 ikev2_parent_inI1outR1_tail ikev2_parse_parent_sa_body sadb = oakley_alg_makedb(st->st_connection->alg_info_ike；本地策略转换为SAsa_v2_convert(sadb)； IKEv1 SA转换为IKEv2 SA。ikev2_process_transforms； 解析对方的建议载荷ikev2_match_transform_list_parent； 将对端建议载荷与本端配置进行匹配填充加密算法：ta.encrypter填充认证算法：ta.integ_hasher填充PRF算法：ta.prf_hasher填充DH组：ta.group将算法存储到state上：st->st_oakley = ta;

③IKEv2的重点说明

3.1 常用的加解密、认证算法：

这里需要注意的一点是：完整性检测算法(认证算法)有两个标准算法：MD5， SHA1；他们的hash_integ_len是固定的96bits==12Bytes。

static struct hash_desc crypto_hasher_md5 = { common: {name: "oakley_md5", officname: "md5", algo_type: IKE_ALG_HASH, algo_id: OAKLEY_MD5, algo_v2id: IKEv2_PRF_HMAC_MD5, algo_next: NULL, }, hash_ctx_size: sizeof(MD5_CTX), hash_key_size: MD5_DIGEST_SIZE, hash_digest_len: MD5_DIGEST_SIZE, hash_integ_len: 0, /*Not applicable*/ hash_init: (void (*)(void *)) osMD5Init, hash_update: (void (*)(void *, const u_int8_t *, size_t)) osMD5Update, hash_final: (void (*)(u_char *, void *)) osMD5Final, }; static struct hash_desc crypto_integ_md5 = { common: {name: "oakley_md5", officname: "md5", algo_type: IKE_ALG_INTEG, algo_id: OAKLEY_MD5, algo_v2id: IKEv2_AUTH_HMAC_MD5_96, algo_next: NULL, }, hash_ctx_size: sizeof(MD5_CTX), hash_key_size: MD5_DIGEST_SIZE, hash_digest_len: MD5_DIGEST_SIZE, hash_integ_len: MD5_DIGEST_SIZE_96, hash_init: (void (*)(void *)) osMD5Init, hash_update: (void (*)(void *, const u_int8_t *, size_t)) osMD5Update, hash_final: (void (*)(u_char *, void *)) osMD5Final, }; static struct hash_desc crypto_hasher_sha1 = { common: {name: "oakley_sha", officname: "sha1", algo_type: IKE_ALG_HASH, algo_id: OAKLEY_SHA, algo_v2id: IKEv2_PRF_HMAC_SHA1, algo_next: NULL, }, hash_ctx_size: sizeof(SHA1_CTX), hash_key_size: SHA1_DIGEST_SIZE, hash_digest_len: SHA1_DIGEST_SIZE, hash_integ_len: 0, /*Not applicable*/ hash_init: (void (*)(void *)) SHA1Init, hash_update: (void (*)(void *, const u_int8_t *, size_t)) SHA1Update, hash_final: (void (*)(u_char *, void *)) SHA1Final, }; static struct hash_desc crypto_integ_sha1 = { common: {name: "oakley_sha", officname: "sha1", algo_type: IKE_ALG_INTEG, algo_id: OAKLEY_SHA, algo_v2id: IKEv2_AUTH_HMAC_SHA1_96, algo_next: NULL, }, hash_ctx_size: sizeof(SHA1_CTX), hash_key_size: SHA1_DIGEST_SIZE, hash_digest_len: SHA1_DIGEST_SIZE, hash_integ_len: SHA1_DIGEST_SIZE_96, hash_init: (void (*)(void *)) SHA1Init, hash_update: (void (*)(void *, const u_int8_t *, size_t)) SHA1Update, hash_final: (void (*)(u_char *, void *)) SHA1Final, };

3.2 IKEv1与IKEv2在建议载荷上的区别

IKEv2的建议载荷： IKEv1的建议载荷： IKEv1与IKEv2除了载荷类型不同，报文的结构也发生了变化，IKEv2中没有了属性载荷，相反IKEv1中的每一个属性载荷对应IKEv2中的一个变化载荷。因此IKEv2在oakley_alg_makedb()生成SA后需要sa_v2_convert()进行依次格式转换，转换为IKEv2的SA格式。

3.3 关于配置参数问题

3.3.1 IPSec隧道IKE-SA协商阶段可以配置的参数：

认证方式： 预共享密钥数字证书 加密算法 DES3DESAESSM4 哈希算法 MD5SHA1SM3 DH组 DH1DH2DH5openswan源码中的DH包含： enum ike_trans_type_dh { OAKLEY_GROUP_MODP768 = 1, OAKLEY_GROUP_MODP1024 = 2, OAKLEY_GROUP_GP155 = 3, OAKLEY_GROUP_GP185 = 4, OAKLEY_GROUP_MODP1536 = 5, OAKLEY_GROUP_MODP2048 = 14, OAKLEY_GROUP_MODP3072 = 15, OAKLEY_GROUP_MODP4096 = 16, OAKLEY_GROUP_MODP6144 = 17, OAKLEY_GROUP_MODP8192 = 18, #ifdef USE_MODP_RFC5114 OAKLEY_GROUP_DH22 = 22, OAKLEY_GROUP_DH23 = 23, OAKLEY_GROUP_DH24 = 24, #endif };

3.3.2 IKEv2中PRF算法是怎么来的：

PRF算法与认证算法都是使用hash进行计算的，NGFW中无法进行单独配置，而是同时配置两者保持一致。除此之外：MD5和SHA1算法的值是相同的在PRF算法和完整性算法中

PRF算法包括：

enum ikev2_trans_type_prf { IKEv2_PRF_HMAC_MD5 = 1, /* RFC2104 */ IKEv2_PRF_HMAC_SHA1 = 2, /* RFC2104 */ IKEv2_PRF_HMAC_TIGER = 3, /* RFC2104 */ IKEv2_PRF_AES128_XCBC = 4, /* RFC4434 */ IKEv2_PRF_HMAC_SHA2_256 = 5, /* RFC4868 */ IKEv2_PRF_HMAC_SHA2_384 = 6, /* RFC4868 */ IKEv2_PRF_HMAC_SHA2_512 = 7, /* RFC4868 */ IKEv2_PRF_AES128_CMAC = 8, /* RFC4615 */ /* 9 - 1023 Reserved to IANA RFC4306 */ /* 1024 - 65535 Private Use RFC4306 */ IKEv2_PRF_INVALID = 65536, };

认证算法(完整性算法)包括：

enum ikev2_trans_type_integ { IKEv2_AUTH_NONE = 0, /* RFC4306 */ IKEv2_AUTH_HMAC_MD5_96 = 1, /* RFC2403 */ IKEv2_AUTH_HMAC_SHA1_96 = 2, /* RFC2404 */ IKEv2_AUTH_DES_MAC = 3, /* RFC4306 */ IKEv2_AUTH_KPDK_MD5 = 4, /* RFC1826 */ IKEv2_AUTH_AES_XCBC_96 = 5, /* RFC3566 */ IKEv2_AUTH_HMAC_MD5_128 = 6, /* RFC4595 */ IKEv2_AUTH_HMAC_SHA1_160 = 7, /* RFC4595 */ IKEv2_AUTH_AES_CMAC_96 = 8, /* RFC4494 */ IKEv2_AUTH_AES_128_GMAC = 9, /* RFC4543 */ IKEv2_AUTH_AES_192_GMAC = 10, /* RFC4543 */ IKEv2_AUTH_AES_256_GMAC = 11, /* RFC4543 */ IKEv2_AUTH_HMAC_SHA2_256_128 = 12, /* RFC4595 */ IKEv2_AUTH_HMAC_SHA2_384_192 = 13, /* RFC4306 */ IKEv2_AUTH_HMAC_SHA2_512_256 = 14, /* RFC4306 */ /* 15 - 1023 Reserved to IANA RFC4306 */ /* 1024 - 65535 Private Use RFC4306 */ IKEv2_AUTH_INVALID =65536 };

2.3 情景三：与业务流量相关注意事项

①函数调用关系

ikev2parent_inR2 ikev2_decrypt_msg 完整性检查 st->st_oakley.integ_hasher ikev2_decode_peer_idikev2_decode_local_idPRF计算ID的HASH值v2_AUTH_RSA ikev2_verify_rsa_sha1 v2_AUTH_SHARED ikev2_verify_psk_auth ikev2_calculate_psk_sighash get_preshared_secretst->st_oakley.prf_hasher对端的首包对端的Nonce载荷数据对端的ID的哈希值 ikev2_child_validate_responder_proposalikev2_parse_child_sa_body p2alg = kernel_alg_makedb(c->policy , c->alg_info_esp; 根据当前配置生成IPSecSA载荷sa_v2_convert； 将IPSecSA载荷转换为IKEv2的格式类型ikev2_process_transforms； 解析对端响应的ipsec-SA的建议载荷ikev2_match_transform_list_child；本端配置和对端选择的ipsec-SA载荷进行匹配ta.encrypter； 保存加密算法ta.integ_hash； 保存完整性检测算法st->st_esp.attrs.transattrs = ta; 将匹配的算法存储到state上st->st_esp.present = TRUE; 封装协议标记位 ikev2_child_notify_processikev2_derive_child_keys 最关键的生成数据流量秘钥函数接口 childsacalc.prf_hasherchildsacalc.nichildsacalc.nrchildsacalc.spiichildsacalc.spirchildsacalc.skeyseed = &st->st_skey_d; 使用了st->st_skey_dst->st_esp.present = TRUE;st->st_esp.keymat_len=enc_len + auth_len;st->st_esp.peer_keymat=v2genbytes(childsacalc, …)st->st_esp.our_keymat=v2genbytes(childsacalc, …) install_ipsec_sa … …

②重点说明

3.1 PRF算法的使用

在IKEv2中PRF算法的应用场景有：

认证数据来源的可靠性

例如ikev2_calculate_psk_sighash()中使用PRF算法、ID、共享秘钥、对端首包、对端Nonce等对数据报文进行认证，从而确保数据包来源的可靠性。

生成IPSec SA的加密秘钥和认证秘钥

在ikev2_derive_child_keys()中，使用PRF算法、双方的Nonce值、SPI、以及先前生成的st_skey_d等生成用于数据流量的加密、认证等的秘钥材料。

3.2 关键名词

完整性

即对报文的完整性检查，在ipsec中经常也称为认证(authenticator), 它是对整个报文做哈希(准确的说应该不是整个报文)，然后将结果添加到报文的末尾。 这个长度目前好像是固定的12字节，即96位（MD5和SHA1都是）。它使用st->st_oakley.integ_hasher进行哈希。见上图中最后12字节数据。

认证载荷

个人理解认证载荷是为了保证数据来源的可靠性，一般包括两种：预共享秘钥和数字证书。它的检查更为严格，以共享秘钥为例：它会对对方的首个报文、Nonce值、ID值同时计算哈希，而不仅仅计算当前报文的内容。认证载荷中填充的数据便是对端对上述内容计算的哈希值。