WO2009076811A1

WO2009076811A1 - 密钥协商方法、用于密钥协商的系统、客户端及服务器

Info

Publication number: WO2009076811A1
Application number: PCT/CN2008/072547
Authority: WO
Inventors: Hongtao Gao
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2007-12-14
Filing date: 2008-09-26
Publication date: 2009-06-25
Also published as: EP2173055A1; CN101459506A; CN101459506B

Description

密钥协商方法、用于密钥协商的系统、客户端及服务器技术领域

本发明涉及通信技术领域，尤其涉及一种适用于传输层安全协议

( TLS , Transport Layer Security Protocol ) 的密钥协商方法、用于密钥协商的系统、客户端及服务器。背景技术

TLS是一种在通信技术领域得到广泛应用的协议，它为应用层提供通信双方认证、数据保密和完整性保护，其中，握手协议（ handshake protocol ) 部分负责通信双方的认证、协商加密、完整性保护算法和密钥，由于密钥是非公开的信息，因此通信双方在建立通信时需要对密钥进行协商，以使通信双方可以获得安全准确的相同密钥。

目前握手协议釆用的密钥协商方法主要有五种： RSA ( Rivest -Shamir

-Adleman ) 方式、匿名迪菲赫尔曼方式 ( Anonymous Diffie-Hellman , DH_anon ) 、固定 DH方式（Diffie-Hellman with signature, DH ) 、短暂 DH方式 ( Ephemeral Diffie-Hellman with signature, DHE ) 、共享密钥方式（pre-shared key, PSK ) 。下面介绍一下以上几种密钥协商方法的实现过程。

1、 RSA方式

RSA算法是一种非对称密码算法，其以发明人名字进行命名，是一种基于证书的密钥协商方法，其流程如图 1所示：

步骤 101、客户端通过发送客户端呼叫（Client— Hello )报文发起会话。在 TLS 中定义先发起呼叫的一方为客户端（client ) , 接收呼叫的一方为服务器（ server ) , 因此无论任何终端在向另一个终端发起呼叫时，发送 Client— Hello报文的一方都可以被称为客户端，接收 Client— Hello报文的一方都可以被称为服务器。

Client— Hello报文的参数包括：客户端支持的最高的 TLS/安全套接层协议层（SSL, Security Socket Layer )版本，随机数，会话标识符，终端支持的密文族（ CipherSuite ) 列表，支持的压缩方法列表。

步骤 102、服务器收到 Client— Hello报文后，从终端支持的密文族列表中选择支持 RSA方式的密文族，返回服务器呼叫（ server— hello )报文。

server— hello报文中包含服务器选择的密文族，及其他参数。

步骤 101和 102用于客户端和服务器协商安全能力，确定用哪种密文族。

步骤 103、服务器发送证书（Certificate )报文给客户端。

该 Certificate 4艮文中包含一个证书或一个证书链。

如果步骤 103中服务器发送的证书是签名证书，则服务器需要生成临时的公钥私钥对；如果是加密证书，则不需要生成临时的公钥私钥对。后续步骤以服务器证书是签名证书的情况为例说明 RSA方式的流程。

步骤 104、服务器生成临时的公钥私钥对。

步骤 105、服务器发送服务器密钥交流（ server— key— exchange )报文给客户端。该报文中包含步骤 104中生成的临时公钥，以及服务器对公钥的签名，该签名由步骤 103中的服务器证书对应的私钥生成。

步骤 106、服务器发送证书请求（ certificate— request )报文给客户端。本步骤是可选的，如果服务器需要对客户端做认证，则服务器发送 certificate— request报文给客户端。该报文包括期望的证书类型和可接受的证书管理机构的名字列表。

步骤 107、服务器发送结束（ ServerHelloDone )报文给客户端，指示服务器部分的消息已发送结束。该消息不含任何参数，发送完该消息后，服务器等待客户端的响应。

步骤 103到步骤 107用于密钥协商的服务器部分的消息发送。步骤 108、客户端验证步骤 103发送来的服务器证书。

验证证书通过后，使用证书中的服务器公钥验证步骤 105发送过来的服务器临时公钥的签名，验证通过即对服务器认证成功，可以认为该服务器是安全有效的。

步骤 109、客户端发送证书（certificate )报文给服务器，该报文包含客户端的证书或证书链。

本步骤通常在服务器要求客户端的证书时执行，即服务器进行过步骤 106后执行。

步骤 1010、客户端生成预先主密钥（ pre-master key ) 。

步骤 101 1、客户端发送预先主密钥给服务器。

客户端发送客户端密钥交流（ client— key— exchange ) 报文给服务器。该报文包含由步骤 105发送过来的服务器临时公钥加密的预先主密钥。

步骤 1012、客户端通过规定的算法从 pre-master key计算得到主密钥 ( master key ) 。

步骤 1013、客户端发送证书校验（ certificate— verify )报文到服务器。本步骤是可选的，如果客户端执行了步骤 109, 即发送了客户端证书给服务器，则客户端将本步骤之前的所有双方交互消息与主密钥 master key级联，并用客户端私钥对级联后的数据签名，然后客户端发送该签名给服务器，即 certificate— verify报文。

步骤 1014、根据 pre-master key 按规定的算法计算得到主密钥 master-key。

服务器用服务器临时私钥解密步骤 1011 发来的消息，即可获得 pre-master key, 然后根据 re-master key 按规定的算法计算得到主密钥 master-key。

此时服务器和客户端都获得了主密钥 master-key,密钥协商基本完成，但是为了安全性考虑，服务器需要对客户端进行认证，即进行步骤 106、步骤 109及步骤 1013的动作，那么服务器此时还需要进行步骤 1015 , 完成对客户端的认证，以确保此次密钥协商是安全可靠的。

步骤 1015、服务器使用客户端证书对步骤 1013发来的数据进行验证。如果验证成功，则对客户端认证成功，说明此次密钥协商是安全可靠的。

步骤 108到步骤 1015通常用于服务器对客户端的认证和客户端部分的消息发送。至此使用 RSA加密算法进行认证的密钥协商流程结束。

2、匿名 DH方式、固定 DH方式和短暂 DH方式

DH (Diffie-Hellmon)是一种密钥协商机制，通信双方会各自生成公开参数和私有参数，然后交换公开参数，再用对方的公开参数和自己的私有参数按一定的算法即可得到相同的密钥。

匿名 DH方式中，服务器在 server— key— exchange报文中发送服务器方 DH公开参数给客户端，客户端在 client— key— exchange报文中发送客户端 DH公开参数给服务器，之后服务器和客户端分别通过公开参数计算得到 pre-shared key , 继而生成主密钥 master key , 完成密钥协商。

固定 DH方式是指通信双方的 DH公开参数被包含在各自的证书中发给对方 ,服务器和客户端双方再从对方证书中提取出对方的 DH公开参数，计算得到 pre-master key, 继而生成主密钥 master key, 完成密钥协商。

短暂 DH方式指通信双方的 DH公开参数被各自签名后发送给对方，即服务器发送自己的 DH公开参数以及利用服务器证书对应的私钥对这些参数做签名到客户端；客户端通过验证该签名，可以判断这些参数在发送过程中是否被修改过，从而防止中间人攻击；客户端发送客户端 DH公开参数以及对这些参数作的签名给服务器，服务器通过验证签名，可以判断这些参数在发送过程中是否被修改过，以防止中间人攻击，然后服务器和客户端双方再从对方证书中提取出对方的 DH公开参数，计算得到共享密钥 pre-master key, 继而生成主密钥 master key, 完成密钥协商。

3、共享密钥方式共享密钥方式是基于客户端 /服务器预先共享的为双方所知的密钥，来实现双方认证和临时会话密钥协商。

在对现有技术的研究和实践过程中，发明人发现现有技术存在以下问题：

1、 RSA方式是一种基于证书的密钥协商方法，该方法通过为用户签发证书将用户身份 ( ID , identification ) 和公钥绑定，使用证书前，需向签发证书的数字证书认证中心（ C A , Certificate Authority )验证证书的有效性，即步骤 108进行的操作，以确定对方身份的有效性。该验证包括：验证 CA签名，验证 CA签名的过程可能涉及到证书链、 CA交叉认证；马全证是否被加入证书回目录（ CRL, Certificate Revocation List ) ；马全证是否在有效期内。这一系列的验证操作需要耗费很多存储和处理器资源，尤其是对于移动终端有限的处理能力以及移动网络有限的传输速度，资源耗费更加突出。

2、使用 DH 算法进行密钥协商，不能对通信双方认证，假设有恶意中间人冒充客户端或服务器攻击对方将不能被识别，因此使用 DH算法进行密钥协商容易受到中间人的攻击，系统安全性较低。

