WO2017045552A1 - 一种在ssl或tls通信中加载数字证书的方法和装置 - Google Patents

一种在ssl或tls通信中加载数字证书的方法和装置 Download PDF

Info

Publication number
WO2017045552A1
WO2017045552A1 PCT/CN2016/098186 CN2016098186W WO2017045552A1 WO 2017045552 A1 WO2017045552 A1 WO 2017045552A1 CN 2016098186 W CN2016098186 W CN 2016098186W WO 2017045552 A1 WO2017045552 A1 WO 2017045552A1
Authority
WO
WIPO (PCT)
Prior art keywords
signature
digital certificate
mode
client
key exchange
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.)
Ceased
Application number
PCT/CN2016/098186
Other languages
English (en)
French (fr)
Inventor
齐铁鹏
杨洋
刘立朋
李振宇
蒋锷
周辉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Publication of WO2017045552A1 publication Critical patent/WO2017045552A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

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/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

Definitions

  • the present application relates to the technical field of communication, and in particular to a method for loading a digital certificate in SSL or TLS communication and an apparatus for loading a digital certificate in SSL or TLS communication.
  • HTTPS Hyper Text Transfer Protocol over Secure Socket Layer
  • HTTPS is a HTTP (Hypertext Transfer Protocol) channel for security purposes. That is, HTTP is added to SSL (Secure Sockets Layer) or its subsequent version TLS (Transport Layer Security). SSL/TLS utilizes data encryption, authentication, and message integrity verification mechanisms to provide security for the transmission of data over the network.
  • SSL Secure Sockets Layer
  • TLS Transport Layer Security
  • SSL/TLS The cryptographic algorithms applied by SSL/TLS, such as the hash algorithm of the digest, the signature algorithm of the certificate, and the encryption algorithm of the data, are also constantly updated, and various clients (including various versions of the browser, various types) Encryption methods that can be supported by applications, etc. are also uneven.
  • the digital certificate is basically loaded at startup. Only one digital certificate can be used for the specified domain name. Once the digital certificate is loaded, the digest algorithm and signature algorithm specified in the certificate can only be used for SSL/TLS handshake. Negotiation.
  • embodiments of the present application have been made in order to provide an overcoming of the above problems or at least partially A method for loading a digital certificate in SSL or TLS communication and a corresponding device for loading a digital certificate in SSL or TLS communication, which solve the above problems.
  • the embodiment of the present application discloses a method for loading a digital certificate in SSL or TLS communication, including:
  • the step of verifying the key exchange mode and the first signature mode supported by the client according to the handshake request message includes:
  • the step of verifying the key exchange mode and the first signature mode supported by the client according to the handshake request message further includes:
  • a first signature mode supported by the client is identified from the extension header.
  • the first signature mode that is verified is the first signature mode with the highest encryption strength of the client.
  • the digital certificate is divided into groups according to the type of the public key, and one of the digital certificates is loaded in each group, and the currently loaded digital certificate is the highest-encrypted digital certificate in the group.
  • the step of determining whether the key exchange mode and the signature mode match the currently loaded digital certificate comprises:
  • loading the other digital certificate that matches the key exchange manner and the first signature manner The steps include:
  • the digital certificate to which the third signature mode belongs is loaded to replace the digital certificate currently loaded in the packet to which the public key belongs.
  • the embodiment of the present application further discloses an apparatus for loading a digital certificate in SSL or TLS communication, including:
  • a handshake request message receiving module configured to receive a handshake request message sent by the client based on a Secure Sockets Layer protocol SSL or a Transport Layer Security Protocol TLS;
  • a client information verification module configured to verify, according to the handshake request message, a key exchange manner supported by the client and a first signature manner
  • a digital certificate matching module configured to determine whether the key exchange mode and the first signature mode match the currently loaded digital certificate; if not, the digital certificate loading module is invoked;
  • a digital certificate loading module loading other digital certificates matching the key exchange manner and the first signature manner
  • the handshake response message returning module is configured to return a handshake response message to the client according to the key exchange manner that matches the success of the digital certificate and the first signature manner.
  • the client information verification module includes:
  • a cipher suite lookup submodule for finding a cipher suite from the handshake request message
  • a cipher suite identification submodule configured to identify a key exchange mode and a first signature mode supported by the client from the cipher suite
  • the client information verification module further includes:
  • An extension header search submodule configured to search for an extension header of a transport layer security protocol TLS from the handshake request
  • the extended header identification submodule is configured to identify, from the extended header, a first signature manner supported by the client.
  • the first signature mode that is verified is the first signature mode with the highest encryption strength of the client.
  • the digital certificate is divided into groups according to the type of the public key, and one of the digital certificates is loaded in each group, and the currently loaded digital certificate is the highest-encrypted digital certificate in the group.
  • the digital certificate matching module includes:
  • a public key lookup submodule configured to find a public key that matches the key exchange manner
  • a current signature mode identification submodule configured to identify a digital certificate currently loaded in a packet to which the public key belongs Second signature method
  • a first signature matching submodule configured to determine whether the first signature mode matches the second signature mode; if yes, the first determining submodule is invoked, and if not, the second determining submodule is invoked;
  • a first determining submodule configured to determine that the key exchange mode and the signature manner match the currently loaded digital certificate
  • the second determining submodule is configured to determine that the key exchange mode and the signature manner do not match the currently loaded digital certificate.
  • the digital certificate loading module includes:
  • a further signature mode identifying submodule configured to identify a third signature mode of other digital certificates in the group to which the public key belongs;
  • a second signature matching sub-module configured to determine whether the third signature mode matches the first signature mode; if yes, calling a digital certificate replacement sub-module;
  • a digital certificate replacement submodule configured to load the digital certificate to which the third signature mode belongs, to replace the digital certificate currently loaded in the packet to which the public key belongs.
  • the digital certificate is matched with the key exchange mode supported by the client and the first signature mode, so that the appropriate digital certificate is dynamically loaded during the handshake negotiation process to ensure successful completion of the SSL/TLS handshake negotiation.
  • the poor compatibility of the website ensures that the client accesses the website through a secure protocol such as HTTPS, which improves the security of the communication.
  • the embodiment of the present application can configure multiple different types of digital certificates for the same domain name, which improves the dynamic loading efficiency of the digital certificate.
  • FIG. 1 is a flow chart showing the steps of an embodiment of a method for loading a digital certificate in SSL/TLS communication according to the present application
  • FIG. 2 is a network model architecture diagram of an embodiment of the present application.
  • FIG. 3 is a signaling diagram of an SSL handshake according to an embodiment of the present application.
  • FIG. 4 is a structural block diagram of an embodiment of an apparatus for loading a digital certificate in SSL/TLS communication according to the present application.
  • SSL/TLS is a secure network transmission protocol, mainly to protect confidential information transmitted over the Internet.
  • the protocol includes two processes: a handshake phase and a data transmission phase.
  • the transmitted data is separately encrypted and decrypted using the negotiated symmetric key, and the digest key is digested to ensure the privacy and integrity of the data.
  • the main purpose of the handshake phase is to confirm the true validity of the identity of the other party and to generate the key required for the data transmission phase.
  • the SSL handshake process is as follows:
  • a client client sends a Client hello message.
  • the message mainly includes the SSL version number, random number, callback ID, cipher suite, and compression method.
  • the cipher suite indicates the list of algorithms that the client can support, including the key exchange method, the signature method, and the encryption method.
  • the server returns a hello message to the client, including the SSL version number, the key exchange mode supported by the server and the client, the signature mode, and the encryption method, and the random number used to generate the secret key.
  • the server needs to match the cipher suite in the client hello through the pre-loaded digital certificate and signature method. Only when the match is successful, the server hello message is returned, and the cipher algorithm used by both parties is identified in Client_hello.
  • the server sends the specified certificate (certificate chain) to the client for authentication.
  • the client After successfully verifying the server certificate, the client sends a client key exchange message to the server, which is used to encrypt the pre-master key through the server's public key and then send it to the server.
  • the two parties generate a master key for the transmission phase according to the pre-master key and the random number, thereby completing the SSL handshake negotiation process.
  • step e when the client verifies the server certificate, the client verifies the digital signature in the certificate according to the signature method in the certificate and the hash digest algorithm used by the signature. If the client does not support the response signature algorithm and the digest algorithm, The verification of the digital certificate will fail and the SSL handshake will not be completed.
  • the digital certificate supported by the client is dynamically loaded to perform handshake to ensure the successful handshake of the SSL/TLS.
  • FIG. 1 is a flow chart showing the steps of an embodiment of a method for loading a digital certificate in an SSL/TLS communication, which may include the following steps:
  • Step 101 Receive a handshake request message sent by the client according to a Secure Sockets Layer protocol SSL or a transport layer security protocol TLS.
  • SSL Secure Sockets Layer protocol
  • TLS transport layer security protocol
  • the SSL/TLS is between the application layer and the TCP (Transmission Control Protocol) and IP (Internet Protocol) protocols.
  • TCP Transmission Control Protocol
  • IP Internet Protocol
  • the application layer data is no longer passed directly to the transport layer, but to the SSL/TLS layer, which encrypts the data received from the application layer.
  • the SSL protocol itself is divided into two layers:
  • the upper layer is an SSL handshake protocol, an SSL change cipher spec protocol, and an SSL alert protocol.
  • the underlying layer is the SSL record protocol.
  • SSL handshake protocol used to negotiate the cipher suite (encryption algorithm, key exchange algorithm, MAC algorithm, etc.) used in the communication process, securely exchange keys between the server and the client, and implement authentication of the server and the client.
  • SSL password change protocol The client and server notify the peer through the password change protocol, and subsequent packets will be protected and transmitted using the newly negotiated cipher suite and key.
  • SSL warning protocol used to report alarm information to the communication peer.
  • the message contains the severity and description of the alarm.
  • SSL record protocol It is mainly responsible for blocking, calculating, adding MAC value, encrypting, and transmitting the processed record block to the upper layer data (SSL handshake protocol, SSL password change protocol, SSL warning protocol, and application layer protocol message). Give the opposite end.
  • the TLS protocol includes two protocol groups: the TLS Record Protocol and the TLS Handshake Protocol.
  • the TLS Recording Protocol is a layered protocol.
  • the information in each layer may contain fields such as length, description, and content.
  • the recording protocol supports information transfer, segmentation of data into processable blocks, compression of data, application of MAC, encryption, and transmission of results.
  • the received data is decrypted, verified, decompressed, reorganized, etc., and then transmitted to the upper client.
  • the TLS handshake protocol consists of three sub-protocol groups, allowing peers to agree on the security parameters of the record layer, self-certify, instantiate security parameters, and report error conditions to each other.
  • TLS is based on SSL and is a subsequent version of SSL, there is a difference between the two, mainly because the encryption algorithms they support are different, and the overall process is basically the same. Therefore, in the implementation of this application In the example, it is mainly explained by SSL.
  • the first phase of the SSL handshake initiates a logical connection and establishes the security capabilities of the connection.
  • the client sends a Client hello message (ie, a handshake request message) to the server and waits for a response from the server.
  • a Client hello message ie, a handshake request message
  • Step 102 Verify, according to the handshake request message, a key exchange mode and a first signature mode supported by the client.
  • Client hello messages usually include Version (version), Random (client random number), Session id (session ID), Cipher suite (client-supported cipher suite), Compression method (client-supported compression method) and other information.
  • the same set of encryption and decryption algorithms can be used to ensure data encryption and decryption in the SSL communication process.
  • the client informs the server of the signature mode it supports, that is, the client transmits a list of locally supported cipher suites (Cipher Suite) to the server.
  • Cipher Suite locally supported cipher suites
  • the server can then look up the cipher suite from the handshake request message, and identify the key exchange mode and the first signature mode supported by the client from the cipher suite.
  • SSL-based cipher suites usually start with "SSL”.
  • TLS-based cipher suites usually start with "TLS”, followed by the key exchange method used in the key exchange phase, the symmetric encryption used to transfer data,
  • the signature method used in the MAC used for data integrity verification uses the word "With” to separate the key exchange method, the symmetric encryption method, and the signature method.
  • DHE_RSA and ECDHE_ECDSA are key exchange modes
  • DES_CBC and AES_128_GCM are symmetric encryption modes
  • SHA and SHA256 are signature modes (that is, different versions of hash algorithms).
  • the first signature method verified may be the first signature mode with the highest encryption strength of the client.
  • the server parses the Client hello, it can traverse the list of cipher suites to record the first signature method with the highest encryption strength.
  • the extension header of the transport layer security protocol TLS can be looked up from the handshake request, and the extension header indicates a list of signature methods that the client can support.
  • the signature mode supported by the client can be read from the extension header, and the first signature party supported by the client is updated. formula.
  • TLS Transmission Control Protocol
  • Internet Explorer may not add extension headers according to the TLS specification. In this case, you can still traverse the cipher suite list to obtain the number supported by the client.
  • a signature method may be used.
  • Step 103 determining the key exchange mode and the first signature mode, whether it matches the currently loaded digital certificate; if not, executing step 104;
  • a standard X.509 digital certificate contains the following contents:
  • Version information serial number, signature method used, issuer name, expiration date, owner name, public key used for negotiation, digital signature.
  • a digital certificate is an electronic certificate that needs to be applied and issued by a specialized digital certificate authority (CA).
  • CA digital certificate authority
  • a private key and a public key are generated.
  • the private key is kept by the server and cannot be leaked.
  • the public key is attached to the digital certificate and can be made public.
  • the digital certificate itself is also accompanied by a certificate electronic signature, which is used to verify the integrity and authenticity of the certificate and to prevent the certificate from being serially altered.
  • the digital certificate may be grouped according to the type of the public key.
  • OpenSSL Open Secure Sockets Layer
  • the server is configured with the following digital certificates:
  • One of the digital certificates can be loaded in each group.
  • the server can read the configured digital certificate into memory and load the specified digital certificate into the context of SSL or TLS at startup.
  • the specified digital certificate can be reloaded into the context of SSL or TLS when the communication of the SSL or TLS is ended.
  • the embodiment of the present application can configure multiple different types of digital certificates for the same domain name, which improves the dynamic loading efficiency of the digital certificate.
  • the currently loaded digital certificate may be the highest-encrypted digital certificate in the group to which it belongs.
  • SHA256 has a higher encryption strength than SHA1, so for the above example grouping, you can load sha256WithRSAEncryption, ecdsa-with-SHA256.
  • a callback function may be registered with the SSL/TLS service program for dynamically selecting the digital certificate according to the signature mode in the subsequent handshake phase.
  • the callback function is called to pass a parameter to the callback function, that is, the signature mode supported by the client, such as the hash algorithm with the highest encryption strength.
  • the callback function performs a matching of the signature algorithm used by the hash algorithm with the certificate of the current same type of packet, and finds the certificate reload with the highest algorithm strength and matching the strength of the client hash algorithm.
  • the public key matching the key exchange manner may be searched for, and the second signature manner of the digital certificate currently loaded in the packet to which the public key belongs is identified;
  • the encryption strength of the second signature mode is equal to or lower than the encryption strength of the first signature mode.
  • the first signature mode is SHA256
  • the second signature mode is SHA224
  • the two match If the second signature mode is SHA512, the two do not match.
  • the key exchange mode and the signature mode may be determined to be matched with the currently loaded digital certificate
  • the key exchange mode and the signature mode may be determined to not match the currently loaded digital certificate.
  • the first signature mode is SHA. If the RSA belongs to the group, the currently loaded digital certificate is sha256WithRSAEncryption, its second signature is sha256, does not match SHA, and needs to reload other matching digital certificates.
  • Step 104 Load other digital certificates that match the key exchange mode and the first signature mode.
  • the third signature mode of the other digital certificate in the group to which the public key belongs may be identified, and whether the third signature mode matches the first signature mode is determined, and if yes, the digital certificate to which the third signature mode belongs is loaded to the SSL. Or the TLS context to replace the digital certificate currently loaded in the packet to which the public key belongs. The subsequent SSL or TLS handshake operation will be sent to the client using this new digital certificate to ensure the normal operation of the handshake operation.
  • the digital certificate with the highest encryption strength in the signature mode can be loaded.
  • Step 105 Return a handshake response message to the client according to the key exchange mode that matches the success of the digital certificate and the first signature mode.
  • step 105 may be directly performed to return a handshake response message.
  • step 103 if it is determined that the key exchange mode and the first signature mode do not match the currently loaded digital certificate, step 104 is executed, the matching digital certificate is loaded, and then step 105 is performed to return a handshake response. Message.
  • the server returns a Server hello message (ie, a handshake response message) to the client, and confirms the information in the Client hello message.
  • a Server hello message ie, a handshake response message
  • Server hello usually includes Version (version, the highest version number supported by the client and the lower version number supported by the server), Random (server random number), Session id (session ID), Cipher suite (server) Information such as the selected cipher suite), Compression method (server-selected compression method).
  • the digital certificate is matched with the key exchange mode supported by the client and the first signature mode, so that the appropriate digital certificate is dynamically loaded during the handshake negotiation process to ensure successful completion of the SSL/TLS handshake negotiation.
  • the poor compatibility of the website ensures that the client accesses the website through a secure protocol such as HTTPS, which improves the security of the communication.
  • the client and server can know the following:
  • the server and client can perform handshake operations and encryption and decryption operations according to the SSL or TLS specifications.
  • the server sends the digital certificate carrying its own public key to the SSL client through a Certificate message.
  • the server sends a Server Hello Done message to notify the client that the version and cipher suite negotiation has ended and the key exchange begins.
  • the public key in the digital certificate is used to encrypt the premaster secret generated by the client, and is sent to the server through the Client Key Exchange message.
  • the client sends a Change Cipher Spec message to inform the server that subsequent packets will be encrypted and MAC calculated using the negotiated key and cipher suite.
  • the client calculates the hash value of the interactive handshake message (all the interactive messages except the Change Cipher Spec message), processes the hash value (calculates and adds the MAC value, encryption, etc.) using the negotiated key and cipher suite, and passes The Finished message is sent to the SSL server.
  • the server uses the same method to calculate the hash value of the exchanged handshake message and compares it with the decrypted result of the Finished message. If the two are the same and the MAC value is successfully verified, the key and cipher suite negotiation is successful.
  • the server sends a Change Cipher Spec message to inform the SSL client that the subsequent message will be encrypted and MAC calculated using the negotiated key and cipher suite.
  • the server calculates the hash value of the handshake message that has been exchanged, processes the hash value (calculates and adds the MAC value, encryption, etc.) using the negotiated key and cipher suite, and sends the message to the client through the Finished message.
  • the client uses the same method to calculate the hash value of the exchanged handshake message and compares it with the decrypted result of the Finished message. If the two are the same and the MAC value is successfully verified, the key and cipher suite negotiation is successful.
  • the client After receiving the Finished message sent by the server, if the decryption succeeds, the client can determine that the server is the owner of the digital certificate, that is, the server authentication succeeds, because only the server with the private key can decrypt the premaster secret from the Client Key Exchange message. Indirectly, the client-to-server authentication is implemented.
  • the server and the client respectively generate the symmetric master key required for encryption, the authentication key and the initialization vector used for integrity verification, respectively, using the preliminary master key.
  • the sender (server or client) will first encrypt with the symmetric key, and use the authentication key to group the data according to the signature negotiated during the handshake (such as MD5 or SHA based MAC). Algorithm) to sign and generate a summary.
  • the signature such as MD5 or SHA based MAC.
  • Algorithm Algorithm
  • the receiving end decrypts with a symmetric key, and uses the authentication key to sign the decrypted data according to the signature method negotiated during handshake (such as MD5 or SHA based MAC algorithm), generating a digest and receiving it.
  • the summary is compared to verify the integrity of the data.
  • the packet is not changed; otherwise, the packet is modified during transmission, and the receiver (client or server) will discard the packet.
  • FIG. 4 a structural block diagram of an apparatus for loading a digital certificate in an SSL/TLS communication according to the present application is shown. Specifically, the following modules may be included:
  • the handshake request message receiving module 401 is configured to receive a handshake request message sent by the client according to the Secure Sockets Layer protocol SSL or the transport layer security protocol TLS;
  • the client information verification module 402 is configured to verify, according to the handshake request message, a key exchange manner supported by the client and a first signature manner;
  • the digital certificate matching module 403 is configured to determine whether the key exchange mode and the first signature mode are matched with the currently loaded digital certificate; if not, the digital certificate loading module 404 is invoked;
  • the digital certificate loading module 404 loads other digital certificates that match the key exchange manner and the first signature manner;
  • the handshake response message returning module 405 is configured to return a handshake response message to the client according to the key exchange mode that matches the success of the digital certificate and the first signature mode.
  • the client information verification module 402 may include the following sub-modules:
  • a cipher suite lookup submodule for finding a cipher suite from the handshake request message
  • a cipher suite identification submodule configured to identify a key exchange mode and a first signature mode supported by the client from the cipher suite
  • the client information verification module 402 may further include the following sub-modules:
  • An extension header search submodule configured to search for an extension header of a transport layer security protocol TLS from the handshake request
  • the extended header identification submodule is configured to identify, from the extended header, a first signature manner supported by the client.
  • the first signature mode that is verified may be the first signature mode with the highest encryption strength of the client.
  • the digital certificate may be grouped according to the type of the public key, and one of the digital certificates is loaded in each group, and the currently loaded digital certificate may be the digital certificate with the highest encryption strength in the group.
  • the digital certificate matching module 404 may include the following sub-modules:
  • a public key lookup submodule configured to find a public key that matches the key exchange manner
  • a current signature mode identification submodule configured to identify a second signature mode of the digital certificate currently loaded in the packet to which the public key belongs
  • a first signature matching submodule configured to determine whether the first signature mode matches the second signature mode; if yes, the first determining submodule is invoked, and if not, the second determining submodule is invoked;
  • a first determining submodule configured to determine the key exchange mode and the signature manner, and match the currently loaded digital certificate
  • the second determining sub-module is configured to determine that the key exchange mode and the signature mode do not match the currently loaded digital certificate.
  • the digital certificate loading module 405 may include the following sub-modules:
  • a further signature mode identifying submodule configured to identify a third signature mode of other digital certificates in the group to which the public key belongs;
  • a second signature matching sub-module configured to determine whether the third signature mode matches the first signature mode; if yes, calling a digital certificate replacement sub-module;
  • a digital certificate replacement submodule configured to load the digital certificate to which the third signature mode belongs, to replace the digital certificate currently loaded in the packet to which the public key belongs.
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • embodiments of the embodiments of the present application can be provided as a method, apparatus, or computer program product. Therefore, embodiments of the present application may adopt an entirely hardware embodiment, an entirely software embodiment, or a combination of soft A form of embodiment of hardware and hardware. Moreover, embodiments of the present application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • the computer device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include non-persistent computer readable media, such as modulated data signals and carrier waves.
  • Embodiments of the present application are described with reference to flowcharts and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the present application. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG.
  • These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing terminal device to produce a machine such that instructions are executed by a processor of a computer or other programmable data processing terminal device
  • Means are provided for implementing the functions specified in one or more of the flow or in one or more blocks of the flow chart.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the instruction device implements the functions specified in one or more blocks of the flowchart or in a flow or block of the flowchart.
  • the above provides a method for loading a digital certificate in SSL/TLS communication and a device for loading a digital certificate in SSL/TLS communication provided by the present application, and a specific example is applied to the principle of the present application.
  • the description of the above embodiments is only for helping to understand the method of the present application and its core ideas; at the same time, for those skilled in the art, according to the idea of the present application, in the specific implementation and application scope There are variations, and the contents of this specification should not be construed as limiting the application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请实施例提供了一种在SSL或TLS通信中加载数字证书的方法和装置，该方法包括：接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；判断所述密钥交换方式和所述第一签名方式是否与当前加载的数字证书匹配；若否，则加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。本申请实施例实现了在握手协商过程中动态加载合适的数字证书，以保证成功完成SSL/TLS的握手协商。

