WEB安全——IPsec传输模式下ESP报文的装包与拆包过程

WEB安全概论

                                                         ——IPsec传输模式下ESP报文的装包与拆包过程

一、IPsec

      （一）简介

      互联网安全协定（英语：Internet Protocol Security，缩写为 IPsec），是透过对IP协议（互联网协议）的分组进行加密和认证来保护IP协议的网络传输协议族（一些相互关联的协议的集合）。

 

      IPsec由两大部分组成：（1）建立安全分组流的密钥交换协议；（2）保护分组流的协议。前者为互联网金钥交换（IKE）协议。后者包括加密分组流的封装安全载荷协议（ESP协议）或认证头协议（AH协议）协议，用于保证数据的机密性、来源可靠性（认证）、无连接的完整性并提供抗重播服务。

 

      （二）设计意图

      IPsec被设计用来提供（1）入口对入口通信安全，在此机制下，分组通信的安全性由单个节点提供给多台机器（甚至可以是整个局域网）；（2）端到端分组通信安全，由作为端点的计算机完成安全操作。上述的任意一种模式都可以用来构建虚拟专用网 (VPN)，而这也是IPsec最主要的用途之一。应该注意的是，上述两种操作模式在安全的实现方面有着很大差别。

       因特网范围内端到端通信安全的发展比预料的要缓慢，其中部分原因，是因为其不够普遍或者说不被普遍信任。公钥基础设施能够得以形成（DNSSEC最初就是为此产生的），一部分是因为许多用户不能充分地认清他们的需求及可用的选项，导致其作为内含物强加到卖主的产品中（这也必将得到广泛采用）；另一部分可能归因于网络响应的退化（或说预期退化），就像兜售信息的充斥而带来的带宽损失一样。

       (三)与其他互联网协议的对比

       IPsec协议工作在OSI 模型的第三层，使其在单独使用时适于保护基于TCP或UDP的协议（如 安全套接子层（SSL）就不能保护UDP层的通信流）。这就意味着，与传输层或更高层的协议相比，IPsec协议必须处理可靠性和分片的问题，这同时也增加了它的复杂性和处理开销。相对而言，SSL/TLS依靠更高层的TCP（OSI的第四层）来管理可靠性和分片。

 

二、ESP

      （一）ESP和传输模式简介

        ESP（Encapsulating Security Payloads），封装安全载荷协议，IPsec 所支持的两类协议中的一种。该协议能够在数据的传输过程中对数据进行完整性度量，来源认证以及加密，也可防止回放攻击。

            传输模式，与隧道模式同为IPsec工作的两种方式。与隧道模式不同，当IPsec工作在传输模式时，新的IP头并不会被生成，而是采用原来的IP头，保护的也仅仅是真正传输的数据，而不是整个IP报文。在处理方法上，原来的IP报文会先被解开，再在数据前面加上新的ESP或AH协议头，最后再装回原来的IP头，即原来的IP包被修改过再传输。

    （二）传输模式下的ESP包

              传输模式下，ESP包大致结构和详细结构如下所示：

      

      （三）传输模式下的ESP装包和拆包过程

        1、装包过程：

        装包过程，即处理外出数据包。

        对在IPv4上运行的传送模式应用来说， ESP头紧跟在IP头（包括IP头可能有的任何选项）之后，插入一个外出的IP包中。IP头的协议字段被复制到ESP头的“下一个头”字段中， ESP头的其余字段则被填满— SPI字段分配到的是来自SADB的、用来对这个包进行处理的特定 SA 的 SPI；填充序列号字段的是序列中的下一个值；填充数据会被插入，其值被分配；同时分配的还有填充长度值。随后， IP头的协议字段得到的是ESP的值，或者50。除了头插入位置不同之外， IPv6处理规则基本上类似于IPv4。 ESP头可插在任意一个扩展头（在路由过程中，有可能被修改）之后。

        从恰当的 SA中选择加密器（加密算法），对包进行加密（从载荷数据的开头，一直到“下一个头”字段）。随后，使用恰当的 SA中的验证器，对包进行验证（自 ESP头开始，中间经过加密的密文，一直到 ESP尾）。随后，将验证器的结果插入 ESP尾的“验证数据”字段中。对外出数据包进行处理的最后一步是：重新计算位于 ESP前面的IP头的校验和。

         在传输模式下，当要发出一个数据包时：

         1、在原IP报文末尾添加尾部（ESP trailer）信息。如上图所示，尾部包含三部分。由所选加密算法可能是块加密，那么当最后一块长度不够时就需要进行填充（padding），附上填充长度（Pad length）方便解包时顺利找出用来填充的那一段数据。而Next header则用来标明被加密的数据报文的类型，例如TCP。

 

           2、将原IP报文以及第1步得到的ESP尾部作为一个整体进行加密。具体的加密算法与密钥由SA给出。

           3、为第2步得到的加密数据添加ESP头部。

           ESP头由两部分组成，SPI和序号（Sequence number）。加密数据与ESP头合称为“enchilada”。

           4、附加完整性度量结果（ICV，Integrity check value）。

           对第三步得到的“enchilada”做摘要，得到一个完整性度量值，并附在ESP报文的尾部。

                 5、拿到原本的IP头。这样就可以发送了。

                2、拆包过程。

                拆包过程，即处理接受到的数据包。

                接收端在收到一个 ESP包之后，若不对这个包进行处理，就无法得知它究竟处于通道模式，还是传送模式。根据对这个包进行处理的SA，便可知道它到底处在什么模式下。

                如果收到的IPSec包是一个分段，必须把它保留下来，直到这个包的其他部分收完为止。

                我们不能对一个不完整的IPSec包进行处理，因为可能会导致对它施行的初次校检失败。

               收到 ESP包后，进行的第一件事情是：检查处理这个包的SA是否存在，这是基本的 IPSec要求，而不是ESP专有的。如果没有SA，这个包就会被丢弃。只有在SA存在的情况下，才可开始进行输入处理。一旦验证通过了一个有效的SA，就可用它开始包的处理。

               首先检查序列号。如果这个包的序列号是有效的—也就是说，它不是一个重复（重播）的包，也不是出现在包含在S A中的序列号窗口的右边—就开始进行处理。由于E S P身份验证密文而不是明文，接下来进行的便是对这个包进行身份验证。利用恰当的密钥，把这个完整的ESP包（当然除开身份验证数据）传递到验证器那里（它取自SA）。如果其结果能与“身份验证数据”字段中包含的数据相符（将身份验证算法可能需要的任何分段考虑在内），就可对这个包进行身份验证。接下来是解密。通过取自SA的密钥和密码算法，就可对 ESP包进行解密，这个ESP包在载荷数据开始之处到下一个头之间。判断解密成功的一个最简单的测试是检验其填充。由于填充内容具有决定意义—要么是一个从1开始的单向递增的数，要么通过加密算法来决定—对填充内容进行验证将决定这个包是否已成功解密。

                传送身份验证和解密检查成功之后，就可对结果数据包进行初步的有效性检验。如果用来处理这个数据包的SA表明在某一特定模式下—要么是通道模式，要么是传送模式—只能处理ESP包，那么还必须检验这个包的适用性。如果这个包与要求的模式不符，就必须把它丢弃。

                对传送模式而言，上层协议头与IP头是同步的，ESP头的下一个头字段被复制到IP头的协议字段中，并计算出一个新的IP校验和；而对通道模式而言，就抛开外部IP头和ESP头—我们需要的是这个解开封装的包。这时，必须进行另一个有效性检验。

                如果它是一个传送模式包，就会转让到一个高一级的协议层—比如TCP或 UDP—由它们对这个包进行处理。