3、使用共享密钥方式进行密钥协商，需要预先具备为通信双方部署为双方所知密钥的条件，这需要根据具体的环境使用不同的方式，有些环境下则很难实现，尤其在网络中更不易实现。同时使用共享密钥方式时，因为通信双方预先都知道共享密钥，无法防止一方否认其做过某个动作，即存在不可否认问题。发明内容

本发明实施例要解决的技术问题是提供一种密钥协商方法、用于密钥协商的系统、客户端及服务器，以使密钥协商的过程可以便捷、安全、易于实现。为解决上述技术问题，本发明实施例一方面，提供了一种密钥协商方法，所述方法包括：

向服务器发送包含密文族列表的客户端呼叫报文，发起会话，所述呼叫报文的密文族列表中包含使用基于用户身份的密码机制的密钥协商方式的密文族；

接收所述服务器返回的包含基于用户身份的密码机制的密钥协商方式的信息；

接收所述服务器发送的服务器密钥交流报文；

接收所述服务器发送的服务器发送结束报文；

获得主密钥；

向服务器发送客户端密钥交流报文，以使服务器可以通过客户端密钥交流报文携带的信息获得主密钥。

另一方面，提供了一种密钥协商方法，所述方法包括：

接收客户端发送的包含密文族列表的客户端呼叫报文，所述呼叫报文的密文族列表中包含使用基于用户身份的密码机制的密钥协商方式的密文族；

从所述密文族列表中选择使用基于用户身份的密码机制的密钥协商方式的密文族，发送给所述客户端；

向所述客户端发送服务器密钥交流报文；

向所述客户端发送服务器发送结束报文；

接收客户端发送的客户端密钥交流报文；

根据所述客户端密钥交流报文中携带的信息获得主密钥。

另一方面，提供了一种用于密钥协商的系统，所述系统包括：客户端，用于发送包含密文族列表的客户端呼叫报文，所述呼叫报文的密文族列表中包含使用基于用户身份的密码机制的密钥协商方式的密文族；接收包含基于用户身份的密码机制的密钥协商方式的信息；接收服务器密钥交流报文；接收服务器发送的服务器发送结束报文；获得主密钥；发送客户端密钥交流报文；

服务器，用于接收所述客户端发送的客户端呼叫报文；从所述密文族列表中选择使用基于用户身份的密码机制的密钥协商方式的密文族，发送给所述客户端；向所述客户端发送服务器密钥交流报文；接收所述客户端发送的客户端密钥交流报文；向所述客户端发送服务器发送结束报文；根据所述客户端密钥交流报文中携带的信息获得主密钥。

另一方面，提供了一种客户端，所述客户端包括：

会话发起单元，用于向服务器发送包含密文族列表的客户端呼叫报文，发起会话，所述呼叫报文的密文族列表中包含使用基于用户身份的密码机制的密钥协商方式的密文族；

客户端密钥交流报文发送单元，用于向服务器发送客户端密钥交流报文，以使服务器可以通过客户端密钥交流报文携带的信息获得主密钥；第一接收单元，用于接收所述服务器返回的包含基于用户身份的密码机制的密钥协商方式的信息；接收服务器发送的服务器密钥交流报文；接收服务器发送的服务器发送结束报文；

客户端密钥获取单元，用于通过所述第一接收单元接收的信息获得主密钥。

另一方面，提供了一种服务器，所述服务器包括：

第二接收单元，用于接收客户端发送的包含密文族列表的客户端呼叫报文；接收客户端发送的客户端密钥交流报文；

选择单元，用于从所述密文族列表中选择使用基于用户身份的密码机制的密钥协商方式的密文族，向所述客户端发送；

服务器密钥交流报文发送单元，用于向所述客户端发送服务器密钥交流报文；

服务器发送结束报文发送单元，用于向所述客户端发送服务器发送结束报文；

服务器密钥获取单元，用于根据所述客户端密钥交流报文中携带的信息获得主密钥。

由以上技术方案可以看出，本发明实施例由于使用了基于用户身份的密码机制的密钥协商方式，使用服务器 ID作为服务器公钥，不需要依赖证书进行认证，有效简化了密钥协商的流程，节约了系统资源，且使用基于用户身份的密码机制的密钥协商方式在密钥协商的过程中就可以完成对对方身份的认证，有效防止了中间人的攻击，保障了系统的安全性，不使用通信双方预先都知道的共享密钥，防止一方否认其做过某个动作，不存在不可否认问题，且不需要进行特别的设置，应用范围较广。附图说明

图 1为现有技术流程图；

图 2为本发明实施例提供的密钥协商方法实施例一流程图；

图 3为本发明实施例提供的密钥协商方法实施例二流程图；

图 4为本发明实施例提供的密钥协商方法实施例三流程图；

图 5为本发明实施例提供的进行密钥协商的系统实施例结构示意图。具体实施方式

本发明实施例提供了一种适用于 TLS协议的密钥协商方法、用于密钥协商的系统、客户端及服务器，以使密钥协商的过程更加简便、应用范围广、且安全。

在本发明实施例提供的密钥协商方法实施例中，使用了一种可以被称为基于用户身份的密码机制（IBC, Identity-Based Cryptograph ) 的非对称密钥机制来进行密钥的协商，该方法使用的用户公钥可以是用户的 ID,也可以是用户 ID经过哈希后的哈希值，通过一定的算法使用公钥可以进一步衍生出私钥。

由于进行哈希时使用的哈希公式为公开参数，任何终端都可以获得，因此将用户 ID经过哈希后的哈希值称为公钥与直接将用户的 ID称为公钥具有相同的含义，因此通常都统一称之为使用用户 ID作为用户公钥。

其中， IBC常用的可以实现的方法包括：基于用户身份的认证和密钥十办商 ( IBAKA, Identity-based Authentication and Key Agreement ) 、基于用户身份的加密（ IBE , Identity-based Encrypt )、基于用户身份的签名（ IBS , Identity-based Signature ) , 本发明实施例提供了使用上述方法实现密钥协商的具体实施方式，以下将分别说明。

在 TLS协议中握手协议部分的密钥协商、加密和完整性保护的方法都有^ ί艮多种，而且各种密钥协商方式、各种加密方法和各种完整性保护方法可以灵活组合，本发明实施例主要是对其中的密钥协商进行改进，即使用上述 IBC的方法进行密钥协商。

在 TLS协议中，对不同的密钥协商、加密和完整性保护组合定义了不同的密文族 ( Cipher Suite ) , 使用一个密文族标识一个密钥协商、加密和完整性保护的组合，通信双方在建立会话时，选择一个密文族，即意味着选择了该密文族标识的密钥协商、加密和完整性保护的方法。

例如密文族 TLS— RSA— WITH— DES— CBC— SHA中， RSA表示使用 RSA 方式进行密钥协商， DES CBC 表示使用数据加密标准（ DES , Data Encryption Standard ) 算法的加密块链接（CBC, Cipher Block cipher )模式做加密操作， SHA表示使用安全哈希算法（ SHA, Safe Hash Algorithm ) 做完整性操作。

下面的密文族实例表示 RSA 方式可以与哪些加密及完整性保护的方法相结合：

Cipher Suite TLS— RSA— WITH— NULL— MD 5

Cipher Suite TLS— RSA— WITH— NULL— SHA Cipher Suite TLS—RSA— WITH— RC4— 128— MD5

Cipher Suite TLS—RSA— WITH— RC4— 128— SHA

Cipher Suite TLS—RSA— WITH— IDEA— CBC— SHA

Cipher Suite TLS—RSA— WITH— DES— CBC— SHA

Cipher Suite TLS—RSA— WITH— 3DES—EDE— CBC— SHA

其中，空（NULL ) 表示不加密； RC4— 128、国际数据加密技术算法 ( IDEA, International Data Encryption Algorithm ) —CBC , DES— CBC , 3DES— EDE (力口密解密力口密， encrypt decrypt encrypt )—CBC表示不同的力口密算法； MD5 (信息摘要算法版本 5 , message digest Version 5 )及 SHA 表示不同的完整性算法。

在 Client— Hello报文中，密文族列表包含客户端支持的密钥协商、加密和完整性保护相组合的列表，按优先级递减次序排列。

由于现有的密文族列表中不包含 IBC方式的密钥协商方法，因此本实施例提供了密钥协商方法标记为 IBC方式的密文族，以供使用，例如，密钥协商方法标记为 IBAKA方式的密文族：

TLS_IBAKA_CK_WITH_RC4_128 SHA

TLS— IBAKA— CK— WITH— 3DES— EDE— CBC— SHA

TLS— IBAKA— CK— WITH— AES— 128— CBC— SHA

TLS— IBAKA— CK— WITH— AES— 256— CBC— SHA

