数据传输安全-IKE工作过程

发布于：2025-08-28 ⋅ 阅读:(18) ⋅ 点赞:(0)

在前面的课程中，你已经掌握了：

  1. IPSec的目标：提供机密性、完整性、身份认证、防重放。

  2. IPSec的执行者：AH和ESP协议。

  3. IPSec的规则手册：SA（安全关联），包含了所有保护参数（算法、密钥、模式等）。

  4. SA的创建方式：手工配置（麻烦、不安全）或自动协商（IKE）。

本课程就是深入讲解“自动协商”这个环节，即 IKE协议是如何工作的。它解决了最根本的问题：如何在不安全的网络上，安全地协商出那些需要用来保护网络安全的秘密参数（尤其是密钥）？

一、IKE的工作过程

1.IKE协议概述与基础

1.1  IKE定义

IKE是一种混合型协议，用于在IPSec通信双方之间，动态地、自动地建立、协商、管理和删除安全关联（SA）。

1.2 IKE的组成

 IKE的组成：一个混合协议

IKE不是一个从零设计的协议，而是一个“集大成者”，它建立在由ISAKMP定义的框架上，并实现了Oakley和SKEME两种协议的一部分功能。

协议组件 角色与贡献 简单理解
ISAKMP
(Internet Security Association and Key Management Protocol)		 定义了协商、建立、修改和删除SA的过程和报文格式（即“怎么谈”）。
注意：ISAKMP只提供了一个通用框架，它本身不定义具体的密钥交换方式或认证方式。		 定义了语言的语法和结构。比如，问句怎么开头，答句怎么结尾。但它不管具体问什么内容。
Oakley 描述了一系列被称为“模式”的密钥交换方法（即“用什么方法谈”），其核心是Diffie-Hellman密钥交换的多种变体。 提供了多种具体的对话技巧。比如，如何通过三步对话达成一个共识，或者如何通过五步对话来达成。
SKEME 提供了一种快速的密钥交换机制，并支持公钥加密认证等概念。 提供了快速达成共识和验证对方身份的方法。

结论：IKE = ISAKMP的框架 + Oakley的交换模式 + SKEME的共享和密钥更新技术。

3.IKE的版本

IKE主要有两个版本：

IKEv1 ：

  • 特点：功能强大且成熟，但协议较复杂，报文交换数量多，有多个模式（主模式、野蛮模式、快速模式）。

  • IKEv1协议直接使用ISAKMP定义的报文结构和交换模式。

IKEv2 (RFC 7296)：

  • 是IKEv1的演进版本，目前已成为新部署项目的首选。

  • 特点：

    • 更简洁：交换次数更少（通常4次报文交换即可完成双向认证和IPSec SA建立）。

    • 更安全：修复了IKEv1的一些已知漏洞。

    • 更可靠：内置了 NAT-T（NAT穿越）支持和更强大的存活检测机制。

    • 效率更高：报文结构更优化。

2. IKE的报文结构

IKE报文是通过UDP协议传输的，其整体结构可以分解为以下三层：

| IP头部 | UDP头部 (源端口500, 目的端口500) | ISAKMP报文 |

其中最核心、最复杂的就是 ISAKMP报文。

一个ISAKMP报文由 一个通用头部 和 一串链接起来的载荷 组成。

ISAKMP报文是IKEv1协议的载体，所有IKEv1的协商（主模式、野蛮模式、快速模式）都通过交换ISAKMP报文完成。其结构分为两大块：固定长度的通用头部 和 可变长度的载荷链。

2.1通用头部

发起方：

应答方：

下一个载荷：

版本号：

交换类型：

标志：

报文ID：

报文长度：

2.2 载荷

载荷是挂在ISAKMP头部后面、真正携带协商信息的数据块。多种不同类型的载荷通过“下一个载荷”字段像链条一样连接起来。

