CN1350382A

CN1350382A - 基于pki的vpn密钥交换的实现方法

Info

Publication number: CN1350382A
Application number: CN 01132348
Authority: CN
Inventors: 胡爱群; 曹秀英; 吴越; 疏朝明; 卜勇华; 宋宇波; 王兴建
Original assignee: Southeast University
Current assignee: Southeast University
Priority date: 2001-11-29
Filing date: 2001-11-29
Publication date: 2002-05-22
Anticipated expiration: 2021-11-29
Also published as: CN1268088C

Abstract

本发明提出基于PKI的VPN密钥交换的实现方法。该方法是针对IKE的不足,提出利用PKI(Public Key Infrastructure)即公共密钥基础设施基础平台来实现IKE密钥交换中设备的身份认证。以PKI为基础的数字签名提供了认证和完整性,以PKI为基础的加密术提供了机密性。PKI能支持控制访问敏感信息的权限的努力和提供交易信息的认证证据,或记录其发起者,PKI能对VPN通信的安全提供一种可靠的技术和法律基础。

Description

基于PKI的VPN密钥交换的实现方法

技术领域

本发明涉及基于IP的网络安全技术，尤其涉及基于PKI的VPN密钥交换的实现方法。

背景技术

Internet RFC2764，RFC2401，RFC2407-RFC2412详细描述了基于IP的虚拟专用网络体系结构、IP安全协议结构和IKE(The Internet Key Exchange)即Internet密钥交换技术。IKE是IPsec目前唯一正式确定的密钥交换协议，并作为ISAKMP的一部分使用，它给AH或ESP提供密钥交换支持，同时也支持VPN密钥协商机制。在ISAKMP中密钥交换是独立的，可以支持不同的密钥交换方式。

IKE使用ISAKMP定义的“阶段”概念。其中第一阶段是指两个ISAKMP对等端(peer)建立安全认证的通信通道和ISAKMP安全关联(SA)，运行在该阶段下的有“主模式”(Main Mode)和“进取模式”(Aggressive Mode)，其中前者是必需的，后者是可选的。第二阶段对安全关联可提供的服务以及这些服务所需要的密钥和(或)参数进行协商，该阶段下运行的有必须实现的“快速模式”(Quick Mode)，它提供密钥更新功能。此外还有必须在第一阶段后运行的“新组模式”(New Group Mode)，它用于定义Diffie-Hellman专用组。

(1)IKE第一阶段(Phase1)：主模式(Main Mode)

ISAKMP通过协商建立双向的安全连接，其中必须协商的内容有：加密算法(必须包括CBC模式的DES，也应该支持3DES)、散列算法(必须包括MD5和SHA)、认证方式、Diffie-Hellman信息。

在阶段1中，首先建立ISAKMP安全关联(ISAKMP SA)。这样，所有通信双方的IKE通信可以被认证加密并得到完整性校验。IKE阶段1建立的安全通道可以保证阶段2的协商通信。在发送者I和接收者R之间共有6条消息交互。

消息1中，发送者I在ISAKMP报头(Header)中产生Cookie_I(C_I)和ISAKMP荷载(Payload)(ISA_I)，ISA_I包括安全关联荷载(SA Payload)和一组建议(Proposals)及每个建议可选择的一组变换(Transforms)；消息2中，接收者R在ISAKMP报头中产生C_R并响应其中的一个建议和变换回应发送者I；消息3和4分别包含了通信双方各自产生的随机数(Nonce)N_I和N_R，Nonce是一个64-2048bit的大随机数，用来增加密钥协商过程的熵(或随机度)，它还可以保证每次会话的新鲜性(Liveliness)，即每次会话只用一个Nonce，从而避免了重发攻击(Replay Attack)；消息5和6是用消息1和2中已协商的加密算法进行了加密(用^*表示已加密)。加密消息中包含了双方各自的身份ID_I和ID_R以及以消息认证码(MAC)形式出现的认证数据AUTH_I和AUTH_R。其中身份ID_I和ID_R可以是预先唯一确定的用户或主机名，如：IP地址，合法的域名(FQDN，Full Qualified Domain Name)，证书或Email地址等。