其中 IBAKA— CK (陈-库达， Chen-Kudla )表示用 IBAKA方式进行密钥协商，所用算法为 Chen-Kudla, IBAKA方式可以使用的算法有很多种，例如， Chen-Kudla算法、 Smart (斯玛特） -Chen-Kudla算法等等，此处以 Chen-Kudla算法为例进行说明。另外需要说明的是 " IB AKA— CK" 只是一个例子，可以使用其它字符替代，只要预先做好定义即可。

密钥协商方法标记为 IBE方式的密文族：

TLS—IBE—BF— WITH— RC4— 128— SHA

TLS IBE BF WITH 3DES EDE CBC SHA TLS—IBE—BF— WITH— AES— 128— CBC—SHA

TLS—IBE—BF— WITH— AES— 256— CBC—SHA

其中 IBE— BF (波讷 -富兰克林， Boneh-Franklin )表示用 IBE方式进行密钥协商，所用算法为 Boneh-Franklin, IBE方式可以使用的算法有艮多种，例如， Boneh-Franklin算法、 Boneh-Boyen (波业）算法等等，此处以 Boneh-Franklin算法为例进行说明。此处需要说明的是 "IBE— BF" 只是一个例子，可以使用其它字符替代，只要预先做好定义即可。

密钥协商方法标记为 IBS方式的密文族：

TLS—DHE— IBS— Hs— WITH— RC4— 128— SHA

TLS—DHE— IBS— Hs— WITH— 3DES—EDE— CBC—SHA

TLS—DHE— IBS— Hs— WITH— AES— 128— CBC—SHA

TLS—DHE— IBS— Hs— WITH— AES— 256— CBC—SHA

其中 DHE— IBS— Hs (赫斯， Hess )表示使用 IBS签名保护临时 DH参数进行密钥协商，所用算法为 Hess, IBS方式可以使用的算法有很多种，例如， Hess算法、 Cha-Cheon (查-册恩）算法等等，此处以 Hess算法为例进行说明。此处需要说明的是 "DHE— IBS— Hs" 只是一个例子，可以使用其它字符替代，只要预先做好定义即可。

本发明实施例提供的密钥协商方法实施例一，以使用 IBAKA为例对进行密钥协商的过程进行说明。

使用 IBAKA实现密钥协商的具体流程有很多种，本发明实施例提供的密钥协商方法实施例一以其中一种为例进行描述，其流程如图 2所示：步骤 201、客户端发送 Client— Hello报文给服务器发起会话。

该 Client— Hello报文包括的参数有：客户端支持的最高的 TLS/SSL, 随机数，会话标识符，支持的密文族列表，支持的压缩方法列表。

如果客户端支持 IBAKA方式，并希望以 IBAKA方式进行密钥协商，则将基于 IBAKA方式的某种密文族设置为较高优先级，即放在密文族列表的前面。客户端可以支持的密钥协商方式通常有多种，鉴于有些时候会发生一些意外情况，例如服务器不支持 IBAKA方式，需要选择其它方式，客户端需要对自身支持的密钥协商方式设置不同的优先级，以使服务器可以尽量选择客户端最希望使用的密钥协商方式。

本实施例一是以 IBAKA方式，因此此 Client— Hello报文的密文族列表中， IBAKA的优先级最高。

步骤 202、服务器选择一种密钥协商方式，发送给客户端。

服务器收到 Client— Hello报文后，在 Client— Hello报文提供的密文族列表中选择服务器支持且优先级最高的密文族，本实施例中选择的是基于 IBAKA 方式的密文族，例如

TLS— IBAKA— CK— WITH— AES— 128— CBC—SHA, 然后将选择的密文族发送到客户端。选择基于 IBAKA方式的密文族即表示选择使用 IBAKA方式实现密钥协商。

在步骤 201和步骤 202中，客户端和服务器完成了安全能力协商，选择使用 IBAKA方式进行密钥协商。

步骤 203、服务器发送服务器密钥交流（ Server— key— exchange )报文给客户端，报文中携带了服务器 IBC参数及服务器公钥信息。

其中，服务器公钥信息包括服务器的公钥，即服务器 ID, 同时还可以包含服务器公钥有效期，服务器公钥有效期用于控制服务器公钥的有效期，超过该有效期，则需要启用新的服务器公钥，即新的服务器 ID。客户端收到服务器公钥有效期后，可以通过判断该有效期是否过期来判断收到的服务器公钥是否过期。

在 IBC中，服务器的私钥由私钥生成中心（ KGC, Key Generate Center) 使用服务器公钥生成，当设置服务器公钥有效期时，则 KGC使用服务器公钥加服务器公钥有效期生成服务器私钥，因此，服务器公钥过期时，相应服务器私钥也会过期，所以服务器公钥有效期同时也是服务器私钥有效期，超过该有效期，且启用了新的服务器公钥后，服务器需要发送新的服务器 ID和新的有效期去 KGC申请新的私钥。

本发明实施例提供的密钥协商方法实施例一中服务器和客户端共用同一个 KGC。

服务器公钥信息还包括服务器的 KGC的标识，该标识为 KGC的域名地址，客户端获得该 KGC的域名地址后，可以去该域名地址获取该 KGC 的公开参数。

服务器 IBC参数根据 IBAKA方式釆用算法的不同而有所不同，假设 IBAKA方式釆用的是 Chen-Kudla算法，服务器 IBC参数可以用 T_s表示。为了获得 T_s, 服务器需要预先完成两个步骤：

1、向 KGC申请生成服务器私钥，且该私钥在有效期内。

月良务器向 KGC发送服务器 ID, 服务器 ID可以以 ID_S表示， KGC使用服务器 ID的哈希值 Q_S=H1(ID_S)和 KGC的主密钥 s的乘积生成服务器私钥 S_s, 并返回给服务器。

服务器私钥 S_s用公式可以描述为：

S_s=sQs

2、获取 KGC的公开参数， KGC是指为客户端和服务器生成私钥的 KGC。 KGC的公开参数通常包含： Gl , G2, e^A, P, Ppub, HI , H2。

其中 Gl , G2分别为基于椭圓曲线构造的加法循环群和乘法循环群， e^A为双线映射操作， e^A: Gl X Gl = G2, 即通过双线性映射将 G1中的元素对应到 G2中的元素。 P为群 G1的生成元，参数 Ppub=sP, s是 KGC的主密钥，是 KGC在以素数为模的整数域中选取的随机数。 HI , H2为两个哈希函数。 HI将任何 0和 1组成的二进制串转换为 G1中的元素。 H2将 G2 中的元素转换为 0和 1组成的二进制串。

服务器 IBC参数 T_s为服务器选择的随机数 a与服务器 ID的哈希值

Q_S=H1(ID_S)的乘积，因此服务器 IBC参数 T_s用公式可以表述为： T_s=aQ_s。

上述步骤 1和 2可以在本流程开始后，步骤 203之前完成，也可以在本流程开始之前完成，例如服务器上一次进行密钥协商时完成。

步骤 204、服务器发送 ServerHelloDone报文给客户端。指示服务器部分的消息已发送结束。该消息不含任何参数。发送完该消息后，服务器等待客户端的响应。

步骤 205、客户端发送 Client— key— exchange报文给服务器，该报文中携带客户端 IBC参数和客户端公钥信息。

其中，客户端公钥信息包括客户端的公钥即客户端 ID, 同时还可以包含客户端公钥有效期，客户端公钥有效期与服务器公钥有效期类似，用于控制客户端公钥的有效期，超过该有效期，则需要启用新的客户端公钥，服务器收到客户端公钥有效期后，可以通过判断该有效期是否过期来判断客户端公钥是否过期。

同时客户端的私钥为 KGC使用客户端公钥生成，当设置有客户端公钥有效期时，则 KGC使用客户端公钥加客户端公钥有效期生成客户端私钥。客户端公钥过期时，相应客户端私钥也会过期，因此客户端公钥有效期同时也是客户端私钥有效期，超过该客户端公钥有效期，客户端需要发送客户端 ID和新的有效期去 KGC申请新的私钥。

客户端公钥信息还包括客户端的 KGC的标识，该标识为 KGC的域名地址，服务器获得该 KGC的域名地址后，可以去该地址获取该 KGC的公开参数。

客户端 IBC参数根据 IBAKA方式釆用算法的不同而有所不同，假设釆用的是 Chen-Kudla算法，客户端 IBC参数可以用 T_c表示。为了获得 T_c, 客户端需要预先完成两个步骤：

1、向 KGC申请生成客户端私钥，且该私钥在有效期内。

客户端向 KGC发送客户端 ID, 客户端 ID可以以 ID_C表示， KGC使用客户端 ID的哈希值 Q_C=H1(ID_C)和 KGC的主密钥 s的乘积生成客户端私钥 S_c, 并返回给客户端。

客户端私钥 S_c用公式可以描述为：

S_c=sQc

2、获取服务器 KGC的公开参数。

客户端 IBC参数 T_c为客户端选择的随机数 b与客户端 ID的哈希值 Qc=H 1 (ID_C)的乘积，因此客户端 IBC参数 T_c用公式可以表述为：

Tc=bQ

此时服务器和客户端都获得了对方的 ID、对方的 IBC参数、服务器和客户端共用的 KGC的公开参数和自己的私钥。接着客户端和服务器就可以根据获得的参数计算出主密钥，图 2中步骤 206到步骤 208为客户端的主密钥计算过程，步骤 209到步骤 2011为服务器的主密钥计算过程。

此处需要说明的是，客户端在步骤 201中，向服务器发出信息时就已经获得了服务器的 ID, 因此， Server— key— exchange报文中可以携带作为服务器公钥的服务器的 ID, 也可以不携带作为服务器公钥的服务器的 ID。

步骤 206、客户端以客户端私钥 Sc：、服务器 ID、服务器 IBC参数 T_s和 KGC的公开参数，计算得到共享密钥 K_c, K_c用公式可以表述为：

Kc=e^(S_c, Ts+bQs)

'•' Ts=aQ_s; S_c=sQc;

.·. K_c=e^( sQc, aQ_s +bQ_s)= ε^Λ( Q_c +Q_s)^s(a+b)

步骤 209、服务器以服务器私钥 S_s、客户端 ID、客户端 IBC参数 T_c和 KGC的公开参数，计算得到共享密钥 K_s, K_s用公式可以表述为：

K_s= e^(S_s, Tc+aQc)

■·■ T_c=bQ_c; S_s=sQs;

.·. K_s=e^( sQ_s , bQ_c + aQ_c)= e （ Q_c +Q_s)^s(a+b)

