2.4 IKE阶段1协商过程

一、第1、2个数据包的核心定位这两个数据包属于IKE主模式的阶段1安全提议协商阶段核心作用是让通信双方交换各自支持的IKE安全参数并从中匹配出一套双方都能接受的共同参数为后续所有密钥协商和身份认证奠定算法基础。关键特征此阶段消息完全明文传输不涉及任何密钥或身份信息仅交换算法配置参数。二、具体交换过程第1包→第2包1. 第1个数据包发起方→响应方发起方发送安全提议发起方如VPN客户端向响应方如VPN服务器发送第一个数据包核心包含1类关键参数——IKE安全提议SA PayloadIKE安全提议SA Proposal包含以下参数参数类别具体内容说明加密算法DES、3DES、AES-128、AES-256 等用于后续消息的对称加密Hash算法MD5、SHA-1、SHA-256、SHA-384 等用于完整性校验和身份认证DH组Diffie-Hellman Group组1768位、组21024位、组51536位、组142048位等决定密钥交换的安全强度认证方式预共享密钥PSK、数字签名RSA/DSA、加密临时值EAP等用于后续身份验证IKE SA 生命周期如 86400 秒SA有效时长超时需重新协商发起方通常会在一个数据包中携带多个安全提议多个Transform组合按优先级从高到低排列供响应方选择。2. 第2个数据包响应方→发起方响应方确认安全提议响应方收到第1包后执行以下处理流程步骤1查找匹配的安全策略响应方查找本地的SPD安全策略数据库检查是否存在与发起方身份匹配的安全策略。步骤2选择匹配的安全提议响应方从发起方提供的安全提议列表中按以下逻辑挑选遍历发起方的安全提议列表从高优先级到低优先级将每个提议与本地配置的IKE策略进行对比找到第一个完全匹配的安全提议组合步骤3生成并发送响应Cookie响应方会生成自己的Cookie一个由IP地址、端口、时间戳等通过哈希生成的唯一标识并添加到第2包的ISAKMP头部中。步骤4回复确认响应方将选中的安全提议仅保留双方匹配的那一套参数封装在响应数据包中发回给发起方。第2个数据包核心内容内容说明确认的SA载荷仅包含双方匹配的一套安全参数加密算法、Hash、DH组、认证方式等响应方Cookie响应方生成的唯一标识用于后续协商中标识此SA如果没有任何安全提议匹配响应方将回复一个包含错误通知的数据包协商终止。3. 关键补充Cookie的作用消息1和2中都包含字段说明发起方Cookie发起方在第1包中生成固定不变响应方Cookie响应方在第2包中生成固定不变Cookie的两大作用抗DoS攻击响应方在验证Cookie有效前不分配资源防止恶意发起方伪造大量源IP消耗服务器资源。唯一标识IKE SA在后续所有IKE消息中通过(发起方Cookie, 响应方Cookie)唯一标识此IKE协商会话。三、第1、2包核心总结数据包发送方向交换的核心内容本地生成是否加密第1包发起方→响应方IKE安全提议列表多套加密算法、Hash算法、DH组、认证方式组合发起方Cookie❌ 明文第2包响应方→发起方确认的单套安全提议 响应方Cookie响应方Cookie❌ 明文核心成果第1、2包完成后双方已就IKE SA的安全参数集达成一致包括✅ 加密算法如 AES-256✅ Hash算法如 SHA-256✅ DH组如 组14/2048位✅ 认证方式如 预共享密钥✅ IKE SA生命周期但这些参数尚未用于任何加密操作因为真正的密钥共享密钥、加密密钥、认证密钥要在第3、4包DH交换之后才能生成。第1、2包在整个IKE主模式中的位置┌──────────────────────────────────────────────────────────────┐ │ IKE主模式6条消息 │ ├──────────────────────────────────────────────────────────────┤ │ 步骤1SA参数协商消息1-2 ← 当前阶段明文传输 │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 消息1发起方发送多个SA提议加密/Hash/DH/认证 │ │ │ │ 消息2响应方选择一个匹配的SA提议 自己的Cookie │ │ │ └─────────────────────────────────────────────────────┘ │ ├──────────────────────────────────────────────────────────────┤ │ 步骤2DH公钥与Nonce交换消息3-4← 生成共享密钥 │ ├──────────────────────────────────────────────────────────────┤ │ 步骤3身份认证与密钥确认消息5-6← 加密传输身份信息 │ └──────────────────────────────────────────────────────────────┘主模式三个交互过程六个消息交互在IKE主模式协商中第3、4个数据包阶段2DH公钥与Nonce交换是密钥体系的核心奠基阶段核心目的是交换“密钥派生所需的原始参数”并在双方本地生成“共享密钥”。以下是详细过程一、第3、4个数据包的核心定位这两个数据包属于IKE主模式的阶段2密钥材料交换阶段作用是让通信双方如VPN客户端与服务器交换“非对称密钥参数”和“随机数”为后续生成所有密钥提供“原始素材”且此阶段消息本身不加密、仅包含公开参数。二、具体交换过程第3包→第4包第3个数据包发起方→响应方发起方发送自身的公开参数发起方如VPN客户端向响应方如VPN服务器发送一个数据包核心包含2类关键公开参数发起方的DH公钥Initiators DH Public Key类型非对称加密算法DH算法的公开密钥是发起方通过DH算法本地生成的“公钥-私钥对”中的公钥部分。作用用于响应方后续计算“共享密钥”的核心参数之一。发起方的NonceInitiators Nonce类型一串随机生成的字节序列无固定格式仅需双方一致认可长度且每次IKE协商都会生成全新的Nonce。作用防止“重放攻击”避免攻击者复用旧协商消息同时是后续生成“主密钥”的关键参数之一。第4个数据包响应方→发起方响应方发送自身的公开参数响应方收到第3包后向发起方回复一个数据包同样包含2类对称的公开参数响应方的DH公钥Responders DH Public Key类型响应方通过DH算法本地生成的“公钥-私钥对”中的公钥部分。作用与发起方的DH私钥配合供发起方本地计算“共享密钥”。响应方的NonceResponders Nonce类型响应方独立生成的全新随机字节序列。作用与发起方Nonce共同构成“主密钥”的派生材料进一步提升密钥随机性。三、此阶段生成的密钥共享密钥Shared Secret第3、4包交换完成后双方不会通过网络传输任何密钥而是在各自本地使用“自身私钥对方公钥”计算生成完全相同的“共享密钥”具体逻辑如下生成参数仅需本地参数无需传输发起方本地计算参数发起方DH私钥 响应方DH公钥来自第4包响应方本地计算参数响应方DH私钥 发起方DH公钥来自第3包生成过程双方基于相同的DH算法如DH、ECDH用上述参数进行数学运算本质是离散对数计算最终得到完全一致的共享密钥因DH算法的特性双方计算结果必然相同。共享密钥的作用共享密钥是整个IKE密钥体系的“源头材料”自身不直接参与消息加密/认证仅用于后续阶段阶段3派生“主密钥”再由主密钥派生“加密密钥”和“认证密钥”。四、阶段2第3、4包核心总结数据包发送方向交换的核心参数本地生成的密钥密钥生成参数第3包发起方→响应方发起方DH公钥、发起方Nonce----第4包响应方→发起方响应方DH公钥、响应方Nonce共享密钥自身DH私钥 对方DH公钥来自对端数据包在IKE主模式协商中第5、6个数据包阶段3身份认证与密钥确认阶段是“敏感信息加密传输身份合法性验证”的核心环节所有敏感内容均通过特定密钥加密且需对应的密钥解密具体过程如下一、第5、6个数据包的核心定位此阶段的核心是双方用阶段2生成的共享密钥派生的“加密密钥”和“认证密钥”加密传输自身身份信息并验证对方身份合法性确保协商双方是“预先约定的合法主体”。二、前置关键先明确此阶段用的2个核心密钥在处理第5、6包前双方已通过“共享密钥第3、4包交换的双方Nonce”经哈希算法如SHA256本地派生完成主密钥Master Key再从主密钥中进一步派生出2个会话密钥仅用于此阶段及后续会话加密密钥Encryption Key用于加密第5、6包中的敏感消息内容防泄露。认证密钥Authentication Key用于生成/验证消息的“完整性标签如HMAC值”防篡改、验身份。注双方派生的加密密钥、认证密钥完全相同且仅本地持有不通过网络传输。三、具体交换过程第5包→第6包第5个数据包发起方→响应方发起方加密传输身份并提供认证发起方如VPN客户端会先构建“敏感消息内容”再用上述2个密钥处理后发送具体步骤步骤1构建待加密的敏感内容明文核心包含“发起方身份标识如客户端IP、设备ID”和“认证数据如预共享密钥的哈希值用于验证身份”这些信息若明文传输会被窃取必须加密。步骤2用“加密密钥”加密敏感内容发起方使用协商好的对称加密算法如AES-256配合加密密钥对上述敏感内容进行加密生成“加密后的密文payload”防止内容泄露。步骤3用“认证密钥”生成完整性标签发起方对“整个第5包的消息头加密后的密文payload”使用哈希算法如HMAC-SHA256和认证密钥生成一个“认证标签HMAC值”附加在数据包末尾防止消息被篡改。步骤4发送第5包最终发送的第5包 消息头 加密后的密文payload 认证标签。第6个数据包响应方→发起方响应方解密验证加密回复响应方收到第5包后先验证消息合法性再用相同逻辑回复具体步骤步骤1用“认证密钥”验证消息完整性响应方提取第5包的“消息头密文payload”使用相同的认证密钥和哈希算法重新计算HMAC值与收到的“认证标签”对比若一致说明消息未被篡改且发送方持有合法的认证密钥间接证明是“约定的发起方”若不一致直接丢弃数据包协商终止。步骤2用“加密密钥”解密敏感内容验证通过后响应方使用相同的加密密钥和对称加密算法对第5包的“密文payload”进行解密得到发起方的身份标识和认证数据完成发起方身份验证。步骤3响应方构建自身的加密认证消息响应方重复发起方的逻辑构建自身的身份标识和认证数据明文用加密密钥加密生成密文payload用认证密钥生成认证标签附加在数据包后。步骤4发送第6包最终发送的第6包消息头响应方加密后的密文payload 响应方的认证标签。发起方验证第6包协商收尾发起方收到第6包后重复响应方的验证逻辑用认证密钥验证第6包的认证标签防篡改用加密密钥解密第6包的密文payload获取响应方身份完成响应方身份验证。双方身份均验证通过后IKE主模式协商完成后续数据传输将使用此阶段的密钥或派生的会话密钥。四、第5、6包核心密钥使用总结操作场景使用的密钥核心目的发起方加密敏感内容第5包加密密钥防止身份等敏感信息泄露发起方生成认证标签第5包认证密钥防止消息被篡改响应方验证第5包完整性认证密钥确认消息未篡改、发起方合法响应方解密第5包密文加密密钥获取发起方身份验证身份响应方加密敏感内容第6包加密密钥防止自身身份信息泄露响应方生成认证标签第6包认证密钥防止自身回复消息被篡改发起方验证第6包完整性认证密钥确认消息未篡改、响应方合法发起方解密第6包密文加密密钥获取响应方身份验证身份关键结论第5、6包的“加密/解密”仅用加密密钥“完整性验证/标签生成”仅用认证密钥二者分工明确且均来自“共享密钥双方Nonce”派生的主密钥。野蛮模式三个交互过程三个消息交互IKE野蛮模式Aggressive Mode是IKEv1协商安全联盟第一阶段的一种模式主要用于建立IKE SA。与主模式相比它减少了交换信息的数目能提高协商速度但未对身份信息进行加密保护。其具体过程如下消息①发起方发送协商提议等信息发起方发送一个或多个IKE安全提议包含加密算法、认证算法、认证身份和Diffie-Hellman公共值、必需的辅助信息以及自身身份。由于身份信息是明文发送存在身份泄露的隐患。消息②响应方回应协商提议等信息响应方根据发起方的提议查找最先匹配的IKE安全提议。响应方还会使用预共享密钥计算hash并将其包含在消息中辅助信息和身份信息供发起方认证。消息③发起方认证及回应发起方根据响应方的身份信息进行hash计算与响应方提供的hash进行比较。如果一致则身份认证通过然后向响应方发送认证消息以及相关的认证数据等用于响应方对发起方的认证。响应方收到后验证发起方的认证数据若通过则IKE SA协商成功。IKE SA协商完毕之后可利用该SA协商IPsec SA从第三条报文开始都是加密传输的。