(2)密钥材料的获取

在使用加密和散列算法时采用不同的密钥，主密钥SKEYID的值由不同的认证方法确定。在IKE的主模式或进取模式中，共有四种认证方法，分别是数字签名认证方式、两种用公钥加密的认证方式和预共享密钥认证方式。SKEYID由所选的认证方法独立计算，具体是：

数字签名认证方式： SKEYID＝hashfunc(N_i|N_r，k)

公钥加密的认证方式： SKEYID＝hashfunc(hashfunc(N_i|N_r)，C_I|C_R)

预共享密钥认证方式： SKEYID＝hashfunc(PSKEY，N_i|N_r)

(3)主模式中的数字签名认证方式

IKE中最常用的是建立在公共密钥基础上的数字签名认证方式。数字签名可采用DSA算法或RSA算法，公共密钥通常是从证书中获取的，而IKE允许证书的交换，而且也允许从一个远程通信方那里索取证书。通信双方各自用自己的私钥对HASH_I和HASH_R进行签名。

图中，数字签名为：

SIG_I＝PRVKEY_I(HASH_I)

SIG_R＝PRVKEY_R(HASH_R)

由于采用了可选的载荷，所以我们既可以请求证书(Cert-Req载荷)，又可以交换证书(Cert载荷)，数字签名是无法抵赖的，只要每一方都保留了同IKE会话对应的状态，它们就可以确定无疑地证明自己是在同一个特定的实体进行通信。

但是，现有的IKE未对证书如何获取和验证作进一步的说明，只给出了数字签名认证方式中证书作为可选项的定义，未详细描述，也未给出具体的实现方法。

发明内容

本发明的目的是针对IKE的不足，提出利用PKI(Public Key Infrastructure)即公共密钥基础设施基础平台来实现IKE密钥交换中设备的身份认证。以PKI为基础的数字签名提供了认证和完整性，以PKI为基础的加密术提供了机密性。PKI能支持控制访问敏感信息的权限的努力和提供交易信息的认证证据，或记录其发起者，PKI能对VPN通信的安全提供一种可靠的技术和法律基础。

本发明的目的是这样实现的，一种基于PKI的VPN密钥交换的实现方法利用PKI基础设施平台来实现IKE密钥交换中设备的身份认证，其具体步骤如下：

a.第一阶段为主模式，数字签名认证方式，在发送者和接收者之间共有6条消息交互，包括，

①消息1和消息2用来协商安全关联的特性，所述消息1和消息2以明文方式传输，且没有身份认证，所述消息1中，发起者有提出好几条建议，每条建议给出一个协议，且每个协议中可以定义几种转换，消息2中响应者只能选择一条建议，如图1所示；消息3和消息4交换现时值nonce，同时用响应方的Diffie-Hellman基本的密钥交换方法交换建立一个主密钥，如图2所示；

③消息5和消息6交换通信双方互相认证所需的信息，其中包含了证书和发送者的数字签名，如图3所示；

④消息5和消息6的内容由所述消息1到消息4建立的密码算法和密钥来保护，其中身份ID_I和ID_R可以是预先唯一确定的用户或主机名；

第二阶段，快速模式，该模式目的是产生一个非ISAKMP SA(如ESP SA或AH SA)。包括，

①消息1的IPSec安全关联(SA)荷载中可以包含一组建议，消息2只能选择一条建议，密钥交换荷载在系统要求完美前向保密时才存在，且散列(Hash)荷载必须紧接在ISAKMP报头之后，如图4所示；即先是ISAKMP荷载，然后是Hash荷载，接下去是SA荷载等等。

②消息3将散列(Hash)结果传送给接收者，如图5所示。