载荷通用头部：每个载荷都以一个简单的头部开始：

  • 下一个载荷 (1字节)：指向链中下一个载荷的类型。如果这是最后一个载荷，则该字段为0。

  • 保留 (1字节) |

  • 载荷长度 (2字节)：当前载荷的总长度（包括本头部）。

3.IKE协商的两个阶段

阶段一：建立IKE SA

2.1 目的

  • 验证对端身份真实性。

  • 协商出一个双向的IKE SA（管理SA），用于保护第二阶段的通信。

2.2 两种模式

  • 主模式 - 6个报文

    • 特点：身份保护（Identity Protection），第5/6报文才交换身份信息且已加密。

    • 过程：三组报文交换（策略协商、DH交换、身份认证）。

  • 野蛮模式- 3个报文

    • 特点：速度快，但身份信息在明文阶段交换。

    • 适用场景：适合对端IP地址不固定（如动态IP）、且对身份暴露不敏感的情况。

2.3 IKE协商第一阶段过程分析

第1、2个报文：协商安全策略（明文交换）

  • 过程：

    1. （报文1） 发起方(RA)将自己支持的所有IKE策略（一个或多个策略套件）放在SA载荷中发送给响应方(RB)。

      • 每个策略套件包含：加密算法（如AES）、散列算法（如SHA）、认证方法（如pre-share）、DH组（如group 14）、生存时间。

    2. （报文2） 响应方(RB)收到后，在自己的策略库中寻找优先级最高且完全匹配的策略，并将该策略通过SA载荷发回给发起方。

  • 状态：明文传输。此时尚未建立安全通道。

  • 结果：双方就保护IKE SA的安全参数达成一致。如果找不到匹配项，协商就此失败。

第3、4个报文：交换DH公共值和随机数（明文交换）

  • 目的：生成共享密钥的“种子”，为后续所有加密和认证提供基础。

  • 过程：

    1. （报文3） 发起方(RA)生成一个DH私钥，计算出对应的DH公钥，放入KE载荷（Key Exchange）。同时，生成一个随机数Ni，放入Nonce载荷。一并发送给对方。

    2. （报文4） 响应方(RB)执行相同的操作：生成自己的DH私钥，计算DH公钥放入KE载荷，生成随机数Nr放入Nonce载荷，发回给发起方。

  • 状态：明文传输。KE和Nonce载荷本身不需要加密，因为DH算法的安全性基于数学难题（离散对数）。

  • 结果：

    • 双方各自使用对方的DH公钥和自己的DH私钥，通过DH算法独立计算出相同的共享秘密 g^ab。这个值从未在网络上传输过。

    • 双方都拥有了两个随机数 Ni 和 Nr。

DH算法

DH的安全性基于一个数学难题：计算离散对数在有限域中是非常困难的。我们用一个经典的“颜色混合”比喻来理解它：

  1. 公开约定公共参数：

    • 通信双方（Alice和Bob）公开约定一种公共颜色（黄色）。这对应DH算法中的公共参数（一个大质数 p 和一个底数 g）。在IKE中，这由选择的 DH组（Group） 决定。

  2. 各自选择私有数字：

    • Alice秘密地选择一个私密数字（Private Key） a。

    • Bob也秘密地选择自己的私密数字（Private Key） b。

    • a 和 b 是核心秘密，永远不告诉任何人，也不在网络上传送。

  3. 计算并交换公共值：

    • Alice用自己的私密数字 a 和公共颜色（黄色）进行混合，得到一种新的混合色（橘色）。她将橘色发送给Bob。

    • Bob用自己的私密数字 b 和公共颜色（黄色）进行混合，得到一种新的混合色（绿色）。他将绿色发送给Alice。

    • 这个过程对应数学运算：A = g^a mod p (Alice计算) 和 B = g^b mod p (Bob计算)。

    • 这里的 A 和 B 就是各自的 DH公钥，对应IKE报文中的 KE载荷，是在网络上明文传输的。

  4. 双方计算最终共享秘密：

    • Alice收到Bob的绿色后，再加入自己的私密数字 a 进行混合，得到最终的颜色（棕色）。

    • Bob收到Alice的橘色后，再加入自己的私密数字 b 进行混合，得到最终的颜色（同样是棕色）。

    • 这个过程对应数学运算：

      • Alice计算：B^a mod p = (g^b)^a mod p = g^{ba} mod p

      • Bob计算：A^b mod p = (g^a)^b mod p = g^{ab} mod p

    • 由于 g^{ab} = g^{ba}，双方独立计算出了完全相同的数字，这个数字就是 DH共享秘密 g^{ab}。

