IPSec协议

简介

IPSec（Internet Protocol Security）：一组基于网络层，密码学的安全通信协议族。不具体指哪个协议，而是一个协议族。可用于VPN或单纯加密数据。

IPSec协议族

ESP：Encapsulating Security Payload，封装安全载荷协议
- ESP完整性检测
  
  ESP报文最后有一个验证数据字段，数据验证字段包含完整性校验值 (ICV)，也称为消息身份验证码，用于验证消息身份验证与完整性。接收方计算 ICV 值并对照发送方计算的值校验它，以验证完整性。ICV 是通过 ESP 报头、负载数据与 ESP 尾端计算的。
- ESP防窃听
  
  ESP通过3DES、DES、AES机密算法加密数据，做到防窃听功能
- ESP防重放
  
  作为可选功能，ESP还能进行防重放保护。防重放保护验证每个报文是唯一的且没有被复制，这种保护确保黑客不能拦截报文和在数据流中插入改变后的报文
  - 跟踪报文顺序号并在目的端使用一个滑动窗口。当在源和目的间建立了一条连接时，两端的计数器被初始化为0
  - 每次有报文发送时，源给报文追加一个顺序号，目的端使用滑动窗口确定预期的顺序号。目的端验证的报文的顺序号不是复制的，并且以正确的顺序被接收
  - 举例
    - 客户端发送ESP封装报文到服务端，序列号为81
    - 服务端响应报文通过ESP加密，响应报文的序列号为81
    - 客户端收到服务端发送的ESP报文后，查看ESP序列号，序列号排序正确则没有重放，排序错误则出现重放
AH：Authentication Header，报文头验证协议

功能：数据完整性、数据源验证、抗报文重放。
SA：Security Association，安全联盟

即AH和ESP协议所使用的密码算法和安全参数集合。通过IKE协议来协商SA。

SA包括：

数据校验算法、加密算法、工作模式(传输或隧道)、密钥生存期等
IKE：Internet密钥交换协议，一个UDP应用层协议

功能：用于协商SA

总结：

AH只能数据源验证、数据完整性校验、防报文重放。
ESP不仅包含AH所有功能外，还可加密IP报文。
IKE协议作用是协商SA，SA就是具体AH和ESP使用的加密校验参数。
IKE定义了如何协商安全参数，如何建立共享密钥，但没有定义协商内容
IKE协商的这些安全参数构成的集合称为安全联盟SA

IPSec认证方式

预共享密钥

预共享密钥认证是IPSec双方配置时手工指定的密钥，无需在网络中互相告知密钥

数字证书

响应端发送数字证书到客户端
发送端收到响应端的数字证书后，会取出附带的数字证书，并读取证书中的发布机构（Issuer），然后从操作系统的受信任证书机构列表中查找该证书办发机构的公钥，如果找不到，说明这个证书颁发机构是个不受信任的，响应端发过来的信息是不安全的。
使用上一步取到的证书颁发机构的公钥，解出数字证书，得到响应端的用户信息和数字签名
发送端通过证书中指定的加密算法对响应端的用户信息进行hash加密
加密后的结果和证书中解出的数字签名进行对比，如果相同，就说明这份用户信息确实是响应端的，也就是说用户信息中包含的公钥确实是响应端的
后续响应端使用私钥加密数据，发送端使用公钥解密。
发送端使用公钥加密，响应端使用私钥解密

协商模式

主动模式

分为两个阶段：

IKE协商
IPSec协商

Ikev1协商

包1：发起端协商SA，使用的是UDP协议，端口号是500，上层协议是ISAKMP，该协议提供的是一个框架，里面的负载Next payload类似模块，可以自由使用。可以看到发起端提供了自己的cookie值，以及SA的加密套件，加密套件主要是加密算法，哈希算法，认证算法，生存时间等
- Initiator SPI：b0b5887b632a532b
  
  发起者的SPI值，告知响应端主机要使用IPSEC的哪一把密钥来加密这个封包。
- Responder SPI：响应者的SPI值，第一个包只有发起者没有响应者所以响应者的SPI为空
- Version：1.0
  
  IKE版本号，1.0表示使用ikev1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
  
  IKE协商模式为主模式
