CN101459506B - 密钥协商方法、用于密钥协商的系统、客户端及服务器 - Google Patents
密钥协商方法、用于密钥协商的系统、客户端及服务器 Download PDFInfo
- Publication number
- CN101459506B CN101459506B CN2007103021457A CN200710302145A CN101459506B CN 101459506 B CN101459506 B CN 101459506B CN 2007103021457 A CN2007103021457 A CN 2007103021457A CN 200710302145 A CN200710302145 A CN 200710302145A CN 101459506 B CN101459506 B CN 101459506B
- Authority
- CN
- China
- Prior art keywords
- key
- client
- server
- message
- user identity
- 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.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 127
- 230000007246 mechanism Effects 0.000 claims abstract description 66
- 230000000977 initiatory effect Effects 0.000 claims description 10
- 230000005540 biological transmission Effects 0.000 claims description 6
- 230000008569 process Effects 0.000 abstract description 33
- 238000012795 verification Methods 0.000 description 6
- 230000009471 action Effects 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 4
- 230000006835 compression Effects 0.000 description 4
- 238000007906 compression Methods 0.000 description 4
- 230000004044 response Effects 0.000 description 4
- 230000033228 biological regulation Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 238000013478 data encryption standard Methods 0.000 description 3
- 238000003860 storage Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- JHIVVAPYMSGYDF-UHFFFAOYSA-N cyclohexanone Chemical compound O=C1CCCCC1 JHIVVAPYMSGYDF-UHFFFAOYSA-N 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000002834 transmittance Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0847—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving identity based encryption [IBE] schemes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明实施例公开了一种密钥协商方法,包括:发送客户端呼叫报文至服务器;接收所述服务器返回的包含基于用户身份的密码机制的密钥协商方式的信息;接收服务器发送的服务器密钥交流报文;获得主密钥;发送客户端密钥交流报文至服务器。本发明实施例还公开了另外一种密钥协商方法,包括:接收客户端发送的客户端呼叫报文;从密文族列表中选择使用基于用户身份的密码机制的密钥协商方式的密文族,发送给客户端;发送服务器密钥交流报文至客户端;接收客户端发送的客户端密钥交流报文;根据所述客户端密钥交流报文中携带的信息获得主密钥。本发明还公开了一种用于密钥协商的系统、及相应的客户端和服务器。以使密钥协商的过程可以便捷、安全、高效。
Description
技术领域
本发明涉及通信技术领域,尤其涉及一种适用于传输层安全协议(TLS,Transport Layer Security Protocol)的密钥协商方法、用于密钥协商的系统、客户端及服务器。
背景技术
TLS是一种在通信技术领域得到广泛应用的协议,它为应用层提供通信双方认证、数据保密和完整性保护,其中,握手协议(handshake protocol)部分负责通信双方的认证、协商加密、完整性保护算法和密钥,由于密钥是非公开的信息,因此通信双方在建立通信时需要对密钥进行协商,以使通信双方可以获得安全准确的相同密钥。
目前握手协议采用的密钥协商方法主要有五种:RSA(Rirest A·Sllalnlr L·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算法是一种非对称密码算法(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报文中包含一个证书或一个证书链。
如果步骤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)。
步骤1011、客户端发送预先主密钥给服务器。
客户端发送客户端密钥交流(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,然后根据pre-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报文中发送服务器方公开参数给客户端,客户端在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)和公钥绑定,使用证书前,需向签发证书的数字证书认证中心(CA,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_MD5
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算法为例进行说明。另外需要说明的是“IBAKA_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参数可以用TS表示。为了获得TS,服务器需要预先完成两个步骤:
1、向KGC申请生成服务器私钥,且该私钥在有效期内。
服务器向KGC发送服务器ID,服务器ID可以以IDS表示,KGC使用服务器ID的哈希值QS=H1(IDS)和KGC的主密钥s的乘积生成服务器私钥SS,并返回给服务器。
服务器私钥SS用公式可以描述为:
SS=sQS
2、获取KGC的公开参数,KGC是指为客户端和服务器生成私钥的KGC。KGC的公开参数通常包含:G1,G2,e^,P,Ppub,H1,H2。
其中G1,G2分别为基于椭圆曲线构造的加法循环群和乘法循环群,e^为双线映射操作,e^:G1xG1=G2,即通过双线性映射将G1中的元素对应到G2中的元素。P为群G1的生成元,参数Ppub=sP,s是KGC的主密钥,是KGC在以素数为模的整数域中选取的随机数。H1,H2为两个哈希函数。H1将任何0和1组成的二进制串转换为G1中的元素。H2将G2中的元素转换为0和1组成的二进制串。
服务器IBC参数TS为服务器选择的随机数a与服务器ID的哈希值QS=H1(IDS)的乘积,因此服务器IBC参数TS用公式可以表述为:
TS=aQS。
上述步骤1和2可以在本流程开始后,步骤203之前完成,也可以在本流程开始之前完成,例如服务器上一次进行密钥协商时完成。
步骤204、服务器发送ServerHelloDone报文给客户端。指示服务器部分的消息已发送结束。该消息不含任何参数。发送完该消息后,服务器等待客户端的响应。
步骤205、客户端发送Client_key_exchange报文给服务器,该报文中携带客户端IBC参数和客户端公钥信息。
其中,客户端公钥信息包括客户端的公钥即客户端ID,同时还可以包含客户端公钥有效期,客户端公钥有效期与服务器公钥有效期类似,用于控制客户端公钥的有效期,超过该有效期,则需要启用新的客户端公钥,服务器收到客户端公钥有效期后,可以通过判断该有效期是否过期来判断客户端公钥是否过期。
同时客户端的私钥为KGC使用客户端公钥生成,当设置有客户端公钥有效期时,则KGC使用客户端公钥加客户端公钥有效期生成客户端私钥。客户端公钥过期时,相应客户端私钥也会过期,因此客户端公钥有效期同时也是客户端私钥有效期,超过该客户端公钥有效期,客户端需要发送客户端ID和新的有效期去KGC申请新的私钥。
客户端公钥信息还包括客户端的KGC的标识,该标识为KGC的域名地址,服务器获得该KGC的域名地址后,可以去该地址获取该KGC的公开参数。
客户端IBC参数根据IBAKA方式采用算法的不同而有所不同,假设采用的是Chen-Kudla算法,客户端IBC参数可以用TC表示。为了获得TC,客户端需要预先完成两个步骤:
1、向KGC申请生成客户端私钥,且该私钥在有效期内。
客户端向KGC发送客户端ID,客户端ID可以以IDC表示,KGC使用客户端ID的哈希值QC=H1(IDC)和KGC的主密钥s的乘积生成客户端私钥SC,并返回给客户端。
客户端私钥SC用公式可以描述为:
SC=sQC
2、获取服务器KGC的公开参数。
客户端IBC参数TC为客户端选择的随机数b与客户端ID的哈希值QC=H1(IDC)的乘积,因此客户端IBC参数TC用公式可以表述为:
TC=bQC。
此时服务器和客户端都获得了对方的ID、对方的IBC参数、服务器和客户端共用的KGC的公开参数和自己的私钥。接着客户端和服务器就可以根据获得的参数计算出主密钥,图2中步骤206到步骤208为客户端的主密钥计算过程,步骤209到步骤2011为服务器的主密钥计算过程。
此处需要说明的是,客户端在步骤201中,向服务器发出信息时就已经获得了服务器的ID,因此,Server_key_exchange报文中可以携带作为服务器公钥的服务器的ID,也可以不携带作为服务器公钥的服务器的ID。
步骤206、客户端以客户端私钥SC、服务器ID、服务器IBC参数TS和KGC的公开参数,计算得到共享密钥KC,KC用公式可以表述为:
KC=e^(SC,TS+bQS)
∵TS=aQS;SC=sQC;
∴KC=e^(sQC,aQS+bQS)=e^(QC+QS)s(a+b)
步骤209、服务器以服务器私钥SS、客户端ID、客户端IBC参数TC和KGC的公开参数,计算得到共享密钥KS,KS用公式可以表述为:
KS=e^(SS,TC+aQC)
∵TC=bQC;SS=sQS;
∴KS=e^(sQS,bQC+aQC)=e^(QC+QS)s(a+b)
由上可知KC=KS=K,因此,在客户端进行过步骤206,服务器进行过步骤209后,通信双方就获得了相同的共享密钥K。
步骤206和步骤209之间没有顺序关系,可以先后执行,也可以同时执行。
步骤207、客户端生成预先主密钥pre-master key。
可以将步骤206中获得的共享密钥K直接作为pre-master key,为了防止版本重放(Version Rollback)攻击,也可以在K之前加上两个字节的客户端版本号(Client_Version)作为pre-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。
步骤2011、服务器从预先主密钥pre-master key生成主密钥master key。
步骤208和步骤2011之间没有顺序关系,可以先后执行,也可以同时执行。
本实施例一中客户端或服务器从pre-master key生成master key方法为TLS中通用的通过pre-master key计算得到master key的算法,即:
master_secret=PRF(pre_master_secret,″master secret″,ClientHello.random+ServerHello.random)[0..47];
ClientHello.random和ServerHello.random分别为ClientHello和ServerHello两个报文中的随机数。Master_secret的长度为48字节。
此时客户端和服务器都获得了主密钥master key,密钥协商完成。
在本实施例中,Server_key_exchange报文和Client_key_exchange报文可以使用如下格式实现:
其中“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算法为例,定义双方的参数如下:
其中,“opaque AlgObjectId”代表算法ID,opaque表示IBC参数为二进制数,大小为0bit到(2^16-1)bits。
使用本发明实施例提供的密钥协商方法实施例一来进行密钥协商,由于IBC是使用用户ID作为用户公钥的,也就不需要使用证书对用户ID和用户公钥进行绑定,因此也就不需要依赖证书进行认证,相应使用证书认证的相关步骤都不需要进行,有效简化了密钥协商的流程,节约了存储和处理器资源,尤其是对于移动终端有限的处理能力以及移动网络有限的传输速度,效果更加明显;同时在密钥协商的过程中就可以完成对对方身份的认证,有效防止了中间人的攻击,保障了系统的安全性;且不需要进行特别的设置,应用范围较广
本发明实施例提供的密钥协商方法实施例二,以使用IBS为例对进行密钥协商的过程进行说明。
使用IBS实现密钥协商的具体流程有很多种,本发明实施例提供的密钥协商方法实施例二以使用IBS进行签名保护DH参数为例进行描述,其流程如图3所示:
步骤301、客户端发送Client_Hello报文给服务器发起会话。
该Client_Hello报文包括的参数有:客户端支持的最高的TLS/SSL,随机数,会话标识符,支持的密文族列表,支持的压缩方法列表。
如果客户端支持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_exchanet报文给客户端,该报文中包含服务器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算法为Hess算法,该Server_key_exchange报文的格式可以定义如下:
其中,ServerDHParams表示服务器DH公开参数。
签名(Signature)表示使用IBS对服务器DH公开参数的签名,在采用Hess算法签名时,签名过程如下:
r=e^(P1,P)k,v=H2(m,r);u=vSS+kP1,
其中P1为服务器随即选取的一个群G1中的元素,k为服务器随即选取的随机数。m为被签名的消息,这里就是服务器的DH公开参数。v和u两个数值就是签名值,该Signature参数可以定义如下:
其中,hs_v<1..2^16-1>和hs_u<1..2^16-1>分别为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^(u,P)·e^(QS,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报文可以定义如下:
其中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。
步骤3011、服务器从预先主密钥pre-master key生成主密钥master key。
客户端或服务器从pre-master key生成master key方法为TLS中制定的通过pre-master key计算得到master key算法,可以参考在本发明实施例提供的密钥协商方法实施例一中描述的方法,在此不再重复。
此时密钥协商完成。
由上可知在本发明实施例提供的密钥协商方法实施例二中,使用IBS签名保护DH参数,以使通信双方可以对对方进行认证,有效防止了中间人的攻击,显著提高了系统的安全性。同样本发明实施例提供的密钥协商方法实施例二也不需要依赖证书进行认证,不需要进行与证书相关的繁琐步骤,节约了网络资源,不需要进行特别的设置,应用范围较广。
同样本发明实施例提供的密钥协商方法实施例二也不需要依赖证书进行认证,不需要进行与证书相关的繁琐步骤,不需要进行特别的设置,应用范围较广。
本发明实施例提供的密钥协商方法实施例三,以使用IBE为例对密钥协商的过程进行说明,本发明实施例提供的密钥协商方法实施例三流程如图4所示:
步骤401、客户端发送Client_Hello报文给服务器发起会话。
该Client_Hello报文包括的参数有:客户端支持的最高版本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使用服务器公钥加服务器公钥有效期生成服务器私钥。服务器公钥过期时,相应服务器私钥也会过期,因此服务器公钥有效期同时也是服务器私钥有效期,超过该服务器公钥有效期,且启用了新的服务器公钥后,服务器需要发送新的服务器ID和新的有效期去KGC申请新的私钥。
本发明实施例三中,服务器的KGC即为服务器生成私钥的KGC,客户端的KGC即为客户端生成私钥的KGC,服务器的KGC和客户端的KGC可能由同一个KGC担任,也有可能由不同KGC担任。在由不同KGC担任,且客户端不知道服务器KGC地址时,就需要在本步骤中发送服务器KGC地址给客户端。
另外需要说明的是,客户端可以向服务器发出Client_Hello报文,即说明客户端知道服务器的ID,也即知道服务器的公钥,因此该报文中服务器ID信息不是必须的,可以不携带。
该Server_key_exchange报文可以如下定义:
其中,ServerIdentity为服务器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报文可以定义如下:
步骤407、客户端按照TLS协议规范从pre-master key生成master key。
步骤406和步骤407之间没有顺序关系,可以先后执行,也可以同时执行。
步骤408、服务器使用服务器的KGC公开参数、服务器公钥与控制参数对接收到的加密过的pre-master key解密,得到pre-master key,再按照TLS协议规范从pre-master key生成master key。
客户端或服务器从pre-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发送的服务器密钥交流报文;接收服务器发送的服务器发送结束报文;
客户端密钥获取单元5110,用于通过所述第一接收单元接收的信息获得主密钥。
客户端5100中的客户端密钥获取单元5110又包括:
第一共享密钥单元5112,用于从所述服务器密钥交流报文中获取所述服务器5200的基于用户身份的密码机制参数;根据所述基于用户身份的密码机制,通过预先获取的私钥生成中心公开参数、客户端私钥、所述服务器5200的基于用户身份的密码机制参数及作为服务器公钥的服务器用户身份,获得共享密钥;
第一主密钥单元5111,用于通过所述共享密钥获得所述主密钥;
第一获取单元5113,用于从所述密钥交流报文中获取所述服务器5200的迪菲赫尔曼公开参数及使用服务器私钥对所述公开参数做的签名;
第一验证单元5114,用于通过预先获得的服务器私钥生成中心公开参数及作为服务器公钥的服务器用户身份,验证所述使用IBC对所述公开参数做的签名;
第二主密钥单元5115,用于在第一验证单元验证通过时,使用所述服务器5200的迪菲赫尔曼公开参数及客户端5100的迪菲赫尔曼公开参数生成迪菲赫尔曼共享密钥,以所述迪菲赫尔曼共享密钥作为预先主密钥,通过所述预先主密钥生成所述主密钥;
第三主密钥单元5116,用于根据传输层安全协议生成预先主密钥,通过所述预先主密钥生成所述主密钥;
客户端密钥获取单元中的第一主密钥单元5111又包括:
第一密钥生成单元51111,用于以所述共享密钥作为预先主密钥,通过所述预先主密钥生成所述主密钥。
第二密钥生成单元51112,用于以所述共享密钥与所述客户端版本号作为预先主密钥,通过所述预先主密钥生成所述主密钥。
客户端5100中的客户端密钥交流报文发送单元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基本一致,在此不再重复描述。
本发明实施例提供的用于密钥协商的系统实施例、本发明实施例提供的客户端实施例、与本发明实施例提供的服务器实施例的具体工作方式可参考上文本发明实施例提供的密钥协商的方法实施例,在此不再重复描述。
以上对本发明所提供的一种密钥协商方法、用于密钥协商的系统、客户端及服务器进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。
Claims (28)
1.一种密钥协商方法,其特征在于,所述方法包括:
向服务器发送包含密文族列表的客户端呼叫报文,发起会话,所述呼叫报文的密文族列表中包含使用基于用户身份的密码机制的密钥协商方式的密文族;
接收所述服务器返回的包含基于用户身份的密码机制的密钥协商方式的信息;
接收所述服务器发送的服务器密钥交流报文;
接收所述服务器发送的服务器发送结束报文;
获得主密钥;
向服务器发送客户端密钥交流报文,以使服务器通过客户端密钥交流报文携带的信息获得主密钥。
2.如权利要求1所述的密钥协商方法,其特征在于,所述基于用户身份的密码机制的密钥协商方式为基于用户身份的认证和密钥协商的密钥协商方式;
所述向服务器发送客户端密钥交流报文包括:在所述客户端密钥交流报文中携带所述客户端的基于用户身份的密码机制参数及客户端公钥,向服务器发送;
所述获得主密钥包括:
从所述服务器密钥交流报文中获取所述服务器的基于用户身份的密码机制参数;
根据所述基于用户身份的密码机制,通过获取的私钥生成中心公开参数、客户端私钥、所述服务器的基于用户身份的密码机制参数及服务器公钥,获得共享密钥;
通过所述共享密钥获得所述主密钥。
3.如权利要求2所述的密钥协商方法,其特征在于,所述通过所述共享密钥获得所述主密钥包括:
以所述共享密钥作为预先主密钥,通过所述预先主密钥生成所述主密钥。
4.如权利要求2所述的密钥协商方法,其特征在于,所述通过所述共享密钥获得所述主密钥包括:
以所述共享密钥与所述客户端版本号作为预先主密钥,通过所述预先主密钥生成所述主密钥。
5.如权利要求2、3或4所述的密钥协商方法,其特征在于,所述方法还包括:
在所述客户端密钥交流报文中携带客户端公钥有效期,以使所述服务器通过所述有效期判断客户端公钥是否过期。
6.如权利要求1所述的密钥协商方法,其特征在于,所述基于用户身份的密码机制的密钥协商方式为基于用户身份的签名的密钥协商方式;
所述向服务器发送客户端密钥交流报文包括:在所述客户端密钥交流报文中携带所述客户端的迪菲赫尔曼公开参数,向服务器发送;
所述获得主密钥包括:
从所述服务器密钥交流报文中获取所述服务器的迪菲赫尔曼公开参数及使用基于用户身份的签名方式对所述迪菲赫尔曼公开参数做的签名;
通过获得的服务器私钥生成中心公开参数及服务器公钥,验证所述服务器密钥交流报文中使用基于用户身份的签名方式对所述迪菲赫尔曼公开参数做的签名;
验证通过时,使用所述服务器的迪菲赫尔曼公开参数和客户端的迪菲赫尔曼私有参数生成迪菲赫尔曼共享密钥,通过所述迪菲赫尔曼共享密钥生成所述主密钥。
7.如权利要求6所述的密钥协商方法,其特征在于,所述方法还包括:
使用基于用户身份的签名方式对所述客户端的迪菲赫尔曼公开参数做签名,并携带在所述客户端密钥交流报文中,以使所述服务器对客户端进行认证。
8.如权利要求1所述的密钥协商方法,其特征在于,所述基于用户身份的密码机制的密钥协商方式为基于用户身份的加密的密钥协商方式;
所述获得主密钥包括:生成预先主密钥,通过所述预先主密钥生成所述主密钥;
所述向服务器发送客户端密钥交流报文包括:使用获得的服务器的私钥生成中心公开参数、服务器公钥及客户端选择的控制参数对所述预先主密钥进行加密,并携带在所述客户端密钥交流报文中向服务器发送。
9.如权利要求8所述的密钥协商方法,其特征在于,所述方法还包括:
将所述控制参数携带在所述客户端密钥交流报文中向服务器发送。
10.一种密钥协商方法,其特征在于,所述方法包括:
接收客户端发送的包含密文族列表的客户端呼叫报文,所述呼叫报文的密文族列表中包含使用基于用户身份的密码机制的密钥协商方式的密文族;
从所述密文族列表中选择使用基于用户身份的密码机制的密钥协商方式的密文族,发送给所述客户端;
向所述客户端发送服务器密钥交流报文;
向所述客户端发送服务器发送结束报文;
接收客户端发送的客户端密钥交流报文;
根据所述客户端密钥交流报文中携带的信息获得主密钥。
11.如权利要求10所述的密钥协商方法,其特征在于,所述基于用户身份的密码机制的密钥协商方式为基于用户身份的认证和密钥协商的密钥协商方式;
所述向所述客户端发送服务器密钥交流报文包括:在所述服务器密钥交流报文中携带所述服务器的基于用户身份的密码机制参数,向所述客户端发送;
所述根据所述客户端密钥交流报文中携带的信息获得主密钥包括:
从所述客户端密钥交流报文中获取所述客户端的基于用户身份的密码机制参数,及客户端公钥;
通过获取的私钥生成中心公开参数、服务器私钥、所述客户端的基于用户身份的密码机制参数及所述客户端公钥,获得共享密钥;
通过所述共享密钥获得所述主密钥。
12.如权利要求11所述的密钥协商方法,其特征在于,所述通过所述共享密钥获得所述主密钥包括:
以所述共享密钥作为预先主密钥,通过所述预先主密钥生成所述主密钥。
13.如权利要求11所述的密钥协商方法,其特征在于,所述通过所述共享密钥获得所述主密钥包括:
以所述共享密钥与所述客户端版本号作为预先主密钥,通过所述预先主密钥生成所述主密钥。
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所述的服务器,其特征在于,所述服务器密钥获取单元进一步包括:
第六主密钥单元,用于从所述客户端密钥交流报文中获取加密过的预先主密钥;使用服务器私钥生成中心公开参数、服务器公钥及客户端选择的控制参数对所述预先主密钥进行解密,获得预先主密钥,通过所述预先主密钥生成所述主密钥。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007103021457A CN101459506B (zh) | 2007-12-14 | 2007-12-14 | 密钥协商方法、用于密钥协商的系统、客户端及服务器 |
EP08862820A EP2173055A1 (en) | 2007-12-14 | 2008-09-26 | A method, a system, a client and a server for key negotiating |
PCT/CN2008/072547 WO2009076811A1 (zh) | 2007-12-14 | 2008-09-26 | 密钥协商方法、用于密钥协商的系统、客户端及服务器 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007103021457A CN101459506B (zh) | 2007-12-14 | 2007-12-14 | 密钥协商方法、用于密钥协商的系统、客户端及服务器 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101459506A CN101459506A (zh) | 2009-06-17 |
CN101459506B true CN101459506B (zh) | 2011-09-14 |
Family
ID=40770151
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007103021457A Expired - Fee Related CN101459506B (zh) | 2007-12-14 | 2007-12-14 | 密钥协商方法、用于密钥协商的系统、客户端及服务器 |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP2173055A1 (zh) |
CN (1) | CN101459506B (zh) |
WO (1) | WO2009076811A1 (zh) |
Families Citing this family (69)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101582906B (zh) * | 2009-06-23 | 2012-04-18 | 中国人民解放军信息工程大学 | 密钥协商方法和装置 |
CN102035644B (zh) * | 2009-09-29 | 2013-02-27 | 国基电子(上海)有限公司 | 主密钥动态配置系统及方法 |
CN102064946A (zh) * | 2011-01-25 | 2011-05-18 | 南京邮电大学 | 一种基于身份加密的密钥共享方法 |
US9288234B2 (en) | 2011-08-04 | 2016-03-15 | International Business Machines Corporation | Security policy enforcement |
EP4322465A3 (en) * | 2011-12-15 | 2024-04-17 | Daedalus Prime LLC | Method and device for secure communications over a network using a hardware security engine |
CN102801616B (zh) * | 2012-08-02 | 2015-04-15 | 华为技术有限公司 | 报文发送和接收的方法、装置和系统 |
MY171259A (en) * | 2012-11-05 | 2019-10-07 | Mimos Berhad | System and method for identity-based entity authentication for client-server communications |
CN103124215A (zh) * | 2013-01-25 | 2013-05-29 | 匡创公司 | 带有时间标记的自认证方法 |
CN103269272B (zh) * | 2013-05-22 | 2016-03-02 | 河海大学 | 一种基于短期证书的密钥封装方法 |
CN103354498B (zh) * | 2013-05-31 | 2016-09-28 | 北京创世泰克科技股份有限公司 | 一种基于身份的文件加密传输方法 |
EP3051744B1 (en) | 2013-10-28 | 2019-01-02 | Huawei Device (Dongguan) Co., Ltd. | Key configuration method and apparatus |
CN105141568B (zh) * | 2014-05-28 | 2019-02-12 | 腾讯科技(深圳)有限公司 | 安全通信通道建立方法及系统、客户端和服务器 |
CN104023013B (zh) * | 2014-05-30 | 2017-04-12 | 上海帝联信息科技股份有限公司 | 数据传输方法、服务端和客户端 |
CN105281940B (zh) * | 2014-07-18 | 2020-08-21 | 南京中兴软件有限责任公司 | 一种基于netconf协议的hello报文交互的方法、设备和系统 |
US9992670B2 (en) | 2014-08-12 | 2018-06-05 | Vodafone Ip Licensing Limited | Machine-to-machine cellular communication security |
GB2529391A (en) * | 2014-08-12 | 2016-02-24 | Vodafone Ip Licensing Ltd | Machine-to-machine cellular communication security |
CN104301103A (zh) * | 2014-09-19 | 2015-01-21 | 闫鸿滨 | 基于环Zn圆锥曲线公钥密码体制的多重密码恢复方法 |
CN104486077B (zh) * | 2014-11-20 | 2017-09-15 | 中国科学院信息工程研究所 | 一种VoIP实时数据安全传输的端到端密钥协商方法 |
CN105991622A (zh) * | 2015-03-05 | 2016-10-05 | 阿里巴巴集团控股有限公司 | 一种报文验证方法及设备 |
KR102284954B1 (ko) * | 2015-04-08 | 2021-08-03 | 삼성전자 주식회사 | 무선 통신 시스템에서 단말에 프로파일을 다운로드 하는 방법 및 장치 |
CZ2015473A3 (cs) * | 2015-07-07 | 2017-02-08 | Aducid S.R.O. | Způsob zabezpečení autentizace při elektronické komunikaci |
KR20170035665A (ko) * | 2015-09-23 | 2017-03-31 | 삼성에스디에스 주식회사 | 키 교환 장치 및 방법 |
CN105553966B (zh) * | 2015-12-10 | 2018-11-09 | 中国联合网络通信集团有限公司 | 密钥交换的方法及装置 |
CN105763333B (zh) * | 2016-01-28 | 2019-05-24 | 北京江南天安科技有限公司 | 一种非对称密钥的协商方法 |
CN105577370A (zh) * | 2016-02-29 | 2016-05-11 | 赵运磊 | 一种应用于客户-服务器环境的认证密钥协商方法 |
CN108259160B (zh) * | 2016-12-28 | 2021-06-18 | 湖北高瞻科技有限责任公司 | 数据通讯加密方法及装置 |
JP6644037B2 (ja) * | 2017-09-08 | 2020-02-12 | 株式会社東芝 | 通信制御システム |
CN108289253A (zh) * | 2018-01-09 | 2018-07-17 | 武汉斗鱼网络科技有限公司 | 弹幕发送间隔控制方法、存储介质、电子设备及系统 |
CN108307244B (zh) * | 2018-01-09 | 2020-06-16 | 武汉斗鱼网络科技有限公司 | 弹幕发言时间控制方法、存储介质、电子设备及系统 |
CN108388946B (zh) * | 2018-01-29 | 2021-08-17 | 湘潭大学 | 一种基于盲量子计算的两方量子计算方法 |
CN108322464B (zh) * | 2018-01-31 | 2020-11-17 | 中国联合网络通信集团有限公司 | 一种密钥验证方法及设备 |
CN108173653A (zh) * | 2018-03-13 | 2018-06-15 | 江苏信源久安信息科技有限公司 | 通过标识密码算法生成具有生命周期密钥的方法 |
CN108965243B (zh) * | 2018-05-29 | 2020-10-16 | 如般量子科技有限公司 | 一种基于对称密钥池和跨中继的类aka身份认证系统和方法 |
CN110662089A (zh) * | 2018-06-29 | 2020-01-07 | 武汉斗鱼网络科技有限公司 | 弹幕接收处理方法、存储介质、电子设备及系统 |
CN110868285B (zh) * | 2018-08-28 | 2023-05-19 | 中国电信股份有限公司 | 认证方法、服务器、系统和计算机可读存储介质 |
CN108989054B (zh) * | 2018-08-30 | 2020-08-04 | 武汉理工大学 | 一种密码系统及数字签名方法 |
CN109740321B (zh) * | 2018-12-25 | 2020-03-31 | 北京深思数盾科技股份有限公司 | 吊销加密机管理员锁的方法、加密机及厂商服务器 |
US10630467B1 (en) * | 2019-01-04 | 2020-04-21 | Blue Ridge Networks, Inc. | Methods and apparatus for quantum-resistant network communication |
CN109617916A (zh) * | 2019-01-16 | 2019-04-12 | 北京云中融信网络科技有限公司 | 秘钥处理方法及即时通讯系统 |
CN111600829A (zh) * | 2019-02-21 | 2020-08-28 | 杭州萤石软件有限公司 | 用于物联网设备间的安全通信方法和系统 |
CN110351096B (zh) * | 2019-07-24 | 2022-02-01 | 深圳壹账通智能科技有限公司 | 多重签名方法、签名中心、程序介质及电子设备 |
CN110380868A (zh) * | 2019-08-22 | 2019-10-25 | 广东浪潮大数据研究有限公司 | 一种通信方法、装置及通信系统和存储介质 |
CN110677389B (zh) * | 2019-09-09 | 2022-01-25 | 杭州迪普科技股份有限公司 | 基于ssl协议的混合攻击防护方法和装置 |
JP7231051B2 (ja) * | 2019-10-04 | 2023-03-01 | 日本電信電話株式会社 | 端末、サーバ、方法及びプログラム |
CN110831000B (zh) * | 2019-10-31 | 2023-04-07 | 迈普通信技术股份有限公司 | 一种安全接入方法、设备及系统 |
US11206135B2 (en) * | 2019-11-11 | 2021-12-21 | International Business Machines Corporation | Forward secrecy in Transport Layer Security (TLS) using ephemeral keys |
CN110971401B (zh) * | 2019-11-19 | 2021-10-22 | 武汉大学 | 一种基于交叉互锁机制的认证密钥协商方法及其实施装置 |
CN110995414B (zh) * | 2019-12-23 | 2023-08-11 | 中金金融认证中心有限公司 | 基于国密算法在tls1_3协议中建立通道的方法 |
CN111327605B (zh) * | 2020-01-23 | 2022-09-13 | 北京无限光场科技有限公司 | 传输私密信息的方法、终端、服务器和系统 |
CN111585976B (zh) * | 2020-04-09 | 2021-11-23 | 北京理工大学 | 通信方法、装置、存储介质和电子设备 |
CN111510291B (zh) * | 2020-04-20 | 2023-06-02 | 重庆邮电大学 | 基于双线性对的高效身份认证密钥协商方法 |
CN111756699B (zh) * | 2020-05-28 | 2022-05-06 | 苏州浪潮智能科技有限公司 | 一种基于非对称加密的lldp协议优化方法与系统 |
JP7521011B2 (ja) * | 2020-05-29 | 2024-07-23 | 華為技術有限公司 | 通信方法及び装置 |
US20230308869A1 (en) * | 2020-07-24 | 2023-09-28 | Beijing Xiaomi Mobile Software Co., Ltd. | Method and device for communication on multiple links, and computer-readable storage medium |
CN112134694B (zh) * | 2020-08-11 | 2024-01-23 | 北京智芯微电子科技有限公司 | 数据交互方法、主站、终端及计算机可读存储介质 |
CN116318677A (zh) * | 2020-08-31 | 2023-06-23 | Oppo广东移动通信有限公司 | 一种数据传输方法、客户端、服务端及存储介质 |
CN114124367B (zh) * | 2020-08-31 | 2023-03-24 | Oppo广东移动通信有限公司 | 一种数据传输方法、装置及存储介质 |
CN112422507B (zh) * | 2020-10-19 | 2023-04-07 | 北京电子科技学院 | 一种基于标识算法的国密ssl加密方法 |
CN115720149A (zh) * | 2020-10-26 | 2023-02-28 | 华为技术有限公司 | 加密报文的检测方法及防护设备 |
CN114499913B (zh) * | 2020-10-26 | 2022-12-06 | 华为技术有限公司 | 加密报文的检测方法及防护设备 |
CN112187832A (zh) * | 2020-11-03 | 2021-01-05 | 北京指掌易科技有限公司 | 数据传输方法和电子设备 |
CN112511550B (zh) * | 2020-12-02 | 2022-02-22 | 迈普通信技术股份有限公司 | 通信方法、装置、电子设备及存储介质 |
CN113179155A (zh) * | 2021-03-26 | 2021-07-27 | 广东工业大学 | 一种基于纠缠交换的单服务器盲量子计算方法 |
CN113438071B (zh) * | 2021-05-28 | 2024-04-09 | 荣耀终端有限公司 | 安全通信的方法及设备 |
CN113300845B (zh) * | 2021-07-20 | 2022-07-05 | 国能信控互联技术有限公司 | 一种智慧热网数据传输安全防护系统和方法 |
CN114337989B (zh) * | 2021-12-30 | 2024-11-12 | 中科曙光国际信息产业有限公司 | Ssh密钥的管理方法、装置、设备以及存储介质 |
CN114760253B (zh) * | 2022-03-31 | 2022-10-28 | 慧之安信息技术股份有限公司 | 快速物联网数据传输方法和系统 |
CN115529129B (zh) * | 2022-09-29 | 2024-10-18 | 上海浦东发展银行股份有限公司 | 加密通信方法、系统、计算机设备、可读存储介质及程序产品 |
WO2024073843A1 (en) * | 2022-10-03 | 2024-04-11 | QDS Holdings Inc. | Systems and methods for establishing a secure digital network environment |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006034428A2 (en) * | 2004-09-20 | 2006-03-30 | Pgp Corporation | Apparatus and method for identity-based encryption within a conventional public-key infrastructure |
WO2006051517A1 (en) * | 2004-11-12 | 2006-05-18 | Dublin City University | Identity based encryption |
CN1929371A (zh) * | 2005-09-05 | 2007-03-14 | 华为技术有限公司 | 用户和外围设备协商共享密钥的方法 |
CN101047945A (zh) * | 2006-03-28 | 2007-10-03 | 华为技术有限公司 | 移动通信系统及用户临时身份分发方法 |
Family Cites Families (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FI102235B1 (fi) * | 1996-01-24 | 1998-10-30 | Nokia Telecommunications Oy | Autentikointiavainten hallinta matkaviestinjärjestelmässä |
FI104666B (fi) * | 1997-11-10 | 2000-04-14 | Nokia Networks Oy | Varma kättelyprotokolla |
JP4186987B2 (ja) * | 2003-07-11 | 2008-11-26 | 日本電信電話株式会社 | データベースアクセス制御方法、データベースアクセス制御装置、データベースアクセス制御のためのプログラム、および該プログラムを記録した記録媒体 |
CN100490375C (zh) * | 2003-12-01 | 2009-05-20 | 中国电子科技集团公司第三十研究所 | 一种基于对称密码算法的强鉴别方法 |
JP2005176144A (ja) * | 2003-12-12 | 2005-06-30 | Ntt Docomo Inc | 端末装置、通信システム及び通信方法 |
CN1655498A (zh) * | 2004-02-10 | 2005-08-17 | 管海明 | 一种多中心的基于身份的密钥管理方法 |
CN1298194C (zh) * | 2004-03-22 | 2007-01-31 | 西安电子科技大学 | 基于漫游密钥交换认证协议的无线局域网安全接入方法 |
CN100359845C (zh) * | 2004-03-26 | 2008-01-02 | 中兴通讯股份有限公司 | 无线局域网自组网模式共享密钥认证和会话密钥协商方法 |
CN100544249C (zh) * | 2004-10-29 | 2009-09-23 | 大唐移动通信设备有限公司 | 移动通信用户认证与密钥协商方法 |
US7370202B2 (en) * | 2004-11-02 | 2008-05-06 | Voltage Security, Inc. | Security device for cryptographic communications |
CN100550725C (zh) * | 2005-06-17 | 2009-10-14 | 中兴通讯股份有限公司 | 一种用户与应用服务器协商共享密钥的方法 |
CN1863040A (zh) * | 2005-07-14 | 2006-11-15 | 华为技术有限公司 | 保证安全联盟信息安全的方法和装置 |
WO2007017884A1 (en) * | 2005-08-05 | 2007-02-15 | Hewlett-Packard Development Company L.P. | System, method and apparatus to obtain a key for encryption/decryption/data recovery from an enterprise cryptography key management system |
CN1921682B (zh) * | 2005-08-26 | 2010-04-21 | 华为技术有限公司 | 增强通用鉴权框架中的密钥协商方法 |
CN100589378C (zh) * | 2005-10-28 | 2010-02-10 | 腾讯科技(深圳)有限公司 | 一种为身份认证提供数据加密的装置和方法 |
CN100505759C (zh) * | 2005-11-15 | 2009-06-24 | 中兴通讯股份有限公司 | 一种非对等实体安全等级协商方法 |
CN1980123B (zh) * | 2005-11-30 | 2010-07-21 | 中国科学院研究生院 | 基于ibe的pki系统的实现方法及其密钥管理装置 |
CN101009919A (zh) * | 2006-01-24 | 2007-08-01 | 华为技术有限公司 | 一种基于移动网络端到端通信的认证方法 |
CN1889433A (zh) * | 2006-07-20 | 2007-01-03 | 上海交通大学 | 基于隐式公钥证书的双方认证密钥协商方法及系统 |
CN100463391C (zh) * | 2006-09-23 | 2009-02-18 | 西安西电捷通无线网络通信有限公司 | 一种网络密钥管理及会话密钥更新方法 |
CN101030862B (zh) * | 2007-03-29 | 2010-05-26 | 中兴通讯股份有限公司 | 非ip多媒体业务ue的鉴权方法、鉴权网络及ue |
CN101060530A (zh) * | 2007-05-22 | 2007-10-24 | 赵运磊 | 可抵赖的互联网密钥交换协议 |
-
2007
- 2007-12-14 CN CN2007103021457A patent/CN101459506B/zh not_active Expired - Fee Related
-
2008
- 2008-09-26 EP EP08862820A patent/EP2173055A1/en not_active Withdrawn
- 2008-09-26 WO PCT/CN2008/072547 patent/WO2009076811A1/zh active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006034428A2 (en) * | 2004-09-20 | 2006-03-30 | Pgp Corporation | Apparatus and method for identity-based encryption within a conventional public-key infrastructure |
WO2006051517A1 (en) * | 2004-11-12 | 2006-05-18 | Dublin City University | Identity based encryption |
CN1929371A (zh) * | 2005-09-05 | 2007-03-14 | 华为技术有限公司 | 用户和外围设备协商共享密钥的方法 |
CN101047945A (zh) * | 2006-03-28 | 2007-10-03 | 华为技术有限公司 | 移动通信系统及用户临时身份分发方法 |
Also Published As
Publication number | Publication date |
---|---|
EP2173055A1 (en) | 2010-04-07 |
WO2009076811A1 (zh) | 2009-06-25 |
CN101459506A (zh) | 2009-06-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101459506B (zh) | 密钥协商方法、用于密钥协商的系统、客户端及服务器 | |
CN107948189B (zh) | 非对称密码身份鉴别方法、装置、计算机设备及存储介质 | |
EP3437247B1 (en) | System and method for distribution of identity based key material and certificate | |
JP4527358B2 (ja) | 鍵供託を使用しない、認証された個別暗号システム | |
JP4709815B2 (ja) | 認証方法および装置 | |
JP4814339B2 (ja) | 制約された暗号キー | |
CN102318258B (zh) | 基于身份的认证密钥协商协议 | |
Steiner et al. | Secure password-based cipher suite for TLS | |
JP2005515701A6 (ja) | データ伝送リンク | |
JP2005515715A (ja) | データ伝送リンク | |
JP2005515701A (ja) | データ伝送リンク | |
US20060288224A1 (en) | System and method for detecting exposure of ocsp responder's session private key | |
WO1999025093A2 (en) | Secure handshake protocol | |
CN110808991B (zh) | 一种安全通信连接的方法、系统、电子设备及存储介质 | |
WO2017167771A1 (en) | Handshake protocols for identity-based key material and certificates | |
CN110690966B (zh) | 终端与业务服务器连接的方法、系统、设备及存储介质 | |
Malik et al. | L-ecqv: Lightweight ecqv implicit certificates for authentication in the internet of things | |
Zhang et al. | Ndn-mps: Supporting multiparty authentication over named data networking | |
KR100456624B1 (ko) | 이동 통신망에서의 인증 및 키 합의 방법 | |
CN117729056B (zh) | 一种设备身份认证方法和系统 | |
Zhou et al. | Trusted channels with password-based authentication and TPM-based attestation | |
Reimair et al. | In Certificates We Trust--Revisited | |
Rösler et al. | Interoperability between messaging services secure–implementation of encryption | |
CN114531235B (zh) | 一种端对端加密的通信方法及系统 | |
JP6609212B2 (ja) | 暗号化通信チャネル確立システム、方法、プログラム及びコンピュータ読取り可能なプログラム記録媒体 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
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 | ||
C17 | Cessation of patent right | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110914 Termination date: 20121214 |