Description

一种在SSL或TLS通信中加载数字证书的方法和装置
本申请要求2015年09月15日递交的申请号为201510587689.7、发明名称为“一种在SSL或TLS通信中加载数字证书的方法和装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信的技术领域，特别是涉及一种在SSL或TLS通信中加载数字证书的方法和一种在SSL或TLS通信中加载数字证书的装置。
背景技术
基于电子商务和网上银行等新兴应用，极大地方便了人们的日常生活，受到人们的青睐。由于这些应用都需要在网络上进行在线交易，它们对网络通信的安全性提出了更高的要求。因此，HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer，超文本传输安全协议)已经被越来越多的网站所使用。
HTTPS是以安全为目标的HTTP(Hypertext transfer protocol，超文本传送协议)通道，即HTTP下加入SSL(Secure Sockets Layer，安全套接层协议)或其后续版本TLS(Transport Layer Security，安全传输层协议)，SSL/TLS利用数据加密、身份验证和消息完整性验证机制，为网络上数据的传输提供安全性保证。
SSL/TLS所应用的密码算法，如摘要的哈希算法、证书的签名算法、数据的加密算法等也随之不断的更新，而目前各种客户端(包括各种版本的浏览器，各种应用等)所能支持的加密方式也参差不齐。
在诸如电子商务平台这样访问量巨大的网站中，经常面临各种版本的客户端访问。
目前对于支持SSL/TLS的服务器基本是在启动时加载数字证书，对于指定的域名只能使用一个数字证书，数字证书一旦加载只能用证书里规定的摘要算法和签名算法来进行SSL/TLS握手协商。
如果某些旧版本的客户端无法支持证书里的较新的算法，则协商失败，从而导致客户端无法通过HTTPS访问网站，网站兼容性差，导致通信的安全性低。
发明内容
鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解 决上述问题的一种在SSL或TLS通信中加载数字证书的方法和相应的一种在SSL或TLS通信中加载数字证书的装置。
为了解决上述问题，本申请实施例公开了一种在SSL或TLS通信中加载数字证书的方法，包括：
接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；
根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；
判断所述密钥交换方式和所述第一签名方式是否与当前加载的数字证书匹配；若否，则加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；
根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。
可选地，所述根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式的步骤包括：
从所述握手请求消息中查找密码套件；
从所述密码套件中识别客户端支持的密钥交换方式和第一签名方式；
可选地，所述根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式的步骤还包括：
从所述握手请求中查找传输层安全协议TLS的扩展头；
从所述扩展头中识别客户端支持的第一签名方式。
可选地，所验证的第一签名方式为客户端的加密强度最高的第一签名方式。
可选地，所述数字证书按照公钥的类型划分分组，在每个分组中加载其中一个数字证书，当前加载的数字证书为所属分组中加密强度最高的数字证书。
可选地，所述判断所述密钥交换方式和所述签名方式是否与当前加载的数字证书匹配的步骤包括：
查找与所述密钥交换方式匹配的公钥；
识别在所述公钥所属的分组中当前加载的数字证书的第二签名方式；
判断所述第一签名方式是否与所述第二签名方式匹配；
若是，则判定所述密钥交换方式和所述签名方式与当前加载的数字证书匹配；
若否，则判定所述密钥交换方式和所述签名方式与当前加载的数字证书不匹配。
可选地，所述加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书的 步骤包括：
识别在所述公钥所属的分组中其他数字证书的第三签名方式；
判断所述第三签名方式是否与所述第一签名方式匹配；
若是，则加载所述第三签名方式所属的数字证书，以替换在所述公钥所属的分组中当前加载的数字证书。
本申请实施例还公开了一种在SSL或TLS通信中加载数字证书的装置，包括：
握手请求消息接收模块，用于接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；
客户端信息验证模块，用于根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；
数字证书匹配模块，用于判断所述密钥交换方式和所述第一签名方式是否与当前加载的数字证书匹配；若否，则调用数字证书加载模块；
数字证书加载模块，加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；
握手响应消息返回模块，用于根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。
可选地，所述客户端信息验证模块包括：
密码套件查找子模块，用于从所述握手请求消息中查找密码套件；
密码套件识别子模块，用于从所述密码套件中识别客户端支持的密钥交换方式和第一签名方式；
可选地，所述客户端信息验证模块还包括：
扩展头查找子模块，用于从所述握手请求中查找传输层安全协议TLS的扩展头；
扩展头识别子模块，用于从所述扩展头中识别客户端支持的第一签名方式。
可选地，所验证的第一签名方式为客户端的加密强度最高的第一签名方式。
可选地，所述数字证书按照公钥的类型划分分组，在每个分组中加载其中一个数字证书，当前加载的数字证书为所属分组中加密强度最高的数字证书。
可选地，所述数字证书匹配模块包括：
公钥查找子模块，用于查找与所述密钥交换方式匹配的公钥；
当前签名方式识别子模块，用于识别在所述公钥所属的分组中当前加载的数字证书 的第二签名方式；
第一签名方式匹配子模块，用于判断所述第一签名方式是否与所述第二签名方式匹配；若是，则调用第一判定子模块，若否，则调用第二判定子模块；
第一判定子模块，用于判定所述密钥交换方式和所述签名方式与当前加载的数字证书匹配；
第二判定子模块，用于判定所述密钥交换方式和所述签名方式与当前加载的数字证书不匹配。
可选地，所述数字证书加载模块包括：
其他签名方式识别子模块，用于识别在所述公钥所属的分组中其他数字证书的第三签名方式；
第二签名方式匹配子模块，用于判断所述第三签名方式是否与所述第一签名方式匹配；若是，则调用数字证书替换子模块；
数字证书替换子模块，用于加载所述第三签名方式所属的数字证书，以替换在所述公钥所属的分组中当前加载的数字证书。
本申请实施例包括以下优点：
本申请实施例数字证书与客户端支持的密钥交换方式和第一签名方式的匹配，实现了在握手协商过程中动态加载合适的数字证书，以保证成功完成SSL/TLS的握手协商，提高了网站的兼容性差，保证了客户端通过HTTPS等安全协议访问网站，提高了通信的安全性。
本申请实施例针对同一域名可以配置多种不同类型的数字证书，提高了数字证书的动态加载效率。
附图说明
图1是本申请的一种在SSL/TLS通信中加载数字证书的方法实施例的步骤流程图；
图2是本申请实施例的一种网络模型架构图；
图3是本申请实施例的一种SSL的握手的信令图；
图4是本申请的一种在SSL/TLS通信中加载数字证书的装置实施例的结构框图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。
SSL/TLS是安全网络传输协议，主要是为了保护在互联网中传递的机密信息，该协议包括两个过程:握手阶段,数据传输阶段。
数据传输阶段就是对传输的数据分别使用协商好的对称秘钥进行加解密和摘要秘钥进行摘要运算以保证数据的私密性和完整性。
而握手阶段的主要目的就是为了确认对方身份的真实有效性并产生数据传输阶段所需要的秘钥。
SSL握手过程如下：
a.客户端项服务器端发送Client hello消息，消息主要包括SSL版本号，随机数、会回话ID、密码套件、压缩方法等信息。
其中，密码套件表明了客户端所能支持的算法列表，其中包括密钥交换方式、签名方式和对此加密方式。
b.服务器返回给客户端Server hello消息，包括SSL版本号，服务器和客户端共同支持的密钥交换方式、签名方式和对此加密方式，以及用于后续生成秘钥的随机数。
这里服务器需要的通过预先加载的数字证书以及签名方式来和Client hello里的密码套件进行匹配，只有匹配成功才会返回Server hello消息，并在Client_hello里标识双方协商好的所使用的密码算法。
c.服务器发送指定的证书(证书链)给客户端，用于身份验证。
d.客户端成功验证服务器证书后，发送client key exchange消息给服务器，用于将预主秘钥通过服务器的公钥加密后发送给服务器。
e.双方根据预主秘钥以及随机数生成用于传输阶段的主秘钥，从而完成SSL握手协商的过程。
在步骤e中，客户端在验证服务器证书的时候根据证书里的签名方式以及签名所使用的哈希摘要算法对证书里的数字签名进行验证，如果客户端不支持响应的签名算法和摘要算法，则数字证书的验证就会失败，SSL握手就无法完成。
因此，提出了本申请实施例的构思之一，当客户端无法支持数字证书的签名算法和摘要算法时，动态加载客户端支持的数字证书进行握手，保证SSL/TLS的握手成功。
参照图1，示出了本申请的一种在SSL/TLS通信中加载数字证书的方法实施例的步骤流程图，具体可以包括如下步骤：
步骤101，接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；
如图2所示，SSL/TLS在应用层与TCP(Transmission Control Protocol传输控制协议)、IP(Internet Protocol，网络之间互连的协议)层之间。
应用层的数据不再直接传递给传输层，而是传递给SSL/TLS层，SSL/TLS层对从应用层收到的数据进行加密。
SSL协议本身分为两层：
上层为SSL握手协议(SSL handshake protocol)、SSL密码变化协议(SSL change cipher spec protocol)和SSL警告协议(SSL alert protocol)；
底层为SSL记录协议(SSL record protocol)。
SSL握手协议：用来协商通信过程中使用的密码套件(加密算法、密钥交换算法和MAC算法等)、在服务器和客户端之间安全地交换密钥、实现服务器和客户端的身份验证。
SSL密码变化协议：客户端和服务器端通过密码变化协议通知对端，随后的报文都将使用新协商的密码套件和密钥进行保护和传输。
SSL警告协议：用来向通信对端报告告警信息，消息中包含告警的严重级别和描述。
SSL记录协议：主要负责对上层的数据(SSL握手协议、SSL密码变化协议、SSL警告协议和应用层协议报文)进行分块、计算并添加MAC值、加密，并把处理后的记录块传输给对端。
TLS协议包括两个协议组：TLS记录协议和TLS握手协议。
TLS记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用MAC、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。
TLS握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。
由于TLS是建立在SSL的基础上的，是SSL的后续版本，两者之间存在着差别，主要是它们所支持的加密算法不同，而整体的流程是基本相同的，因此，在本申请实施 例中，主要以SSL进行说明。
SSL握手的第一阶段启动逻辑连接，建立这个连接的安全能力。
如图3所示，客户端(client)向服务器(server)发出Client hello消息(即握手请求消息)并等待服务器(server)的响应。
步骤102，根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；
Client hello消息通常包括Version(版本)，Random(客户端随机数)，Session id(会话ID)，Cipher suite(客户端支持的密码套件)，Compression method(客户端支持的压缩方法)等信息。
具体而言，由于不同版本的客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在SSL通信过程中使用同一套加解密算法才能保证数据能够正常的加解密。
因此，在SSL握手阶段，客户端告知服务端其所支持的签名方式，即客户端将本地支持的密码套件(Cipher Suite)的列表传送给服务器。
则服务器可以从握手请求消息中查找密码套件，从密码套件中识别客户端支持的密钥交换方式和第一签名方式。
基于SSL的密码套件通常以“SSL”开头，基于TLS的密码套件通常以或“TLS”开头，紧跟着的是密钥交换阶段所使用密钥交换方式、传输数据所使用的对称加密方式、数据完整性验证所使用的MAC里所采用的签名方式(如哈希算法)，用“With”这个词把密钥交换方式、对称加密方式、签名方式分开。
密码套件的示例下：
SSL_DHE_RSA_WITH_DES_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
其中，DHE_RSA、ECDHE_ECDSA为密钥交换方式，DES_CBC、AES_128_GCM为对称加密方式，SHA、SHA256为签名方式(即不同版本的哈希算法)。
为了进一步保证通信的安全性，所验证的第一签名方式可以为客户端的加密强度最高的第一签名方式。
因此，服务器在解析Client hello的时候，可以遍历密码套件的列表，从而记录加密强度最高的第一签名方式。
此外，如果是基于TLS进行通信并且含有TLS签名方式的扩展头，则可以从握手请求中查找传输层安全协议TLS的扩展头，这个扩展头里指明了客户端所能支持的签名方式的列表，从扩展头中可以读取客户端支持的签名方式，更新客户端支持的第一签名方 式。
需要说明的是，某些使用了TLS的客户端，如IE浏览器，也可能没有按照TLS的规范增加扩展头，此种情况下，仍可以遍历密码套件列表来获取客户端所能支持的第一签名方式。
步骤103，判断所述密钥交换方式和所述第一签名方式、是否与当前加载的数字证书匹配；若否，则执行步骤104；
数字证书的格式普遍采用的是X.509V3国际标准，一个标准的X.509数字证书包含以下一些内容：
版本信息，序列号，所使用的签名方式，发行机构名，有效期，所有人名称，协商使用的公开秘钥，数字签名。
通常情况下，数字证书是需要申请，并由专门的数字证书认证机构(CA)通过审核之后颁发的电子证书。
颁发数字证书的同时，会产生一个私钥和公钥。私钥由服务器保存，不可泄漏。公钥则是附带在数字证书的信息中，可以公开的。
数字证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被串改。
在本申请实施例中，数字证书可以按照公钥的类型划分分组，目前OpenSSL(Open Secure Sockets Layer，开放式安全套接层协议)可以支持同时加载三种类型的数字证书，以便在协商的时候可以更好地支持不同类型的客户端，减少数字证书匹配的时间。
例如，服务器配置了如下数字证书：
sha256WithRSAEncryption(公钥使用RSA)
sha1WithRSAEncryption(公钥使用RSA)
ecdsa-with-SHA256(公钥使用ECC)
ecdsa-with-SHA1(公钥使用ECC)
则可以将sha256WithRSAEncryption，sha1WithRSAEncryption划分为一个分组，即此组中所有数字证书的公钥使用RSA，将ecdsa-with-SHA256，ecdsa-with-SHA1划分为另一个分组，即此组中所有数字证书的公钥使用ECC。
在每个分组中可以加载其中一个数字证书。
在一种情况中，服务器在启动的时候，可以将配置好的数字证书读入内存，并将指定的数字证书加载到SSL或TLS的上下文。
在另一种情况中，若在SSL或TLS的通信时加载了其他数字证书，在结束该SSL或TLS的通信时，可以重新将指定的数字证书加载到SSL或TLS的上下文。
由于数字证书加载操作较为简单，属于轻加载，即使频繁替换数字证书也不会对SSL或TLS的握手协商产生影响。
在实际应用中，可以对服务器(如Tengine)修改配置文件，可以允许配置多个数字证书，以及修改相应的存储结构。
本申请实施例针对同一域名可以配置多种不同类型的数字证书，提高了数字证书的动态加载效率。
为了进一步保证通信的安全性，当前加载的数字证书可以为所属分组中加密强度最高的数字证书。
例如，SHA256的加密强度比SHA1高，则对于上述示例的分组，在可以加载sha256WithRSAEncryption、ecdsa-with-SHA256。
在本申请实施例中，服务器(如Tengine)在初始化SSL/TLS的时候，可以向SSL/TLS服务程序注册一个回调函数，用于在后续握手阶段根据签名方式动态选择数字证书。
在握手阶段(即接收到Client hello消息进行解析的时候)，调用这个回调函数，向回调函数传递的一个参数，即客户端所能支持的签名方式，如加密强度最高的哈希算法。
回调函数执行对此哈希算法和当前同类型分组的的证书所使用的签名算法进行匹配，找到算法强度最高并且匹配客户端哈希算法强度的证书重新加载。
具体而言，在匹配当前的数字证书时，可以查找与密钥交换方式匹配的公钥，识别在该公钥所属的分组中当前加载的数字证书的第二签名方式；
从而，判断第一签名方式是否与第二签名方式匹配，所谓匹配，则第二签名方式的加密强度等于或低于第一签名方式的加密强度。
例如，假设第一签名方式为SHA256，若第二签名方式为SHA224，则两者匹配，若第二签名方式为SHA512，则两者不匹配。
当第一签名方式与第二签名方式匹配时，则可以判定密钥交换方式和签名方式、是与当前加载的数字证书匹配；
当第一签名方式与第二签名方式不匹配时，则可以判定密钥交换方式和签名方式、与当前加载的数字证书不匹配。
例如，若客户端的密码套件为SSL_DHE_RSA_WITH_DES_CBC_SHA，则其第一签名方式为SHA，若在RSA所属的分组中，当前加载的数字证书为 sha256WithRSAEncryption，则其第二签名方式为sha256，与SHA不匹配，需要重新加载其他匹配的数字证书。
步骤104，加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；
在具体实现中，可以识别在公钥所属的分组中其他数字证书的第三签名方式，判断第三签名方式是否与第一签名方式匹配，若是，则加载第三签名方式所属的数字证书至SSL或TLS的上下文，以替换在在公钥所属的分组中当前加载的数字证书，后续的SSL或TLS的握手操作，将使用此新的数字证书发送给客户端以保证握手操作的正常进行。
为了进一步保证通信的安全性，若识别到多个匹配的数字证书，则可以加载其中签名方式的加密强度最高的数字证书。
步骤105，根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。
需要说明的是，在步骤103中，若判断所述密钥交换方式和所述第一签名方式、与当前加载的数字证书匹配，则可以直接执行步骤105，返回握手响应消息。
在步骤103中，若判断所述密钥交换方式和所述第一签名方式、与当前加载的数字证书不匹配，则执行步骤104，加载匹配的数字证书，再执行执行步骤105，返回握手响应消息。
如图3所示，服务器(server)向客户端(client)返回Server hello消息(即握手响应消消息)，对Client hello消息中的信息进行确认。
Server hello通常消息包括Version(版本，取客户端支持的最高版本号和服务端支持的最高版本号中的较低者)，Random(服务器随机数)，Session id(会话ID)，Cipher suite(服务器选择的密码套件)，Compression method(服务器选择的压缩方法)等信息。
本申请实施例数字证书与客户端支持的密钥交换方式和第一签名方式的匹配，实现了在握手协商过程中动态加载合适的数字证书，以保证成功完成SSL/TLS的握手协商，提高了网站的兼容性差，保证了客户端通过HTTPS等安全协议访问网站，提高了通信的安全性。
这个阶段之后，客户端、服务器可以知道下列内容：
(1)SSL版本；
(2)密钥交换方式、签名方式和对称加密方式；
(3)压缩方法；
(4)有关密钥生成的两个随机数。
步骤这个阶段之后，服务器和客户端可以按照SSL或TLS的规范进行握手操作和加解密的操作。
以下以SSL的规范进行讲解：
服务器将携带自己公钥的数字证书通过Certificate消息发送给SSL客户端。
服务器发送Server Hello Done消息，通知客户端版本和密码套件协商结束，开始进行密钥交换。
客户端验证服务器的数字证书合法后，利用数字证书中的公钥加密客户端随机生成的premaster secret(预备主密钥)，并通过Client Key Exchange消息发送给服务器。
客户端发送Change Cipher Spec消息，通知服务器后续报文将采用协商好的密钥和密码套件进行加密和MAC计算。
客户端计算已交互的握手消息(除Change Cipher Spec消息外所有已交互的消息)的Hash值，利用协商好的密钥和密码套件处理Hash值(计算并添加MAC值、加密等)，并通过Finished消息发送给SSL服务器。
服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和密码套件协商成功。
服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和密码套件进行加密和MAC计算。
服务器计算已交互的握手消息的Hash值，利用协商好的密钥和密码套件处理Hash值(计算并添加MAC值、加密等)，并通过Finished消息发送给客户端。
客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和密码套件协商成功。
客户端接收到服务器发送的Finished消息后，如果解密成功，则可以判断服务器是数字证书的拥有者，即服务器身份验证成功，因为只有拥有私钥的服务器才能从Client Key Exchange消息中解密得到premaster secret，从而间接地实现了客户端对服务器的身份验证。
握手完成后，服务器和客户端分别用预备主密钥各自生成了加密所需要的对称主密钥，完整性验证所用的认证秘钥和初始化向量。
在数据传输阶段，对于每一个数据分组，发送端(服务器或客户端)都会先用对称秘钥进行加密，用认证秘钥对数据分组按照握手时协商的签名方式(如基于MD5或SHA的MAC算法)进行签名，产生摘要。
接收端(客户端或服务器)用对称秘钥进行解密，并且对解密数据用认证密钥按照握手时协商的签名方式(如基于MD5或SHA的MAC算法)进行签名，产生摘要并与接收得到的摘要作对比，校验数据的完整性。
如果二者相同，则报文没有改变；否则，报文在传输过程中被修改，，接收端(客户端或服务器)将丢弃该报文。
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。
参照图4，示出了本申请的一种在SSL/TLS通信中加载数字证书的装置实施例的结构框图，具体可以包括如下模块：
握手请求消息接收模块401，用于接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；
客户端信息验证模块402，用于根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；
数字证书匹配模块403，用于判断所述密钥交换方式和所述第一签名方式、是否与当前加载的数字证书匹配；若否，则调用数字证书加载模块404；
数字证书加载模块404，加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；
握手响应消息返回模块405，用于根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。
在本申请的一个实施例中，所述客户端信息验证模块402可以包括如下子模块：
密码套件查找子模块，用于从所述握手请求消息中查找密码套件；
密码套件识别子模块，用于从所述密码套件中识别客户端支持的密钥交换方式和第一签名方式；
在本申请的一个实施例中，所述客户端信息验证模块402还可以包括如下子模块：
扩展头查找子模块，用于从所述握手请求中查找传输层安全协议TLS的扩展头；
扩展头识别子模块，用于从所述扩展头中识别客户端支持的第一签名方式。
在具体实现中，所验证的第一签名方式可以为客户端的加密强度最高的第一签名方式。
在实际应用中，所述数字证书可以按照公钥的类型划分分组，在每个分组中加载其中一个数字证书，当前加载的数字证书可以为所属分组中加密强度最高的数字证书。
在本申请的一个实施例中，所述数字证书匹配模块404可以包括如下子模块：
公钥查找子模块，用于查找与所述密钥交换方式匹配的公钥；
当前签名方式识别子模块，用于识别在所述公钥所属的分组中当前加载的数字证书的第二签名方式；
第一签名方式匹配子模块，用于判断所述第一签名方式是否与所述第二签名方式匹配；若是，则调用第一判定子模块，若否，则调用第二判定子模块；
第一判定子模块，用于判定所述密钥交换方式和所述签名方式、与当前加载的数字证书匹配；
第二判定子模块，用于判定所述密钥交换方式和所述签名方式、与当前加载的数字证书不匹配。
在本申请的一个实施例中，所述数字证书加载模块405可以包括如下子模块：
其他签名方式识别子模块，用于识别在所述公钥所属的分组中其他数字证书的第三签名方式；
第二签名方式匹配子模块，用于判断所述第三签名方式是否与所述第一签名方式匹配；若是，则调用数字证书替换子模块；
数字证书替换子模块，用于加载所述第三签名方式所属的数字证书，以替换在所述公钥所属的分组中当前加载的数字证书。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软 件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种在SSL/TLS通信中加载数字证书的方法和一种在SSL/TLS通信中加载数字证书的装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (13)

  1. 一种在SSL或TLS通信中加载数字证书的方法，其特征在于，包括：
    接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；
    根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；
    判断所述密钥交换方式和所述第一签名方式是否与当前加载的数字证书匹配；若否，则加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；
    根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。
  2. 根据权利要求1所述的方法，其特征在于，所述根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式的步骤包括：
    从所述握手请求消息中查找密码套件；
    从所述密码套件中识别客户端支持的密钥交换方式和第一签名方式。
  3. 根据权利要求2所述的方法，其特征在于，所述根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式的步骤还包括：
    从所述握手请求中查找传输层安全协议TLS的扩展头；
    从所述扩展头中识别客户端支持的第一签名方式。
  4. 根据权利要求1或2或3所述的方法，其特征在于，所验证的第一签名方式为客户端的加密强度最高的第一签名方式。
  5. 根据权利要求1或2或3所述的方法，其特征在于，所述数字证书按照公钥的类型划分分组，在每个分组中加载其中一个数字证书，当前加载的数字证书为所属分组中加密强度最高的数字证书。
  6. 根据权利要求5所述的方法，其特征在于，所述判断所述密钥交换方式和所述签名方式是否与当前加载的数字证书匹配的步骤包括：
    查找与所述密钥交换方式匹配的公钥；
    识别在所述公钥所属的分组中当前加载的数字证书的第二签名方式；
    判断所述第一签名方式是否与所述第二签名方式匹配；
    若是，则判定所述密钥交换方式和所述签名方式与当前加载的数字证书匹配；
    若否，则判定所述密钥交换方式和所述签名方式与当前加载的数字证书不匹配。
  7. 根据权利要求6所述的方法，其特征在于，所述加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书的步骤包括：
    识别在所述公钥所属的分组中其他数字证书的第三签名方式；
    判断所述第三签名方式是否与所述第一签名方式匹配；
    若是，则加载所述第三签名方式所属的数字证书，以替换在所述公钥所属的分组中当前加载的数字证书。
  8. 一种在SSL或TLS通信中加载数字证书的装置，其特征在于，包括：
    握手请求消息接收模块，用于接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；
    客户端信息验证模块，用于根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；
    数字证书匹配模块，用于判断所述密钥交换方式和所述第一签名方式是否与当前加载的数字证书匹配；若否，则调用数字证书加载模块；
    数字证书加载模块，加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；
    握手响应消息返回模块，用于根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。
  9. 根据权利要求8所述的装置，其特征在于，所述客户端信息验证模块包括：
    密码套件查找子模块，用于从所述握手请求消息中查找密码套件；
    密码套件识别子模块，用于从所述密码套件中识别客户端支持的密钥交换方式和第一签名方式。
  10. 根据权利要求9所述的装置，其特征在于，所述客户端信息验证模块还包括：
    扩展头查找子模块，用于从所述握手请求中查找传输层安全协议TLS的扩展头；
    扩展头识别子模块，用于从所述扩展头中识别客户端支持的第一签名方式。
  11. 根据权利要求8或9或10所述的装置，其特征在于，所述数字证书按照公钥的类型划分分组，在每个分组中加载其中一个数字证书，当前加载的数字证书为所属分组中加密强度最高的数字证书。
  12. 根据权利要求11所述的装置，其特征在于，所述数字证书匹配模块包括：
    公钥查找子模块，用于查找与所述密钥交换方式匹配的公钥；
    当前签名方式识别子模块，用于识别在所述公钥所属的分组中当前加载的数字证书的第二签名方式；
    第一签名方式匹配子模块，用于判断所述第一签名方式是否与所述第二签名方式匹配；若是，则调用第一判定子模块，若否，则调用第二判定子模块；
    第一判定子模块，用于判定所述密钥交换方式和所述签名方式与当前加载的数字证书匹配；
    第二判定子模块，用于判定所述密钥交换方式和所述签名方式与当前加载的数字证书不匹配。
  13. 根据权利要求12所述的装置，其特征在于，所述数字证书加载模块包括：
    其他签名方式识别子模块，用于识别在所述公钥所属的分组中其他数字证书的第三签名方式；
    第二签名方式匹配子模块，用于判断所述第三签名方式是否与所述第一签名方式匹配；若是，则调用数字证书替换子模块；
    数字证书替换子模块，用于加载所述第三签名方式所属的数字证书，以替换在所述公钥所属的分组中当前加载的数字证书。