由上可知 K_C=K_S=K, 因此，在客户端进行过步骤 206, 服务器进行过步骤 209后，通信双方就获得了相同的共享密钥 K。

步骤 206和步骤 209之间没有顺序关系，可以先后执行，也可以同时执行。

步骤 207、客户端生成预先主密钥 pre-master key。

可以将步骤 206中获得的共享密钥 K直接作为 pre-master key, 为了防止版本重放（ Version Rollback )攻击，也可以在 K之前加上两个字节的客户端版本号 ( Client— Version )作为 re-master key, 该 Client— Version为客户端支持的最高 TLS版本号。

步骤 2010、服务器生成预先主密钥 pre-master key。

可以将步骤 209中获得的共享密钥 K直接作为 pre-master key, 为了防止版本重放攻击，也可以在 K之前加上两个字节的 Client一 Version作为 pre-master key, 该 Client_Version为客户端支持的最高 TLS版本号，服务器可以通过在步骤 201 中获得的 Client— Hello 报文中获取该 Client— Version。

步骤 207和步骤 2010之间没有顺序关系，可以先后执行，也可以同时执行。

步骤 208、客户端从预先主密钥 pre-master key生成主密钥 master key„ 步骤 201 1、服务器从预先主密钥 pre-master key 生成主密钥 master key。

步骤 208和步骤 201 1之间没有顺序关系，可以先后执行，也可以同时执行。

本实施例一中客户端或服务器从 re-master key生成 master key方法为 TLS中通用的通过 re-master key计算得到 master key的算法，即： master— secret = PRF (pre— master一 secret, "master secret", ClientHello. random + ServerHello.random)[0..47];

ClientHello. random 和 ServerHello. random 分另¹ J为 ClientHello 和 ServerHello两个报文中的随机数。 Master— secret的长度为 48字节。

此时客户端和服务器都获得了主密钥 master key, 密钥协商完成。在本实施例中 , Server— key— exchange才艮文和 Client— key— exchange才艮文可以使用如下格式实现：

struct {

select (KeyExchangeAlgorithm) {

/* other cases for rsa, diffie— hellman, psk, etc. */ case ibaka: /* NEW */

ibakaserverpara;

ServerPublicSecret;

}；

} ServerKeyExchange;

Struct{

String<0..1024> Serverldentity;

ValidityPeriod;

string<0..1024> Serverkgc;

} ServerPublicSecret;

Struct ValidityPeriod {

Uint32 notBefore;

Uint32 not After;

} struct {

select (KeyExchangeAlgorithm) {

/* other cases for rsa, diffie— hellman, psk, etc. */ case ibaka: /* NEW */

ibakaclientpara; ClientPublicSecret;

} exchange— keys;

} ClientKeyExchange;

其中 "ibakaserverpara"代表服务器端 IBC参数； " ServerPublicSecret" 代表服务器公钥信息； "String<0..1024>ServerIdentity" 代表服务器 ID; "ValidityPeriod" 代表公钥有效期； "String<0..1024>Serverkgc，，代表服务器 KGC 的地址； " ibakaclientpara，，代表客户端 IBC 参数， "ClientPublicSecret" 代表客户端公钥信息。

针对不同的算法，例如 Chen-Kudla算法、 Smart-Chen-Kudla算法等等， ibakaserverpara和 ibakaclientpara也会有不同 , 上文都是以 Chen-Kudla算法为例进行描述的，下面以 BF算法为例，定义双方的参数如下：

struct {

opaque AlgObjectld;

opaque t_s<0..2^A16-l>;

} ibakaServerParams; struct {

opaque AlgObjectld;

opaque t_c<1..2^A16-l>;

} ibakaClientParams;

其中 , "opaque AlgObjectld" 代表算法 ID, opaque表示 IBC参数为二进制数，大小为 O bit到 ( 2^Λ16-1 ) bits„

使用本发明实施例提供的密钥协商方法实施例一来进行密钥协商，由于 IBC是使用用户 ID作为用户公钥的，也就不需要使用证书对用户 ID和用户公钥进行绑定，因此也就不需要依赖证书进行认证，相应使用证书认证的相关步骤都不需要进行，有效简化了密钥协商的流程，节约了存储和处理器资源，尤其是对于移动终端有限的处理能力以及移动网络有限的传输速度，效果更加明显；同时在密钥协商的过程中就可以完成对对方身份的认证，有效防止了中间人的攻击，保障了系统的安全性；且不需要进行特别的设置，应用范围较广

本发明实施例提供的密钥协商方法实施例二，以使用 IBS为例对进行密钥协商的过程进行说明。

使用 IBS实现密钥协商的具体流程有很多种，本发明实施例提供的密钥协商方法实施例二以使用 IBS进行签名保护 DH参数为例进行描述，其流程如图 3所示：

步骤 301、客户端发送 Client— Hello报文给服务器发起会话。

如果客户端支持 IBS方式，并希望以此方式进行密钥协商，则将基于 IBS方式的某种密文族设置为最高优先级，即放在密文族列表的前面。

客户端可以支持的密钥协商方式通常有多种，鉴于有些时候会发生一些意外情况，例如服务器不支持 IBS方式，则需要选择其它方式。客户端需要对自身支持的密钥协商方式设置不同的优先级，以使服务器可以尽量选择客户端最希望使用的密钥协商方式。

本实施例二是以使用 IBS签名保护 DH参数为例进行描述的，并且所用算法为 Hess, 因此，可以将密钥协商方法标记为 "DHE— IBS— Hs" 的密文族放在此 Client— Hello报文的密文族列表的前面。

步骤 302、服务器选择一种密钥协商方式，发送给客户端。

服务器收到 Client— Hello报文后，在 Client— Hello报文提供的密文族列表中选择服务器支持且优先级最高的密文族，本实施例中选择的是基于 IBS 方式的密文族，例如 TLS—DHE— IBS— Hs— WITH— 3DES—EDE—CBC—SHA,然后将选择的密文族发送到客户端。选择基于 IBS方式的密文族即表示选择使用 IBS方式实现密钥协商。

在步骤 301和步骤 302中，客户端和服务器完成了安全能力协商，选择使用 DHE— IBS— Hs方式进行密钥协商。

步骤 303、服务器发送 Server— key— exchange才艮文给客户端，该才艮文中包含服务器 DH公开参数，用 IBS对该 DH公开参数作的签名，以及服务器公钥信息。

其中，服务器公钥信息包括服务器的公钥即服务器 ID, 同时还可以包含服务器公钥有效期及服务器 KGC的地址。服务器公钥有效期，用于控制服务器公钥的有效期，超过该有效期，则需要启用新的服务器公钥，即新的服务器 ID。客户端收到服务器公钥有效期后，可以通过判断该有效期是否过期来判断收到的服务器公钥是否过期。

同时服务器的私钥为服务器 KGC使用服务器公钥生成，当设置服务器公钥有效期时，则 KGC使用服务器公钥加服务器公钥有效期生成服务器私钥。服务器公钥过期时，相应服务器私钥也会过期，因此服务器公钥有效期同时也是服务器私钥有效期，超过该服务器公钥有效期，且启用了新的服务器公钥后，服务器需要发送新的服务器 ID和新的有效期去 KGC 申请新的私钥。

客户端收到服务器公钥有效期后，可以通过判断该有效期是否过期来判断收到的服务器公钥是否过期。