关键点：窃听者（Eve）可以看到公共颜色（黄色）、Alice的混合色（橘色）和Bob的混合色（绿色）。但从这些颜色中，她几乎无法分离出最终的棕色。数学上，从公钥 A 或 B 反推私钥 a 或 b（离散对数问题）在计算上是不可行的。

DH组定义了密钥交换的强度。组号越大，使用的质数 p 越大，计算出的共享秘密 g^{ab} 就越长，安全性越高，但计算开销也越大。（回顾）

第5、6个报文：身份认证（加密交换）

  • 目的：验证对端身份的真实性。确认你正在和“正确的人”通信，而不是中间人。

  • 过程：

    1. （密钥衍生） 在交换3、4报文后，双方已经可以计算出共享秘密 g^ab 并拥有随机数 Ni, Nr 和Cookie CKYi, CKYr。它们会使用一个伪随机函数(PRF)，结合预共享密钥，衍生出三把关键的密钥：

      • SKEYID_e：用于加密后续IKE报文的密钥。

      • SKEYID_a：用于认证（完整性验证）后续IKE报文的密钥。

      • SKEYID_d：作为种子，用于衍生IPSec SA的密钥。
        例如：SKEYID = prf(pre-shared-key, Ni | Nr)

    2. （报文5 - 已加密） 发起方(RA)使用刚生成的 SKEYID_e 和 SKEYID_a 对ID载荷（身份信息，如IP地址）和Hash载荷进行计算和加密，然后发送给响应方。

      • Hash_I = prf(SKEYID, RA's_IP | RB's_IP | CKYi | CKYr | SA_offer | IDi)

    3. （报文6 - 已加密） 响应方(RB)收到后，先用 SKEYID_e 解密，再用相同的算法和本地信息计算一个Hash值。如果与自己收到的 Hash_I 完全一致，则证明：

      • 消息未被篡改（完整性）。

      • 发起方拥有正确的预共享密钥（身份认证）。
        验证通过后，响应方以同样方式发送自己的ID和Hash载荷给发起方进行验证。

  • 状态：加密传输。从第5个报文开始，所有载荷均被 SKEYID_e 加密，并用 SKEYID_a 进行认证。

  • 结果：完成双向身份认证。至此，一个安全的、经过认证的IKE SA正式建立。

总结：

❓“DH交换是在哪个阶段完成的？为什么它不怕被窃听？”

"DH交换是在IKE阶段一的第3和第4个报文中完成的。

它不怕被窃听是因为其安全性基于计算离散对数的数学难题。虽然双方在网络上明文传输了各自的DH公钥（g^a mod p 和 g^b mod p），但窃听者无法从这些公钥中反算出双方的私钥 a 和 b，因此也就无法计算出双方最终协商出的共享秘密 g^{ab} mod p。这个共享秘密本身从未在链路上出现過。"

❓“IKE阶段一是如何实现身份认证的？”

"IKE阶段一主要通过验证对方是否拥有相同的预共享密钥或数字证书来实现身份认证。