拆包过程如下：

1. 收到数据报文后，发现协议类型是50，故知道这是一个IPsec包。首先查看ESP 头， 通过里面的SPI决定数据报文所对应的SA。

2. 计算“enchilada”部分的摘要，与附在末尾的ICV做对比，如果一样的话说明数据 是完整的。否则可以断定所收到的报文已经不是原来的报文了。

3. 检查Seq里的顺序号，保证数据是“新鲜”的。

4. 根据SA所提供的加密算法和密钥，解密被加密过的数据，即“enchilada”。得到原 IP报文与ESP尾部（trailer）。

5. 根据ESP尾部里的填充长度信息，我们可以找出填充字段的长度，删去后就得到原来 的IP报文。

6. 最后转让到一个高一级的协议层—比如TCP或 UDP—由它们对这个包进行处理。

             (四)拓展：传输模式下的ESP装包和拆包过程

 

装包过程: 

1. 在原IP报文末尾添加尾部(ESP trailer)信息。如上图所示,尾部包含三部分。由所选加密算法可能是块加密,那么当最后一块长度不够时就需要进行填充(padding),附上填充长度(Pad length)方便解包时顺利找出用来填充的那一段数据。而Next header则用来标明被加密的数据报文的类型,例如TCP。 

2. 将原IP报文以及第1步得到的ESP尾部作为一个整体进行加密。具体的加密算法与密钥由SA给出。

3. 为第2步得到的加密数据添加ESP头部。如上图所示,ESP头由两部分组成,SPI和序号(Sequence number)。加密数据与ESP头合称为“enchilada”。 

4. 附加完整性度量结果(ICV,Integrity check value)。对第三步得到的“enchilada”做摘要,得到一个完整性度量值,并附在ESP报文

的尾部。
5. 加上新的IP头。新构造的IP头附在ESP报文的前面组成一个新的IP报文。注意这个新的IP头的目的地址跟源地址可以不一样。协议类型为50,说明它里面装的是一个IPsec报文。 

 

 

拆包过程:

1. 接收方收到数据报文后,发现协议类型是50,故知道这是一个IPsec包。首先查看ESP头,通过里面的SPI决定数据报文所对应的SA。

2. 计算“enchilada”部分的摘要,与附在末尾的ICV做对比,如果一样的话说明数据是完整的。否则可以断定所收到的报文已经不是原来的报文了。

3.检查Seq里的顺序号,保证数据是“新鲜”的。

4.根据SA所提供的加密算法和密钥,解密被加密过的数据,即“enchilada”。得到原IP报文与ESP尾部(trailer)。

5. 根据ESP尾部里的填充长度信息,我们可以找出填充字段的长度,删去后就得到原来的IP报文。

6. 最后根据得到的原IP包的目的地址来进行转发。

 

参考资料：

#传输模式下ESP的装包和拆包过程#

http://blog.sina.com.cn/s/blog_64ffd1280101egtj.html

#IPSec传输模式/隧道模式下ESP报文的装包与拆包过程#

http://blog.csdn.net/johnson_puning/article/details/14163751

#IPsec#

http://zh.wikipedia.org/wiki/IPsec