主动模式下IPsec 9个包分析

时间  2021-01-21 标签 Linux高级网络编程 IPSec v*n

第一阶段：ISAKMP协商阶段

1.1 第一包

  • 包1：发起端协商SA，使用的是UDP协议，端口号是500，上层协议是ISAKMP，该协议提供的是一个框架，里面的负载Next payload类似模块，可以自由使用。可以看到发起端提供了自己的cookie值，以及SA的加密套件，加密套件主要是加密算法，哈希算法，认证算法，生存时间等。

  • Initiator cookie：817622ea01367ec9

发起者的cookie值，告知响应端主机要使用IPSEC的哪一把密钥来加密这个封包。

  • Responder cookie：0000000000000000

响应者的cookie值，第一个包只有发起者没有响应者所以响应者的cookie为空

  • Version：1.0

IKE版本号，1.0表示使用IKE v1建立连接

  • Exchange type:Identity Protection (Main Mode) (2)

IKE协商模式为主模式

  • Life-Type (11): Seconds (1)

生存期时间的单位为秒

  • Life-Duration (12): Duration-Value (86400)

密钥周期86400，密钥周期超过86400后会重新协商IKE

  • Encryption-Algorithm (1): AES-CBC (7)

IKE使用DES-CBC加密算法加密数据

  • Hash-Algorithm (2): SHA (2)

IKE使用SHA算法校验数据完整性

  • Authentication-Method (3): RSA-SIG (3)

RSA方式进行认证，除此之外还有与共享秘钥(Pre-shared key)

  • Group-Description (4): Alternate 1024-bit MODP group (2)

Diffie-Hellman (DH) 组在密钥交换进程中使用的1024 bit的密钥的强度

  • Key-Length (14): Key-Length (128)

秘钥长度128位

1.2第二包

包2：响应端收到发送端发送的加密套件后，对比自己是否有相对应的加密套件，如果有就使用和发送端相同的加密套件加密数据，把自己的cookie值和选择好的加密套件发送给发送端；如果没有相同加密套件则IKE建立失败响应。

  • Initiator cookie：817622ea01367ec9

发起者的cookie值，告知响应端主机要使用IPSEC的哪一把密钥来加密这个封包。

  • Responder cookie: 58E452AA5DC6679B

响应者的cookie值，告知发起端主机要使用IPSEC的哪一把密钥来加密这个封包

  • Version：1.0

IKE版本号，1.0表示使用IKE v1建立连接

  • Exchange type:Identity Protection (Main Mode) (2)

IKE协商模式为主模式

  • Life-Type (11): Seconds (1)

生存期时间的单位为秒

  • Life-Duration (12): Duration-Value (86400)

密钥周期86400，密钥周期超过86400后会重新协商IKE

  • Encryption-Algorithm (1): AES-CBC (7)

IKE使用DES-CBC加密算法加密数据

  • Hash-Algorithm (2): SHA (2)

IKE使用SHA算法校验数据完整性

  • Authentication-Method (3): RSA-SIG (3)

RSA方式进行认证，除此之外还有与共享秘钥(Pre-shared key)

  • Group-Description (4): Alternate 1024-bit MODP group (2)

Diffie-Hellman (DH) 组在密钥交换进程中使用的1024 bit的密钥的强度

  • Key-Length (14): Key-Length (128)

秘钥长度128位

1.3第三包

包3：发送端生成随机数和DH公共值，包3的主要目的是向响应端发送自己的DH公共值和Nonce随机数。用于生成加密时所需要的KEY值。(生成三把钥匙)

 cookie：817622ea01367ec9

发起者的cookie值，告知响应端主机要使用IPSEC的哪一把密钥来加密这个封包。

  • Responder cookie: 58E452AA5DC6679B

响应者的cookie值，告知发起端主机要使用IPSEC的哪一把密钥来加密这个封包

  • Version：1.0

IKE版本号，1.0表示使用ikev1建立连接

  • Exchange type:Identity Protection (Main Mode) (2)

 IKE协商模式为主模式

  • Key Exchange Data: 6bdd2d265808783f234725716b99323d7501818e939a640fcb8fd0d3be2ad3dfceed7efefaad3e52c371d90fcfd92bf75f0b663c7f06dbcd6139daaee3c9872f808302328cacd4f26a0063d50ade8e3af764b5467728ec1146d5e71d6bd0a53acfc5adc81719971e0f5ed77d0b628d6ec1a59e24208e59364e8e16ab71499e79

DH公共值，DH公共值通过Diffie-Hellman算法计算出来；在包1和包2中所协商的算法，它们必须需要一个相同的KEY（即，共享密钥中设置的密码），但同时这个KEY不能在链路中传递。所以，该过程的目的是分别在两个对等体间独立地生成一个DH公共值，然后在报文中发送给对端，对端通过公式计算出相同的KEY值。

1.4第四包

包4：响应端收到包3后，自己生成一个随机数，然后通过Diffie-Hellman算法计算出DH公共值，把随机数和DH公共值传输给发送端。(生成三把钥匙)

  • Initiator cookie：817622ea01367ec9

发起者的cookie值，告知响应端主机要使用IPSEC的哪一把密钥来加密这个封包。

  • Responder cookie: 58E452AA5DC6679B

响应者的cookie值，告知发起端主机要使用IPSEC的哪一把密钥来加密这个封包

  • Version：1.0