上述的消息5和消息6用于交换通信双方互相认证所需的信息。消息5和消息6的内容由消息1到消息4建立的密码算法和密钥来保护。其中身份ID_I和ID_R可以是预先唯一确定的用户或主机名，如：IP地址，合法的域名(FQDN，Full Qualified Domain Name)或Email地址等。证书可以有多种选择，但应用最为广泛的是X.509证书，X.509方案的核心是与每个用户联系的公开密钥证书。这些用户证书采取由某些可信证书授权机构(CA)创建，由CA或用户放在目录中。目录服务其本身不负责公开密钥的生成或证书函数，它仅提供一个易于访问的位置以便用户获得证书。

X.509也包括三个可选的认证过程——单向认证，双向认证，三向认证以供不同的应用使用。所有这些过程都使用公开密钥签名。它假定双方都知道对方的公开密钥，或者通过从目录获得对方的证书，或者证书被包含在每方的初始报文中。

本发明采用X.509证书来确保身份(Identity)的正确性，同时也向接收消息者提供发送消息者的公共密钥，用来验证数字签名。从而保证使IKE阶段1建立的安全通道可以保证阶段2的协商通信。

在图6中，VPN网关1发送自己的X.509证书给VPN网关2，VPN网关2收到含VPN网关1公钥(由CA签发)的证书后，便到目录服务器去查询和验证证书是否有效，以认证中心的公共密钥验证此证书，若是验证正确，则相信认证中心的公正性，进而相信此证书是正确的，也相信了证书中所含公钥的正确性。这样将网络上需要对每个实体都必须认证的问题，收敛到对认证中心的认证，只要取得认证中心正确的公钥，就可以验证证书进而验证发送者数字签名的有效性。

本发明完成了基于LINUX操作系统的客户机/服务器IKE密钥交换缺省认证的方法，提出将PKI与VPN紧密集成，弥补了IKE中未对证书如何获取和验证作详细描述的不足，充分保证基于IPSec的VPN网络密钥交换的安全性。

附图说明图1：消息1和消息2报文格式图2：消息3和消息4报文格式图3：消息5和消息6报文格式图4：快速模式消息1和消息2报文格式图5：快速模式消息3报文格式图6：基于PKI的企业Intranet VPN方案图7：实施例编程框图

具体实施方式

下面结合附图以及实施例对本发明作进一步说明。

图6为基于PKI的企业Intranet VPN的构建方案，PKI管理中心14包含证书授权机构CA(Certificate Authority)和证书注册机构RA(Registration Authority)，它提供产生、分发、撤消、认证等服务，以及不同CA之间的交叉认证。PKI管理中心14将证书信息和证书撤消信息CRL(Certificate Revocation List)放在证书库中，通常证书库采用X.500目录服务或轻量级目录访问协议LDAP来实现，即将证书及其相关信息放在目录服务器中供用户访问。VPN网关1发送自己的X.509证书给VPN网关2，VPN网关2收到含VPN网关1公钥(由CA签发)的证书后，便到目录服务器12去查询和验证证书是否有效，以认证中心的公共密钥验证此证书，若是验证正确，则相信认证中心的公正性，进而相信此证书是正确的，也相信了证书中所含公钥的正确性。这样将网络上需要对每个实体都必须认证的问题，收敛到对认证中心的认证，只要取得认证中心正确的公钥，就可以验证证书进而验证发送者数字签名的有效性。

编程框图如图7所示，右边的两个模块，包括套接字层21、传输层协议22、IP24、链路层协议25、应用层进程17和应用层协议19为TCP/IP协议栈，上方的ISAKMP为应用层协议，通过应用程序编程接口API20为安全协议模块23(如认证协议AH、安全负载封装协议ESP)提供安全关联和密钥管理，而密钥交换定义模块18此处为Internet密钥交换协议IKE，解释域模块DOI(Domain Of Interpretation)15则用来说明IPSec中的交换类型、荷载格式和处理方法等。本方法的演示程序利用套接口(sockets)API20在Linux操作系统下开发，演示了IKE两个阶段的密钥交换过程，在第一阶段，选用主模式(Main mode)，一共六条消息；第二阶段，采用快速模式(Quick mode)，共三条消息。

第一阶段：

