幻灯片 1
幻灯片 2
幻灯片 3
幻灯片 4
幻灯片 5
IPSec（IP Security）协议族是IETF制定的一系列协议，它为IP数据报提供了高质量的、可互操作的、基于密码学的安全性。换一个说法就是，IPSec不是一个单独的协议，而是一系列为IP网络提供完整安全性的协议和服务的集合。这些协议和服务结合起来提供不同数据的保护。因为IPSec工作在IP层，所以它能为上层协议和应用提供透明的安全服务，这也是它的最大好处。 IPSec提供的安全服务包括： 私有性（Confidentiality）
指对用户数据进行加密保护，用密文的形式传送。 完整性（Data integrity）
指对接收的数据进行验证，以判定报文是否被篡改。 真实性（Data authentication）
指验证数据源，以保证数据来自真实的发送者。 防重放（Anti-replay）
指防止恶意用户通过重复发送捕获到的数据包所进行的攻击，即接收方会拒绝旧的或重复的数据包。
幻灯片 6
IPSec协议有两种操作模式：传输模式和隧道模式。
在传输模式下，IPSec协议处理模块会在IP报头和高层协议报头之间插入一个IPSec报头。在这种模式下，IP报头与原始IP分组中的IP报头是一致的，只是IP报文中的协议字段会被改成IPSec协议的协议号（50或者51 ，并重新计算IP报头校验和。传输模式保护数据包的有效载荷、高层协议，IPSec源端点不会修改IP报头中目的IP地址，原来的IP地址也会保持明文。传输模式只为高层协议提供安全服务。这种模式常应用在需要保护的两台主机之间的端到端连接，而不是多台主机的两个网关之间的数据流。
与传输模式不同，在隧道模式下，原始IP分组被封装成一个新的IP报文，在内部报头以及外部报头之间插入一个IPSec报头，原IP地址被当作有效载荷的一部分收到IPSec的保护。另外，通过对数据加密，还可以隐藏原数据包中的IP地址，这样更有利于保护端到端通信中数据的安全性。
幻灯片 7
IPSec是在两个端点之间提供安全通信，端点被称为IPSec对等体。IPSec能够允许系统、网络的用户或管理员控制对等体间安全服务的粒度。例如，某个组织的安全策略可能规定来自特定子网的数据流应同时使用AH和ESP进行保护，并使用3DES（Triple Data Encryption Standard）进行加密；另一方面，策略可能规定来自另一个站点的数据流只使用ESP保护，并仅使用DES加密。通过SA（SecurityAssociation），IPSec能够对不同的数据流提供不同级别的安全保护。
安全联盟是IPSec的基础，也是IPSec的本质。SA是通信对等体间对某些要素的约定，例如，使用哪种安全协议、协议的操作模式（传输模式和隧道模式）、
加密算法（DES和3DES）、特定流中保护数据的共享密钥以及密钥的生存周期等。
安全联盟是单向的，在两个对等体之间的双向通信，最少需要两个安全联盟来分别对两个方向的数据流进行安全保护。同时，如果希望同时使用AH和ESP来保护对等体间的数据流，则分别需要两个SA，一个用于AH，另一个用于ESP。 安全联盟由一个三元组来唯一标识，这个三元组包括安全参数索引（SPI, Security Parameter Index）、目的IP地址、安全协议号（AH 或ESP）。SPI 是为唯一标识SA 而生成的一个32 比特的数值，它在IPSec头中传输。
幻灯片 8
AH和ESP是IPSec的两个主要协议。认证头（AH , Authentication Header）协议为IP通信提供数据源认证、数据完整性检验和防重放保证。封装安全载荷（ESP, Encapsulating Security Payload）为IP通信提供完整性检验、认证、加密和防重放保证。
AH和ESP可以单独使用，也可以同时使用。 在实际的组网中,ESP协议使用较多。
幻灯片 9
IPSec协议组成——ESP
ESP使用一系列加密算法提供机密性，数据完整性则由认证算法保证。具体使用过程中采用的算法则是由ESP安全联盟的相应组件决定的。另外ESP能够通过序列号提供防重放服务，至于是否采用则由数据包的接收者来决定。这是因为一个唯一的、单向递增的序列号是由发送端插入的，但却并不要求接收端对该数据报进行检验。由于这项保护对安全性大有好处，所以一般都会采用。 ESP可在不同的操作模式下使用。不管ESP处于什么模式， ESP头都会紧紧跟在一个IP头之后。在IPv4中，ESP头紧跟在IP头后面。ESP使用的协议号
是50。也就是说，当ESP头插入原始报文中后，ESP之前的IP头中的协议字段将是50，以表明IP头之后是一个ESP头。
作为一个IPSec头，ESP头中必然包含一个SPI字段。这个值，和IP头之前的目标地址以及协议结合在一起，用来标识特定的安全联盟。SPI本身是个任意数，可以是使用者自己指定，也可交由一些密钥管理技术自行协商决定。需要注意的是， SPI可以经过了验证，但却无法被加密。这是必不可少的一种做法，因为SPI用于SA的标识，指定了采用的加密算法以及密钥，并用于对包进行解密。如果SPI本身已被加了密，我们会碰到一个非常严重的问题——“先有鸡，还是先有蛋”。
序列号是一个独一无二、单向递增、并由发送端插在ESP头中的一个32位数值。通过序列号，ESP具有了防重放的能力。与SPI一样，序列号经过了验证，但却没有加密。这是由于我们希望在协议模块处理流程的最前端可以根据它判断一个包是否重复，然后决定是否丢弃这个包，而不至于动用更多的资源对其进行解密。
幻灯片 10
初始化向量（IV, Initial Vector）并不是一个必不可少的字段，但在ESP定义的加密算法中，有一些特殊的加密算法需要这个值。根据不同的加密算法，IV的取值方式也不尽相同。以DES-CBC来说，IV是载荷数据字段中的第一个8位组。相同的原因，IV也是只验证不加密的字段。
填充字段在ESP头中主要有三个功能。某些加密算法对输入的明文有严格的定义，例如明文的大小必须是某个数目字节的整数倍 如分块加密算法中要求明文是单块长度的整数倍）。填充字段的第一个功能就是将明文扩展到算法需要的长度。另外，由于ESP要求ESP头必须是32比特的整数倍，“填充长度”以及“下一个报头”这两个字段需要靠右对齐排列，填充字段也用来保证这样的报文
格式。最后一个功能是处于安全性考虑的，就是填充字段可以隐藏数据载荷的实际长度，从而提供一定的保密性。填充字段的最大长度可达255个字节。填充内容与提供机密性的加密算法有关，如果这个算法定义了一个特定值，那么填充字段的内容就只能采用这个值。如果算法没有指定需要填充的值，ESP就会指定填充的第一个字节的值是1，后面的所有字节值都单向递增。
填充长度字段则标明了“填充字段”中填充数据的长度。接收端可以根据这个字段恢复载荷数据的真实长度。填充项长度字段是硬性规定的，因此，即使没有填充，填充长度字段仍会将它表示出来。
下一个报头字段表明载荷内的数据类型。如果在隧道模式下使用ESP，这个值就会是4，表示IP-in-IP。如果在传输模式下使用ESP，这个值表示的就是它背后的上一级协议的类型，比如TCP对应的就是6。
认证数据字段用于容纳数据完整性的检验结果，通常是一个经过密钥处理的散列函数。这一字段的长度由SA所用的身份验证算法决定。如果 SA中没有指定认证算法，则认证数据字段将不存在。
幻灯片 11
具体应用中，ESP可以使用传输模式也可以使用隧道模式。不同的模式决定了ESP对保护对象的定义。在传输模式中无法保护原有的IP头；在隧道模式中，整个原始报文都可以收到保护。
幻灯片 12
IPSec协议组成——AH
验证头（Authentication Header, AH）是IPSec协议集合中的另外一个重要安全协议，用于为IP提供数据完整保护、数据原始身份认证以及防重放服务。它定义在RFC2402中。除了机密性之外，AH提供ESP能够提供的一切功能。 由于AH不提供机密性保证，所以它也不需要加密算法。AH定义保护方法、报头的位置、身份验证的覆盖范围以及输出和输入处理规则，但没有对所用的身份验证算法进行定义。与ESP一样，AH没有硬性规定防重放保护，是否使用防
重放服务由接收端自行选择。发送端无法得知接收端是否会检查其序列号，其结果是，发送端必须一直认定接收端正在采用防重放服务。
和ESP一样，AH也是IP的一个万用型安全服务协议。但是AH提供的数据完整性与ESP提供的数据完整性稍有不同； AH对外部IP头各部分也会进行身份验证。
AH分配到的协议号是51。也就是说，AH保护的IPv4数据报文的协议字段将是51，表明IP头之后是一个AH头。AH头比ESP头简单得多，因为它没有提供机密性。由于不需要填充和一个填充长度指示器，因此也不存在尾部字段。另外，也不需要一个初始化向量。
幻灯片 13
和ESP一样，AH可以使用传输模式来保护一个上层协议，或者使用隧道模式来保护一个完整的IP数据报。在任何一种模式下， AH头都会紧跟在一个IP头之后。AH可以单独使用， 也可以与ESP联合使用，为数据提供最完整的安全保护。
AH用于传输模式时，保护的是端到端的通信。通信的终点必须是IPSec终点。AH头被插在数据报中，紧跟在IP头之后（和任意选项），需要保护的上层协议之前。
AH用于隧道模式时，它将自己保护的数据报文封装起来，另外，在AH头之前，另添了一个新的IP头。“里面的”IP数据报中包含了通信的原始报文，而新的IP头则包含了IPSec端点的地址。隧道模式可用来替换端对端安全服务的传输模式。
幻灯片 14
幻灯片 15
用IPSec保护一个IP包之前，必须先建立一个安全联盟（SA）。IPSec的安全联盟可以通过手工配置的方式建立。但是当网络中节点较多时，手工配置将非常困难，而且难以保证安全性。这时就可以使用IKE（Internet Key Exchange）自动进行安全联盟建立与密钥交换的过程。Internet密钥交换（IKE）就用于动态建立SA，代表IPSec对SA进行协商。
由RFC2409文件描述的IKE属于一种混合型协议。它建立在由Internet安全联盟和密钥管理协议（ISAKMP）定义的一个框架上，详情可见RFC2408文件。同时，IKE还实现了两种密钥管理协议的一部分——Oakley和SKEME。此外，IKE还定义了它自己的两种密钥交换方式。
Oakley是由亚利桑那大学的安全专家Hilarie Orman开发的一种基于
Diffie-Hellman（简称“DH”）算法的协议。它是一种自由形态的协议，允许各研究机构根据自身的水平改进协议状态。IKE在其基础上定义了正规的密钥交换方法。尽管由于降低了Oakley模型的灵活性，但仍然提供了多种交换模式供用户选择，所以最终还是成为一个非常适宜的密钥交换技术。
SKEME则是另外一种密钥交换协议，由加密专家Hugo Krawczyk设计。SKEME定义了如何验证密钥交换。其中，通信各方利用公共密钥加密实现相互间的验证，同时“共享”交换的组件。每一方都要用对方的公共密钥来加密一个随机数字，两个随机数（解密后）都会对最终的密钥产生影响。IKE在它的一种验证方法（公共密钥加密验证）中，直接借用了SKEME的这种技术。
ISAKMP是由美国国家安全局（NSA）的研究人员开发出来的。NSA过去是一个高度机密的组织，美国政府甚至还否认过它的存在。近年来， NSA已慢慢走到公众面前，其专业加密技术和安全技术也日渐引人瞩目。ISAKMP便是由它公开的一项技术。
ISAKMP、Oakley和SKEME—这三个协议构成了IKE的基础。因此，我们说IKE是一种“混合型”协议，它沿用了ISAKMP的基础、Oakley的模式以及SKEME的共享和密钥更新技术，从而定义出自己独一无二的验证加密材料生成技术，以及协商共享策略。在IKE规范中，三种技术发挥的作用可在后文对IKE本身的讨论中略见一二，其中ISAKMP发挥的作用最为巨大。
ISAKMP定义了通信双方沟通的方式，信息的格式以及定义了保障通信安全的状态变换过程。 但ISAKMP本身没有定义具体的密钥交换技术。密钥交换的定义留给其他协议处理。对IPSec而言，已定义的密钥交换就是IKE——即Internet密钥交换。IKE利用ISAKMP语言来定义密钥交换，是对安全服务进行协商的手段。IKE交换的最终结果是一个通过验证的密钥以及建立在双方同意基础上的安全服务——亦即所谓的“IPSec安全联盟（IPSec SA）”。但是， IKE并非仅由IPSec专用的。只要其他协议需要，比方说RIPv2或OSPF，也可以使用它来提供安全服务。
幻灯片 16
IKE具有一套自保护机制，可以在不安全的网络上安全地分发密钥、验证身份、建立IPSec 安全联盟。
DH（Diffie-Hellman）交换及密钥分发
Diffie-Hellman 算法是一种公共密钥算法。通信双方在不传送密钥的情况下通过交换一些数据，计算出共享的密钥。加密的前提是交换加密数据的双方必须要有共享的密钥。IKE 的精髓就在于它永远不在不安全的网络上直接传送密钥，而是通过一系列数据的交换，最终计算出双方共享的密钥。即使第三者（如黑客）截获了双方用于计算密钥的所有交换数据，也不足以计算出真正的密钥。
完善的前向安全性（Perfect Forward Secrecy）
PFS 是一种安全特性，指一个密钥被破解，并不影响其他密钥的安全性，因为这些密钥间没有派生关系。PFS 是由DH 算法保障的。此特性是通过在IKE 阶段2的协商中增加密钥交换来实现的。 身份验证
身份验证确认通信双方的身份。对于pre-shared key 验证方法，验证字用来作为一个输入产生密钥，验证字不同是不可能在双方产生相同的密钥的。验证字是验证双方身份的关键。 身份保护
身份数据在密钥产生之后加密传送，实现了对身份数据的保护。
幻灯片 17
KE使用了两个阶段的ISAKMP。第一阶段建立IKE安全联盟（IKE SA），第二阶段利用这个既定的安全联盟，为IPSec协商具体的安全联盟。
在RFC2409（The Internet Key Exchange）中规定，IKE 第一阶段的协商可以采用两种模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）。这两种模式各自做着的是相同的事情：建立一个加密和验证无误的通信信道（IKE SA），以及生成验证过的密钥，为双方的IKE通信提供机密性、消息完整性以及消息源验证服务。IKE中定义的其他所有交换都要求一个验证过的IKE SA作为首要条件。所以无论主模式还是野蛮模式，第一阶段都必须在其他任何交换之前完成。
幻灯片 18
IKE交换阶段第一阶段——主模式交换
主模式被设计成将密钥交换信息与身份认证信息相分离的一种交换技术。这种分离保证了身份信息在传输过程中的安全性，这是因为交换的身份信息受到了加密保护。
主模式总共需要经过三个步骤共6条消息来完成第一阶段的协商，最终建立IKE SA。
这三个步骤分别是模式协商、Diffie-Hellman交换和nonce交换、以及对对方身份的验证。主模式的特点包括身份保护以及对ISAKMP协商能力的完全利用。其中，身份保护在对方希望隐藏自己的身份时显得尤为重要。在我们讨论野蛮模式时，协商能力的完全利用与否也会凸显出其重要性。若使用预共享密钥方法验证。
在消息1、2发送之前，协商发起者和响应者必须计算产生自己的cookie，用于唯一标识每个单独的协商交换，cookie使用源/目的IP地址、随机数字、日期、和时间进行MD5运算得出，并且放入消息1的ISAKMP中，用以标识单独的一个协商交换。
在第一次交换中，需要交换双方的cookie和SA载荷，在SA载荷中携带需要协商的IKE SA的各项参数，主要包括IKE的散列类型、加密算法、认证算法和IKE SA的协商时间限制等。
第一次交换后第二次交换前，通信双方需要生成用于产生Diffie-Hellman共享密钥的DH值。生成方法是双方各自生成一个随机数字，通过DH算法对随机数字进行运算，得出一个DH值Xa和Xb（Xa是发起放的DH值，Xb是响应者的DH值），然后双方再根据DH算法运算得出一个临时值Ni和Nr。
第二次交换中，双方交换各自的密钥交换载荷（即Diffie-Hellman交换）以及临时值载荷（即nonce交换）。其中密钥交换载荷包含了Xa和Xb，临时值交换包含了Ni和Nr。
双方交换了临时值载荷Ni和Nr之后，配合事先预置好的预共享密钥，再通过为随机函数运算便可产生一个密钥SKEYID，这个密钥使后续所有密钥生成的基础。随后，通过自己算出来的DH值、交换得到的DH值以及SKEYID进行运算便可产生一个只有双方才知道的共享密钥SKEYID_d。此共享密钥并不进行传输，传输的只是是DH值以及临时值，因此即使第三方得到了这些材料也无法计算出共享密钥。
在第二次交换完成之后，双方所需的计算材料都已经交换完毕，此时，双方就可以将所有的密钥计算出来，并使用该密钥对随后的IKE消息提供安全保护。这些密钥包括：SKEYID_a以及SKEYID_e。SKEYID_a用来为IKE消息提供完整性以及数据源身份验证等安全服务；SKEYID_e则用于对IKE消息进行加密。 第三次交换是对标识载荷和散列载荷进行交换。标识载荷包含了发起者的标识信息、IP地址或主机名，散列载荷包含上一过程中产生的三组密钥进行HASH运算得出的值。这两个载荷通过SKEYID_e进行加密，如果双方的载荷相同，那么认证成功。IKE第一阶段主模式预共享密钥交换也就完成了。
幻灯片 19
IKE交换阶段第一阶段——野蛮模式交换
从上述主模式协商的叙述中可以看到，在第二次交换之后便可生成会话密钥，会话密钥的生成材料中包含了预共享密钥。而当一个对等体同时与多个对等体进行协商SA时，则需要为每个对等体设置一个预共享密钥。为了对每个对等体正确地选择对应地预共享密钥，主模式需要根据前面交换信息中的IP地址来区分不同的对等体。
但是当发起者的IP地址是动态分配获得的时候，由于发起者的IP地址不可能被响应者提前知道，而且双方都打算采用预共享密钥验证方法，此时响应者就无法根据IP地址选择对应地预共享密钥。野蛮模式就是被用于解决这个矛盾的。 与主模式不同，野蛮模式仅用3条信息便完成了IKE SA的建立。由于对消息数进行了限制，野蛮模式同时也限制了它的协商能力，而且不会提供身份保护。 在野蛮模式的交换过程中，发起者会提供一个保护套件列表、Diffie-Hellman公共值、nonce以及身份资料。所有这些信息都是随第一条信息进行交换的。作为响应者，则需要回应选择一个保护套件、Diffie-Hellman公共值、nonce、身份资料以及一个验证载荷。发起者将它的验证载荷在最后一条消息交换。 野蛮模式由于在其第一条信息中就携带了身份信息，因此本身无法对身份信息进行加密保护，这就降低了协商的安全性，但也因此不依赖IP地址标识身份，在野蛮模式下也就有了更多灵活的应用。
幻灯片 20
幻灯片 21
IKE交换阶段第二阶段——快速模式交换
建立好IKE SA之后（无论通过主模式还是通过野蛮模式交换），便可用它为IPSec生成相应的SA。IPSec SA是通过快速模式交换来建立的，对快速模式交换来说，它是在以前建立好的IKE SA的保护下完成的。
在一次快速交换模式中，通信双方需要协商拟定IPSec安全联盟的各项特征，并为其生成密钥。IKE SA保护快速模式交换的方法是：对其进行加密，并对消息进行验证。消息的验证是通过伪随机函数来进行的。来自IKE SA的SKEYID_a的值作为一个密钥，对快速模式交换的整个消息进行验证。这种验证除了能提供
数据完整性保证之外，还能对数据源的身份进行验证：在消息接收到之后，我们知道它只有可能来自验证通过的实体，而且那条消息在传送过程并未发生改变。而通过加密（使用SKEYID_e），则可保障交换的机密性。
快速模式需要从SKEYID_d状态中衍生出用于IPSec SA的密钥。随同交换的nonce以及来自IPSec SA的SPI及协议一道，这个密钥将在伪随机函数中使用，这样便可确保每个SA都有自己独一无二的密钥：每个SA都有一个不同的SPI，所以入方向SA的密钥也会与出方向SA不同。所有IPSec密钥都是自相同的来源衍生的，所以相互间都有关联。假如一名攻击者能够根据IKE SA判断出SKEYID_d的值，那么就能非常容易地掌握自那个SKEYID_d衍生出来的任何IPSec SA的任何密钥。另外，还能继续掌握未来将要衍生的所有密钥！这显然是个大问题，所有这些密钥都不能保证所谓的“完美向前保密（PFS）”。快速模式为此专门提供了一个PFS选项，来满足这方面的需要，用户可根据自己地安全需要选择是否使用PFS。
为了在快速模式交换中实现PFS，需要执行一次额外的Diffie-Hellman交换，最终生成的共享密钥将在为IPSec生成密钥的过程中用到。显然，一旦交换完成，这个密钥便不复存在。一旦完成，它所驻留的那个内存位置必须清零和释放。从而保证了密钥之间地不相关性。
我们前面将快速模式描述成一种简单的请求／响应交换，但它的实际功用远不止于此。发起者可能需要一个“在场”证据，证明响应者在线，而且已经实际地处理了它的初始快速模式消息。为了达到这个要求，响应者需亚在验证散列载荷中，加入交换的发起者nonce以及消息ID。这个摘要现在不仅能保障消息的完整性，也能为发起者提供源验证功能，另外还能提供在场证据。
响应者也需要一个在场证据，从发起者传来的可能是一条过期的消息，是由不怀好意的人重播的。这个人可能不知道消息的内容，但通过对通信的分析，能够知道它是一条快速模式消息。如果重播那条消息，响应者便不得不创建多余的SA。我们可将其想像成一种“服务否认”攻击，只是属于比较温和的那种，因为响应者会根据这条消息，增加不必要的内存及SA管理开销。想要防范此类攻击，需
在快速模式交换中增加第三条消息。在这条消息中，发起者需要同时包括nonce和此次交换的消息ID，并把它们保存在一个验证散列载荷中。这样发起者便可向响应者证实：自己是此次交换的活动参与者。
在前两条消息中，发起者和响应者都发送了SA载荷，和主模式、野蛮模式一样，SA载荷是用来协商各种保护算法的。而Ni、Nr以及ID则是用来提供“在场证据”的。Xa以及Xb则是用来生成新的DH共享密钥，保证PFS的。Xa以及Xb将与IKE第一阶段生成的SKEYID_d、Ni、Nr以及SPI等信息共同生成最终用于IPSec加密的密钥。
最后发起者会发送一条确认信息，响应者收到该信息后就知道发起者已经收到了第二条消息。此时IKE第二阶段结束。
幻灯片 23
幻灯片 24
因篇幅问题不能全部显示，请点此查看更多更全内容