- IKE Attribute (t=12,l=4): Life-Duration: 86400
  
  密钥周期86400，密钥周期超过86400后会重新协商IKE
- IKE Attribute (t=1,l=2): Encryption-Algorithm: DES-CBC
  
  IKE使用DES-CBC加密算法加密数据
- IKE Attribute (t=2,l=2): Hash-Algorithm: MD5
  
  IKE使用MD5算法校验数据完整性
- IKE Attribute (t=3,l=2): Authentication-Method: Pre-shared key
  
  使用预共享密钥认证
- IKE Attribute (t=4,l=2): Group-Description: Alternate 1024-bit MODP group
  
  Diffie-Hellman (DH) 组在密钥交换进程中使用的1024 bit的密钥的强度。
包2：响应端收到发送端发送的加密套件后，对比自己是否有相对应的加密套件，如果有就使用和发送端相同的加密套件加密数据，把自己的cookie值和选择好的加密套件发送给发送端；如果没有相同加密套件则IKE建立失败响应
- Initiator SPI：b0b5887b632a532b
  
  发送端的SPI值，告知响应端主机要使用IPSEC的哪一把密钥来加密这个封包。
- Responder SPI：e5dd838c8d5138b9
  
  响应者的SPI值，告知发送端使用哪一把密钥加密数据包
- Version：1.0
  
  IKE版本号，1.0表示使用ikev1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
  
  IKE协商模式为主模式
- IKE Attribute (t=12,l=4): Life-Duration: 86400
  
  密钥周期86400，密钥周期超过86400后会重新协商IKE
- IKE Attribute (t=1,l=2): Encryption-Algorithm: DES-CBC
  
  IKE使用DES-CBC加密算法加密数据
- IKE Attribute (t=2,l=2): Hash-Algorithm: MD5
  
  IKE使用MD5算法校验数据完整性
- IKE Attribute (t=3,l=2): Authentication-Method: Pre-shared key
  
  使用预共享密钥认证
- IKE Attribute (t=4,l=2): Group-Description: Alternate 1024-bit MODP group
  
  Diffie-Hellman (DH) 组在密钥交换进程中使用的1024 bit的密钥的强度。
包3：发送端生成随机数和DH公共值，包3的主要目的是向响应端发送自己的DH公共值和Nonce随机数。用于生成加密时所需要的KEY值
- Version：1.0
  
  IKE版本号，1.0表示使用ikev1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
  
  IKE协商模式为主模式
- Key Exchange Data: aba538345be9d5bfa1dff1e169b2db2a72d3771038f4cc8e…
  
  DH公共值，DH公共值通过Diffie-Hellman算法计算出来；在包1和包2中所协商的算法，它们必须需要一个相同的KEY（即，共享密钥中设置的密码），但同时这个KEY不能在链路中传递。所以，该过程的目的是分别在两个对等体间独立地生成一个DH公共值，然后在报文中发送给对端，对端通过公式计算出相同的KEY值
包4：响应端收到包3后，自己生成一个随机数，然后通过Diffie-Hellman算法计算出DH公共值，把随机数和DH公共值传输给发送端
- Version：1.0
  
  IKE版本号，1.0表示使用ikev1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
  
  IKE协商模式为主模式
- Key Exchange Data：74d204991cd082a20289989380d3b953e1505fc21af6bafc…
  
  DH公共值，用于生成加密时所需要的KEY值
包5：发起方发起身份验证，报文中带有认证的数据（预共享密钥或者数字签名）。由于包1和包2已经协商好了加密算法，包3和包4协商好了加密的KEY值，所以包5的消息被加密了。
- Version：1.0
  
  IKE版本号，1.0表示使用ikev1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
  
  IKE协商模式为主模式
包6：响应端回应报文，同样发送认证的数据（预共享密钥或者数字签名），验证对方身份信息。包6的数据同样使用包1、包2协商的算法和包3、包4协商的key值加密数据，所以包6的认证数据是加密的。双方身份验证通过后，IKE协商结束
- Version：1.0
  
  IKE版本号，1.0表示使用ikev1建立连接
