图1.4 数据机密性的实现过程
注：目前，在IPSec体系架构里面，并没有使用到非对称密钥。但是与IPSec紧密相关的一个协议——IKE，使用了D-H（Diffie-Hellman，该算法是根据发明该算法的密码学家名称来命名的）交换来协商密钥，协商后的密钥就是IPSec用来实际加解密的对称密钥。在配置中，就是配置IKE的policy中的Group。
4.1.5．非对称密钥的数字签名
数字签名是公钥体制下提供的一项十分具有优势的服务（对称密钥体制下虽然也可以实现数字签名，但十分繁琐且可靠性不高）。通过数字签名，可以认证发送方的身份。消息发送者A在消息末尾附上的标识自己身份且别人无法伪造的一串密文信息。消息接收者B可以通过验证这串信息来确认该消息是否是真正的A所发送的。
数字签名从根本上来说是依靠密钥对的概念。用户A通过杂凑函数把要发送的消息数据进行运算，得到固定长度的数据串，然后用自己的私钥对杂凑后的结果加密，其加密结果就是A的签名。其它用户在接收到A传来的消息后，同样先用杂凑函数对数据部分进行杂凑得到固定长度的数据串M，然后用A的公钥对加密信息进行解密得到M’，最后将M与M’进行对比看是否匹配。如果匹配，则A的签名得到了验证，证实这条消息是A发出来的，否则验证失败。
因此，数字签名实际上就是一次私钥操作（在发送端）和一次公钥操作（在接收端）的过程，如图1.5所示。
文件
Hash 发送者的私钥 Hash值 数字签名 发送 文件
图1.5 数字签名的实现过程
4.1.6．非对称密钥的数字签名验证（数据完整性）
杂凑函数（Hash）的特征之一就是很难找到两个不同的输入产生相同的输出，数据的任何改动会导致杂凑后的结果不同，从而导致签名验证的失败。因此，如果签名验证成功，接收者就可以认为数据是完整无缺的。验证过程如图1.6所示。
图1.6 数据完整性的实现过程
注：目前IPSec协议体系结构用到的杂凑算法有MD5-HMAC、SHA-1-HMAC。在实际配置命令，就是在配置变换集合的时候，选择esp-md5算法。
crypto ipsec transform-set tr1 esp-des esp-md5-hmac mode tunnel exit
4.1.7．协商密钥
从上面的描述中，可以看到如果用对称密钥加/解密数据时，发送方和接收方必须事先知道这对密钥。我们可以通过打电话，写信等方式得到密钥，但是必须要保证电话和信件不被窃取。其实，根据数论中的一些原理，两个实体间可以通过一系列对话，交换一些用来产生密钥的材料，协商出一个对称密钥，而这些材料即使泄露，也不会对产生的密钥构成威胁。当然，这个对称密钥是不为其它的实体所知的。
4.2．Internet密钥交换（IKE）
IKE的唯一用途就是动态地在IPSec通信双方之间，建立起共享安全参数以及验证过的密钥，即，建立“安全联盟”关系。
IKE以什么方式来建立IPSec SA，要由它自己的策略设定所决定。IKE以“保护组（Protection suite）”的形式来定义策略。每个保护组都至少需要定义采用的加密算法、散列算法、Diffie-Hellman组以及验证方法。IKE的策略数据库则列出了所有保护组（按各个参数的顺序）。由于通信双方决定了一个特定的策略组后，它们以后的通信便必须根据它进行，所以这种形式的协商是两个IKE通信实体第一步所需要做的。
注：IKE的“保护组”就是在路由器或者VPN3020上面配置的policy。命令如下：
crypto isakmp policy 1 encryption des hash sha
authentication pre-share group 1 lifetime 86400 exit
有可能会问，为什么前面的配置脚本里面都没有这些命令呢？情况是这样的，在路由器上和VPN3020上面存在默认的policy，即使不配置policy，系统也有一个默认的policy，在路由器上可以通过命令：show crypto isakmp policy来查看系统已经存在的policy。
MP2692#show crypto isakmp policy Protection suite priority 1
encryption algorithm: DES - Data Encryption Standard (56 bit keys) hash algorithm: SHA - Security Hash Algorith authentication method: Pre-shared key
Diffie-Hellman group: #1 (768 bits Diffie-Hellman group) lifetime: 86400 seconds
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys) hash algorithm: SHA - Secure Hash Standard authentication method: Pre-shared key
Diffie-Hellman group: #1 (768 bits Diffie-Hellman group) lifetime: 86400 seconds
粗体显示的就是系统默认的一个policy。前面的那个Protection suite priority 1是手工配置进去。数字1表示的是优先级（数字越小，优先级越高）——在存在多个policy情况在，优先匹配使用优先级高的policy。建议不要配置policy，因为路由器的默认policy配置和VPN3020的默认policy是一致，如果要配置，主要两端的配置参数一致（包括加密算法、hash算法、认证方式、D-H组，生存时间可以不一致。）。
双方建立一个共享的秘密时，尽管事实上有多种方式都可以做到，但IKE无论如何都只使用一个Diffie-Hellman交换。进行Diffie-Hellman交换这一事实是铁定的，是不可协商改变的！但是，对其中采用的具体参数而言，却是可以商量的。Diffie-Hellman交换以及一个共享秘密的建立是IKE协议的第二步。
Diffie-Hellman交换完成后，通信双方已建立了一个共享的秘密，只是尚未验证通过。它们可利用该秘密（在IKE的情况下，则使用自它衍生的一个秘密）来保护自家的通信。但在这种情况下，却不能保证远程通信方事实上真是自己所信任的。因此， IKE交换的下一个步骤便是对Diffie-Hellman共享秘密进行验证，同时理所当然地，还要对IKE SA本身进行验证。IKE定义了五种验证方法：预共享密钥；数字签名（使用数字签名标准，即DSS）；数字签名（使用RSA公共密钥算法）；用RSA进行加密的nonce交换；以及用加密nonce进行的一种“校订”验证方法，它与其它加密的nonce方法稍有区别（所谓“nonce”，其实就是一种随机数字。）。
通过上面三步，IKE SA就完成了创建（我们称IKE SA的创建为“阶段一”）。之后，在特定的IKE SA的保护之下，协商拟定IPSec SA（IKE SA是由阶段一的某种交换所创建的），称为“阶段二”。
在默认情况下， IPSec SA使用的密钥是自IKE秘密状态衍生的。伪随机nonce会在阶段二进行交换，并与秘密状态进行散列处理，以生成密钥，并确保所有SA都拥有独一无二的密钥。所有这样的密钥均不具备“完美向前保密（PFS）”的特性，因为它们都是从同一个“根”密钥衍生出来的（IKE共享秘密）。为了提供PFS，Diffie-Hellman公共值以及衍生出它们的那个组都要和nonce一道进行交换，同时还要交换具体的IPSec SA协商参数。最后，用得到的秘密来生成IPSec SA，以确保实现所谓的“完美向前保密”。
4.3．IPSec与NAT
牢骚两句NAT：对NAT的技术可谓是爱恨交加，谁教IP地址是如此的紧缺呢？一方面，
NAT技术极大的缓解了Internet地址的耗尽，也从给网络带来了一定程度上的安全性。解决了很多由于IP地址紧缺的问题。但同时，由于它破坏了Internet的设计初衷之一——数据在传输过程中不应该被更改，导致了与很多应用都与之存在冲突，产生了很多关于NAT穿越的问题，给研发人员带来沉重的负担。例如FTP穿越NAT、H.323（IP语音）穿越NAT，MSN穿越NAT、NetBIOS穿越NAT，下面主要谈谈是IPSec为什么与NAT产生冲突，以及是如何解决这种冲突的。
4.3.1．IPSec与NAT的冲突
应该说，自从IPSec协议一出来，就与NAT技术产生了几乎是难以调和的矛盾。在了解冲突之前，有必要对NAT做一简单的说明。NAT（Network Address Translation，网络地址转换），是根据需要将数据包的源地址或者目的地址更换成另外一个地址，一般是应用在网络边界上。NAPT（Network Address Port Translation，网络地址端口转换）是解决内网多台PC共用一个IP接入Internet的一种技术。关于IPSec与NAT的冲突在RFC草案上面的详细描述有十几条，这里我只是从较易理解的角度来说明几点冲突：
1、NAT与IPSec协议族中的AH协议存在冲突。并且直到如今，该冲突都没有解决（由于有ESP协议可以使用，也没有谁去解决）。前面已经简单讲过，AH是认证头协议，它认证的范围是包括IP报文的头部。通俗可以理解成这样：如果你更改了我的IP头，我就认为你这个报文已经被篡改，我将丢弃它。同时，我们知道，NAT就是专门干这种事情的——我就是要修改你的IP头。互不相让，结果，该冲突导致的结果，在NAT设备存在的情况下，即使IPSec支持NAT穿越，也不能使用AH协议。（因此，在前文已建议在配置变换集合的时候不要选用ah协议。）
2、NAPT无法解析ESP协议。NAPT技术与传输层的协议是密切相关的，它是依靠TCP或者UDP的端口号来区分它的每一条连接。ESP协议是被IP所封装，其协议号是50（AH是51），当NAT设备试图对其进行解析的时候，发现不是它说熟知的TCP、UDP或者ICMP，这时候，不同的NAT实现，有不同的实现方式，有的是丢弃，有的是仅仅转换其IP地址（当IP地址不够的时候，就只有丢弃了）。
3、IKE协议与NAT的冲突。IKE协议是用来协商Internet密钥的，在前面所有的配置案例中都需要用到它。IKE协议是用UDP协议封装的，其知名端口号是500。在标准的IKE实现中，要求其源端口必须也是500。当他们之前存在NAT设备的时候，就有可能存在问题了，有些NAT设备可能会更改报文的源端口号，导致对端设备会误认为这一个非法的IKE协商请求。其实，这也是技术人员反映的隧道都能够建立成功，但是为什么数据不通的原因了。建立隧道的过程是IKE报文（被UDP报文所封装）交互的过程，由于NAT设备能够处理UDP报文，因此，他们能够成功建立隧道。但是当ESP报文到来的时候，NAT设备无法处理，就会丢弃报文而导致数据不通。
4.3.2．IPSec的解决与NAT冲突的方案
解决该冲突的方案与那些FTP穿越NAT、H.323穿越NAT存在很大不同的。像FTP穿越NAT、H.323穿越NAT都是NAT设备改进来适应该应用，而IPSec的NAT穿越是修改IPSec的处理方式来适应NAT的环境。
目前，很多厂家的实现方案都是在ESP报文的前面在封装一层UDP头（UDP报文是可以轻松穿过NAT设备的），同时修改IKE协议的一些限制（如，不再需要对端是源端口是500，而可以是浮动端口）等。当两端检测到中间存在NAT设备的时候，他们在协商的完成以后，在完成ESP封装以后，就会再封装一层UDP头。如果中间没有NAT设备，就像正常的处理一样