以预共享密钥为例：

  1. 双方在完成DH交换后，会使用预共享密钥、交换的随机数（Nonce）等参数，衍生出一个认证密钥（SKEYID_a）。

  2. 随后，双方会计算一个哈希值（例如 Hash_I），这个哈希值的内容包含了身份信息和之前的协商参数，并用 SKEYID_a 作为密钥。

  3. 这个哈希值在加密通道中交换。接收方用相同的本地参数和预共享密钥重新计算一遍。

  4. 如果计算出的哈希值与对方发来的完全一致，就证明对方拥有正确的预共享密钥，身份认证通过。如果不一致，协商立即终止。"

❓“主模式和野蛮模式的主要区别是什么？”（野蛮模式更快但身份明文传输，且只有3个报文）

"主模式和野蛮模式的主要区别有三点：

  1. 报文数量与速度：主模式是6次报文交换，速度较慢；野蛮模式只有3次交换，速度更快。

  2. 身份保护：这是最核心的区别。主模式的身份交换（ID载荷）在加密后的第5、6报文中进行，隐藏了身份信息。而野蛮模式的身份信息在明文的第1、2报文中就交换了，无法提供身份保护。

  3. 适用场景：主模式更安全通用。野蛮模式通常用于对端IP地址不固定（如动态IP）且对身份信息暴露不敏感的特殊场景。"

阶段二：建立IPSec SA

2.3 目标

在IKE SA的保护下，协商用于保护用户数据的IPSec SA。

2.4 快速模式 - 3个报文

  • 所有报文均被IKE SA的加密和认证功能所保护。

  • 协商IPSec SA的具体参数：协议（AH/ESP）、模式（传输/隧道）、算法、生存期、受保护的数据流等。

2.5 IKE阶段二（快速模式）过程

第1个报文：发起提议

  • 目的：发起方(RA)提出保护用户数据的IPSec SA策略。

  • 载荷内容：

    • SA载荷：包含一个或多个提议载荷和变换载荷，详细定义了IPSec SA的参数：

      • 安全协议：是使用 ESP 还是 AH？

      • 封装模式：是传输模式还是隧道模式？

      • 加密算法：用于数据的算法（如AES-256）和密钥长度。

      • 认证算法：用于数据完整性的算法（如SHA256）。

      • 生存时间：IPSec SA的有效期（时间或流量）。

    • Nonce载荷：发送一个新的随机数 Ni2，用于保证交换的新鲜性，防止重放攻击，并参与新密钥的生成。

    • (可选) KE载荷：如果启用了完美前向保密（PFS），则会包含一个新的DH公钥，用于一次全新的DH交换。

    • ID载荷：标识要保护的数据流（通常由ACL定义），例如 源IP：192.168.1.0/24 -> 目标IP: 192.168.2.0/24。

    • Hash载荷：用于对消息进行认证。

第2个报文：响应应答

  • 目的：响应方(RB)接受发起方的提案，并参与生成新密钥。

  • 过程：

    1. RB 收到报文后，用IKE SA的密钥（SKEYID_e和SKEYID_a）进行解密和验证。

    2. 在自己的配置中查找与收到的提案匹配的IPSec策略。

    3. 如果找到，RB 会生成自己的随机数 Nr2。

    4. RB 构建一个回应报文，其载荷结构与报文1类似：

      • SA载荷：指明所接受的提议。

      • Nonce载荷：携带 Nr2。

      • (可选) KE载荷：如果对方请求了PFS，则也返回自己的新DH公钥。

      • ID载荷：标识数据流。

      • Hash载荷：计算一个新的Hash值进行回应和认证。

第3个报文：确认

  • 目的：发起方(RA)对响应方的应答进行最终确认，完成协商。

  • 过程：

    1. RA 收到报文后，同样进行解密和验证。

    2. 验证通过后，RA 发送第三个也是最后一个报文。

    3. 这个报文通常只包含一个Hash载荷，作为对整个快速模式交换的确认。

  • 结果：收到此报文后，双方都认为IPSec SA已成功建立，可以开始用来保护用户数据了。

总结：

网站公告

今日签到

点亮在社区的每一天
去签到

热门文章

最新发布