如图1所示，消息1提出一个或几个关于“保护套件”的题案，“保护套件”是一组参数，包括加密算法，散列算法，验证方法，以及Diffe-Helllman组，作为转换载荷(transformpayload)。例如，我们可以选用DES CBC或3DES CBC作为加密算法，SHA-1或MD5作为散列算法，验证方法选用DSS算法或预共享密钥，Diffe-Helllman组选用一个含768位模数的MODP组，模数为：

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF

格式如下例：

消息2：根据消息1中的题案，选取一组合适的参数，作为“保护套件”。例如，加密算法采用DES CBC，散列算法采用SHA-1，验证方法采用预共享密钥，Diffe-Helllman组选用768位模数的MODP组。

以下各项数据从同一次密钥交换过程中得到。

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      ～            ISAKMP Header with XCHG of Main Mode，                ～

       ～                 and Next Payload of ISA_SA                     ～

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ！      0        ！    RESERVED   ！       Payload Length          ！

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ！                 Domain of Interpretation                        ！

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ！                         Situation                                ！

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ！      0        ！   RESERVED    ！       Payload Length          ！

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ！ Proposal #1  ！PROTO_ISAKMP   ！SPI size＝0   | # Transforms  ！

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ！   ISA_TRANS   ！   RESERVED    ！       Payload Length          ！

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ！ Transform #1 ！ KEY_OAKLEY    |          RESERVED2            ！

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ～                  prefered SA attributes                         ～

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ！      0        ！   RESERVED    ！       Payload Length          ！

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ！ Transform #2 ！ KEY_OAKLEY    |          RESERVED2            ！
				
				<dp n="d6"/>
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      ～                  alternate SA attributes                       ～

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

如图2所示，消息3交换两个消息，其一为发起方的Diffe-Helllman公共密钥，假设xi为发起方的私钥，则g^xi(在MODP768组中，g取2)就是其Diffe-Helllman公共密钥，私钥是随机产生的，只有发送方知道，接收方或截获者很难通过g^xi求出xi来。另一个为发起方的nonce，它是个伪随机序列。消息3格式如下例：

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ～            ISAKMP Header with XCHG of Main Mode，                ～

       ～                 and Next Payload of ISA_KE                     ～

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ！   ISA_NONCE   ！   RESERVED    ！       Payload Length          ！

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ～  D-H Public Value  (g^xi from initiator g^xr from responder)  ～

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ！       0       ！   RESERVED    ！       Payload Length          ！

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ～        Ni (from initiator) or  Nr (from responder)            ～

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

某次演示中得出的g^xi为：

cc8f 80d2 ccab ca21 3c20 3c98 a69c 882e b70a 86c6 78ae bfcc cd72 a21f cdd2e8be 9b6f e9a2 5245 ff54 8e78 c73a 14ea 6217 6722 c747 51bd 6f71 6658 b2a9 af3dd9a5 9ba2 4828 08f3 8a03 b811 838b fa8f 429c 86b5 5b62 551f 948e ef5f 7bbb 6cd8f063

得出的发起方nonce为：

a946f020699f27ba13d4980cbba80aef

消息4：与消息3类似，即交换响应方的Diffe-Helllman公共密钥和nonce，假设g^xr表示响应方的Diffe-Helllman公共密钥，某次演示中得出的g^xr值为：

d1f9 1f74 6b16 0e7e 14b6 8856 be78 ecc2 faed de04 ef9c da96 85ba e348 d0e18d26 84fd 88a1 43ba 65bf e089 3f5e 763d d741 4bc8 625d 176f fd32 c70f 71cd c8efbe03 fcdb 5dcc 97fc 6e02 9152 baef 70d9 970e dfd6 411e 94f5 8dc3 8262 8257 f1cd691b

响应方nonce为：

f106115c9b6325c426c3eeef1e9124e8

根据前四条消息提供的信息，求出一组密钥：

如果采用签名验证，SKEYID＝prf(Ni_b|Nr_b，g^xy)

如果采用公钥加密，SKEYID＝prf(hash(Ni_b|Nr_b)，CKY-I|CKY-R)