本发明实施例二中，服务器的 KGC即为服务器生成私钥的 KGC, 客户端的 KGC即为客户端生成私钥的 KGC ,服务器的 KGC和客户端的 KGC 可能由同一个 KGC担任，也有可能由不同 KGC担任，在由不同 KGC担任，且客户端不知道服务器 KGC地址时，就需要在本步骤中发送服务器 KGC地址给客户端。

另外需要说明的是，客户端可以向服务器发出 Client— Hello报文，即说明客户端知道服务器的 ID, 即知道服务器的公钥，因此该报文中服务器 ID信息不是必须的，可以不携带。

用 IBS对 DH公开参数作的签名，即为使用服务器私钥、及服务器的 KGC公开参数对该 DH公开参数进行加密，因此本步骤之前，服务器必须预先完成两个步骤：

1、向服务器 KGC申请生成服务器私钥，且该私钥在有效期内。

2、获取服务器 KGC的公开参数。

完成步骤 1和步骤 2的详细方法，可参考实施例一中步骤 203中的描述，在此不再重复描述。

步骤 1和步骤 2可以在本流程开始后，步骤 303之前完成，也可以在本流程开始之前完成，例如服务器上一次进行密钥协商时完成。

本实施例二中，服务器对 DH公开参数做的签名使用的 IBS 算法为该 Server— key— exchange才艮文的格式可以定义口下：