PCT/CN2016/098186 2015-09-15 2016-09-06 一种在ssl或tls通信中加载数字证书的方法和装置 Ceased WO2017045552A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510587689.7 2015-09-15
CN201510587689.7A CN106533689B (zh) 2015-09-15 2015-09-15 一种在ssl/tls通信中加载数字证书的方法和装置

Publications (1)

Publication Number Publication Date
WO2017045552A1 true WO2017045552A1 (zh) 2017-03-23

Family

ID=58288106

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/098186 Ceased WO2017045552A1 (zh) 2015-09-15 2016-09-06 一种在ssl或tls通信中加载数字证书的方法和装置

Country Status (2)

Country Link
CN (1) CN106533689B (zh)
WO (1) WO2017045552A1 (zh)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108040071A (zh) * 2017-12-30 2018-05-15 深圳市潮流网络技术有限公司 一种VoIP音视频加密密钥动态切换方法
CN111771357A (zh) * 2019-01-31 2020-10-13 深圳市汇顶科技股份有限公司 Tls证书认证方法、装置、设备及存储介质
CN112235235A (zh) * 2020-08-28 2021-01-15 中国大唐集团科学技术研究院有限公司 一种基于国密算法的sdp认证协议实现方法
CN112532390A (zh) * 2019-08-30 2021-03-19 华为技术有限公司 加载数字证书认证机构证书的方法及装置
CN113364776A (zh) * 2021-06-04 2021-09-07 北银金融科技有限责任公司 一种验证区块链节点使用国密算法通信的方法和系统
CN113746807A (zh) * 2021-08-11 2021-12-03 北银金融科技有限责任公司 一种区块链节点支持国密算法通信检测方法
CN114448729A (zh) * 2022-04-07 2022-05-06 中国信息通信研究院 工业互联网中客户端的身份认证方法和装置
CN114830602A (zh) * 2019-12-17 2022-07-29 微芯片技术股份有限公司 用于低吞吐量通信链路的系统的相互认证协议及用于执行该协议的设备
CN115021932A (zh) * 2022-05-30 2022-09-06 支付宝(杭州)信息技术有限公司 用于tlcp协议的握手过程的身份验证方法
CN115714681A (zh) * 2022-11-11 2023-02-24 中国联合网络通信集团有限公司 数据验证方法、装置及存储介质
CN117560718A (zh) * 2024-01-11 2024-02-13 广东广宇科技发展有限公司 一种基于群智感知的消防物联网远程监测方法
CN119167110A (zh) * 2024-11-20 2024-12-20 吉林森亿智能科技有限公司 一种基于规则引擎的互联网领域客户指标计算方法和系统
CN119496613A (zh) * 2024-12-02 2025-02-21 中电科网络安全科技股份有限公司 一种后量子tlcp协议设计方法、装置、设备及介质
CN119892871A (zh) * 2024-12-28 2025-04-25 国网辽宁省电力有限公司锦州供电公司 一种基于json格式的智能运维通信方法
US12556611B2 (en) 2023-03-13 2026-02-17 Microchip Technology Incorporated Addressing and routing for devices using connectivity framework for embedded connectivity

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2561822B (en) 2017-04-13 2020-02-19 Arm Ip Ltd Reduced bandwidth handshake communication
CN106936848A (zh) * 2017-04-19 2017-07-07 武汉票据交易中心有限公司 一种服务器的socket加密通信方法
CN109302369B (zh) * 2017-07-24 2021-03-16 贵州白山云科技股份有限公司 一种基于密钥验证的数据传输方法及装置
CN108566361B (zh) * 2018-01-05 2020-08-21 武汉信安珞珈科技有限公司 一种基于ssl/tls协议的安全参数协商方法和系统
CN108429615A (zh) * 2018-01-10 2018-08-21 如般量子科技有限公司 一种基于量子密钥的Stunnel通信方法和Stunnel通信系统
CN108833541A (zh) * 2018-06-15 2018-11-16 北京奇安信科技有限公司 一种识别终端信息的方法及装置
CN109905239A (zh) * 2019-03-07 2019-06-18 亚数信息科技（上海）有限公司 一种证书管理方法及装置
CN111917694B (zh) * 2019-05-09 2023-02-28 中兴通讯股份有限公司 一种tls加密流量识别方法及装置
CN110971616B (zh) * 2019-12-24 2022-04-01 广州市百果园信息技术有限公司 基于安全传输层协议的连接建立方法、客户端和服务器
CN111064738B (zh) * 2019-12-26 2022-09-30 山东方寸微电子科技有限公司 一种tls安全通信的方法及系统
EP3866428B1 (en) * 2020-02-13 2021-12-29 Axis AB A method for re-provisioning a digital security certificate and a system and a non-transitory computer program product thereof
CN113328980B (zh) * 2020-02-29 2022-05-17 杭州迪普科技股份有限公司 Tls认证方法、装置、系统、电子设备及可读介质
CN114124368B (zh) * 2020-08-31 2023-04-14 Oppo广东移动通信有限公司 一种数据传输方法、客户端、服务端及存储介质
CN112422530B (zh) * 2020-11-04 2023-05-30 无锡沐创集成电路设计有限公司 Tls握手过程中服务器端的密钥安全保护方法及密码设备
CN114666070A (zh) * 2020-12-04 2022-06-24 华为技术有限公司 一种权限认证方法、权限信息的处理方法及装置
CN112637348B (zh) * 2020-12-23 2022-05-10 北京金山云网络技术有限公司 一种连接建立方法、装置、系统及电子设备
CN112906063B (zh) * 2021-02-26 2024-04-26 杭州萤石软件有限公司 一种数字摘要算法处理设备方法、装置、系统及设备
CN113037480A (zh) * 2021-03-25 2021-06-25 北京华宇信息技术有限公司 基于jsse的国密加密通信方法及其装置、存储介质
CN114006724B (zh) * 2021-09-18 2023-08-29 中国互联网络信息中心 一种加密dns解析器发现及认证的方法与系统
CN113872990B (zh) * 2021-10-19 2023-06-30 南方电网数字电网研究院有限公司 基于ssl协议的vpn网络证书认证方法、装置和计算机设备
CN114048456A (zh) * 2021-11-19 2022-02-15 杭州安恒信息技术股份有限公司 一种数字证书的验证方法、装置、设备及可读存储介质
CN115150067B (zh) * 2022-05-10 2025-03-25 北京理工大学 一种基于网络隐蔽通道的tls协议构建方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101127604A (zh) * 2007-09-25 2008-02-20 中兴通讯股份有限公司 信息安全传输方法和系统
CN101770619A (zh) * 2008-12-31 2010-07-07 中国银联股份有限公司 一种用于网上支付的多因子认证方法和认证系统
CN103607417A (zh) * 2012-12-03 2014-02-26 深圳市证通电子股份有限公司 支持ssl协议的网络服务器
US8782774B1 (en) * 2013-03-07 2014-07-15 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
CN104639534A (zh) * 2014-12-30 2015-05-20 北京奇虎科技有限公司 网站安全信息的加载方法和浏览器装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009091611A1 (en) * 2008-01-18 2009-07-23 Identrust, Inc. Binding a digital certificate to multiple trust domains
CN101325519B (zh) * 2008-06-05 2011-02-16 成都市华为赛门铁克科技有限公司 基于安全协议的内容审计方法、系统和内容审计设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101127604A (zh) * 2007-09-25 2008-02-20 中兴通讯股份有限公司 信息安全传输方法和系统
CN101770619A (zh) * 2008-12-31 2010-07-07 中国银联股份有限公司 一种用于网上支付的多因子认证方法和认证系统
CN103607417A (zh) * 2012-12-03 2014-02-26 深圳市证通电子股份有限公司 支持ssl协议的网络服务器
US8782774B1 (en) * 2013-03-07 2014-07-15 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
CN104639534A (zh) * 2014-12-30 2015-05-20 北京奇虎科技有限公司 网站安全信息的加载方法和浏览器装置

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108040071A (zh) * 2017-12-30 2018-05-15 深圳市潮流网络技术有限公司 一种VoIP音视频加密密钥动态切换方法
CN108040071B (zh) * 2017-12-30 2023-02-17 深圳市潮流网络技术有限公司 一种VoIP音视频加密密钥动态切换方法
CN111771357B (zh) * 2019-01-31 2022-05-24 深圳市汇顶科技股份有限公司 Tls证书认证方法、装置、设备及存储介质
CN111771357A (zh) * 2019-01-31 2020-10-13 深圳市汇顶科技股份有限公司 Tls证书认证方法、装置、设备及存储介质
CN112532390A (zh) * 2019-08-30 2021-03-19 华为技术有限公司 加载数字证书认证机构证书的方法及装置
CN114830602A (zh) * 2019-12-17 2022-07-29 微芯片技术股份有限公司 用于低吞吐量通信链路的系统的相互认证协议及用于执行该协议的设备
US12088741B2 (en) 2019-12-17 2024-09-10 Microchip Technology Incorporated Mutual authentication protocol for systems with low-throughput communication links, and devices for performing the same
CN112235235A (zh) * 2020-08-28 2021-01-15 中国大唐集团科学技术研究院有限公司 一种基于国密算法的sdp认证协议实现方法
CN112235235B (zh) * 2020-08-28 2023-09-22 中国大唐集团科学技术研究院有限公司 一种基于国密算法的sdp认证协议实现方法
CN113364776A (zh) * 2021-06-04 2021-09-07 北银金融科技有限责任公司 一种验证区块链节点使用国密算法通信的方法和系统
CN113746807A (zh) * 2021-08-11 2021-12-03 北银金融科技有限责任公司 一种区块链节点支持国密算法通信检测方法
CN114448729A (zh) * 2022-04-07 2022-05-06 中国信息通信研究院 工业互联网中客户端的身份认证方法和装置
CN114448729B (zh) * 2022-04-07 2022-06-07 中国信息通信研究院 工业互联网中客户端的身份认证方法和装置
CN115021932A (zh) * 2022-05-30 2022-09-06 支付宝(杭州)信息技术有限公司 用于tlcp协议的握手过程的身份验证方法
CN115714681A (zh) * 2022-11-11 2023-02-24 中国联合网络通信集团有限公司 数据验证方法、装置及存储介质
CN115714681B (zh) * 2022-11-11 2024-05-14 中国联合网络通信集团有限公司 数据验证方法、装置及存储介质
US12556611B2 (en) 2023-03-13 2026-02-17 Microchip Technology Incorporated Addressing and routing for devices using connectivity framework for embedded connectivity
US12580990B2 (en) 2023-03-13 2026-03-17 Microchip Technology Incorporated Connectivity framework having unified stack and messaging protocol for embedded secure connectivity
CN117560718B (zh) * 2024-01-11 2024-04-09 广东广宇科技发展有限公司 一种基于群智感知的消防物联网远程监测方法
CN117560718A (zh) * 2024-01-11 2024-02-13 广东广宇科技发展有限公司 一种基于群智感知的消防物联网远程监测方法
CN119167110A (zh) * 2024-11-20 2024-12-20 吉林森亿智能科技有限公司 一种基于规则引擎的互联网领域客户指标计算方法和系统
CN119167110B (zh) * 2024-11-20 2025-03-11 吉林森亿智能科技有限公司 一种基于规则引擎的互联网领域客户指标计算方法和系统
CN119496613A (zh) * 2024-12-02 2025-02-21 中电科网络安全科技股份有限公司 一种后量子tlcp协议设计方法、装置、设备及介质
CN119496613B (zh) * 2024-12-02 2025-09-16 中电科网络安全科技股份有限公司 一种后量子tlcp协议设计方法、装置、设备及介质
CN119892871A (zh) * 2024-12-28 2025-04-25 国网辽宁省电力有限公司锦州供电公司 一种基于json格式的智能运维通信方法