- Exchange type:Identity Protection (Main Mode) (2)
  
  IKE协商模式为主模式

IPSec加密协商

包7：发起方主要是进行IPSEC SA的协商，建立安全联盟，报文内容主要是协商用的封装方式以及后面的加密算法以及生存时间和感兴趣流等等。由于数据加密所以无法查看
- Initiator SPI：b0b5887b632a532b
  
  发起者的SPI值是由上阶段IKE协商时已经确定的，所以IPSec协商依然使用上阶段的SPI
- Responder SPI：e5dd838c8d5138b9
  
  响应者的SPI值是由上阶段IKE协商时已经确定的，所以IPSec协商依然使用上阶段的SPI
- Version：1.0
  
  IKE版本号，1.0表示使用ikev1建立连接
- Exchange type：Quick Mode（32）
  
  交换类型使用快速模式，IPSec协商时只有快速模式
包8：响应方回包，同意包7发送的封装方式、加密算法、生存时间、感兴趣流等等，同时，也能起到确认收到对端消息的作用。由于数据加密所以无法查看
- Version：1.0
  
  IKE版本号，1.0表示使用ikev1建立连接
- Exchange type：Quick Mode（32）
  
  交换类型使用快速模式，IPSec协商时只有快速模式
包9：发送确认报文。其中包含一个HASH，其作用是确认接收方的消息以及证明发送方处于主动状态（表示发送方的第一条消息不是伪造的）。由于数据加密所以无法查看
- Version：1.0
  
  IKE版本号，1.0表示使用ikev1建立连接
- Exchange type：Quick Mode（32）
  
  交换类型使用快速模式，IPSec协商时只有快速模式

野蛮模式

野蛮模式使用3个报文进行交换加密方式等消息

发起端协商SA，发起端提供了自己的cookie值，以及SA的传输集
响应端收到后，会将自己的sa协商消息附上签名认证信息后发回给sa的发起者
发起端发送自己的数字签名认证等信息

野蛮模式无论是共享密钥认证还是证书认证都支持NAT穿越

工作模式

传输模式

应用场景：主机和主机间端到端通信数据保护。

过程如下：

将原IP报文的IP头和数据报文部分分离，在数据报文部分的尾部添加ESP尾部。ESP尾部包含：选择的加密算法需要对明文进行填充的数据Padding、填充长度Padding Length、下一头部Next Header标注被加密的数据报文类型，例如TCP协议。
对第一步得到的整体信息（原数据报文和ESP尾部）进行加密。具体的加密算法以及密钥由SA给出。
对第二步得到的已经加密的信息添加ESP头部(SPI和序列号)，组装成Enchilada
对第三步得到的Enchilada做摘要，得到完整性度量结果(ICV)，附加在Enchilada尾部
在第四步得到的数据前加上原IP头，将原IP头中的Protocol中的值改成50，代表ESP

隧道模式

可数据加密，还可隐藏原数据包IP地址

应用场景：私网与私网之间通过公网通信，建立安全VPN通道

在原IP报文末尾添加尾部(ESP trailer)信息。如下图所示，尾部包含三部分。由所选加密算法可能是块加密，那么当最后一块长度不够时就需要进行填充(padding)，附上填充长度(Pad length)方便解包时顺利找出用来填充的那一段数据。而Next header则用来标明被加密的数据报文的类型，例如TCP协议。
将原IP报文以及第1步得到的ESP尾部作为一个整体进行加密。具体的加密算法与密钥由SA给出。

为第2步得到的加密数据添加ESP头部。如上图所示,ESP头由两部分组成,SPI和序号(Sequence number)。加密数据与ESP头合称为“enchilada”
附加完整性度量结果(ICV,Integrity check value)。对第三步得到的“enchilada”做摘要,得到一个完整性度量值,并附在ESP报文的尾部
加上新的IP头。新构造的IP头附在ESP报文的前面组成一个新的IP报文。注意这个新的IP头的目的地址跟源地址可以不一样。协议类型为50,说明它里面装的是一个IPsec报文