zoukankan      html  css  js  c++  java
  • 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

     

  • 相关阅读:
    利用pipe实现进程通信一例
    司机和售票员问题 信号signal注册一例
    HDU 1003
    HDU 1847
    HDU 1846(巴什博弈)
    《断弦》感想
    夺冠概率
    熄灯问题
    HDU 2176(Nim博弈)
    NYOJ 541
  • 原文地址:https://www.cnblogs.com/2014-cjs/p/4068923.html
Copyright © 2011-2022 走看看