CN109462476A - 密钥协商方法、装置、终端及计算机可读存储介质 - Google Patents
密钥协商方法、装置、终端及计算机可读存储介质 Download PDFInfo
- Publication number
- CN109462476A CN109462476A CN201811414131.9A CN201811414131A CN109462476A CN 109462476 A CN109462476 A CN 109462476A CN 201811414131 A CN201811414131 A CN 201811414131A CN 109462476 A CN109462476 A CN 109462476A
- Authority
- CN
- China
- Prior art keywords
- information
- key
- opposite end
- authentication
- session code
- 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
Links
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
-
- 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/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- 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/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
-
- 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
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)
- Power Engineering (AREA)
- Mobile Radio Communication Systems (AREA)
- Storage Device Security (AREA)
Abstract
本公开涉及一种密钥协商方法、装置、终端及计算机可读存储介质,涉及移动通信技术领域,应用于任一终端,该方法包括:任一终端均向对端发送用户证书信息;利用接收到的对端的用户证书信息以及本端的打包公钥生成身份验证信息,向对端发送身份验证信息;对接收到的对端的身份验证信息进行身份验证操作;若身份验证通过,利用对端的打包公钥生成会话秘钥生成信息,并向对端发送;利用接收到的对端发送的会话秘钥生成信息生成会话秘钥;上述技术方案利用进行密钥协商的双方信息组成身份验证信息,保证后续进行密钥协商的安全性;相对于通过提高通信信道传输要求的方式,能够不依赖于核心网络设施,降低了对网络环境的要求,提高密钥协商的适应性。
Description
技术领域
本公开涉及移动通信技术领域,具体地,涉及一种密钥协商方法、装置、终端及计算机可读存储介质。
背景技术
密钥协商指的是两个及以上的通信实体,共同协商建立会话密钥,任何一个参与者均会对结果产生影响。目前,关于密钥协商的相关技术通常对通信实体之间的通信信道的传输要求都很高,因此在具体的密钥协商时需要对核心网或通信基础设置进行修改,或者是依靠后台密管参与。这些过程都增加了密钥协商的复杂性和难度。
发明内容
本公开的目的是提供一种密钥协商方法、装置、终端及计算机可读存储介质,能够不依赖于核心网络设施,降低了对网络环境的要求,提高了密钥协商的适应性和便捷性。
为了实现上述目的,一方面,本公开提供了一根据本公开实施例的第一方面,提供一种密钥协商方法,应用于任一终端,包括:
任一终端均向对端发送用户证书信息;
利用接收到的对端的用户证书信息以及本端的打包公钥生成身份验证信息,并向对端发送所述身份验证信息;
对接收到的对端的身份验证信息进行身份验证操作;
若身份验证通过,利用对端的打包公钥生成会话秘钥生成信息,并向对端发送所述会话秘钥生成信息;
利用接收到的对端发送的会话秘钥生成信息生成会话秘钥。
可选地,所述任一终端均向对端发送用户证书信息之前,还包括:
从建立安全通信信道的服务器中获取验证码;
将用户证书生成参数信息发送给所述服务器,以使所述服务器利用所述用户证书生成参数信息生成用户证书信息;其中,所述用户证书生成参数信息包括所述验证码、标识信息以及密码卡序列号;
接收所述服务器发送的所述用户证书信息。
可选地,还包括:
若接收到对端发送的版本信息,判断本端是否支持所述版本信息对应的版本;
若本端不支持所述版本信息对应的版本,则终止密钥协商。
可选地,当所述用户证书信息为用户证书序列号时,所述利用接收到的对端的用户证书信息以及本端的打包公钥生成身份验证信息,包括:
解析接收到的对端的用户证书序列号,得到解析结果;
按照预设提取规则,从所述解析结果中提取对应的序列号信息作为证书验证信息;
利用预设私钥对本端的打包公钥的哈希值进行签名得到签名信息;
将所述打包公钥和所述签名信息作为签名验证信息;
将所述证书验证信息连接所述签名验证信息生成身份验证信息。
可选地,所述对接收到的对端的身份验证信息进行身份验证操作,包括:
验证接收到的对端的身份验证信息中的证书验证信息是否与本端的用户证书信息一致;
若对端的身份验证信息中的证书验证信息与本端的用户证书信息一致,验证所述证书验证信息里的标识信息是否与本端的标识信息一致;
若所述证书验证信息里的标识信息与本端的标识信息一致,验证所述身份验证信息中的签名信息是否正确;
若所述身份验证信息中的签名信息正确,则身份验证通过。
可选地,所述利用对端的打包公钥生成会话秘钥生成信息,并向对端发送所述会话秘钥生成信息,包括:
生成第一随机数以及第一向量数据;
利用对端的打包公钥对所述第一随机数和所述第一向量数据进行加密,得到会话秘钥生成信息;
向对端发送所述会话秘钥生成信息。
可选地,所述利用接收到的对端发送的会话秘钥生成信息生成会话秘钥,包括:
利用本端的打包私钥对接收到的对端发送的会话秘钥生成信息进行解密,得到第二随机数以及第二向量数据;
将所述第一随机数和所述第二随机数进行第一运算,生成会话秘钥;
将所述第一向量数据和所述第二向量数据进行所述第一运算,生成所述会话秘钥对应的初始向量。
可选地,所述利用接收到的对端发送的会话秘钥生成信息生成会话秘钥之后,还包括:
接收对端发送的会话秘钥验证信息;
利用本端的会话秘钥和对应的初始向量,解密所述会话秘钥验证信息;
若解密结果正确,则所述会话秘钥正确。
其中,所述会话秘钥验证信息的生成方法,包括:
生成第三随机数;
利用本端的会话秘钥和对应的初始向量加密所述第三随机数,形成第一验证信息;
将所述第一验证信息连接所述第三随机数的哈希值形成会话秘钥验证信息。
根据本公开实施例的第二方面,提供一种密钥协商装置,应用于任一终端,包括:
第一发送模块,用于任一终端均向对端发送用户证书信息;
身份验证信息生成模块,用于利用接收到的对端的用户证书信息以及本端的打包公钥生成身份验证信息;
第二发送模块,用于向对端发送所述身份验证信息;
身份验证模块,用于对接收到的对端的身份验证信息进行身份验证操作;
第三发送模块,用于在身份验证通过时,利用对端的打包公钥生成会话秘钥生成信息,并向对端发送所述会话秘钥生成信息;
会话秘钥生成模块,用于利用接收到的对端发送的会话秘钥生成信息生成会话秘钥。
根据本公开实施例的第三方面,提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述所述方法的步骤。
根据本公开实施例的第四方面,提供一种终端,包括:
存储器,其上存储有计算机程序;
处理器,用于执行所述存储器中的所述计算机程序,以实现上述所述方法的步骤。
通过上述技术方案,由任一终端均向要进行密钥协商的对端发送用户证书信息,并在接收到的对端的用户证书信息时,利用接收到的对端的用户证书信息以及本端的打包公钥生成身份验证信息以及向对端发送所述身份验证信息;然后任一终端对接收到的对端的身份验证信息进行身份验证操作,仅在身份验证通过,利用对端的打包公钥生成会话秘钥生成信息,并向对端发送会话秘钥生成信息,并在接收到的对端发送的会话秘钥生成信息时生成会话秘钥。可见,上述技术方案利用进行密钥协商的双方信息(即对端的用户证书信息和本端的打包公钥)组成身份验证信息,不仅包含用户证书信息还包含打包公钥,提高了身份验证的可靠性,进而保证了后续进行密钥协商的安全性;相对于通过提高通信信道传输要求或者通过后台密管的方式,能够不依赖于核心网络设施或者额外的专业设备,即便在开放性网络的环境中也能够执行本公开中的身份验证过程进而保证密钥协商的安全性;降低了对网络环境以及专业密管设备的要求,提高了密钥协商的适应性和便捷性。且在生成会话秘钥生成信息时利用了对端的打包公钥,进一步提高了会话秘钥生成信息的可靠性,进而提升了会话秘钥的可靠性和安全性,能够避免中间人攻击,以保证密钥协商的安全性。
本公开的其他特征和优点将在随后的具体实施方式部分予以详细说明。
附图说明
附图是用来提供对本公开的进一步理解,并且构成说明书的一部分,与下面的具体实施方式一起用于解释本公开,但并不构成对本公开的限制。在附图中:
图1是根据一示例性实施例示出的一种密钥协商方法的流程图;
图2是根据另一示例性实施例示出的一种密钥协商方法的流程图;
图3是根据又一示例性实施例示出的一种生成身份验证信息的流程图;
图4是根据又一示例性实施例示出的一种身份验证操作的流程图;
图5是根据一示例性实施例示出的一种密钥协商装置的结构框图;
图6是根据另一示例性实施例示出的一种身份验证信息生成模块的结构框图;
图7是根据又一示例性实施例示出的一种身份验证模块的结构框图;
图8是根据又一示例性实施例示出的一种第二发送模块的结构框图;
图9是根据又一示例性实施例示出的一种会话秘钥生成模块的结构框图;
图10是根据另一示例性实施例示出的一种密钥协商装置的结构框图;
图11是根据又一示例性实施例示出的一种验证模块的结构框图;
图12是根据一示例性实施例示出的一种终端的框图。
具体实施方式
以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是,此处所描述的具体实施方式仅用于说明和解释本公开,并不用于限制本公开。
目前,关于密钥协商的相关技术通常对通信实体之间的通信信道的传输要求都很高,因此在具体的密钥协商时需要对核心网或通信基础设置进行修改,或者是依靠后台密管参与。致使当前密钥协商时需要专业人员对核心网或通信基础设置进行修改,增加了密钥协商的复杂性和难度;或者是依靠后台密管参与,增加了密钥协商的成本。本公开通过对密钥协商过程进行重新的设计以克服上述问题。为此,本公开提供了一种密钥协商方法、装置、终端及计算机可读存储介质。
请参考图1,图1是根据一示例性实施例示出的一种密钥协商方法的流程图;该方法应用于任一终端,可以包括:
步骤S101、向对端发送用户证书信息。
需要指出的是,本实施例中并不对参与密钥协商的终端的数量进行限定,其由进行密钥协商时的实际应用场景的需要确定。由于密钥协商是两个及以上的终端共同协商建立会话密钥的过程。因此,一次成功的密钥协商过程中参与密钥协商的各个终端均需要执行步骤S101至步骤S105。例如本步骤中任一终端均会向对端发送各自的用户证书信息。本实施例中后续出现的本端即指当前需要执行对应步骤的终端。当然可以理解的是,对端就是本次密钥协商过程中与本端相对应的需要进行交互的终端就是对端。本实施例中也不对各个终端对应的对端的数量进行限定,一般情况下密钥协商在两者之间进行,此时对端就是一个。其中,这里的终端可以理解为能够进行密钥协商的通信主体也就是通信终端。
本步骤中参与密钥协商的各个终端均向其对应的对端发送本端的用户证书信息,以便为后续身份验证信息的生成提供参数。本实施例中并不对用户证书信息的具体内容进行限定。例如用户证书信息可以是本端(任一终端)的完整用户证书信息,当然这里的完整用户证书信息可以理解为证书集团中本端对应的本级用户证书,也可以是本端对应的整个证书集团的全部证书或者包含本级用户证书的部分证书均可。用户证书信息也可以是本端的完整用户证书信息中的部分内容,本实施例并不对该部分内容进行限定,只要可以唯一标识该用户证书信息的关键内容即可(例如用户证书信息中的序列号信息)。用户可以根据终端对应的硬件计算能力,以及密钥协商的效率进行选择。
当然,本实施例也不限定用户证书信息的获取方式。只要每一个终端均具有其对应的用户证书信息即可。例如终端可以通过服务器(如CA服务器即电子商务认证中心)获取。本实施例提供的一个获取过程可以如下:从建立安全通信信道的服务器中获取验证码;将用户证书生成参数信息发送给服务器,以使服务器利用用户证书生成参数信息生成用户证书信息;其中,用户证书生成参数信息包括验证码、标识信息以及密码卡序列号;接收服务器发送的用户证书信息。该获取过程中并不对安全通信信道的种类进行限定,例如可以是SSL(Secure Sockets Layer,安全套接层)安全通信通道。当然也不限定验证码获取的方式,例如可以通过终端对应的电话号码获取,也可以是通过终端绑定的邮箱获取。本实施例中不限定用户证书生成参数信息的内容。其可以根据用户对用户证书信息的安全性以及具体选择的用户证书生成方法所需要的参数适应性确定。一般情况下,包括密码卡序列号和验证码。进一步,由于后续在生成身份验证信息时需要用到用户证书信息,为了提高身份验证操作的可靠性,该实施例中的用户证书生成参数信息包括标识信息,标识信息一般是指可以唯一标识该终端身份的信息。即通过标识信息又可以进一步确定终端身份,给了用户证书信息又一个验证维度。本实施例并不对标识信息进行限定,例如可以是终端对应的电话号码,或者是终端IP,或者是终端绑定的邮箱地址等。
基于上述论述,本实施例提供的另一个获取过程可以如下:终端与服务器建立SSL安全通道之后,终端输入电话号码,发起验证码申请,服务器通过短信服务器将验证码发送给终端,终端输入验证码,将验证码、电话号码、密码卡序列号发送给服务器。服务器短信验证通过之后,重新签发用户证书CERT2(CERT2即可以是用户证书信息)给终端,终端将该用户证书存储到密码卡中。
步骤S102、利用接收到的对端的用户证书信息以及本端的打包公钥生成身份验证信息,并向对端发送身份验证信息。
本实施例为了在不需要改变现有网络设施设置的基础上,实现安全可靠的密钥协商,因此采用提高参与密钥协商的各终端身份验证的可靠性来提高密钥协商的安全性。提高参与密钥协商的各终端身份验证的前提就是提供用于验证身份的身份验证信息,身份验证信息的可靠是后续进行身份验证的可靠性的基础。因此,本实施例中为了提高身份验证信息的可靠性,通过对端的用户证书信息以及本端的打包公钥来生成身份验证信息。即采用进行密钥协商的双方信息组成身份验证信息。也就是说通过二维信息来提高后续身份验证的维度。
本步骤中本端在接收到对端的用户证书信息后,利用对端的用户证书信息以及本端的打包公钥这两维不易伪造的信息生成身份验证信息,并在得到身份验证信息后向对端发送该身份验证信息。本实施例中并不限定生成身份验证信息的具体方式,只要生成的身份验证信息中包含有这两维信息即可。例如分别将对端的用户证书信息以及本端的打包公钥进行加密后组成身份验证信息。也可以是将本端的打包公钥加密后连接用户证书信息生成身份验证信息。也可以是将本端的打包公钥的哈希值加密后连接用户证书信息生成身份验证信息。也可以是将本端的打包公钥加密后连接用户证书信息中选定的关键信息(如序列号信息)生成身份验证信息。
当然,本实施例中也不会限定具体的加密方式,只要参与本次密钥协商的各个终端均使用同样的方式进行加密即可。例如利用参与本次密钥协商的各个终端的共享密钥对本端的打包公钥加密;或者是利用本端的密码卡身份私钥对本端的打包公钥加密。其中,本实施例中并不限定共享密钥或者本端的密码卡身份私钥的生成方式。例如本端的密码卡身份私钥可以是在本端中的密码卡初始化的过程中产生。本实施例提供的一个实现过程可以如下:本端的密码卡初始化产生密码设备的安全机制参数SP和密码卡身份公私钥对T_PK/T_SK,并将密码卡身份公钥T_PK上传到服务器,服务器向本端密码卡注入服务器证书签发公钥C_PK和根据密码卡身份公钥产生的证书CERT1,即本端密码卡中可以存储的安全机制参数SP、密码卡身份私钥T_SK、服务器证书签发公钥C_PK和密码卡的身份证书CERT1。
步骤S103、对接收到的对端的身份验证信息进行身份验证操作。
本步骤中本端在接收到对端发送的对端产生的身份验证信息后,需要对该身份验证信息进行身份验证操作,以便判断进行密钥协商的各终端是否合法,当身份验证均通过时,即参与密钥协商的各终端均合法,此时就可以保证后续交互过程的安全性。继而可以实现即便在开放性网络的环境中也能够执行本实施例中身份验证过程进而保证密钥协商的安全性;降低了密钥协商对网络环境以及专业密管设备的要求,提高了密钥协商的适应性和便捷性。
本实施例中并不对身份验证操作的具体过程进行限定,即该身份验证操作需要与步骤S102中生成身份验证信息的方式相适应。也就是说可以根据步骤S102中生成身份验证信息的方式确定身份验证操作的方式。当然由于身份验证信息中包含两维的信息,当身份验证操作是将两者分开验证时,为了保证身份验证操作的可靠性,在这两维信息的验证全部通过时,认为对端的身份验证通过。
例如生成身份验证信息的方式为:将对端的用户证书信息以及本端的打包公钥进行加密后组成身份验证信息时,身份验证操作的方式可以是:首先利用相应的解密算法对身份验证信息进行解密得到本端的用户证书信息以及对端的打包公钥,并可以根据本端的准确的用户证书信息来验证解密得到本端的用户证书信息是否正确,并验证对端的打包公钥是否正确;只要在均正确时,才能确定身份验证通过。可以理解的是,由于本端在生成身份验证信息时,使用的是对端的用户证书信息以及本端的打包公钥,因此对端接收到该身份验证信息时,里面的对端的用户证书信息也就是对端自己的用户证书信息,本端的打包公钥也就是对端对应的对端的打包公钥。此时站在接收端的角度其得到的身份验证信息中的内容就是本端的用户证书信息以及对端的打包公钥。生成身份验证信息的方式为:将本端的打包公钥加密后连接用户证书信息生成身份验证信息时,身份验证操作的方式可以是:首先利用相应的解密算法对身份验证信息进行解密得到对端的打包公钥,并可以根据本端的准确的用户证书信息来验证身份验证信息中的本端的用户证书信息是否正确,并验证对端的打包公钥是否正确;只要在均正确时,才能确定身份验证通过。
步骤S104、若身份验证通过,利用对端的打包公钥生成会话秘钥生成信息,并向对端发送会话秘钥生成信息。
本步骤中本端在验证对端身份信息通过后,会向对端发送会话秘钥生成信息。本实施例并不对会话秘钥生成信息的内容进行限定,其可以根据参与密钥协商的各个终端使用的会话秘钥生成算法相关。当然,为了提高会话秘钥生成信息以及会话秘钥的可靠性和安全性;在会话秘钥生成信息的生成过程中需要对端的打包公钥参与,进而能够避免中间人攻击,以保证密钥协商的安全性。本实施例并不对利用对端的打包公钥生成会话秘钥生成信息的具体过程进行限定。
例如当使用的会话秘钥生成算法为zuc算法(即祖冲之算法)时,该会话秘钥生成信息包含随机数和向量数据。当会话秘钥生成算法为zuc算法时,本实施例提供的一个实现过程可以如下:生成第一随机数以及第一向量数据;利用对端的打包公钥对第一随机数和第一向量数据进行加密,得到会话秘钥生成信息;向对端发送会话秘钥生成信息。在发送该第一随机数以及第一向量数据时,利用对端的打包公钥对第一随机数和第一向量数据进行加密可以保证第一随机数和第一向量数据的安全性。
当然,本实施例中并不对身份验证不通过的情况所要执行的操作进行限定。例如可以是直接终止本次密钥协商。也可以是在终止本次密钥协商的基础上产生提示信息。
步骤S105、利用接收到的对端发送的会话秘钥生成信息生成会话秘钥。
本步骤中本端在接收到对端发送的对端生成的会话秘钥生成信息,生成本端对应的会话秘钥。可以理解的是,本实施例中并不对利用会话秘钥生成信息生成会话秘钥的过程进行限定,其需要根据参与密钥协商的各个终端使用的会话秘钥生成算法确定。当会话秘钥生成算法为zuc算法时,本实施例提供的一个实现过程可以如下:利用本端的打包私钥对接收到的对端发送的会话秘钥生成信息进行解密,得到第二随机数以及第二向量数据(此时,本端将对端生成的第一随机数以及第一向量数据称为第二随机数以及第二向量数据,也就是本端在接收到对端发送的会话秘钥生成信息时对其进行解密,得到对端利用本端的打包公钥进行加密的第一随机数以及第一向量数据。也就是对端利用本端的打包公钥对对端生成的第一随机数x以及第一向量数据y进行加密得到会话秘钥生成信息,本端利用本端的打包公钥对该会话秘钥生成信息进行解密得到第一随机数x以及第一向量数据y,此时本端将得到的第一随机数x以及第一向量数据y称为第二随机数以及第二向量数据,这样只是为了后续便于理解各端进行数据处理的具体过程);将第一随机数和第二随机数进行第一运算,生成会话秘钥;将第一向量数据和第二向量数据进行第一运算,生成会话秘钥对应的初始向量。本实施例并不对第一运算进行限定。例如可以是运算过程简单的异或运算。此时由于会话秘钥生成与本次密钥协商产生的随机数即向量数据相关,即通过随机数来使得会话密钥不重复。因此可以保证会话密钥一次一密,通话结束即销毁。若中间人使用历史协商数据进行攻击,双方有感从而可结束协商。
在参与密钥协商的各个终端都成功得到会话秘钥后就完成了密钥协商过程。可见,本实施例中仅通过一种新的身份验证过程就可以安全可靠的完成整个密钥协商过程,整个过程不需要对网络进行重新设置,也不需要依赖后台密管。
需要说明的是,本实施例中不对参与密钥协商的各个终端所处的网络进行限定,只要处于该网络中可以实现上述功能即可。
通过上述技术方案,利用进行密钥协商的双方信息(即对端的用户证书信息和本端的打包公钥)组成身份验证信息,不仅包含用户证书信息还包含打包公钥,相当于在密钥交换协议中加入数字签名和公钥证书来完成对对方身份的认证,因此可以避免中间人攻击,以保障密钥协商的安全性;相对于通过提高通信信道传输要求或者通过后台密管的方式,能够不依赖于核心网络设施或者额外的专业设备,即便在开放性网络的环境中也能够执行本公开中的身份验证过程进而保证密钥协商的安全性以及实现安全的通信;降低了对网络环境以及专业密管设备的要求,提高了密钥协商的适应性和便捷性。且在生成会话秘钥生成信息时利用了对端的打包公钥,进一步提高了会话秘钥生成信息的可靠性,进而提升了会话秘钥的可靠性和安全性,能够避免中间人攻击,以保证密钥协商的安全性。
本实施例中可以进一步提高密钥协商的可靠性,请参考图2,图2是根据另一示例性实施例示出的一种密钥协商方法的流程图;应用于任一终端,可以包括:
步骤S201、向对端发送用户证书信息。
步骤S202、利用接收到的对端的用户证书信息以及本端的打包公钥生成身份验证信息,并向对端发送身份验证信息。
步骤S203、对接收到的对端的身份验证信息进行身份验证操作。
步骤S204、若身份验证通过,向对端发送会话秘钥生成信息。
步骤S205、利用接收到的对端发送的会话秘钥生成信息生成会话秘钥。
步骤S206、验证会话秘钥的正确性。
本实施例中为了进一步提高密钥协商的可靠性,在计算得到会话秘钥后还需要对得到的会话秘钥的正确性进行验证。进而确保最终得到的会话秘钥准确无误,以此来进一步提高密钥协商的可靠性。本实施例中并不对具体的会话秘钥的验证方式进行限定。例如可以对已经得到的会话秘钥进行先关操作得到会话秘钥验证信息,再将其发送给对端,进而每个终端就可以对其得到的会话秘钥验证信息进行验证。
当然,本实施例中并不限定具体会话秘钥验证信息的生成方式。例如可以是生成第三随机数;利用本端的会话秘钥和对应的初始向量加密第三随机数,形成会话秘钥验证信息。此时并不对加密第三随机数的方式进行限定。例如可以是利用本端的会话秘钥和对应的初始向量加密第三随机数,形成第一验证信息;将第一验证信息连接第三随机数的哈希值形成会话秘钥验证信息。该过程中不仅对第三随机数进行加密,为了保证后续验证的可靠性,还在会话秘钥验证信息中增加了不易篡改的第三随机数的哈希值,进而可以保证生成的会话秘钥验证信息的可靠性和安全性,也就能够保证后续验证过程的可靠性。本实施例中并不限定第一验证信息连接第三随机数的哈希值的形式。例如可以直接两者放在一起,整体作为会话秘钥验证信息,此时可以不对两者连接的顺序进行限定。也可以是利用一些符号将两者连接起来后作为会话秘钥验证信息。
可以理解的是,由于本实施例并不限定会话秘钥验证信息的生成方式,对应就不会限定验证会话秘钥的正确性的方式。其与会话秘钥验证信息的生成过程相适应。例如当利用本端的会话秘钥和对应的初始向量加密第三随机数,形成会话秘钥验证信息时,对应的验证会话秘钥的正确性的方式可以是:接收对端发送的会话秘钥验证信息;利用本端的会话秘钥和对应的初始向量,解密会话秘钥验证信息;若解密结果正确,则该会话秘钥正确。此时,利用本端的会话秘钥和对应的初始向量对会话秘钥验证信息进行解密的过程与利用本端的会话秘钥和对应的初始向量加密第三随机数的加密过程相对应。
通过上述技术方案,通过对会话秘钥的正确性进行验证,可以防止攻击者截获历史正确的报文进行重放攻击,可以进一步增强密钥协商的可靠性。可见,本实施例安全性高,由于添加会话密钥的校验过程和一次一密的随机过程,所以本方案可抗击加密消息的前向和后向安全。
本实施例可以进一步增强密钥协商的可靠性以及密钥协商的效率,本实施例在上述任意实施例的基础上还可以包括:
若接收到对端发送的版本信息,判断本端是否支持版本信息对应的版本;
若本端不支持所述版本信息对应的版本,则终止密钥协商。
本实施例中主要是通过比较需要进行密钥协商的各个终端的版本信息是否一致或者能够相互支持。其目的是为了在需要进行密钥协商的各个终端的版本信息不一致或者不能够相互支持时,尽早终止本次密钥协商,提高密钥协商的效率。进一步,防止出现由于需要进行密钥协商的各个终端的版本信息不一致或者不能够相互支持,导致的后续密钥协商的错误,进而提高密钥协商的可靠性。
本实施例中并不限定版本信息的内容。例如版本信息可以包含协商版本号,或者是密码套件信息,或者是协商版本号和密码套件信息。对应的本实施例也不限定判断本端是否支持版本信息对应的版本的过程,其需要和具体选定的版本信息的内容适应性的确定。例如当版本信息为协商版本号时,判断对端的协商版本号和本端的协商版本号是否一致。当版本信息为密码套件信息时,判断对端的密码套件信息和本端的密码套件信息是否相互支持。当版本信息为协商版本号和密码套件信息时,需要本端的协商版本号和密码套件信息均与对端的协商版本号和密码套件信息相互支持。
进一步,本实施例中并不限定执行判断本端是否支持版本信息对应的版本的顺序。例如该步骤可以在上述实施例中步骤S102之前执行,当然也可以是在上述实施例中步骤S101之前执行。一般来说,为了提高密钥协商的效率,越早确定本端和对端的版本信息是否相互支持越好。当然,本实施例中版本信息可以是和用户证书信息一起发出。
通过上述技术方案,通过比较需要进行密钥协商的各个终端的版本信息是否一致或者能够相互支持,进一步增强密钥协商的可靠性以及密钥协商的效率。
本实施例在上述任意实施例的基础上,请参考图3和图4,当任一终端均向对端发送用户证书信息为用户证书信息时,利用接收到的对端的用户证书信息以及本端的打包公钥生成身份验证信息可以包括:
步骤S301、解析接收到的对端的用户证书序列号,得到解析结果。
本实施例中之所以采用用户证书序列号是因为其数据量相比较完整的用户证书数据来说小了很多。因此针对小数据量的用户证书序列号,无论是在数据传输方面,还是在后续验证过程都提高了数据处理效率。
本实施例中并不对具体的解析过程进行限定,其可以根据具体的用户证书序列号的种类进行确定,只要可以得到解析结果即可。
步骤S302、按照预设提取规则,从解析结果中提取对应的序列号信息作为证书验证信息。
本实施例中并不对预设提取规则进行限定。例如预设提取规则可以是全部提取,即将解析结果整体作为证书验证信息。当然也可以是仅提取出用户证书序列号中的区别数据,即将解析结果中的部分内容作为证书验证信息。可以根据终端中硬件的计算能力来确定预设提取规则。
步骤S303、利用预设私钥对本端的打包公钥的哈希值进行签名得到签名信息。
本实施例中并不对预设私钥进行限定。例如可以是参与密钥协商的各个终端对应的共享私钥。也可以是本端的密码卡身份私钥。例如利用本端的密码卡身份私钥对本端的打包公钥的哈希值进行签名得到签名信息。
本实施例中不不对哈希值计算方式以及签名的方式进行限定,只要可以计算得到本端的打包公钥的哈希值,以及利用预设私钥对本端的打包公钥的哈希值进行签名得到签名信息即可。由于哈希值以及签名的不可篡改性,因此对本端的打包公钥的哈希值进行签名的方式提高了本端的打包公钥的可靠性。
步骤S304、将打包公钥和签名信息作为签名验证信息。
本实施例中并不限定打包公钥和签名信息作为签名验证信息的形式。例如可以直接两者放在一起,整体作为签名验证信息,如将打包公钥连接签名信息组成签名验证信息,此时可以不对两者连接的顺序进行限定。也可以是利用一些符号将两者连接起来后作为签名验证信息。
步骤S305、将证书验证信息连接签名验证信息生成身份验证信息。
本实施例中并不限定证书验证信息连接签名验证信息的形式。例如可以直接两者放在一起,整体作为身份验证信息,此时可以不对两者连接的顺序进行限定。也可以是利用一些符号将两者连接起来后作为身份验证信息。
对应的,对接收到的对端的身份验证信息进行身份验证操作可以包括:
步骤S401、接收对端的身份验证信息。
步骤S402、验证接收到的对端的身份验证信息中的证书验证信息是否与本端的用户证书信息一致;若是进入步骤S403,若否进入步骤S406。
本步骤中要验证接收到的证书验证信息是否与本端的用户证书信息一致。本实施例中并不限定具体验证过程,通常是比较证书验证信息中的数据与本端的用户证书信息(这里的用户证书信息可以指用户证书序列号)中对应数据是否一致。例如验证证书验证信息对应的证书数据是否与本端的用户证书信息中相应部分完全一致,若一致则该步骤的验证通过。或者是验证证书验证信息对应签发的CA是否与本端的用户证书信息对应签发的CA一致,若一致则该步骤的验证通过。或者是同时验证证书验证信息对应的证书数据是否与本端的用户证书信息中相应部分完全一致以及验证证书验证信息对应签发的CA是否与本端的用户证书信息对应签发的CA一致(这里两个验证的顺序可以不限定,即可以同时验证,可以先验证前者并在验证通过后再验证后者),当两个验证均一致时则该步骤的验证通过。
步骤S403、验证证书验证信息里的标识信息是否与本端的标识信息一致;若是进入步骤S404,若否进入步骤S406。
本步骤中为了进一步提高身份验证的可靠性,还可以验证证书验证信息里的标识信息是否与本端的标识信息一致。本实施例中并不对标识信息的内容进行限定。例如可以是电话号码,也可以是邮箱地址,也可以是终端IP等,当然也可以是它们的任意组合。当标识信息为电话号码时,验证证书验证信息里的标识信息是否与本端的标识信息一致可以是:验证证书验证信息里的电话号码是否与本端的电话号码一致。且此时可以实现在移动通信信道中,通过替换语音帧,来完成密钥协商。
步骤S404、验证身份验证信息中的签名信息是否正确;若是进入步骤S405,若否进入步骤S406。
本步骤中要验证身份验证信息中的签名信息是否正确。本实施例并不限定身份验证信息中的签名信息的验证方式,其与签名信息具体的获取方式相关。例如当签名信息是通过密码卡身份私钥对打包公钥的哈希值进行签名得到的,此时可以通过用户证书信息中的公钥来进行解密,并在解密后执行验证过程。
步骤S405、则身份验证通过。
步骤S406、则终止密钥协商。
当然本实施例并不限定步骤S402至步骤S404的执行顺序。只要这三个验证过程均执行即可。无论执行顺序如何,都是前一个验证过程通过,才能执行后一个验证过程。还要存在验证不通过的情况,就会执行步骤S406来终止密钥协商。当然也可以在终止密钥协商的基础上进行提示(本实施例并不对该提示的方式以及提示内容进行限定,其中,提示方式可以是语音提示,也可以是字符提示或者是声音提示等)。
通过上述技术方案,通过用户证书序列号替换用户证书信息,增强密钥协商的数据传输及处理效率。又通过证书验证信息连接签名验证信息生成身份验证信息方式,同时实现降低数据量,以及提高生成的身份验证信息的可靠性。进一步,通过对身份验证信息的多重验证过程来提高身份验证操作的可靠性,进而增强密钥协商的可靠性。
本实施例提供了一种详细的端到端的密钥协商方案,具体过程如下:可以理解的是,下述每两两的步骤的执行顺序并不进行限定,例如步骤1和步骤2可以改变顺序。为了更加方便对于本实施例的了解,本实施例中将上述各个实施例中任一终端(本实施例中具体为两个终端,可以理解为任一终端为终端一和终端二)均需要做的事情,分别使用主叫(终端一)和被叫(终端二)来执行。
步骤1:被叫将协商版本号、本端的用户证书序列号以及密码套件信息组成Message1;被叫向主叫发送密钥协商消息Message1。
步骤2:主叫将协商版本号、本端的用户证书序列号以及密码套件信息组成Message2;主叫向被叫发送密钥协商消息Message2。
步骤3:被叫在收到主叫的Message2后,对Message2进行协商版本号和加密套件信息验证,若任一项本端不支持,则终止密钥协商;对主叫的Message2消息中的用户证书序列号进行解析,确认被叫需要发送的身份验证信息Message3的第一部分Part1(即证书验证信息),同时使用被叫密码卡中存储的密码卡身份私钥T_SK1对本端的打包公钥T_PKWRAP1进行签名,形成签名Sign1(即签名信息),T_PKWRAP1连接Sign1作为Message3的第二部分Part2(即签名验证信息),将Part1连接Part2作为Message3(即被叫生成的身份验证信息)发送给主叫。
步骤4:主叫在收到被叫的Message1后,对Message1进行协商版本号和加密套件信息验证,若任一项本端不支持,则终止密钥协商;对被叫的Message1消息中的用户证书序列号进行解析,确认主叫需要发送的身份验证信息Message4的第一部分Part1(即证书验证信息),同时使用被叫密码卡中存储的密码卡身份私钥T_SK2对本端的打包公钥T_PKWRAP2进行签名,形成签名Sign2(即签名信息),T_PKWRAP2连接Sign2作为Message4的第二部分Part2(即签名验证信息),将Part1连接Part2作为Message4(即主叫生成的身份验证信息)发送给被叫。
步骤5:被叫在收到主叫的Message4后,验证Message4的Part1部分的证书数据是否为本端应该接收的全部证书链,若不全或错误则终止协商;其次,验证证书验证信息中证书是否与本端为同一个CA签发,否则终止协商;然后,验证证书验证信息中的通信号码是否与本端的通信号码保持一致,否则终止协商;其次验证Message4的Part2部分的打包公钥签名是否正确,否则终止协商;被叫在验证Message4通过后,产生被叫的第一随机数Rand1和第一向量数据IV1,连接Rand1和IV1,使用主叫端的T_PKWRAP2加密得到Message5(即被叫生成的会话秘钥生成信息);将Message5发送给主叫。
步骤6:主叫在收到主叫的Message3后,验证Message3的Part1部分的证书数据是否为本端应该接收的全部证书链,若不全或错误则终止协商;其次,验证证书验证信息中证书是否与本端为同一个CA签发,否则终止协商;然后,验证证书验证信息中的通信号码是否与本端的通信号码保持一致,否则终止协商;其次验证Message3的Part2部分的打包公钥签名是否正确,否则终止协商;主叫在验证Message3通过后,产生主叫的第一随机数Rand2和第一向量数据IV2,连接Rand2和IV2,使用被叫端的T_PKWRAP1加密得到Message6(即主叫生成的会话秘钥生成信息);将Message6发送给被叫。
步骤7:被叫在收到主叫的Message6之后,使用本端打包私钥T_SKWRAP1进行解密,从而得到Rand2和IV2;将Rand1和Rand2进行异或计算,得到会话密钥KS1;将IV1和IV2进行异或计算,得到初始向量WK1;被叫产生第三随机数Rand3,使用KS1和WK1加密Rand3的结果作为Message7(即被叫的会话秘钥验证信息)的第一部分Part1(即第一验证信息),Rand3的哈希值作为Message7的第二部分Part2,连接Part1和Part2的Message7发送给主叫。
步骤8:主叫在收到被叫的Message5之后,使用本端打包私钥T_SKWRAP2进行解密,从而得到Rand1和IV1;将Rand1和Rand2进行异或计算,得到会话密钥KS2;将IV1和IV2进行异或计算,得到初始向量WK2;主叫产生第三随机数Rand4,使用KS2和WK2加密Rand4的结果作为Message8(即主叫的会话秘钥验证信息)的第一部分Part1(即第一验证信息),Rand4的哈希值作为Message8的第二部分Part2,连接Part1和Part2的Message8发送给被叫。
步骤9:被叫使用会话密钥KS1和初始向量WK1解密Message8,查看会话密钥正确性,错误则终止协商。
步骤10:主叫使用会话密钥KS2和初始向量WK2解密Message7,查看会话密钥正确性,错误则终止协商。
其中,步骤5和相应的步骤6的具体传输数据可以是:使用对端打包公钥打包本端32字节随机密钥产生的密文。步骤7、步骤8中使用本端打包私钥解密上述步骤5/6的密文之后,得到的32字节的明文,该32字节的明文与本端的32字节的随机数异或计算后,得到的结果为KS和IV。若会话秘钥正确性验证成功,即主叫和被叫的会话密钥相同,则可以使用会话密钥和初始向量进行双方会话的加解密过程。
本实施例中主叫和被叫可以包含密码装置例如密码卡,用来存储、产生密钥协商过程需要的公私钥、参数等。例如上述密钥协商过程中产生的密码卡身份公私钥对T_PK/T_SK;密码卡在收到终端密钥协商请求时,产生密钥协商所需的临时打包公私钥对T_PKWRAP/T_SKWRAP和随机数Rand和初始向量IV。
通过上述技术方案,本实施例中通过两个及以上的终端通过身份验证,密钥因子交换,从而计算出协商的会话密钥,用以保障密钥协商过程的安全性以及会话密钥的安全性。即带外完成明密识别等准备过程(例如用户证书信息的获取,密码卡的初始化等),带内实现密钥协商过程,不需改变现有网络设施,成本较小。而且保证了会话密钥一次一密,通话结束即销毁。若中间人使用历史协商数据进行攻击,双方有感从而可结束协商。
请参考图5,图5是根据一示例性实施例示出的一种密钥协商装置的结构框图;密钥协商装置500可以包括:
第一发送模块510,用于任一终端均向对端发送用户证书信息;
身份验证信息生成模块520,用于利用接收到的对端的用户证书信息以及本端的打包公钥生成身份验证信息;
第二发送模块530,用于向对端发送身份验证信息;
身份验证模块540,用于对接收到的对端的身份验证信息进行身份验证操作;
第三发送模块550,用于在身份验证通过时,向对端发送会话秘钥生成信息;
会话秘钥生成模块560,用于利用接收到的对端发送的会话秘钥生成信息生成会话秘钥。
通过上述技术方案,利用进行密钥协商的双方信息(即对端的用户证书信息和本端的打包公钥)组成身份验证信息,不仅包含用户证书信息还包含打包公钥,相当于在密钥交换协议中加入数字签名和公钥证书来完成对对方身份的认证,因此可以避免中间人攻击,以保障密钥协商的安全性;相对于通过提高通信信道传输要求或者通过后台密管的方式,能够不依赖于核心网络设施或者额外的专业设备,即便在开放性网络的环境中也能够执行本公开中的身份验证过程进而保证密钥协商的安全性以及实现安全的通信;降低了对网络环境以及专业密管设备的要求,提高了密钥协商的适应性和便捷性。
基于上述实施例,本实施例中还可以包括:
验证码获取模块,用于从建立安全通信信道的服务器中获取验证码;
用户证书生成参数信息发送模块,用于将用户证书生成参数信息发送给服务器,以使服务器利用用户证书生成参数信息生成用户证书信息;其中,用户证书生成参数信息包括验证码、标识信息以及密码卡序列号;
用户证书信息获取模块,用于接收服务器发送的用户证书信息。
基于上述任意实施例,本实施例还可以包括:
版本信息判断模块,用于若接收到对端发送的版本信息,判断本端是否支持版本信息对应的版本;
终止模块,用于在本端不支持版本信息对应的版本时,则终止密钥协商。
基于上述任意实施例,请参考图6,身份验证信息生成模块520可以包括:
解析单元521,用于解析接收到的对端的用户证书序列号,得到解析结果;
提取单元522,用于按照预设提取规则,从解析结果中提取对应的序列号信息作为证书验证信息;
签名单元523,用于利用预设私钥对本端的打包公钥的哈希值进行签名得到签名信息;
签名验证信息生成单元524,用于将打包公钥和签名信息作为签名验证信息;
身份验证信息生成单元525,用于将证书验证信息连接签名验证信息生成身份验证信息。
基于上述任意实施例,请参考图7,身份验证模块540可以包括:
第一验证单元541,用于验证接收到的对端的身份验证信息中的证书验证信息是否与本端的用户证书信息一致;
第二验证单元542,用于在对端的身份验证信息中的证书验证信息与本端的用户证书信息一致时,验证证书验证信息里的标识信息是否与本端的标识信息一致;
第三验证单元543,用于在证书验证信息里的标识信息与本端的标识信息一致时,验证身份验证信息中的签名信息是否正确;
执行单元544,用于在身份验证信息中的签名信息正确时,则身份验证通过;在身份验证信息中的签名信息不正确时,则终止密钥协商。
基于上述任意实施例,请参考图8,第三发送模块550可以包括:
第一生成单元551,用于生成第一随机数以及第一向量数据;
第二生成单元552,用于利用对端的打包公钥对第一随机数和第一向量数据进行加密,得到会话秘钥生成信息;
第三发送单元553,用于向对端发送会话秘钥生成信息。
基于上述实施例,请参考图9,会话秘钥生成模块560可以包括:
解密单元561,用于利用本端的打包私钥对接收到的对端发送的会话秘钥生成信息进行解密,得到第二随机数以及第二向量数据;
会话秘钥生成单元562,用于将第一随机数和第二随机数进行第一运算,生成会话秘钥;
初始向量生成单元563,用于将第一向量数据和第二向量数据进行第一运算,生成会话秘钥对应的初始向量。
基于上述任意实施例,请参考图10,图10是根据另一示例性实施例示出的一种密钥协商装置的结构框图;密钥协商装置还可以包括:
验证模块570,用于验证会话秘钥的正确性。
基于上述实施例,请参考图11,验证模块570可以包括:
会话秘钥验证信息接收单元571,用于接收对端发送的会话秘钥验证信息;
会话秘钥验证信息验证单元572,用于利用本端的会话秘钥和对应的初始向量,解密会话秘钥验证信息;若解密结果正确,则会话秘钥正确。
基于上述实施例,还可以包括:
会话秘钥验证信息生成模块,用于生成第三随机数;利用本端的会话秘钥和对应的初始向量加密第三随机数,形成会话秘钥验证信息。
基于上述实施例,会话秘钥验证信息生成模块可以包括:
第一验证信息生成单元,用于利用本端的会话秘钥和对应的初始向量加密第三随机数,形成第一验证信息;
会话秘钥验证信息生成单元,用于将第一验证信息连接第三随机数的哈希值形成会话秘钥验证信息。
通过上述技术方案,本实施例中通过两个及以上的终端通过身份验证,密钥因子交换,从而计算出协商的会话密钥,用以保障密钥协商过程的安全性以及会话密钥的安全性。即带外完成明密识别等准备过程(例如用户证书信息的获取,密码卡的初始化等),带内实现密钥协商过程,不需改变现有网络设施,成本较小。而且保证了会话密钥一次一密,通话结束即销毁。若中间人使用历史协商数据进行攻击,双方有感从而可结束协商。
关于上述实施例中的密钥协商装置,其中各个模块和单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述,此处将不做详细阐述说明。
图12是根据一示例性实施例示出的一种终端1200的框图。如图12所示,该终端1200可以包括:处理器1201,存储器1202。该终端1200还可以包括多媒体组件1203,输入/输出(I/O)接口1204,以及通信组件1205中的一者或多者。本实施例中终端还可以包含密码装置例如密码卡,用来存储、产生密钥协商过程需要的公私钥、参数等。
其中,处理器1201用于控制该终端1200的整体操作,以完成上述的密钥协商方法中的全部或部分步骤。存储器1202用于存储各种类型的数据以支持在该终端1200的操作,这些数据例如可以包括用于在该终端1200上操作的任何应用程序或方法的指令,以及应用程序相关的数据,例如联系人数据、收发的消息、图片、音频、视频等等。该存储器1202可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,例如静态随机存取存储器(Static Random Access Memory,简称SRAM),电可擦除可编程只读存储器(ElectricallyErasable Programmable Read-Only Memory,简称EEPROM),可擦除可编程只读存储器(Erasable Programmable Read-Only Memory,简称EPROM),可编程只读存储器(Programmable Read-Only Memory,简称PROM),只读存储器(Read-Only Memory,简称ROM),磁存储器,快闪存储器,磁盘或光盘。多媒体组件1203可以包括屏幕和音频组件。其中屏幕例如可以是触摸屏,音频组件用于输出和/或输入音频信号。例如,音频组件可以包括一个麦克风,麦克风用于接收外部音频信号。所接收的音频信号可以被进一步存储在存储器1202或通过通信组件1205发送。音频组件还包括至少一个扬声器,用于输出音频信号。I/O接口1204为处理器1201和其他接口模块之间提供接口,上述其他接口模块可以是键盘,鼠标,按钮等。这些按钮可以是虚拟按钮或者实体按钮。通信组件1205用于该终端1200与其他设备之间进行有线或无线通信。无线通信,例如Wi-Fi,蓝牙,近场通信(Near FieldCommunication,简称NFC),2G、3G或4G,或它们中的一种或几种的组合,因此相应的该通信组件1205可以包括:Wi-Fi模块,蓝牙模块,NFC模块。
在一示例性实施例中,终端1200可以被一个或多个应用专用集成电路(Application Specific Integrated Circuit,简称ASIC)、数字信号处理器(DigitalSignal Processor,简称DSP)、数字信号处理设备(Digital Signal Processing Device,简称DSPD)、可编程逻辑器件(Programmable Logic Device,简称PLD)、现场可编程门阵列(Field Programmable Gate Array,简称FPGA)、控制器、微控制器、微处理器或其他电子元件实现,用于执行上述的密钥协商方法。
在另一示例性实施例中,还提供了一种包括程序指令的计算机可读存储介质,该程序指令被处理器执行时实现上述的密钥协商方法的步骤。例如,该计算机可读存储介质可以为上述包括程序指令的存储器1202,上述程序指令可由终端1200的处理器1201执行以完成上述的密钥协商方法。
以上结合附图详细描述了本公开的优选实施方式,但是,本公开并不限于上述实施方式中的具体细节,在本公开的技术构思范围内,可以对本公开的技术方案进行多种简单变型,这些简单变型均属于本公开的保护范围。
另外需要说明的是,在上述具体实施方式中所描述的各个具体技术特征,在不矛盾的情况下,可以通过任何合适的方式进行组合,例如降低一个实施例和第二个实施例结合,为了避免不必要的重复,本公开对各种可能的组合方式不再另行说明。
此外,本公开的各种不同的实施方式之间也可以进行任意组合,只要其不违背本公开的思想,其同样应当视为本公开所公开的内容。
Claims (11)
1.一种密钥协商方法,其特征在于,应用于任一终端,包括:
任一终端均向对端发送用户证书信息;
利用接收到的对端的用户证书信息以及本端的打包公钥生成身份验证信息,并向对端发送所述身份验证信息;
对接收到的对端的身份验证信息进行身份验证操作;
若身份验证通过,利用对端的打包公钥生成会话秘钥生成信息,并向对端发送所述会话秘钥生成信息;
利用接收到的对端发送的会话秘钥生成信息生成会话秘钥。
2.根据权利要求1所述的密钥协商方法,其特征在于,所述任一终端均向对端发送用户证书信息之前,还包括:
从建立安全通信信道的服务器中获取验证码;
将用户证书生成参数信息发送给所述服务器,以使所述服务器利用所述用户证书生成参数信息生成用户证书信息;其中,所述用户证书生成参数信息包括所述验证码、标识信息以及密码卡序列号;
接收所述服务器发送的所述用户证书信息。
3.根据权利要求1所述的密钥协商方法,其特征在于,还包括:
若接收到对端发送的版本信息,判断本端是否支持所述版本信息对应的版本;
若本端不支持所述版本信息对应的版本,则终止密钥协商。
4.根据权利要求1-3任一项所述的密钥协商方法,其特征在于,当所述用户证书信息为用户证书序列号时,所述利用接收到的对端的用户证书信息以及本端的打包公钥生成身份验证信息,包括:
解析接收到的对端的用户证书序列号,得到解析结果;
按照预设提取规则,从所述解析结果中提取对应的序列号信息作为证书验证信息;
利用预设私钥对本端的打包公钥的哈希值进行签名得到签名信息;
将所述打包公钥和所述签名信息作为签名验证信息;
将所述证书验证信息连接所述签名验证信息生成身份验证信息。
5.根据权利要求4所述的密钥协商方法,其特征在于,所述对接收到的对端的身份验证信息进行身份验证操作,包括:
验证接收到的对端的身份验证信息中的证书验证信息是否与本端的用户证书信息一致;
若对端的身份验证信息中的证书验证信息与本端的用户证书信息一致,验证所述证书验证信息里的标识信息是否与本端的标识信息一致;
若所述证书验证信息里的标识信息与本端的标识信息一致,验证所述身份验证信息中的签名信息是否正确;
若所述身份验证信息中的签名信息正确,则身份验证通过。
6.根据权利要求1所述的密钥协商方法,其特征在于,所述利用对端的打包公钥生成会话秘钥生成信息,并向对端发送所述会话秘钥生成信息,包括:
生成第一随机数以及第一向量数据;
利用对端的打包公钥对所述第一随机数和所述第一向量数据进行加密,得到会话秘钥生成信息;
向对端发送所述会话秘钥生成信息。
7.根据权利要求6所述的密钥协商方法,其特征在于,所述利用接收到的对端发送的会话秘钥生成信息生成会话秘钥,包括:
利用本端的打包私钥对接收到的对端发送的会话秘钥生成信息进行解密,得到第二随机数以及第二向量数据;
将所述第一随机数和所述第二随机数进行第一运算,生成会话秘钥;
将所述第一向量数据和所述第二向量数据进行所述第一运算,生成所述会话秘钥对应的初始向量。
8.根据权利要求1所述的密钥协商方法,其特征在于,所述利用接收到的对端发送的会话秘钥生成信息生成会话秘钥之后,还包括:
接收对端发送的会话秘钥验证信息;
利用本端的会话秘钥和对应的初始向量,解密所述会话秘钥验证信息;
若解密结果正确,则所述会话秘钥正确;
其中,所述会话秘钥验证信息的生成方法,包括:
生成第三随机数;
利用本端的会话秘钥和对应的初始向量加密所述第三随机数,形成第一验证信息;
将所述第一验证信息连接所述第三随机数的哈希值形成会话秘钥验证信息。
9.一种密钥协商装置,其特征在于,应用于任一终端,包括:
第一发送模块,用于任一终端均向对端发送用户证书信息;
身份验证信息生成模块,用于利用接收到的对端的用户证书信息以及本端的打包公钥生成身份验证信息;
第二发送模块,用于向对端发送所述身份验证信息;
身份验证模块,用于对接收到的对端的身份验证信息进行身份验证操作;
第三发送模块,用于在身份验证通过时,利用对端的打包公钥生成会话秘钥生成信息,并向对端发送所述会话秘钥生成信息;
会话秘钥生成模块,用于利用接收到的对端发送的会话秘钥生成信息生成会话秘钥。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现权利要求1-8中任一项所述方法的步骤。
11.一种终端,其特征在于,包括:
存储器,其上存储有计算机程序;
处理器,用于执行所述存储器中的所述计算机程序,以实现权利要求1-8中任一项所述方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811414131.9A CN109462476B (zh) | 2018-11-23 | 2018-11-23 | 密钥协商方法、装置、终端及计算机可读存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811414131.9A CN109462476B (zh) | 2018-11-23 | 2018-11-23 | 密钥协商方法、装置、终端及计算机可读存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109462476A true CN109462476A (zh) | 2019-03-12 |
CN109462476B CN109462476B (zh) | 2021-10-08 |
Family
ID=65611598
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811414131.9A Active CN109462476B (zh) | 2018-11-23 | 2018-11-23 | 密钥协商方法、装置、终端及计算机可读存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109462476B (zh) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110189486A (zh) * | 2019-05-24 | 2019-08-30 | 上海银行股份有限公司 | 自助机具密钥自动下发方法 |
CN110768795A (zh) * | 2019-10-30 | 2020-02-07 | 迈普通信技术股份有限公司 | 一种会话建立方法及装置 |
CN111614621A (zh) * | 2020-04-20 | 2020-09-01 | 深圳奇迹智慧网络有限公司 | 物联网通信方法和系统 |
CN111639353A (zh) * | 2020-05-26 | 2020-09-08 | 浙江大华技术股份有限公司 | 一种数据管理方法、装置、嵌入式设备及存储介质 |
CN111818483A (zh) * | 2020-06-29 | 2020-10-23 | 郑州信大捷安信息技术股份有限公司 | 一种基于5g的v2v车联网通信系统及方法 |
CN112003697A (zh) * | 2020-08-25 | 2020-11-27 | 成都卫士通信息产业股份有限公司 | 密码模块加解密方法、装置、电子设备及计算机存储介质 |
CN112019351A (zh) * | 2020-09-03 | 2020-12-01 | 杭州天宽科技有限公司 | 基于SDKey的移动终端信息交互方法 |
CN112422275A (zh) * | 2020-10-26 | 2021-02-26 | 深圳Tcl新技术有限公司 | Uart通信中的秘钥协商方法、系统、设备及计算机存储介质 |
CN112468470A (zh) * | 2020-11-16 | 2021-03-09 | 北京字节跳动网络技术有限公司 | 数据传输方法、装置和电子设备 |
CN112861156A (zh) * | 2021-02-26 | 2021-05-28 | 上海升途智能系统有限公司 | 显示数据的安全通信方法、装置、电子设备及存储介质 |
CN113300832A (zh) * | 2020-02-21 | 2021-08-24 | 阿里巴巴集团控股有限公司 | 通信链接的建立方法、装置、存储介质、处理器及系统 |
CN114070550A (zh) * | 2020-07-31 | 2022-02-18 | 马上消费金融股份有限公司 | 一种信息处理方法、装置、设备和存储介质 |
CN114499848A (zh) * | 2022-01-26 | 2022-05-13 | 无锡融卡科技有限公司 | 会话密钥生成装置及方法 |
WO2023185936A1 (zh) * | 2022-03-31 | 2023-10-05 | 阿里云计算有限公司 | 用于云网络系统的通信方法、装置、系统及存储介质 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020166048A1 (en) * | 2001-05-01 | 2002-11-07 | Frank Coulier | Use and generation of a session key in a secure socket layer connection |
CN101431415A (zh) * | 2008-12-12 | 2009-05-13 | 天柏宽带网络科技(北京)有限公司 | 一种双向认证的方法 |
US20160330179A1 (en) * | 2015-05-06 | 2016-11-10 | Samsung Sds Co., Ltd. | System and method for key exchange based on authentication information |
CN106506470A (zh) * | 2016-10-31 | 2017-03-15 | 大唐高鸿信安(浙江)信息科技有限公司 | 网络数据安全传输方法 |
CN106603485A (zh) * | 2016-10-31 | 2017-04-26 | 美的智慧家居科技有限公司 | 密钥协商方法及装置 |
CN107959656A (zh) * | 2016-10-14 | 2018-04-24 | 阿里巴巴集团控股有限公司 | 数据安全保障系统及方法、装置 |
-
2018
- 2018-11-23 CN CN201811414131.9A patent/CN109462476B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020166048A1 (en) * | 2001-05-01 | 2002-11-07 | Frank Coulier | Use and generation of a session key in a secure socket layer connection |
CN101431415A (zh) * | 2008-12-12 | 2009-05-13 | 天柏宽带网络科技(北京)有限公司 | 一种双向认证的方法 |
US20160330179A1 (en) * | 2015-05-06 | 2016-11-10 | Samsung Sds Co., Ltd. | System and method for key exchange based on authentication information |
CN107959656A (zh) * | 2016-10-14 | 2018-04-24 | 阿里巴巴集团控股有限公司 | 数据安全保障系统及方法、装置 |
CN106506470A (zh) * | 2016-10-31 | 2017-03-15 | 大唐高鸿信安(浙江)信息科技有限公司 | 网络数据安全传输方法 |
CN106603485A (zh) * | 2016-10-31 | 2017-04-26 | 美的智慧家居科技有限公司 | 密钥协商方法及装置 |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110189486A (zh) * | 2019-05-24 | 2019-08-30 | 上海银行股份有限公司 | 自助机具密钥自动下发方法 |
CN110768795A (zh) * | 2019-10-30 | 2020-02-07 | 迈普通信技术股份有限公司 | 一种会话建立方法及装置 |
CN113300832A (zh) * | 2020-02-21 | 2021-08-24 | 阿里巴巴集团控股有限公司 | 通信链接的建立方法、装置、存储介质、处理器及系统 |
CN111614621A (zh) * | 2020-04-20 | 2020-09-01 | 深圳奇迹智慧网络有限公司 | 物联网通信方法和系统 |
CN111614621B (zh) * | 2020-04-20 | 2022-09-06 | 深圳奇迹智慧网络有限公司 | 物联网通信方法和系统 |
CN111639353A (zh) * | 2020-05-26 | 2020-09-08 | 浙江大华技术股份有限公司 | 一种数据管理方法、装置、嵌入式设备及存储介质 |
CN111639353B (zh) * | 2020-05-26 | 2023-08-11 | 浙江大华技术股份有限公司 | 一种数据管理方法、装置、嵌入式设备及存储介质 |
CN111818483B (zh) * | 2020-06-29 | 2022-02-11 | 郑州信大捷安信息技术股份有限公司 | 一种基于5g的v2v车联网通信系统及方法 |
CN111818483A (zh) * | 2020-06-29 | 2020-10-23 | 郑州信大捷安信息技术股份有限公司 | 一种基于5g的v2v车联网通信系统及方法 |
CN114070550B (zh) * | 2020-07-31 | 2024-07-02 | 马上消费金融股份有限公司 | 一种信息处理方法、装置、设备和存储介质 |
CN114070550A (zh) * | 2020-07-31 | 2022-02-18 | 马上消费金融股份有限公司 | 一种信息处理方法、装置、设备和存储介质 |
CN112003697A (zh) * | 2020-08-25 | 2020-11-27 | 成都卫士通信息产业股份有限公司 | 密码模块加解密方法、装置、电子设备及计算机存储介质 |
CN112003697B (zh) * | 2020-08-25 | 2023-09-29 | 成都卫士通信息产业股份有限公司 | 密码模块加解密方法、装置、电子设备及计算机存储介质 |
CN112019351B (zh) * | 2020-09-03 | 2023-05-16 | 杭州天宽科技有限公司 | 基于SDKey的移动终端信息交互方法 |
CN112019351A (zh) * | 2020-09-03 | 2020-12-01 | 杭州天宽科技有限公司 | 基于SDKey的移动终端信息交互方法 |
CN112422275A (zh) * | 2020-10-26 | 2021-02-26 | 深圳Tcl新技术有限公司 | Uart通信中的秘钥协商方法、系统、设备及计算机存储介质 |
CN112468470A (zh) * | 2020-11-16 | 2021-03-09 | 北京字节跳动网络技术有限公司 | 数据传输方法、装置和电子设备 |
CN112468470B (zh) * | 2020-11-16 | 2022-10-11 | 北京字节跳动网络技术有限公司 | 数据传输方法、装置和电子设备 |
CN112861156A (zh) * | 2021-02-26 | 2021-05-28 | 上海升途智能系统有限公司 | 显示数据的安全通信方法、装置、电子设备及存储介质 |
CN114499848A (zh) * | 2022-01-26 | 2022-05-13 | 无锡融卡科技有限公司 | 会话密钥生成装置及方法 |
CN114499848B (zh) * | 2022-01-26 | 2023-05-30 | 无锡融卡科技有限公司 | 会话密钥生成装置及方法 |
WO2023185936A1 (zh) * | 2022-03-31 | 2023-10-05 | 阿里云计算有限公司 | 用于云网络系统的通信方法、装置、系统及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN109462476B (zh) | 2021-10-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109462476A (zh) | 密钥协商方法、装置、终端及计算机可读存储介质 | |
CN105978917B (zh) | 一种用于可信应用安全认证的系统和方法 | |
CN103974241B (zh) | 一种面向Android系统移动终端的语音端到端加密方法 | |
CN106487511B (zh) | 身份认证方法及装置 | |
Boyd et al. | Protocols for authentication and key establishment | |
CN109639412A (zh) | 一种通信方法、系统及电子设备和存储介质 | |
CN106304074B (zh) | 面向移动用户的身份验证方法和系统 | |
CN108881224A (zh) | 一种配电自动化系统的加密方法及相关装置 | |
CN104301115B (zh) | 一种手机与蓝牙key签名验证密文通讯方法 | |
Edris et al. | Formal verification and analysis of primary authentication based on 5G-AKA protocol | |
CA2518032A1 (en) | Methods and software program product for mutual authentication in a communications network | |
CN104468126B (zh) | 一种安全通信系统及方法 | |
CN105376059B (zh) | 基于电子钥匙进行应用签名的方法和系统 | |
CN109302412A (zh) | 基于CPK的VoIP通信处理方法、终端、服务器及存储介质 | |
CN106301767A (zh) | 一种加密通话的处理方法、装置、终端及kmc | |
WO2016082401A1 (zh) | 通话方法、装置、用户终端及计算机存储介质 | |
CN108599926A (zh) | 一种基于对称密钥池的HTTP-Digest改进型AKA身份认证系统和方法 | |
CN104065648B (zh) | 一种语音通话的数据处理方法 | |
CN109994115A (zh) | 通讯方法及装置、数据处理方法及设备 | |
Jarecki et al. | Two-factor password-authenticated key exchange with end-to-end security | |
CN108616350A (zh) | 一种基于对称密钥池的HTTP-Digest类AKA身份认证系统和方法 | |
CN109714297A (zh) | 安全验证方法、系统及用户终端和应用平台 | |
KR20140058196A (ko) | 모바일 메시지 데이터의 보안 장치 및 방법 | |
Coffey et al. | Formal verification: an imperative step in the design of security protocols | |
CN103974242B (zh) | 一种语音通话的数据处理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
CP01 | Change in the name or title of a patent holder | ||
CP01 | Change in the name or title of a patent holder |
Address after: No. 333, Yunhua Road, high tech Zone, Chengdu, Sichuan 610041 Patentee after: China Electronics Technology Network Security Technology Co.,Ltd. Address before: No. 333, Yunhua Road, high tech Zone, Chengdu, Sichuan 610041 Patentee before: CHENGDU WESTONE INFORMATION INDUSTRY Inc. |