Also Published As

Publication number Publication date
CN106533689B (zh) 2019-07-30
CN106533689A (zh) 2017-03-22

Similar Documents

Publication Publication Date Title
CN106533689B (zh) 一种在ssl/tls通信中加载数字证书的方法和装置
US11985239B2 (en) Forward secrecy in transport layer security (TLS) using ephemeral keys
JP7215684B2 (ja) 部分的に信頼できる第三者機関を通しての鍵交換
US12401505B2 (en) Agile cryptographic deployment service
JP7836879B2 (ja) トランスポート層セキュリティおよび他のコンテキストでのデータの検証のための非集中型技術
CN109347835B (zh) 信息传输方法、客户端、服务器以及计算机可读存储介质
RU2718689C2 (ru) Управление конфиденциальной связью
CN104580189B (zh) 一种安全通信系统
US10963593B1 (en) Secure data storage using multiple factors
CN106464496B (zh) 用于创建对用户身份鉴权的证书的方法和系统
WO2016107320A1 (zh) 网站安全信息的加载方法和浏览器装置
CN104580190B (zh) 安全浏览器的实现方法和安全浏览器装置
KR20210134655A (ko) 보안 시스템 및 관련 방법
US20160119291A1 (en) Secure communication channel with token renewal mechanism
KR102128244B1 (ko) Ssl/tls 기반의 네트워크 보안 장치 및 방법
US20200162245A1 (en) Method and system for performing ssl handshake
TW201742399A (zh) 資料安全傳輸方法、客戶端及服務端方法、裝置及系統
CN106790090A (zh) 基于ssl的通信方法、装置及系统
CN104170312A (zh) 用于使用硬件安全引擎通过网络进行安全通信的方法和设备
WO2016112580A1 (zh) 业务处理方法及装置
JP2022545809A (ja) 暗号鍵生成のためのセキュアな環境
CN110519304A (zh) 基于tee的https双向认证方法
WO2019223232A1 (zh) 实现交易信息验证的方法和装置
JP7772310B2 (ja) ネットワーク通信方法、装置、コンピュータ機器及びコンピュータプログラム
WO2019223231A1 (zh) 实现交易信息验证的方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16845666

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16845666

Country of ref document: EP

Kind code of ref document: A1