IKE版本号，1.0表示使用ikev1建立连接

  • Exchange type:Identity Protection (Main Mode) (2)

 IKE协商模式为主模式

  • Key Exchange Data: 9e2652cf76c9a0a40e9f04a10046b8e6a3f3ed653c5792c58dee602f050a127067df9e9f9b7d90a1830369bc3054dedc7429e62cc0d7e0b559e0cb412cb508aaaa7d6d2fc24b843b444cf95ba1fbd6302a3cab1c1440e1d1e7f2f21697839171ef62f33dff54b51d841cedda71fccdab1f4072a58b88d7604464dab150246e84

DH公共值，DH公共值通过Diffie-Hellman算法计算出来。

1.5第五包

  • 包5：发起方发起身份验证，报文中带有认证的数据（预共享密钥或者数字签名）。由于包1和包2已经协商好了加密算法，包3和包4协商好了加密的KEY值，所以包5的消息被加密了。（使用第一把钥匙）

  • Initiator cookie：817622ea01367ec9

发起者的cookie值，告知响应端主机要使用IPSEC的哪一把密钥来加密这个封包。

  • Responder cookie: 58E452AA5DC6679B

响应者的cookie值，告知发起端主机要使用IPSEC的哪一把密钥来加密这个封包

  • Version：1.0

IKE版本号，1.0表示使用ikev1建立连接

  • Exchange type:Identity Protection (Main Mode) (2)

 IKE协商模式为主模式

  • Encrypted payload (304 bytes)

加密后的数据

1.6第六包

  • 包6：响应端回应报文，同样发送认证的数据（预共享密钥或者数字签名），验证对方身份信息。包6的数据同样使用包1、包2协商的算法和包3、包4协商的key值加密数据，所以包6的认证数据是加密的。双方身份验证通过后，IKE协商结束。

  • Initiator cookie：817622ea01367ec9

发起者的cookie值，告知响应端主机要使用IPSEC的哪一把密钥来加密这个封包。

  • Responder cookie: 58E452AA5DC6679B

响应者的cookie值，告知发起端主机要使用IPSEC的哪一把密钥来加密这个封包

  • Version：1.0

IKE版本号，1.0表示使用ikev1建立连接

  • Exchange type:Identity Protection (Main Mode) (2)

 IKE协商模式为主模式

  • Encrypted payload (304 bytes)

加密后的数据

 

第二阶段：IPSec SA协商阶段

2.1第七包

  • 包7：发起方主要是进行IPSEC SA的协商，建立安全联盟，报文内容主要是协商用的封装方式以及后面的加密算法以及生存时间和感兴趣流等等。由于数据加密所以无法查看。

  • Initiator cookie: 817622EA01367EC9

发起者的cookie值是由上阶段IKE协商时已经确定的，所以IPSec协商依然使用上阶段的cookie

  • Responder cookie: 58E452AA5DC6679B

响应者的cookie值是由上阶段IKE协商时已经确定的，所以IPSec协商依然使用上阶段的cookie

  • Next payload: Hash (8)

 

  • Version：1.0

IKE版本号，1.0表示使用ikev1建立连接

  • Exchange type：Quick Mode（32）

交换类型使用快速模式，IPSec协商时只有快速模式

  • Encrypted payload (128 bytes)

被加密的数据，主要为感兴趣流、加密策略协商。（这里使用第二把钥匙进行加密）

2.2第八包

  • 包8：响应方回包，同意包7发送的封装方式、加密算法、生存时间、感兴趣流等等，同时，也能起到确认收到对端消息的作用。由于数据加密所以无法查看。

  • Initiator cookie: 817622EA01367EC9

发起者的cookie值是由上阶段IKE协商时已经确定的，所以IPSec协商依然使用上阶段的cookie

  • Responder cookie: 58E452AA5DC6679B

响应者的cookie值是由上阶段IKE协商时已经确定的，所以IPSec协商依然使用上阶段的cookie

  • Next payload: Hash (8)

 

  • Version：1.0

IKE版本号，1.0表示使用ikev1建立连接

  • Exchange type：Quick Mode（32）

交换类型使用快速模式，IPSec协商时只有快速模式

  • Encrypted payload (128 bytes)

被加密的数据，主要为感兴趣流、加密策略协商。（这里使用第二把钥匙进行加密）

2.3第九包

  • 包9：发送确认报文。其中包含一个HASH，其作用是确认接收方的消息以及证明发送方处于主动状态（表示发送方的第一条消息不是伪造的）。由于数据加密所以无法查看。

  • Initiator cookie: 817622EA01367EC9

发起者的cookie值是由上阶段IKE协商时已经确定的，所以IPSec协商依然使用上阶段的cookie

  • Responder cookie: 58E452AA5DC6679B

响应者的cookie值是由上阶段IKE协商时已经确定的，所以IPSec协商依然使用上阶段的cookie

  • Next payload: Hash (8)

 

  • Version：1.0

IKE版本号，1.0表示使用ikev1建立连接

  • Exchange type：Quick Mode（32）

交换类型使用快速模式，IPSec协商时只有快速模式

  • Encrypted payload (128 bytes)

被加密的数据，主要为感兴趣流、加密策略协商。（这里使用第二把钥匙进行加密）

联系我们 沪ICP备13005482号-10