如果采用预共享密钥，SKEYID＝prf(pre-shared-key，Ni_b|Nr_b)

SKEYID_d＝prf(SKEYID，g^xy|CKY-I|CKY-R|0)

SKEYID_a＝prf(SKEYID，SKEYID_d|g^xy|CKY-I|CKY-R|1)

SKEYID_e＝prf(SKEYID，SKEYID_a|g^xy|CKY-I|CKY-R|2)

SKEYID_d用于生成IPSec的密钥，SKEYID_a用来保障IKE消息的完整性并对数据源身份进行验证，SKEYID_e用于对IKE消息进行加密。

这次演示得到的这组密钥如下：

SKEYID＝ccff491b8075c2d6351cf99f3895c4fe3c941cde

SKEYID_d＝475cd7edec45f582d98295ada94b4c085c22b881

SKEYID_a＝d23c6e33503e2c8ebc2dbb68cbf0bcde561cff4b

SKEYID_e＝191c1a3a77163ecce87aec4fe0711d65515f9f81

如图3所示，消息5和6：用来对本次密钥交换进行验证，方法是通信双方各计算出一个散列结果，对发起方：

对响应方：

IDii_b及IDir_b分别代表发起方和响应方的身份。如果采用预共享密钥验证，只需根据已知信息，计算出与接收到的散列相对应的结果，如果相符，即验证通过。如果采用签名验证，还需要对散列结果用公钥进行签名，双方验证签名后的结果。这两条消息需要用SKEYID_e进行加密。

快速模式本身不是一个完整的交换过程，它只是SA协商过程中的第二阶段中的一种模式。快模式必须在第一阶段完成之后进行，受到第一阶段得到的ISAKMP SA的保护，为其他的非ISAKMP SA协商安全策略及交换相应的密钥。所以快模式中的交换数据除了ISAKMP头之外，都是加密传输的。

如图4所示，消息1中，ISAKMP头与第一阶段的基本相同。但isa_xchg应设为ISAKMP_XCHG_QUICK，并把加密比特位置位为1，而在第一阶段中是不加密的，相应位为0。Icookie和rcookie对应于第一阶段相应的cookie，以表示此快模式是在该ISAKMPSA的保护下进行的。而message ID是此快模式独有的，用来标示同一个，当然也可能不同的ISAKMP SA保护下的不同的快模式交换。这样有了不同的message ID，就可以并发进行多个快模式交换了。ISAKMP头中的载荷长度应包括加密填充后的整体长度。

对于HASH载荷，由于在作散列运算时要涉及到下面的载荷，所以放在所有的载荷处理完之后进行处理。

下面就是SA载荷，包括若干个建议，以及一个建议中相应的若干个转换。在这里我们只提一个建议，就是AH，当然也可以提ESP，或者两者都提。在AH建议中，我们又提供了两个转换，其一为AH_SHA；其二为AH_MD5，相应于提供的AH的两种建议算法，供给相应端选择。对于每一个建议都对应于一个唯一的SPI(4字节)

再下来是Nonce载荷，用随即数得到。然后是两个ID载荷，分别对应于发起端和相应端。这里，我们把发起端及相应端的IP地址最为其标识数据。

接下来，就是遗留下来的HASH载荷了。散列数据按以下公式得到：

HASH＝prf(SKEYID_a，M_ID|SA|Nonce_I|ID_I|ID_r)

其中，prf是第一阶段协商好的单向散列函数，SKEYID_a是第一阶段得到的认证密钥，下面的就是当前消息中的数据。

这样整个消息就完成了，为了安全期间，要用第一阶段协商好的加密算法和相应的密钥对这个消息加密。当然为了加密，可能会产生填充数据，这也应该算在消息长度中。

最后就是把加密了的第一条消息发送出去。

消息2对消息1提供的建议做出选择，并把结果告诉发起端。

消息2的构成与消息1类似，区别在于SA载荷，相应端要根据自己的安全策略选择发起端提供的安全建议。所以对于多个建议可能选其中的一个，或者一些，而对于转换，对应一个建议只能选一个转换。在这里，我们的建议是AH，选择MD5算法。