struct {

select (KeyExchangeAlgorithm) {

case dhe_ibs:

ServerDHParams params;

Signature signed— params;

ServerPublicSecret;

其中， ServerDHParams表示服务器 DH公开参数。

签名（Signature )表示使用 IBS对服务器 DH公开参数的签名，在釆用 Hess算法签名时，签名过程如下：

r = e^A(Pl , P) ^k, v=H2(m, r); u=vS_s+kPl ,

其中 PI为服务器随即选取的一个群 Gl中的元素， k为服务器随即选取的随机数。 m为被签名的消息，这里就是服务器的 DH公开参数。 V和 u两个数值就是签名值，该 Signature参数可以定义如下： struct {

select (SignatureAlgorithm) {

case ibs-hs:

digitally-signed struct {

opaque hs_v <1..2^A16-1>;

opaque hs_u <1..2^A16-1>;

}；

} Signature;

其中， hs— ¥<1..2 6-1>和 hs—u<1..2^A16-l>分别为 Hess算法中签名操作后的两个值。

步骤 304、服务器发送 ServerHelloDone报文给客户端。指示服务器部分的消息已发送结束。该消息不含任何参数。发送完该消息后，服务器等待客户端的响应。

步骤 305、客户端验证 Server— key— exchange报文中的签名。

客户端收到 Server— key— exchange报文后，对该报文中携带的用 IBS 对该参数作的签名进行验证。验证前，客户端需要预先获得服务器的 KGC 公开参数及服务器的公钥，获得服务器的 KGC公开参数的方法，通常是通过服务器的 KGC地址到服务器的 KGC去获取。

由于服务器的 KGC和客户端的 KGC可能由同一个 KGC担任，也有可能由不同 KGC担任，因此在由不同 KGC担任时，客户端可能不知道服务器的 KGC地址，客户端获取服务器的 KGC地址的时机，可以是在本步骤进行，从该 Server— key— exchange 报文获取，也可以是在本流程之前，在上一次与该服务器进行密钥协商时获取。

同样，获取服务器的 KGC公开参数可以是在本步骤进行，也可以是在本流程之前，例如在上一次与该服务器进行密钥协商时获取。

客户端对 Server— key— exchange才艮文中的签名验证过程如下：已知消息 m (即服务器 DH公开参数)和签名（V, u),计算 r=e^A(u, P) -e^A(Q_s, Ppub)^v。

如果 v = H2(m,r), 则验证成功。

如果验证成功，表示服务器 DH公开参数未被替换或修改，同时也代表服务器的身份是可信的，相当于对服务器进行了认证。

由于本步骤对服务器进行了认证，可以有效防止中间人的攻击。

步骤 306、客户端发送 Client— key— exchange报文给服务器。

该 Client— key— exchange才艮文中包含客户端 DH公开参数。

该 Client— key— exchange报文中还可以包含用 IBS算法对该 DH公开参数做的签名及客户端公钥信息，以便于在服务器需要对客户端进行认证时，可以通过验证签名确认客户端身份，签名方式为使用客户端私钥、及客户端的 KGC的公开参数对该 DH公开参数进行加密。如果服务器不需要对客户端做认证，该 Client— key— exchange报文中也可以不包含对 DH参数的签名。在 Client— key— exchange报文中包含用 IBS算法对 DH参数做的签名时，该 Client— key— exchange报文可以定义如下：

struct {

select (KeyExchangeAlgorithm) {

case diffie— hellman— ibs:

ClientDHParams public;

Signature signed— params;

ClientPublicSecret;

}；

} ClientKeyExchange;

其中 ClientDHParams表示客户端 DH公开参数。

Signature表示使用 IBS对客户端 DH公开参数的签名，可以釆用步骤

303中 Signature的定义实现，在此不再重复描述。

步骤 305与步骤 306之间没有顺序关系，可以先后执行，也可以同时执行。

步骤 307、服务器验证 Client— key— exchange报文中的签名。

当步骤 306中发出的 Client— key— exchange报文中包含用 IBS算法对

DH参数做的签名时，服务器会对该签名进行验证，如果验证通过，表示客户端 DH公开参数未被替换或修改，同时也代表客户端的身份是可信的，相当于对客户端进行了认证，可以有效防止中间人的攻击。

在服务器不需要对客户端进行认证时，可以不进行步骤 307。

此时服务器和客户端都获得了对方的 DH公开参数。

步骤 308、客户端按 Diffie-Hellmon算法，根据服务器 DH公开参数及客户端 DH私有参数生成 DH共享密钥 pre-shared key,从而得到预先主密钥 pre-master key。本实施例二从共享密钥得到预先主密钥的方法可以参考实施例一中的相关描述。。

步骤 309、服务器按 Diffie-Hellmon算法，根据客户端 DH公开参数及服务器 DH私有参数生成 DH共享密钥 pre-shared key,从而得到预先主密钥 pre-master key。本实施例二从共享密钥得到预先主密钥的方法可以参考实施例一中的相关描述。

步骤 308与步骤 309之间没有顺序关系，可以先后执行，也可以同时执行。客户端和服务器分别在步骤 308与步骤 309中，通过各自的 DH私有参数，与对方的 DH公开参数生成相同的 DH共享密钥。

步骤 3010、客户端从预先主密钥 pre-master key 生成主密钥 master key。

步骤 301 1、服务器从预先主密钥 pre-master key 生成主密钥 master key。

客户端或服务器从 re-master key生成 master key方法为 TLS中制定的通过 re-master key计算得到 master key算法，可以参考在本发明实施例提供的密钥协商方法实施例一中描述的方法，在此不再重复。此时密钥协商完成。

由上可知在本发明实施例提供的密钥协商方法实施例二中，使用 IBS 签名保护 DH参数，以使通信双方可以对对方进行认证，有效防止了中间人的攻击，显著提高了系统的安全性。同样本发明实施例提供的密钥协商方法实施例二也不需要依赖证书进行认证，不需要进行与证书相关的繁瑣步骤，节约了网络资源，不需要进行特别的设置，应用范围较广。

同样本发明实施例提供的密钥协商方法实施例二也不需要依赖证书进行认证，不需要进行与证书相关的繁瑣步骤，不需要进行特别的设置，应用范围较广。

本发明实施例提供的密钥协商方法实施例三，以使用 IBE为例对密钥协商的过程进行说明，本发明实施例提供的密钥协商方法实施例三流程如图 4所示：

步骤 401、客户端发送 Client— Hello报文给服务器发起会话。

该 Client— Hello 4艮文包括的参数有：客户端支持的最高版本 TLS/SSL, 随机数，会话标识符，支持的密文族列表，支持的压缩方法列表。

如果客户端支持 IBE方式，并希望以此方式进行密钥协商，则将基于 IBE方式的某种密文族设置为最高优先级，即放在密文族列表的前面。

客户端可以支持的密钥协商方式通常有多种，鉴于有些时候会发生一些意外情况，例如服务器不支持 IBE方式，需要选择其它方式，客户端需要对自身支持的密钥协商方式设置不同的优先级，以使服务器可以尽量选择客户端希望使用的密钥协商方式。

本实施例是以使用 IBE 为例进行描述的，并且所用算法为 Boneh-Franklin算法，因此，可以将密钥协商方法标记为 "IBE— BF" 的密文族放在此 Client— Hello报文的密文族列表的前面。

步骤 402、服务器选择一种密钥协商方式，发送给客户端。

服务器收到 Client— Hello报文后，在 Client— Hello报文提供的密文族列表中选择服务器支持且优先级最高的密文族，本实施例三中选择的是基于 IBE方式的密文族，例如 TLS—IBE—BF— WITH— AES— 128— CBC—SHA, 然后将选择的密文族发送到客户端。选择基于 IBE方式的密文族即表示选择使用 IBE方式实现密钥协商。

在步骤 401和步骤 402中，客户端和服务器完成了安全能力协商，选择使用 IBE— BF方式进行密钥协商。

步骤 403、服务器发送 Server— key— exchange报文给客户端，报文中携带服务器公钥信息。

其中，服务器公钥信息包括服务器的公钥即服务器 ID, 同时还可以包含服务器公钥有效期和服务器 KGC的地址。服务器公钥有效期，用于控制服务器公钥的有效期，超过该有效期，则需要启用新的服务器公钥，即新的服务器 ID。客户端收到服务器公钥有效期后，可以通过判断该有效期是否过期来判断收到的服务器公钥是否过期。

本发明实施例三中，服务器的 KGC即为服务器生成私钥的 KGC, 客户端的 KGC即为客户端生成私钥的 KGC ,服务器的 KGC和客户端的 KGC 可能由同一个 KGC担任，也有可能由不同 KGC担任。在由不同 KGC担任，且客户端不知道服务器 KGC地址时，就需要在本步骤中发送服务器 KGC地址给客户端。

另外需要说明的是，客户端可以向服务器发出 Client— Hello报文，即说明客户端知道服务器的 ID,也即知道服务器的公钥，因此该报文中服务器 ID信息不是必须的，可以不携带。

该 Server— key— exchange才艮文可以^口下定义：

struct {

select (KeyExchangeAlgorithm) {

case ibe— bf:

ServerPublicSecret;

}；

} S erverKey Exchange； Struct{

String<0..1024> Serverldentity;

ValidityPeriod;

string<0..1024> Serverkgc; 〃服务器 KGC的地址

} ServerPublicSecret;

Struct ValidityPeriod {

Uint32 notBefore;

Uint32 notAfter;

}

其中， Serverldentity 为服务器 ID; ValidityPeriod 为公钥有效期；

"string<0..1024> Serverkgc" 为服务器 KGC的地址。

步骤 404、服务器发送 ServerHelloDone报文给客户端。指示服务器部分的消息已发送结束。该消息不含任何参数。发送完该消息后，服务器等待客户端的响应。

步骤 405、客户端按照现有技术 TLS 协议规范生成预先主密钥 pre-master key。

步骤 406、客户端发送 Client— key— exchange报文至服务器。

客户端通过服务器的 KGC 地址到服务器的 KGC 去获取服务器的 KGC公开参数，使用服务器的 KGC公开参数、服务器公钥与客户端选择的控制参数力口密 pre-master key , 并将力口密后的 pre-master key 携带在 Client— key— exchange报文中发送到服务器。

该 Client— key— exchange报文中还可以包含服务器公钥及控制参数。控制参数可以是步骤 403中描述的服务器公钥有效期参数，也可以由客户端指定将服务器公钥有效期作为控制参数。如果是由客户端指定的将服务器公钥有效期作为控制参数 ,则该 Client— key— exchange报文中必须包含控制参数。

此时 , 该 Client— key— exchange才艮文可以定义如下：

struct {

select (KeyExchangeAlgorithm) {

case ibe— bf: IbeEncryptedPreMasterSecret;

} exchange— keys;

} ClientKeyExchange; struct {

public-key-encrypted PreMasterSecret pre— master— secret; } EncryptedPreMasterSecret;

步骤 407、客户端按照 TLS协议规范从 pre-master key生成 master key„ 步骤 406和步骤 407之间没有顺序关系，可以先后执行，也可以同时执行。

步骤 408、服务器使用服务器的 KGC公开参数、服务器公钥与控制参数对接收到的力。密过的 pre-master key解密，得到 pre-master key, 再按照 TLS十办议规范从 re-master key生成 master key。

客户端或服务器从 re-master key生成 master key方法为 TLS中制定的通过 pre-master key计算得到 master key算法，可以参考本发明实施例提供的密钥协商方法实施例一中的相关描述，在此不再重复。此时密钥协商完成。

由上可知在本发明实施例提供的密钥协商方法实施例三中，不需要预先在进行密钥协商的通信双方两端部署为两者共知的共享密钥，而由客户端生成预先主密钥 pre-master key发送给服务器，客户端和服务器再依据 pre-master key生成 master key, 完成密钥协商，并使用服务器的 KGC公开参数、服务器公钥与控制参数保护 pre-master key的传递过程，以使密钥协商的过程安全，可靠，非常容易实现，也不受应用环境的限制，应用范围较广，不使用通信双方预先都知道的共享密钥，防止一方否认其做过某个动作，不存在不可否认问题，同样本发明实施例提供的密钥协商方法实施例三也不需要依赖证书进行认证，不需要进行与证书相关的繁瑣步骤，节约了网络资源。

同样本发明实施例提供的密钥协商方法实施例三也不需要依赖证书进行认证，不需要进行与证书相关的繁瑣步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括如下步骤：

向服务器发送包含密文族列表的客户端呼叫报文，发起会话，所述密文族列表中包含使用基于用户身份的密码机制的密钥协商方式的密文族；接收所述服务器返回的包含基于用户身份的密码机制的密钥协商方式的信息；

接收所述服务器发送的服务器密钥交流报文；

接收所述服务器发送的服务器发送结束报文；

获得主密钥；

或者包括如下步骤：接收客户端发送的包含密文族列表的客户端呼叫报文，所述密文族列表中包含使用基于用户身份的密码机制的密钥协商方式的密文族；

向所述客户端发送服务器密钥交流报文；

向所述客户端发送服务器发送结束报文；

接收客户端发送的客户端密钥交流报文；

根据所述客户端密钥交流报文中携带的信息获得主密钥。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

本发明实施例提供的用于密钥协商的系统实施例结构如图 5所示，包括：

客户端 5100 , 用于发送包含密文族列表的客户端呼叫报文，所述呼叫报文的密文族列表中包含使用基于用户身份的密码机制的密钥协商方式的密文族；接收包含基于用户身份的密码机制的密钥协商方式的信息；接收服务器密钥交流报文；接收服务器发送的服务器发送结束报文；获得主密钥；发送客户端密钥交流报文。

服务器 5200 , 用于接收所述客户端发送的客户端呼叫报文；从所述密文族列表中选择使用基于用户身份的密码机制的密钥协商方式的密文族，发送给所述客户端；向所述客户端发送服务器密钥交流报文；接收所述客户端发送的客户端密钥交流报文；向所述客户端发送服务器发送结束报文；根据所述客户端密钥交流报文中携带的信息获得主密钥。

系统中客户端 5100又包括：

会话发起单元 5130 , 用于向服务器 5200发送包含密文族列表的客户端呼叫报文，发起会话，所述呼叫报文的密文族列表中包含使用基于用户身份的密码机制的密钥协商方式的密文族；

客户端密钥交流报文发送单元 5140 , 用于向服务器 5200发送客户端密钥交流报文，以使服务器 5200 可以通过客户端密钥交流报文携带的信息获得主密钥；

第一接收单元 5120, 用于接收所述服务器 5200返回的包含基于用户身份的密码机制的密钥协商方式的信息；接收服务器 5200发送的服务器密钥交流报文；接收服务器发送的服务器发送结束报文；

客户端密钥获取单元 51 10,用于通过所述第一接收单元接收的信息获得主密钥。

客户端 5100中的客户端密钥获取单元 5110又包括：

第一共享密钥单元 5112 ,用于从所述服务器密钥交流报文中获取所述服务器 5200 的基于用户身份的密码机制参数；根据所述基于用户身份的密码机制，通过预先获取的私钥生成中心公开参数、客户端私钥、所述服务器 5200 的基于用户身份的密码机制参数及作为服务器公钥的服务器用户身份，获得共享密钥；

第一主密钥单元 511 1 , 用于通过所述共享密钥获得所述主密钥；第一获取单元 51 13 ,用于从所述密钥交流报文中获取所述服务器 5200 的迪菲赫尔曼公开参数及使用服务器私钥对所述公开参数做的签名；

第一验证单元 5114,用于通过预先获得的服务器私钥生成中心公开参数及作为服务器公钥的服务器用户身份，验证所述使用 IBC对所述公开参数做的签名；

第二主密钥单元 5115 , 用于在第一验证单元验证通过时，使用所述服务器 5200的迪菲赫尔曼公开参数及客户端 5100的迪菲赫尔曼公开参数生成迪菲赫尔曼共享密钥，以所述迪菲赫尔曼共享密钥作为预先主密钥，通过所述预先主密钥生成所述主密钥；

第三主密钥单元 5116, 用于根据传输层安全协议生成预先主密钥，通过所述预先主密钥生成所述主密钥；

客户端密钥获取单元中的第一主密钥单元 51 11又包括：第一密钥生成单元 51 11 1 , 用于以所述共享密钥作为预先主密钥，通过所述预先主密钥生成所述主密钥。

第二密钥生成单元 51 112, 用于以所述共享密钥与所述客户端版本号作为预先主密钥，通过所述预先主密钥生成所述主密钥。

客户端 5100中的客户端密钥交流 4艮文发送单元 5140又包括：第一客户端发送单元 5141 , 用于向服务器 5200发送携带所述客户端 5100的基于用户身份的密码机制参数的客户端密钥交流报文。

第二客户端发送单元 5142, 用于向服务器 5200发送携带所述客户端 5100的迪菲赫尔曼公开参数的客户端密钥交流报文。

签名单元 5143 , 用于在所述客户端密钥交流报文中携带使用 IBC对所述客户端 5100的迪菲赫尔曼公开参数做的签名。

第三客户端发送单元 5144,用于使用预先获得的服务器私钥生成中心公开参数、作为服务器公钥的服务器用户身份及客户端选择的控制参数对所述预先主密钥进行加密，并携带在所述客户端密钥交流报文中发送至服务器 5200。

控制参数单元 5145 , 用于生成所述控制参数，并将所述控制参数携带在所述客户端密钥交流报文中向服务器 5200发送。

系统中服务器 5200又包括：

第二接收单元 5250, 用于接收客户端 5100发送的包含密文族列表的客户端呼叫报文；接收客户端 5100发送的客户端密钥交流报文；

选择单元 5220,用于从所述密文族列表中选择使用基于用户身份的密码机制的密钥协商方式的密文族，向所述客户端 5100发送；

服务器密钥交流报文发送单元 5210, 用于向所述客户端 5100发送服务器密钥交流报文；

服务器发送结束报文发送单元，用于向所述客户端 5100发送服务器发送结束报文；服务器密钥获取单元 5270,用于根据所述客户端密钥交流报文中携带的信息获得主密钥，完成密钥协商。

第二获取单元 5230,用于从所述客户端密钥交流报文中获取使用 IBC 对所述客户端 5100的迪菲赫尔曼公开参数做的签名；

第二验证单元 5240,用于通过预先获得的客户端私钥生成中心公开参数及作为客户端公钥的客户端用户身份，验证所述使用 IBC对所述客户端 5100的迪菲赫尔曼公开参数做的签名；验证通过，则使所述第五主密钥单元 5271使用服务器 5200的迪菲赫尔曼公开参数及所述客户端 5100的迪菲赫尔曼公开参数生成迪菲赫尔曼共享密钥。

参数获取单元 5260, 用于从所述密钥交流报文中获取所述控制参数。服务器 5200中服务器密钥获取单元 5270又包括：

第二共享密钥单元 5272 ,用于从所述密钥交流报文中获取所述客户端 5100的基于用户身份的密码机制参数，及客户端公钥的客户端用户身份；根据所述基于用户身份的密码机制，通过预先获取的私钥生成中心公开参数、服务器私钥、所述客户端 5100 的基于用户身份的密码机制参数及所述客户端用户身份，获得共享密钥；

第四主密钥单元 5274, 用于通过所述共享密钥获得所述主密钥；第五主密钥单元 5271 , 用于从所述密钥交流报文中获取所述客户端 5100的迪菲赫尔曼公开参数；使用服务器 5200的迪菲赫尔曼公开参数及所述客户端 5100 的迪菲赫尔曼公开参数生成迪菲赫尔曼共享密钥，以所述迪菲赫尔曼共享密钥作为预先主密钥，通过所述预先主密钥生成所述主密钥；

第六主密钥单元 5273 ,用于从所述密钥交流报文中获取加密过的预先主密钥；使用服务器私钥生成中心公开参数、作为服务器公钥的服务器用户身份及客户端选择的控制参数对所述预先主密钥进行解密，获得预先主密钥，通过所述预先主密钥生成所述主密钥。服务器密钥获取单元 5270中第四主密钥单元 5274又包括：

第三密钥生成单元 52741 , 用于以所述共享密钥作为预先主密钥，通过所述预先主密钥生成所述主密钥。

第四密钥生成单元 52742, 用于以所述共享密钥与所述客户端版本号作为预先主密钥，通过所述预先主密钥生成所述主密钥。

服务器 5200中服务器密钥交流报文发送单元 5210又包括：

第一服务器发送单元 5211 , 用于向所述客户端 5100发送携带所述服务器的基于用户身份的密码机制参数的服务器密钥交流报文。

第二服务器发送单元 5212,用于在所述服务器密钥交流报文中携带所述服务器 5200的迪菲赫尔曼公开参数及使用 IBC对所述公开参数做的签名，向所述客户端 5100发送。

本发明实施例提供的客户端实施例与本发明实施例提供的用于密钥协商的系统实施例中描述的客户端 5100基本一致，在此不再重复描述。

本发明实施例提供的服务器实施例与本发明实施例提供的用于密钥协商的系统实施例中描述的服务器 5200基本一致，在此不再重复描述。

本发明实施例提供的用于密钥协商的系统实施例、本发明实施例提供的客户端实施例、与本发明实施例提供的服务器实施例的具体工作方式可参考上文本发明实施例提供的密钥协商的方法实施例，在此不再重复描述。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明，可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质（可以是 CD-ROM, U盘，移动硬盘等）中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述的方法。以上对本发明所提供的一种密钥协商方法、用于密钥协商的系统、客户端及服务器进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims

权利要求书

1、一种密钥协商方法，其特征在于，所述方法包括：

接收所述服务器发送的服务器密钥交流报文；

接收所述服务器发送的服务器发送结束报文；

获得主密钥；

2、如权利要求 1 所述的密钥协商方法，其特征在于，所述基于用户身份的密码机制的密钥协商方式为基于用户身份的认证和密钥协商的密钥协商方式；

所述向服务器发送客户端密钥交流报文包括：在所述客户端密钥交流报文中携带所述客户端的基于用户身份的密码机制参数及客户端公钥，向服务器发送；

所述获得主密钥包括：

从所述服务器密钥交流报文中获取所述服务器的基于用户身份的密码机制参数；

根据所述基于用户身份的密码机制，通过获取的私钥生成中心公开参数、客户端私钥、所述服务器的基于用户身份的密码机制参数及服务器公钥，获得共享密钥；

通过所述共享密钥获得所述主密钥。

3、如权利要求 2所述的密钥协商方法，其特征在于，所述通过所述共享密钥获得所述主密钥包括：

以所述共享密钥作为预先主密钥，通过所述预先主密钥生成所述主密钥。

4、如权利要求 2所述的密钥协商方法，其特征在于，所述通过所述共享密钥获得所述主密钥包括：

以所述共享密钥与所述客户端版本号作为预先主密钥，通过所述预先主密钥生成所述主密钥。

5、如权利要求 2、 3或 4所述的密钥协商方法，其特征在于，所述方法还包括：

在所述客户端密钥交流报文中携带客户端公钥有效期，以使所述服务器可以通过所述有效期判断客户端公钥是否过期。

6、如权利要求 1 所述的密钥协商方法，其特征在于，所述基于用户身份的密码机制的密钥协商方式为基于用户身份的签名的密钥协商方式；所述向服务器发送客户端密钥交流报文包括：在所述客户端密钥交流报文中携带所述客户端的迪菲赫尔曼公开参数，向服务器发送；

所述获得主密钥包括：

从所述服务器密钥交流报文中获取所述服务器的迪菲赫尔曼公开参数及使用基于用户身份的签名方式对所述迪菲赫尔曼公开参数做的签名；通过获得的服务器私钥生成中心公开参数及服务器公钥，验证所述服务器密钥交流报文中使用基于用户身份的签名方式对所述迪菲赫尔曼公开参数做的签名；

验证通过时，使用所述服务器的迪菲赫尔曼公开参数和客户端的迪菲赫尔曼私有参数生成迪菲赫尔曼共享密钥，通过所述迪菲赫尔曼共享密钥生成所述主密钥。

7、如权利要求 6所述的密钥协商方法，其特征在于，所述方法还包括：使用基于用户身份的签名方式对所述客户端的迪菲赫尔曼公开参数做签名，并携带在所述客户端密钥交流报文中，以使所述服务器可以对客户端进行认证。

8、如权利要求 1 所述的密钥协商方法，其特征在于，所述基于用户身份的密码机制的密钥协商方式为基于用户身份的加密的密钥协商方式；所述获得主密钥包括：生成预先主密钥，通过所述预先主密钥生成所述主密钥；

所述向服务器发送客户端密钥交流报文包括：使用获得的服务器的私钥生成中心公开参数、服务器公钥及客户端选择的控制参数对所述预先主密钥进行加密，并携带在所述客户端密钥交流报文中向服务器发送。

9、如权利要求 8 所述的密钥协商方法，其特征在于，所述方法还包括：

将所述控制参数携带在所述客户端密钥交流报文中向服务器发送。

10、一种密钥协商方法，其特征在于，所述方法包括：

向所述客户端发送服务器密钥交流报文；

向所述客户端发送服务器发送结束报文；

接收客户端发送的客户端密钥交流报文；

根据所述客户端密钥交流报文中携带的信息获得主密钥。

1 1、如权利要求 10所述的密钥协商方法，其特征在于，所述基于用户身份的密码机制的密钥协商方式为基于用户身份的认证和密钥协商的密钥协商方式；所述向所述客户端发送服务器密钥交流报文包括：在所述服务器密钥交流报文中携带所述服务器的基于用户身份的密码机制参数，向所述客户端发送；

所述根据所述客户端密钥交流报文中携带的信息获得主密钥包括：从所述客户端密钥交流报文中获取所述客户端的基于用户身份的密码机制参数，及客户端公钥；

通过获取的私钥生成中心公开参数、服务器私钥、所述客户端的基于用户身份的密码机制参数及所述客户端公钥，获得共享密钥；

通过所述共享密钥获得所述主密钥。

12、如权利要求 1 1 所述的密钥协商方法，其特征在于，所述通过所述共享密钥获得所述主密钥包括：

13、如权利要求 1 1 所述的密钥协商方法，其特征在于，所述通过所述共享密钥获得所述主密钥包括：

14、如权利要求 10所述的密钥协商方法，其特征在于，所述基于用户身份的密码机制的密钥协商方式为基于用户身份的签名的密钥协商方式；

所述向所述客户端发送服务器密钥交流报文包括：在所述服务器密钥交流报文中携带所述服务器的迪菲赫尔曼公开参数及使用基于用户身份的签名方式对所述公开参数做的签名，向所述客户端发送；

所述根据所述客户端密钥交流报文中携带的信息获得主密钥包括：从所述客户端密钥交流报文中获取所述客户端的迪菲赫尔曼公开参数；使用所述客户端的迪菲赫尔曼公开参数和服务器的迪菲赫尔曼私有参数生成迪菲赫尔曼共享密钥，通过所述迪菲赫尔曼共享密钥生成所述主密钥。

15、如权利要求 14所述的密钥协商方法，其特征在于，所述方法还包括：

从所述客户端密钥交流报文中获取使用基于用户身份的签名方式对所述客户端的迪菲赫尔曼公开参数做的签名；

通过获得的客户端私钥生成中心公开参数及客户端公钥验证所述客户端密钥交流报文中的使用基于用户身份的签名方式对所述客户端的迪菲赫尔曼公开参数做的签名；验证通过，则生成迪菲赫尔曼共享密钥。

16、如权利要求 10所述的密钥协商方法，其特征在于，所述基于用户身份的密码机制的密钥协商方式为基于用户身份的加密的密钥协商方式；

所述根据所述客户端密钥交流报文中携带的信息获得主密钥包括：从所述客户端密钥交流报文中获取加密过的预先主密钥；

使用服务器私钥生成中心公开参数、服务器公钥及客户端选择的控制参数对所述加密的预先主密钥进行解密，获得预先主密钥，通过所述预先主密钥生成所述主密钥。

17、如权利要求 10到 16中任一项所述的密钥协商方法，其特征在于，所述方法还包括：

在所述服务器密钥交流报文中携带服务器公钥有效期，以使所述客户端可以通过所述有效期判断服务器公钥是否过期。

18、一种用于密钥协商的系统，其特征在于，所述系统包括：客户端，用于发送包含密文族列表的客户端呼叫报文，所述呼叫报文的密文族列表中包含使用基于用户身份的密码机制的密钥协商方式的密文族；接收包含基于用户身份的密码机制的密钥协商方式的信息；接收服务器密钥交流报文；接收服务器发送的服务器发送结束报文；获得主密钥；发送客户端密钥交流报文；

19、一种客户端，其特征在于，所述客户端包括：

20、如权利要求 19所述的客户端，其特征在于，所述客户端密钥获取单元进一步包括：

第一共享密钥单元，用于从所述服务器密钥交流报文中获取所述服务器的基于用户身份的密码机制参数；根据所述基于用户身份的密码机制，通过获取的私钥生成中心公开参数、客户端私钥、所述服务器的基于用户身份的密码机制参数及服务器公钥，获得共享密钥；

第一主密钥单元，用于通过所述共享密钥获得所述主密钥；

所述客户端密钥交流报文发送单元进一步包括：第一客户端发送单元，用于向服务器发送所述客户端密钥交流报文，在所述客户端密钥交流报文中携带所述客户端的基于用户身份的密码机制参数及客户端公钥。

21、如权利要求 19所述的客户端，其特征在于，所述客户端密钥获取单元进一步包括：

第一获取单元，用于从所述服务器密钥交流报文中获取所述服务器的迪菲赫尔曼公开参数及使用服务器私钥对所述迪菲赫尔曼公开参数做的签名；

第一验证单元，用于通过获得的服务器私钥生成中心公开参数及服务器公钥，验证所述使用基于用户身份的签名方式对所述迪菲赫尔曼公开参数做的签名；

第二主密钥单元，用于在第一验证单元验证通过时，使用所述服务器的迪菲赫尔曼公开参数及客户端的迪菲赫尔曼公开参数和私有参数生成迪菲赫尔曼共享密钥，通过所述迪菲赫尔曼共享密钥生成所述主密钥；所述客户端密钥交流报文发送单元包括：

第二客户端发送单元，用于向服务器发送携带所述客户端的迪菲赫尔曼公开参数的客户端密钥交流报文。

22、如权利要求 21 所述的客户端，其特征在于，所述客户端密钥交流报文发送单元还包括：

签名单元，用于使用基于用户身份的签名方式对所述客户端的迪菲赫尔曼公开参数做签名，并携带在所述客户端密钥交流报文中。

23、如权利要求 19所述的客户端，其特征在于，所述客户端密钥获取单元包括：

第三主密钥单元，用于生成预先主密钥，通过所述预先主密钥生成所述主密钥；

所述客户端密钥交流报文发送单元包括：第三客户端发送单元，用于使用获得的服务器的私钥生成中心公开参数、服务器公钥及客户端选择的控制参数对所述预先主密钥进行加密，并携带在所述客户端密钥交流报文中向服务器发送。

24、一种服务器，其特征在于，所述服务器包括：

25、如权利要求 24所述的服务器，其特征在于，所述服务器密钥获取单元进一步包括：

第二共享密钥单元，用于从所述客户端密钥交流报文中获取所述客户端的基于用户身份的密码机制参数，及客户端公钥；根据所述基于用户身份的密码机制，通过获取的私钥生成中心公开参数、服务器私钥、所述客户端的基于用户身份的密码机制参数及所述客户端用户身份，获得共享密钥；

第四主密钥单元，用于通过所述共享密钥获得所述主密钥；所述服务器密钥交流报文发送单元进一步包括：

第一服务器发送单元，用于向所述客户端发送携带所述服务器的基于用户身份的密码机制参数的服务器密钥交流报文。

26、如权利要求 24所述的服务器，其特征在于，所述服务器密钥获取单元进一步包括：

第五主密钥单元，用于从所述客户端密钥交流报文中获取所述客户端的迪菲赫尔曼公开参数；使用服务器的迪菲赫尔曼公开参数及所述客户端的迪菲赫尔曼公开参数和私有参数生成迪菲赫尔曼共享密钥，以所述迪菲赫尔曼共享密钥作为预先主密钥，通过所述预先主密钥生成所述主密钥；所述服务器密钥交流报文发送单元进一步包括：

第二服务器发送单元，用于在所述服务器密钥交流报文中携带所述服务器的迪菲赫尔曼公开参数及使用基于用户身份的签名方式对所述公开参数做的签名，并向所述客户端发送。

27、如权利要求 26所述的服务器，其特征在于，所述服务器还包括：第二获取单元，用于从所述客户端密钥交流报文中获取使用基于用户身份的签名方式对所述客户端的迪菲赫尔曼公开参数做的签名；

第二验证单元，用于通过获得的客户端私钥生成中心公开参数及客户端公钥，验证所述使用客户端私钥对所述客户端的迪菲赫尔曼公开参数做的签名；验证通过，则控制第五主密钥单元生成迪菲赫尔曼共享密钥。

28、如权利要求 24所述的服务器，其特征在于，所述服务器密钥获取单元进一步包括：

第六主密钥单元，用于从所述客户端密钥交流报文中获取加密过的预先主密钥；使用服务器私钥生成中心公开参数、服务器公钥及客户端选择的控制参数对所述预先主密钥进行解密，获得预先主密钥，通过所述预先主密钥生成所述主密钥。