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

基于pki的vpn密钥交换的实现方法 Download PDF

Info

Publication number
CN1350382A
CN1350382A CN 01132348 CN01132348A CN1350382A CN 1350382 A CN1350382 A CN 1350382A CN 01132348 CN01132348 CN 01132348 CN 01132348 A CN01132348 A CN 01132348A CN 1350382 A CN1350382 A CN 1350382A
Authority
CN
China
Prior art keywords
message
certificate
authentication
pki
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN 01132348
Other languages
English (en)
Other versions
CN1268088C (zh
Inventor
胡爱群
曹秀英
吴越
疏朝明
卜勇华
宋宇波
王兴建
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Southeast University
Original Assignee
Southeast University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Southeast University filed Critical Southeast University
Priority to CN 01132348 priority Critical patent/CN1268088C/zh
Publication of CN1350382A publication Critical patent/CN1350382A/zh
Application granted granted Critical
Publication of CN1268088C publication Critical patent/CN1268088C/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

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(CI)和ISAKMP荷载(Payload)(ISAI),ISAI包括安全关联荷载(SA Payload)和一组建议(Proposals)及每个建议可选择的一组变换(Transforms);消息2中,接收者R在ISAKMP报头中产生CR并响应其中的一个建议和变换回应发送者I;消息3和4分别包含了通信双方各自产生的随机数(Nonce)NI和NR,Nonce是一个64-2048bit的大随机数,用来增加密钥协商过程的熵(或随机度),它还可以保证每次会话的新鲜性(Liveliness),即每次会话只用一个Nonce,从而避免了重发攻击(Replay Attack);消息5和6是用消息1和2中已协商的加密算法进行了加密(用*表示已加密)。加密消息中包含了双方各自的身份IDI和IDR以及以消息认证码(MAC)形式出现的认证数据AUTHI和AUTHR。其中身份IDI和IDR可以是预先唯一确定的用户或主机名,如:IP地址,合法的域名(FQDN,Full Qualified Domain Name),证书或Email地址等。
(2)密钥材料的获取
在使用加密和散列算法时采用不同的密钥,主密钥SKEYID的值由不同的认证方法确定。在IKE的主模式或进取模式中,共有四种认证方法,分别是数字签名认证方式、两种用公钥加密的认证方式和预共享密钥认证方式。SKEYID由所选的认证方法独立计算,具体是:
数字签名认证方式:      SKEYID=hashfunc(Ni|Nr,k)
公钥加密的认证方式:    SKEYID=hashfunc(hashfunc(Ni|Nr),CI|CR)
预共享密钥认证方式:    SKEYID=hashfunc(PSKEY,Ni|Nr)
(3)主模式中的数字签名认证方式
IKE中最常用的是建立在公共密钥基础上的数字签名认证方式。数字签名可采用DSA算法或RSA算法,公共密钥通常是从证书中获取的,而IKE允许证书的交换,而且也允许从一个远程通信方那里索取证书。通信双方各自用自己的私钥对HASHI和HASHR进行签名。
图中,数字签名为:
SIGI=PRVKEYI(HASHI)
SIGR=PRVKEYR(HASHR)
由于采用了可选的载荷,所以我们既可以请求证书(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建立的密码算法和密钥来保护,其中身份IDI和IDR可以是预先唯一确定的用户或主机名;
第二阶段,快速模式,该模式目的是产生一个非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建立的密码算法和密钥来保护。其中身份IDI和IDR可以是预先唯一确定的用户或主机名,如: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:用来对本次密钥交换进行验证,方法是通信双方各计算出一个散列结果,对发起方:
HASH_I=prf(SKEYID,g^xi|g^xr|CKY-I|CKY-R|SAi_b|IDii_b)
对响应方:
HASH_R=prf(SKEYID,g^xr|g^xi|CKY-R|CKY-I|SAi_b|IDir_b)
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 (4)

1、一种基于PKI的VPN密钥交换的实现方法,其特征在于,所述实现方法利用PKI基础设施平台来实现IKE密钥交换中设备的身份认证,其具体步骤如下:
a.第一阶段,主模式数字签名认证方式,在发送者和接收者之间共有6条消息交互,包括,
①消息1和消息2用来协商安全关联的特性,所述消息1和消息2以明文方式传输,且没有身份认证,所述消息1中,发起者有提出好几条建议,每条建议给出一个协议,且每个协议中可以定义几种转换,消息2中响应者只能选择一条建议;
②消息3和消息4交换nonce,同时用响应方的Diffie-Hellman交换建立一个主密钥:
③消息5和消息6交换通信双方互相认证所需的信息,其中包含了证书和发送者的数字签名;
④消息5和消息6的内容由所述消息1到消息4建立的密码算法和密钥来保护,其中身份IDI和IDR可以是预先唯一确定的用户或主机名;
b.第二阶段,快速模式,包括,
①消息1的IPSec安全关联(SA)荷载中包含一组建议,消息2只能选择一条建议,密钥交换荷载在系统要求完美前向保密时才存在,且散列(Hash)荷载必须紧接在ISAKMP报头之后;
②消息3将散列(Hash)结果传送给接收者。
2、如权利要求1所述的实现方法,其特征在于,所述认证选用的证书是X.509证书,所述用户证书由可信证书授权机构(CA)创建,由CA或用户放在目录中,所述目录服务本身不负责公开密钥的生成或证书函数,它仅提供一个易于访问的位置使用户获得证书。
3、如权利要求2所述的实现方法,其特征在于,所述X.509证书包括三个可选的认证过程,单向认证,双向认证,三向认证,所述认证过程都使用公开密钥签名,设定发送者和接收者都知道对方的公开密钥,或者通过从目录获得对方的证书,或者证书被包含在每方的初始报文中。
4、如权利要求2所述的实现方法,其特征在于,所述X.509证书向接收消息者提供发送消息者的公共密钥。
CN 01132348 2001-11-29 2001-11-29 基于pki的vpn密钥交换的实现方法 Expired - Fee Related CN1268088C (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN 01132348 CN1268088C (zh) 2001-11-29 2001-11-29 基于pki的vpn密钥交换的实现方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN 01132348 CN1268088C (zh) 2001-11-29 2001-11-29 基于pki的vpn密钥交换的实现方法

Publications (2)

Publication Number Publication Date
CN1350382A true CN1350382A (zh) 2002-05-22
CN1268088C CN1268088C (zh) 2006-08-02

Family

ID=4671379

Family Applications (1)

Application Number Title Priority Date Filing Date
CN 01132348 Expired - Fee Related CN1268088C (zh) 2001-11-29 2001-11-29 基于pki的vpn密钥交换的实现方法

Country Status (1)

Country Link
CN (1) CN1268088C (zh)

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007065333A1 (en) * 2005-12-07 2007-06-14 Huawei Technologies Co. Ltd. A method and system for authenticating the identity
CN100347986C (zh) * 2003-11-24 2007-11-07 华中科技大学 一种身份认证的方法和系统
CN100352220C (zh) * 2004-11-18 2007-11-28 中兴通讯股份有限公司 基于动态主机配置协议加网络门户认证的安全接入方法
CN100356756C (zh) * 2004-03-04 2007-12-19 上海交通大学 实现大规模交互式虚拟专用网教学实验的方法
CN100385885C (zh) * 2004-07-09 2008-04-30 威达电股份有限公司 具ssl保护功能的安全网关及方法
CN100534092C (zh) * 2003-07-17 2009-08-26 国际商业机器公司 用于执行认证操作的方法及其装置
CN1777093B (zh) * 2004-11-16 2010-04-14 中兴通讯股份有限公司 一种解决因特网密钥协商协议中协商碰撞的方法
CN101084505B (zh) * 2004-11-12 2010-04-21 索尼计算机娱乐公司 用于保护数据处理和传送安全的方法和设备
CN1578215B (zh) * 2003-06-30 2010-05-12 微软公司 安全协议的自动协商系统和方法
CN101272241B (zh) * 2008-04-09 2010-05-12 西安西电捷通无线网络通信有限公司 一种密钥的分配与管理方法
CN1685660B (zh) * 2002-09-27 2010-06-09 英特尔公司 在一个密码系统中增强鉴别的方法
CN1711740B (zh) * 2002-10-14 2010-08-25 思科技术公司 轻度可扩展验证协议的密码预处理
CN1578218B (zh) * 2003-06-30 2010-12-08 微软公司 用透明虚拟专用网络减少网络配置复杂性
CN101156412B (zh) * 2005-02-11 2011-02-09 诺基亚公司 用于在通信网络中提供引导过程的方法和装置
CN101282208B (zh) * 2007-04-05 2011-04-06 华为技术有限公司 安全连接关联主密钥的更新方法和服务器及网络系统
CN1652502B (zh) * 2004-02-06 2011-04-06 松下电器产业株式会社 通信装置和通信程序
CN101248614B (zh) * 2005-08-26 2011-04-27 维亚赛斯公司 建立会话密钥的方法和实施该方法的单元
CN1759564B (zh) * 2003-03-10 2011-07-06 索尼株式会社 访问控制处理方法
CN1863048B (zh) * 2005-05-11 2012-04-11 中兴通讯股份有限公司 用户与接入设备间因特网密钥交换协商方法
CN101455025B (zh) * 2006-05-26 2012-09-05 卢森特技术有限公司 用于安全分组传输的加密方法
CN103534975A (zh) * 2011-05-11 2014-01-22 阿尔卡特朗讯公司 根据公开密钥发现用于密钥管理的安全关联
CN104243150A (zh) * 2014-09-05 2014-12-24 中国联合网络通信集团有限公司 一种IPSec公钥交互方法、节点和DNS服务器
CN105915511A (zh) * 2016-04-13 2016-08-31 深圳市融钞科技有限公司 基于vpdn专网的无线通讯方法
CN107409133A (zh) * 2015-03-30 2017-11-28 高通股份有限公司 具有完全前向保密的认证与密钥协商
CN108028838A (zh) * 2015-07-31 2018-05-11 Nicira股份有限公司 分布式vpn服务
CN111865564A (zh) * 2020-07-29 2020-10-30 北京浪潮数据技术有限公司 一种IPSec通信的建立方法和系统
CN114500013A (zh) * 2022-01-13 2022-05-13 中国人民解放军海军工程大学 一种数据加密传输方法
US11394692B2 (en) 2015-07-31 2022-07-19 Nicira, Inc. Distributed tunneling for VPN

Cited By (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1685660B (zh) * 2002-09-27 2010-06-09 英特尔公司 在一个密码系统中增强鉴别的方法
CN1711740B (zh) * 2002-10-14 2010-08-25 思科技术公司 轻度可扩展验证协议的密码预处理
CN1759564B (zh) * 2003-03-10 2011-07-06 索尼株式会社 访问控制处理方法
CN1578215B (zh) * 2003-06-30 2010-05-12 微软公司 安全协议的自动协商系统和方法
CN1578218B (zh) * 2003-06-30 2010-12-08 微软公司 用透明虚拟专用网络减少网络配置复杂性
CN100534092C (zh) * 2003-07-17 2009-08-26 国际商业机器公司 用于执行认证操作的方法及其装置
CN100347986C (zh) * 2003-11-24 2007-11-07 华中科技大学 一种身份认证的方法和系统
CN1652502B (zh) * 2004-02-06 2011-04-06 松下电器产业株式会社 通信装置和通信程序
CN100356756C (zh) * 2004-03-04 2007-12-19 上海交通大学 实现大规模交互式虚拟专用网教学实验的方法
CN100385885C (zh) * 2004-07-09 2008-04-30 威达电股份有限公司 具ssl保护功能的安全网关及方法
CN101084505B (zh) * 2004-11-12 2010-04-21 索尼计算机娱乐公司 用于保护数据处理和传送安全的方法和设备
CN1777093B (zh) * 2004-11-16 2010-04-14 中兴通讯股份有限公司 一种解决因特网密钥协商协议中协商碰撞的方法
CN100352220C (zh) * 2004-11-18 2007-11-28 中兴通讯股份有限公司 基于动态主机配置协议加网络门户认证的安全接入方法
CN101156412B (zh) * 2005-02-11 2011-02-09 诺基亚公司 用于在通信网络中提供引导过程的方法和装置
CN1863048B (zh) * 2005-05-11 2012-04-11 中兴通讯股份有限公司 用户与接入设备间因特网密钥交换协商方法
CN101248614B (zh) * 2005-08-26 2011-04-27 维亚赛斯公司 建立会话密钥的方法和实施该方法的单元
WO2007065333A1 (en) * 2005-12-07 2007-06-14 Huawei Technologies Co. Ltd. A method and system for authenticating the identity
CN101455025B (zh) * 2006-05-26 2012-09-05 卢森特技术有限公司 用于安全分组传输的加密方法
CN101282208B (zh) * 2007-04-05 2011-04-06 华为技术有限公司 安全连接关联主密钥的更新方法和服务器及网络系统
CN101272241B (zh) * 2008-04-09 2010-05-12 西安西电捷通无线网络通信有限公司 一种密钥的分配与管理方法
CN103534975B (zh) * 2011-05-11 2016-09-07 阿尔卡特朗讯公司 根据公开密钥发现用于密钥管理的安全关联
CN103534975A (zh) * 2011-05-11 2014-01-22 阿尔卡特朗讯公司 根据公开密钥发现用于密钥管理的安全关联
CN104243150A (zh) * 2014-09-05 2014-12-24 中国联合网络通信集团有限公司 一种IPSec公钥交互方法、节点和DNS服务器
CN107409133A (zh) * 2015-03-30 2017-11-28 高通股份有限公司 具有完全前向保密的认证与密钥协商
CN107409133B (zh) * 2015-03-30 2020-06-19 高通股份有限公司 一种具有完全前向保密的认证与密钥协商的方法以及设备
CN108028838A (zh) * 2015-07-31 2018-05-11 Nicira股份有限公司 分布式vpn服务
CN108028838B (zh) * 2015-07-31 2020-11-24 Nicira股份有限公司 分布式vpn服务
US11394692B2 (en) 2015-07-31 2022-07-19 Nicira, Inc. Distributed tunneling for VPN
CN105915511A (zh) * 2016-04-13 2016-08-31 深圳市融钞科技有限公司 基于vpdn专网的无线通讯方法
CN111865564A (zh) * 2020-07-29 2020-10-30 北京浪潮数据技术有限公司 一种IPSec通信的建立方法和系统
CN114500013A (zh) * 2022-01-13 2022-05-13 中国人民解放军海军工程大学 一种数据加密传输方法
CN114500013B (zh) * 2022-01-13 2023-06-13 中国人民解放军海军工程大学 一种数据加密传输方法

Also Published As

Publication number Publication date
CN1268088C (zh) 2006-08-02

Similar Documents

Publication Publication Date Title
CN1268088C (zh) 基于pki的vpn密钥交换的实现方法
US9819666B2 (en) Pass-thru for client authentication
CN1148926C (zh) 使代理主机参与保密通信的方法和系统以及密码系统
CN100558035C (zh) 一种双向认证方法及系统
US8635445B2 (en) Method for digital identity authentication
JP4000111B2 (ja) 通信装置および通信方法
CN1468488A (zh) 用于通过网关认证移动用户的方法和系统
US20090240941A1 (en) Method and apparatus for authenticating device in multi domain home network environment
US20050149732A1 (en) Use of static Diffie-Hellman key with IPSec for authentication
WO2010078755A1 (zh) 电子邮件的传送方法、系统及wapi终端
CN108650227A (zh) 基于数据报安全传输协议的握手方法及系统
CN1645792A (zh) 通信装置、数字签名发行方法、装置及签名发送方法
CN1722658A (zh) 计算机系统的有效的和安全的认证
JP2008545353A (ja) 未知の通信当事者間における信頼できる関係の確立
CA2551113A1 (en) Authentication system for networked computer applications
CN102404347A (zh) 一种基于公钥基础设施的移动互联网接入认证方法
JP2003298568A (ja) 鍵供託を使用しない、認証された個別暗号システム
CN103905384A (zh) 基于安全数字证书的嵌入式终端间会话握手的实现方法
JP4870427B2 (ja) デジタル証明書交換方法、端末装置、及びプログラム
WO2008002081A1 (en) Method and apparatus for authenticating device in multi domain home network environment
CN100499453C (zh) 一种客户端认证的方法
CN1859772A (zh) 一种基于通用鉴权框架的安全业务通信方法
CN1352434A (zh) 基于信任与授权服务的电子政务安全平台系统
KR20080005344A (ko) 인증서버가 사용자단말기를 인증하는 시스템
KR20070035342A (ko) 패스워드 기반의 경량화된 상호 인증 방법

Legal Events

Date Code Title Description
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
C19 Lapse of patent right due to non-payment of the annual fee
CF01 Termination of patent right due to non-payment of annual fee