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和传输模式简介

        ESPEncapsulating 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

 

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。