接受到第一条消息后，首先要进行的是解密，解密的算法和密钥是从第一阶段的交换中得到的。通过加密传输消息，消息的安全性得到了保证。解密成功后可以得到原始消息，相应端按照原始消息重新计算HASH，公式同上，并把计算结果与随消息传送过来的HASH结果相比较，如果不同，说明传输过程中出错了，或者有人恶意修改了消息中的某些数据。这样消息的完整性得到了保证。

首先通过cookie和message ID可以唯一的确定一次交换，这样如果收到了不同交换的第一条消息，就可以丢弃。如果一切正常，那么相应端加入自己的Nonce，即Nonce_r，这样对应于不同的建议，就有了相应唯一确定的SPI，算法和相应的密钥，其中得到密钥的算法如下：

KEYMAT＝prf(SKEYID_d，protocao|SPI|Nonce_i|Nonce_r)

其中的SKEYID_d也是第一阶段得到的，Nonce是确定的，但SPI是不同的，这样得到的密钥也是不一样的。

对应于消息2的HASH算法如下：

HASH＝prf(SKEYID_a，M-ID|Nonce_i|SA|Nonce_r|ID_I|ID_r)

这样第二条消息就处理好了，下面就是对其加密，发送。

如图5所示，消息3要简单很多，主要是接受相应端的选择，并向相应端发送确认消息。

消息3只由两部分构成，ISAKMP头和消息摘要。

同样地，先是解密和验证消息完整性的过程。通过以后，是读取响应端的选择结果，并根据相应端的Nonce计算出相应SPI的密钥，计算公式同上。

这样就得到了保护数据传输的安全算法及相应的密钥，安全的数据传输通道建立起来了。下面就是给相应端发送一个确认消息。

确认消息中的HASH算法如下：

HASH＝prf(SKEYID_a，0|M-ID|Nonce_i|Nonce_r)

在进行散列运算前，首先是要填充1字节的0。

最后就是加密，发送。

最后，响应端接受到发起端的确认信息，经过解密和完整性验证，整个快模式交换过程就结束了。下面就可以在建立起来的IPsec安全通道上进行安全的通信了。

Claims

1、一种基于PKI的VPN密钥交换的实现方法，其特征在于，所述实现方法利用PKI基础设施平台来实现IKE密钥交换中设备的身份认证，其具体步骤如下：

a.第一阶段，主模式数字签名认证方式，在发送者和接收者之间共有6条消息交互，包括，

①消息1和消息2用来协商安全关联的特性，所述消息1和消息2以明文方式传输，且没有身份认证，所述消息1中，发起者有提出好几条建议，每条建议给出一个协议，且每个协议中可以定义几种转换，消息2中响应者只能选择一条建议；

②消息3和消息4交换nonce，同时用响应方的Diffie-Hellman交换建立一个主密钥：

③消息5和消息6交换通信双方互相认证所需的信息，其中包含了证书和发送者的数字签名；

b.第二阶段，快速模式，包括，

①消息1的IPSec安全关联(SA)荷载中包含一组建议，消息2只能选择一条建议，密钥交换荷载在系统要求完美前向保密时才存在，且散列(Hash)荷载必须紧接在ISAKMP报头之后；

②消息3将散列(Hash)结果传送给接收者。

2、如权利要求1所述的实现方法，其特征在于，所述认证选用的证书是X.509证书，所述用户证书由可信证书授权机构(CA)创建，由CA或用户放在目录中，所述目录服务本身不负责公开密钥的生成或证书函数，它仅提供一个易于访问的位置使用户获得证书。

3、如权利要求2所述的实现方法，其特征在于，所述X.509证书包括三个可选的认证过程，单向认证，双向认证，三向认证，所述认证过程都使用公开密钥签名，设定发送者和接收者都知道对方的公开密钥，或者通过从目录获得对方的证书，或者证书被包含在每方的初始报文中。

4、如权利要求2所述的实现方法，其特征在于，所述X.509证书向接收消息者提供发送消息者的公共密钥。