CN113438071B - Method and device for secure communication - Google Patents

Method and device for secure communication Download PDF

Info

Publication number
CN113438071B
CN113438071B CN202110594366.6A CN202110594366A CN113438071B CN 113438071 B CN113438071 B CN 113438071B CN 202110594366 A CN202110594366 A CN 202110594366A CN 113438071 B CN113438071 B CN 113438071B
Authority
CN
China
Prior art keywords
server
client
key
http
message
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.)
Active
Application number
CN202110594366.6A
Other languages
Chinese (zh)
Other versions
CN113438071A (en
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.)
Honor Device Co Ltd
Original Assignee
Honor Device Co 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 Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202110594366.6A priority Critical patent/CN113438071B/en
Publication of CN113438071A publication Critical patent/CN113438071A/en
Application granted granted Critical
Publication of CN113438071B publication Critical patent/CN113438071B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

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)
  • Computer And Data Communications (AREA)

Abstract

The application provides a method and equipment for secure communication, and relates to the technical field of channel encryption communication. The method can be applied to the client, and comprises the following steps: sending a first HTTP request message to a server, wherein an extension field of a header of the first HTTP request message comprises a first key negotiation parameter; receiving a first HTTP response message sent by the server, wherein an extension field of a header of the first HTTP response message comprises a second key negotiation parameter; and generating a negotiation key according to the first key negotiation parameter and the second key negotiation parameter, wherein the negotiation key is used for the client and the server to carry out encrypted communication. According to the method, the client and the server can realize secure communication based on the HTTP protocol by carrying the related parameters for generating the negotiation key in the extension field of the HTTP message header, so that the problem that specific data cannot be encrypted in a targeted manner during HTTP communication is solved.

Description

Method and device for secure communication
Technical Field
The present disclosure relates to the field of channel encryption communications, and in particular, to a method and apparatus for secure communications.
Background
Currently, in a communication scenario based on the hypertext transfer protocol (hyper text transfer protocol, HTTP) protocol, in order to achieve secure communication between a client and a server, a manner of upgrading HTTP to the hypertext transfer security protocol (hyper texttransfer protocol over securesocketlayer, HTTPs) is generally adopted. HTTPS relies on secure sockets (secure sockets layer, SSL) protocol or transport layer security (transport layer security, TLS) protocol to establish a secure channel, complete encryption of transmission contents, and guarantee security of data transmission. The existing HTTPS encryption method encrypts both the header and the entity of the data packet, but cannot accurately encrypt only specific data to be encrypted.
However, in many cases, the header of the message has more data and no encryption is necessary, and only the entity data is important to be encrypted, so that the conventional HTTPS encryption method performs indiscriminate encryption on the transmitted data message, which results in reduced communication efficiency.
Disclosure of Invention
The application provides a method and equipment for secure communication, which enable a client and a service terminal to realize secure communication based on an HTTP protocol by carrying relevant parameters for generating a negotiation key in an extension field of an HTTP message header, so as to solve the problem that specific data cannot be encrypted in a targeted manner during HTTP communication.
In a first aspect, a method for secure communication is provided, applied to a client, including: sending a first HTTP request message to a server, wherein an extension field of the header of the first HTTP request message comprises a first key negotiation parameter; receiving a first HTTP response message sent by the server, wherein an extension field of the header of the first HTTP response message comprises a second key negotiation parameter; generating a negotiation key according to the first key negotiation parameter and the second key negotiation parameter, wherein the negotiation key is used for carrying out encrypted communication between the client and the server; and generating an HTTP encrypted message according to the negotiation key, and sending the HTTP encrypted message to the server, wherein an extension field of the HTTP encrypted message head comprises first encryption strategy information, and the first encryption strategy information is used for indicating the type of encrypted data or the position of the encrypted data in the HTTP encrypted message.
The negotiation key may be, for example, a master key used by the client and the server for encryption when the client and the server communicate based on HTTP, where the negotiation key is used to encrypt data in the secure communication process of the client and the server based on HTTP protocol.
According to the method for secure communication provided by the implementation mode of the application, the relevant parameters for calculating and generating the negotiation key by the client and the server are carried in the extension field of the header of the HTTP request message and/or the HTTP response message, so that the client and the server can negotiate and generate the key in the process of communication based on the HTTP protocol, the secure communication is realized on the basis of the HTTP communication architecture, and the requirements of users for accuracy and high efficiency of data encryption are met. In addition, by carrying encryption strategy information indicating the type or the position of the encrypted data in the extension field of the message header, the opposite terminal can efficiently and accurately decrypt the encrypted data based on the indication information and smoothly read the message, thereby improving the communication efficiency.
With reference to the first aspect, in some implementations of the first aspect, the generating an HTTP encrypted message according to the negotiation key specifically includes: encrypting the data of the target type in the HTTP encryption message according to the negotiation key; or encrypting the data of the target position in the HTTP encrypted message according to the negotiation key.
The type of the encrypted data to be encrypted may include, for example, important data such as parameters related to the negotiation generation key.
The data encrypted using the negotiation key may include, for example, entity data (whole or part of entity data) of the HTTP encrypted message, or may also include data of the HTTP encrypted message header. In other words, after the negotiation key is obtained, the client (or the server) can pertinently encrypt the specific data according to the communication requirement or the data type.
According to the method for secure communication provided by the implementation mode of the application, the specific data can be encrypted in a targeted manner, the encryption is more flexible, different encryption requirements can be met, encryption computing resources can be saved on the basis of guaranteeing the security of important data, and the efficiency of secure communication is improved.
With reference to the first aspect, in certain implementations of the first aspect, the data of the target type includes at least one of: parameters of key negotiation, encryption algorithm set, certificate of the client or the server, and encryption policy information.
With reference to the first aspect, in certain implementations of the first aspect, the data of the target location includes at least one of: partial data positioned at the head of the second HTTP request message; or, part of data located in the entity part of the second HTTP request message; or, the whole data in the entity part of the second HTTP request message is located.
With reference to the first aspect, in certain implementation manners of the first aspect, the extension field of the HTTP encrypted packet header further includes second encryption policy information, where the second encryption policy information is used to instruct the server to encrypt the data of the target type and/or encrypt the data of the target location.
According to the method for secure communication provided by the implementation mode of the application, the communication opposite end is informed of the encryption strategy, so that the communication opposite end can encrypt specific data by adopting the same communication strategy, and the encryption and decryption efficiency of the communication opposite end in the communication process is improved.
With reference to the first aspect, in certain implementation manners of the first aspect, the extension field of the HTTP encrypted packet header further includes third encryption policy information, where the third encryption policy information is used to indicate at least one of the following information: after the negotiation key is generated, encrypting the message transmitted between the server and the client each time; or, after generating the negotiation key, regenerating the new negotiation key every N transmission intervals, where N is an integer greater than 1.
According to the method for secure communication provided by the implementation mode of the application, the opposite terminal encryption strategy is notified, so that the two communication terminals can communicate or update the negotiation key according to the same strategy, and the secure communication is ensured to be carried out smoothly.
With reference to the first aspect, in certain implementation manners of the first aspect, the extension field of the first HTTP response message header further includes a certificate of the server, where the certificate of the server includes a public key of the server, and the method further includes: authenticating the certificate of the server and acquiring a public key of the server; generating a premaster secret key of the client according to the public key of the server; and sending a second HTTP request message to the server, wherein an extension field of the header of the second HTTP request message comprises the premaster secret key.
It should be understood that, in the implementation manner of the present application, the extension fields of the HTTP request packet and/or the header of the HTTP response packet may be customized according to the communication requirements, for example, may carry parameters related to the generation of the key, etc. Therefore, the client and the server can realize encrypted communication when communicating based on the HTTP protocol, and the information security problem existing in the conventional HTTP plaintext communication mode is solved.
According to the method for secure communication provided by the implementation mode of the application, the client and the service end can realize secure communication based on the HTTP protocol by carrying the parameter of the negotiation generation key in the extension field in the message header of the HTTP request message or the HTTP response message, and the message or the specific data in the message transmitted each time can be flexibly encrypted according to the need, so that the communication efficiency is further improved on the basis of ensuring the secure communication.
With reference to the first aspect, in some implementations of the first aspect, the first key negotiation parameter is a first random number generated by the client, and the second key negotiation parameter is a second random number generated by the server; the generating a negotiation key according to the first key negotiation parameter and the second key negotiation parameter specifically includes: and generating the negotiation key according to the first random number, the second random number and the premaster secret key.
The first key negotiation parameter, the second key negotiation parameter and the premaster key all belong to related parameters for generating the negotiation key, and can be used for generating the negotiation key by the client and the server. The first key agreement parameter may be, for example, a random number, such as random-C, randomly generated by the client; the second key may be, for example, a random number randomly generated by the server, such as random-S; the premaster secret may be encrypted data generated by the client encrypting a random number based on the public key of the server.
According to the method for secure communication provided by the implementation mode of the application, the client and the service end can realize secure communication based on the HTTP protocol by carrying the parameter of the negotiation generation key in the extension field in the message header of the HTTP request message or the HTTP response message, and the message or the specific data in the message transmitted each time can be flexibly encrypted according to the need, so that the communication efficiency is further improved on the basis of ensuring the secure communication.
With reference to the first aspect, in certain implementation manners of the first aspect, the extension field of the first HTTP request message header further includes a set of encryption algorithms supported by the client.
Wherein the set of encryption algorithms may comprise at least one encryption algorithm supported by the client. The encryption algorithm set is used for the server to select the encryption algorithm which is also supported by the server, such as a first encryption algorithm, so that the client and the server can calculate the negotiation key according to the first encryption algorithm.
According to the method for secure communication provided by the implementation mode of the application, the client sends the encryption algorithm set to the server, so that the server can conveniently select the encryption algorithm supported by the server and the client from the encryption algorithm set, the client or the server can successfully calculate the negotiation key based on the encryption algorithm, and the success rate and the efficiency of calculation of the negotiation key are improved.
With reference to the first aspect, in certain implementation manners of the first aspect, the extension field of the first HTTP response message header further includes a first encryption algorithm, where the first encryption algorithm is any encryption algorithm supported by the server in the encryption algorithm set.
The first encryption algorithm may be an encryption algorithm which is also supported by the server and selected from the set of encryption algorithms, that is, the first encryption algorithm is an encryption algorithm supported by both the client and the server.
According to the method for secure communication provided by the implementation mode of the application, the first encryption algorithm supported by the server side is selected, the client side is informed of the selected first encryption algorithm, the client side and the server side can use the same encryption algorithm to calculate the negotiation key later, and the consistency of the master key obtained by calculation of the client side and the server side is guaranteed, so that the encrypted secure communication based on the HTTP protocol is realized.
With reference to the first aspect, in certain implementation manners of the first aspect, when the extension field of the first HTTP response message header further includes a certificate request, the certificate request is used to request a certificate of the client, the extension field of the second HTTP request message header further includes the certificate of the client.
In a second aspect, a method for secure communication is provided, applied to a server, and includes: receiving a first HTTP request message sent by a client, wherein an extension field of a header of the first HTTP request message comprises a first key negotiation parameter of the client; responding to the first HTTP request message, sending a first HTTP response message to the client, wherein an extension field of a header of the first HTTP response message comprises a second key negotiation parameter of the server and a certificate of the server, and the certificate of the server comprises a public key of the server; receiving a second HTTP request message sent by the client, wherein a header extension field of the second HTTP request message comprises a premaster secret key of the client; generating a negotiation key according to the first key negotiation parameter, the second key negotiation parameter and the premaster key, wherein the negotiation key is used for carrying out encrypted communication between the client and the server.
The negotiation key may be, for example, a master key used by the client and the server for encryption when the client and the server communicate based on HTTP, where the negotiation key is used to encrypt data in the secure communication process of the client and the server based on HTTP protocol.
According to the method for secure communication provided by the implementation mode of the application, the relevant parameters for calculating and generating the negotiation key by the client and the server are carried in the extension field of the header of the HTTP request message and/or the HTTP response message, so that the client and the server can negotiate and generate the key in the process of communication based on the HTTP protocol, the secure communication is realized on the basis of the HTTP communication architecture, and the requirements of users for accuracy and high efficiency of data encryption are met.
With reference to the second aspect, in certain implementations of the second aspect, the method further includes: receiving an HTTP encrypted message sent by the client, wherein an extension field of the header of the HTTP encrypted message comprises first encryption strategy information, and the first encryption strategy information is used for indicating the type of the encrypted data or the position of the encrypted data; and decrypting the encrypted data according to the first encryption strategy information.
The type of the encrypted data to be encrypted may include, for example, important data such as parameters related to the negotiation generation key.
The data encrypted using the negotiation key may include, for example, entity data (whole or part of entity data) of the HTTP encrypted message, or may also include data of the HTTP encrypted message header. In other words, after the negotiation key is obtained, the client (or the server) can pertinently encrypt the specific data according to the communication requirement or the data type.
According to the method for secure communication provided by the implementation mode of the application, the encryption strategy information indicating the encrypted data is carried in the extension field of the message header, so that the opposite terminal can efficiently and accurately decrypt the encrypted data based on the indication information, and the message is read smoothly, thereby improving the communication efficiency.
With reference to the second aspect, in some implementations of the second aspect, the extension field of the HTTP encrypted packet header further includes second encryption policy information, where the second encryption policy information is used to instruct the server to encrypt the target type of data and/or encrypt the target location of data, and the method further includes: and encrypting the data of the target type and/or the data of the target position according to the second encryption strategy information and the negotiation key.
With reference to the second aspect, in certain implementations of the second aspect, the data of the target type includes at least one of: parameters of key negotiation, encryption algorithm set, certificate of the client or the server, and encryption policy information.
With reference to the second aspect, in certain implementations of the second aspect, the data of the target location includes at least one of: partial data positioned at the head of the HTTP encrypted message; or, part of data located in the HTTP encrypted message entity part; or, all data in the physical part of the HTTP encryption message.
With reference to the second aspect, in certain implementation manners of the second aspect, the extension field of the HTTP encrypted packet header further includes third encryption policy information, where the third encryption policy information is used to indicate at least one of the following information: after the negotiation key is generated, encrypting the message transmitted between the server and the client each time; or, after generating the negotiation key, regenerating the new negotiation key every N transmission intervals, where N is an integer greater than 1.
With reference to the second aspect, in some implementations of the second aspect, the first key negotiation parameter is a first random number generated by the client, and the second key negotiation parameter is a second random number generated by the server.
According to the method for secure communication provided by the implementation mode of the application, the first encryption algorithm supported by the server side is selected, the client side is informed of the selected first encryption algorithm, the client side and the server side can use the same encryption algorithm to calculate the negotiation key later, and the consistency of the master key obtained by calculation of the client side and the server side is guaranteed, so that the encrypted secure communication based on the HTTP protocol is realized.
With reference to the second aspect, in certain implementations of the second aspect, the extension field of the first HTTP request packet header further includes a set of encryption algorithms supported by the client, and the method further includes: and selecting a first encryption algorithm supported by the server according to the encryption algorithm set.
Wherein the set of encryption algorithms may comprise at least one encryption algorithm supported by the client. The encryption algorithm set is used for the server to select the encryption algorithm which is also supported by the server, such as a first encryption algorithm, so that the client and the server can calculate the negotiation key according to the first encryption algorithm.
According to the method for secure communication provided by the implementation mode of the application, the client sends the encryption algorithm set to the server, so that the server can conveniently select the encryption algorithm supported by the server and the client from the encryption algorithm set, the client or the server can successfully calculate the negotiation key based on the encryption algorithm, and the success rate and the efficiency of calculation of the negotiation key are improved.
With reference to the second aspect, in certain implementations of the second aspect, the extension field of the first HTTP response message header further includes certificate request information, where the certificate request information is used to request a certificate of the client.
With reference to the second aspect, in certain implementations of the second aspect, the second HTTP request message further includes a certificate of the client, and the method further includes: and verifying the identity of the client according to the certificate of the client.
According to the method for secure communication provided by the implementation mode of the application, the identity of the communication terminal is verified through the certificate, and the client (or the server) can be ensured to be legal, so that the security of the communication process is ensured. With reference to the second aspect, in certain implementations of the second aspect, the HTTP encrypted packet header extension field further includes an encryption policy of the negotiation key, where the encryption policy includes at least one of: after the negotiation key is generated, encrypting the message transmitted between the server and the client each time; or, after generating the negotiation key, regenerating a new negotiation key every N transmission intervals; or when the message transmitted between the server and the client comprises the data of the target type, encrypting the data of the target type by using the negotiation key.
According to the method for secure communication provided by the implementation mode of the application, after the negotiation key is acquired, the client (or the server) can pertinently encrypt specific data according to communication needs or data types and the like, encryption is more flexible, and different encryption requirements can be met.
In a third aspect, there is provided a client device comprising at least one processor, a memory and a communication interface for communicating with other devices, the memory comprising computer program instructions which, when executed in the processor, cause the client device to implement a method of secure communication as described in any of the implementations of the first aspect above.
In a fourth aspect, there is provided a server device comprising at least one processor, a memory and a communication interface for communicating with other devices, the memory comprising computer program instructions which, when executed in the processor, cause the client device to implement a method of secure communication as described in any of the above second aspects.
In a fifth aspect, a system for secure communication is provided, comprising a client device for performing the method for secure communication according to any of the implementation forms of the first aspect as described above, and a server device for performing the method for secure communication according to any of the implementation forms of the second aspect as described above.
In a sixth aspect, there is provided a computer readable storage medium storing a computer executable program which, when invoked by a computer, causes the computer to perform a method as described in any one of the above first aspects or to perform a method as described in any one of the above second aspects.
In a seventh aspect, there is provided a chip system comprising: a communication interface for inputting and/or outputting information; a memory for storing a computer executable program; a processor for executing the extreme and executable program to cause a device on which the chip system is installed to perform the method as described in any of the implementations of the first aspect or to perform the method as described in any of the implementations of the second aspect.
In an eighth aspect, there is provided a computer program product comprising computer program instructions which, when run on a computer, cause the computer to implement a method as in any of the above-described implementations of the first aspect or to implement a method as in any of the above-described implementations of the second aspect.
Drawings
Fig. 1 is a schematic diagram of a system architecture for secure communication according to an embodiment of the present application.
Fig. 2 is a schematic structural diagram of an electronic device in communication based on HTTP protocol according to an embodiment of the present application.
Fig. 3 is a schematic structural diagram of an electronic device in communication based on HTTPS protocol according to an embodiment of the present application.
Fig. 4 is a schematic diagram of a message structure according to an embodiment of the present application.
Fig. 5 is a schematic diagram of another message structure provided in an embodiment of the present application.
Fig. 6 is a schematic flow chart diagram of another method of secure communication provided by an embodiment of the present application.
Fig. 7 is a schematic flow chart diagram of yet another method of secure communication provided by an embodiment of the present application.
Fig. 8 is a schematic structural diagram of a client device according to an embodiment of the present application.
Fig. 9 is a schematic structural diagram of a server device according to an embodiment of the present application.
Fig. 10 is a schematic structural diagram of another client device according to an embodiment of the present application.
Fig. 11 is a schematic structural diagram of another server device according to an embodiment of the present application.
Detailed Description
It should be noted that the terms used in the implementation section of the embodiments of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application. In the description of the embodiments of the present application, unless otherwise indicated, "/" means or, for example, a/B may represent a or B; "and/or" herein is merely an association relationship describing an association object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. In addition, in the description of the embodiments of the present application, unless otherwise indicated, "a plurality" means two or more, and "at least one", "one or more" means one, two or more.
The terms "first" and "second" are used below for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a definition of "a first", "a second" feature may explicitly or implicitly include one or more of such features.
Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.
The technical scheme of the embodiment of the application can be applied to various communication systems. For example: global system for mobile communications (global system of mobile communication, GSM), code division multiple access (code division multiple access, CDMA) system, wideband code division multiple access (wideband code division multiple access, WCDMA) system, general packet radio service (general packet radio service, GPRS), long term evolution (long term evolution, LTE) system, LTE frequency division duplex (frequency division duplex, FDD) system, LTE time division duplex (time division duplex, TDD), universal mobile telecommunications system (universal mobile telecommunication system, UMTS), worldwide interoperability for microwave access (worldwide interoperability for microwave access, wiMAX) communication system, future fifth generation (5th generation,5G) system, or New Radio (NR), etc.
As described in the background art, in the current HTTPS-based secure communication process, both header data and entity data of a message are encrypted, and it is not possible to encrypt only specific data that needs to be encrypted accurately. In addition, in the communication process based on the HTTPS protocol, the client and the server generally perform encryption processing on data sent by each interaction, and do not determine whether to encrypt data transmitted for a certain time according to the importance of the data. Therefore, the existing secure communication process based on the HTTPS protocol cannot flexibly encrypt specific data according to importance, resulting in lower communication efficiency.
In view of the above problems, the embodiments of the present application provide a method for secure communication, which carries encryption negotiation information in a header extension field of an HTTP packet, so that a client and a server may negotiate encryption information in a communication process based on an HTTP protocol, so as to encrypt only specific data having encryption necessity, thereby saving encryption computing resources and improving secure communication efficiency.
In order to more clearly understand the various implementations in the embodiments of the present application, the technical terms referred to in the embodiments of the present application are defined or explained below first.
(1) SSL protocol, TLS protocol: the method is a safe encryption transmission protocol which is widely used at present. Wherein the TLS protocol is an upgraded version of the SSL protocol, both of which are used to protect data of a transmission control protocol (transmission control protocol, TCP) connection, so SSL and TLS may sometimes be used in combination. The currently widely used HTTPS secure communication method can be understood as a secure communication method according to the SSL/TLS protocol based on the HTTP protocol.
(2) Message (packet): in the embodiments of the present application, the packet may also be described, for example, a data packet is also a packet. In this embodiment, the data stream between the client and the server based on the HTTP protocol may include a plurality of messages.
(3) Handshake message (handshake packet): and the message used for establishing connection through the secure encryption transmission protocol is between the client and the server. In existing HTTPS protocol based communication, handshake messages may occur during the handshake phase of a TLS, SSL, etc. connection. In the method for secure communication provided in the embodiment of the present application, the handshake packet may occur in a handshake phase between the client and the server. In the following embodiments of the present application, the handshake message may be specifically described as a handshake request message and a handshake response message, where the handshake request message may be a message sent by a client to a server for requesting to establish a connection with the server, and the handshake response message may be handshake information fed back by the server to the client.
(4) Extension field: the HTTP protocol works in a request-response mode, i.e., a client sends an HTTP request message (or HTTP request message) to a server to request a resource, and the server sends an HTTP response message (or HTTP response message) to the client to respond to the client's request. The HTTP request/response message may include a header (header) and a payload (payload) (or payload, entity). Since the HTTP protocol has better extensibility, the header of the HTTP message may have multiple extensible fields. In the communication process based on the HTTP protocol, the client and the server can realize the requirement of transmitting various types of data by modifying or filling in the field content in the header of the HTTP message. The embodiments of the present application describe the extensible field in the header of the HTTP message as an extension field.
Exemplary, as shown in fig. 1, a system architecture schematic diagram of secure communication is provided in an embodiment of the present application. The system architecture includes an electronic device 100 as a client and a server 200 as a server.
In some embodiments, the electronic device 100 may be a computing device with network access capabilities, such as a workstation, desktop or laptop personal computer, personal digital assistant (personal digital assistant, PDA), personal computer (personal computer, PC), handheld device with wireless communication capabilities (e.g., cell phone, tablet), in-vehicle device, wearable device, set-top box, smart sensor, smart medical device, smart television, etc., or fifth generation mobile communication technology (5 th generation, 5G) network or future evolution public land mobile network (public land mobile network, PLMN), etc., as described in the embodiments of the present application.
In some embodiments, the server 200 may include a processor and a computer-readable storage medium storing computer-readable program code that, when executed by the processor, causes the methods in embodiments of the present application to be implemented. By way of example, the computer readable program code may implement server 200 as a network (web) server, file server, video server, database server, application server, voice system, conference server, media gateway, media center, or the like, a variety of servers that may provide network or application services to clients 100 using the HTTP protocol.
Exemplary, as shown in fig. 2, a schematic structural diagram of an electronic device according to an embodiment of the present application is provided. The electronic device may be the electronic device 100 shown in fig. 1 as a client.
In some embodiments, the electronic device 100 may include an application layer (application layer), a transport layer (transport layer), a network layer (network layer), and a data link layer (data link layer). Wherein the application layer is used for communication activities when providing application services to users, and the HTTP protocol exists in the layer. The transport layer, which is used to provide data transmission between the client and the server in the processing connection, may include the TCP protocol. A network layer for processing data packets transmitted over the network, the layer defining the path through which the data packets are transmitted to the peer, the layer may include internet protocol (internet protocol, IP). The link layer is used for processing the hardware parts connected with the network, such as the control operating system, the device driver of the hardware, the network card, the optical fiber and other physically visible parts. In the secure communication process provided in the embodiment of the present application, the HTTP layer data plus the TCP header and the IP header may form an IP packet transmitted over the internet.
It should be understood that, compared to the existing HTTPS secure communication base (as shown in fig. 3), in the method for secure communication provided in the embodiment of the present application, the application layer does not need to include an SSL secure encrypted transmission protocol or a TLS secure encrypted transmission protocol (such as the TLS handshake protocol, the TLS change password standard protocol, the TLS alarm protocol, and the TLS record protocol shown in fig. 3), but rather, an existing HTTP network hierarchy is used as a communication base, and no modification is required to an existing HTTP network hierarchy architecture.
For a better understanding of the method for secure communication provided in the embodiments of the present application, the HTTP message format is described below with reference to the accompanying drawings. Exemplary, as shown in fig. 4, a schematic diagram of a message format is provided in an embodiment of the present application.
In some embodiments, the message format shown in fig. 4 includes an internet protocol (internet protocol, IP) header, a transmission control protocol (transmission control protocol, TCP) header, and an HTTP message. The IP header and the TCP header may include communication addresses of the client and the server, such as an IP address and a port number of the client, an IP address and a port number of the server, and other data, such as a sequence number, a flag bit, a window size, and the like. It should be understood that the information included in the IP header and the TCP header may refer to existing IP protocols and TCP protocols, which are not described in detail herein.
In some embodiments, the HTTP message format may be shown on the right side of fig. 4, including a start line, a header, a null line (CRLF), and an entity (entity/body).
The HTTP message is an HTTP request message, and specific information content included in each portion of HTTP is described by taking an example. Fig. 5 is a schematic diagram of an HTTP request message format according to an embodiment of the present application.
In some embodiments, the HTTP request message (request) may specifically include: request lines (corresponding to the start line in fig. 4), request headers (corresponding to the HTTP header in fig. 4), empty lines, and request bodies (corresponding to the entities in fig. 4). The request line can comprise information such as a request mode (method), a uniform resource locator (uniform resource location, URL), version information (version) and the like, spaces can be arranged among the information, and the end of the request line is finished by carriage return (\r) and line feed (\n); the request header may include a request header parameter; the request head and the request body are separated by an empty line; the request body may include the transmitted specific data, and the specific data type in the request body is not limited in this application.
It should be noted that, in the embodiment of the present application, the header of the HTTP message (such as the request header of the HTTP request message, or the response header of the HTTP response message) may further include an extension field, and in the process of performing communication based on the HTTP protocol, the client and the server may modify or fill in the content of the extension field in the header of the HTTP message to fulfill the requirement of transmitting multiple types of data. The extension field may include, for example, parameters for the client to negotiate a generation key with the server, information indicating encryption policies (e.g., information indicating which specific data is encrypted), and so on. In other words, in the method for secure communication provided in the embodiment of the present application, the client and the server may fill in parameters of the negotiation key in an extension field of the HTTP packet header, so as to achieve the purposes of encrypting communication based on the HTTP protocol and guaranteeing data transmission security.
In some embodiments, when the format of the extension field meets the specification of the HTTP protocol, and the client or the server can successfully read the information content carried by the extension field, the extension field may be located at any position of the request header, and the specific position of the extension field in the request header is not limited in the embodiments of the present application.
In some embodiments, the extension field of the HTTP message header may be customized according to the communication requirements; alternatively, the extension field of the HTTP message header may be defined with reference to a field involved in the existing HTTPS communication procedure (e.g., the header field of the HTTPS message), but this application is not limited thereto. For example, in the embodiment of the present application, the extension field of the HTTP packet may be defined according to the following characteristics of the existing HTTPs header field: (1) case-less; (2) The space is not generated in the field name and after the field name, a plurality of spaces can be generated after the colon (:), and the field name is not used and can be used-; (3) field order is meaningless; (4) field cannot be repeated, etc.
For example, according to the type of the description content of the extension field, the extension field of the HTTP packet in the embodiment of the present application may be specifically defined as the following four types: (1) A handshake field, which may be used to indicate that the client is to establish secure communications with the server; (2) A record field, which can be used after the handshake between the client and the server is successful, and can represent the related content of the negotiation generation key; (3) The change password specification field can be used for indicating that the key needs to be changed, for example, if the contents of the change password specification field and/or the handshake field are too much, the contents of the fields can be split, and the record field is used for indicating part of the contents; (4) The reserved field, which may be a spare field, is used to represent information of other meanings. It should be appreciated that these four types of fields may be carried in either a request message or a response message as desired, rather than being carried simultaneously each time a request/response is made.
It should be appreciated that the HTTP response message (response) is similar to the format of the request message, and the relevant parameters may be filled in the extension field of the response message header when the server negotiates keys with the client. For brevity of description, the format of the HTTP response message will not be specifically described herein.
It should also be understood that the format of the HTTP request message shown in fig. 5 is merely an example, and in practical applications, the HTTP request message may include more types of data than shown in fig. 5, or may have a more complex format than shown in fig. 5, which is not limited in this embodiment of the present application.
The method for secure communication provided in the embodiments of the present application may be performed by a client and a server as main bodies, and includes the following steps:
s101, a first HTTP request message is sent to a server, and an extension field of a header of the first HTTP request message comprises a first key negotiation parameter.
The format of the first HTTP request message may be as shown in fig. 5.
In some embodiments, the first key negotiation parameter included in the extension field of the first HTTP request message header may be a first random number that is randomly generated by the client, for example, random-C, and may be used by the client and the server to generate the negotiation key.
In some embodiments, the extension field of the first HTTP request message header may also include a client-supported encryption algorithm set, in other words, the encryption algorithm set may include a plurality of client-supported encryption algorithms. After the server receives the first HTTP request message, the encryption algorithm set can select a first encryption algorithm which can be supported by the server, and the first encryption algorithm can be used for calculating the negotiation key later.
S102, receiving a first HTTP response message sent by a server, wherein an extension field of a header of the first HTTP response message comprises a second key negotiation parameter.
In some embodiments, a server receives a first HTTP request message and generates a first HTTP response message in response to the first HTTP request message. The second key negotiation parameter included in the extension field of the header of the first HTTP response message may be a second random number that is randomly generated by the server, where the second random number is, for example, random-S, and the second random number may be used for generating a negotiation key by the client and the server.
In some embodiments, the extension field of the first HTTP response message header may further include a certificate (or public key certificate) of the server, where the certificate of the server includes the public key of the server. In some embodiments, after receiving the first HTTP response message, the client may authenticate the certificate of the server, obtain the public key of the server according to the certificate of the server after the authentication is passed, and then generate the premaster secret key of the client according to the public key of the server. Illustratively, the process of generating the premaster secret by the client may be: the client may encrypt a random number (which may be different from the first random number and the second random number) generated randomly by using the public key of the server, to generate the premaster secret key of the client.
In some embodiments, the client may send a second HTTP request message to the server, and the extension field of the second HTTP request message header may include the client's premaster secret. The server receives the second HTTP request message and can decrypt the premaster secret key of the client according to the private key stored locally at the server, wherein if the server successfully decrypts the premaster secret key, the public key of the server acquired by the client is determined to be correct. And then, the server side can generate a negotiation key according to the first key negotiation parameter, the second key negotiation parameter and the premaster key.
In some embodiments, the extension field of the first HTTP response message header further includes a first encryption algorithm, where the first encryption algorithm is any encryption algorithm supported by the server in the set of encryption algorithms. In other words, the first encryption algorithm is an encryption algorithm supported by both the client and the server, and thus can be used for subsequent calculation of the negotiation key by the client and the server.
In some embodiments, the extension field of the first HTTP response message header may further include a certificate request for requesting a certificate of the client. In response to the certificate request of the server, the client may carry the certificate of the client in the extension field of the header of the second HTTP request message sent to the server, so that the server performs identity authentication on the client according to the certificate.
S103, generating a negotiation key according to the first key negotiation parameter and the second key negotiation parameter, wherein the negotiation key is used for the client and the server to carry out encrypted communication.
In some embodiments, the client may generate a negotiation key according to the obtained first random number, the second random number and the generated premaster secret, where the negotiation key may be a master key (or public key) for secure communications between the client and the server candidate, and the negotiation key may be further described as a master key in the following embodiments.
In some embodiments, after receiving the second HTTP request message from the client, the server decrypts the second HTTP request message to obtain the premaster secret, and then the server may generate the negotiation key according to the obtained first random number, second random number, and premaster secret.
S104, generating an HTTP encrypted message according to the negotiation key, and sending the HTTP encrypted message to the server, wherein an extension field of the HTTP encrypted message header comprises first encryption strategy information, and the first encryption strategy information is used for indicating the type of encrypted data or the position of the encrypted data in the HTTP encrypted message.
In some embodiments, after the client generates the negotiation key, the HTTP encrypted message may be encrypted using the negotiation key. For example, the client may encrypt the HTTP encrypted message according to a preset encryption policy, for example, encrypt the data of the target type in the HTTP encrypted message according to a negotiation key; or encrypting the data of the target position in the HTTP encrypted message according to the negotiation key. Wherein the data of the target type may include at least one of: parameters of key agreement, encryption algorithm set, certificate of the client or the server, encryption policy information (e.g., first encryption policy information and second encryption policy information, third encryption policy information, etc. mentioned below); the data of the target location may include at least one of: partial data located at the header of the HTTP encrypted message; or part of data positioned in the HTTP encrypted message entity part; or all data located in the physical part of the HTTP encrypted message.
Optionally, the extension field of the HTTP encrypted message header may include first encryption policy information, which may be used to indicate a type of encrypted data or a location of the encrypted data; after receiving the HTTP encrypted message, the server can decrypt the encrypted data in the HTTP encrypted message according to the first encryption strategy information.
It should be understood that the server side can accurately and pertinently decrypt the encrypted data in the HTTP encrypted message according to the first encryption policy information, so that the decryption efficiency of the server side can be improved.
In some embodiments, the client and the server may preset encryption policies, such as which types of data need to be encrypted, which locations of data need to be encrypted, negotiating a key usage period, and so on. In the communication process, the client side can inform the encryption strategy selected by the client side to the server side through an HTTP encryption message. Specifically, the extension field of the HTTP encrypted packet header may further include second encryption policy information, where the second encryption policy information may be used to instruct the server to encrypt the data of the target type and/or encrypt the data of the target location. The extension field of the HTTP encrypted message header may further include third encryption policy information that may be used to indicate at least one of: after generating the negotiation key, encrypting the message transmitted between the server and the client each time (namely one-time pad); alternatively, after the negotiation key is generated, a new negotiation key is regenerated every N transmission intervals (i.e., one-time-pad), where N is an integer greater than 1. After receiving the HTTP encrypted message, the server can encrypt the HTTP encrypted message according to the data of the second encryption strategy target type, or can encrypt the HTTP encrypted message according to the data of the second encryption strategy target position; it is also possible to communicate with the client in a one-time-pad manner or with the client in a multiple-time-pad manner according to a third encryption policy.
According to the method for secure communication provided by the embodiment of the application, the client and the server can realize secure communication based on the HTTP protocol by carrying the parameters of the negotiation generation key in the extension field in the message header of the HTTP request message or the HTTP response message, and the message or the specific data in the message transmitted each time can be flexibly encrypted according to the need, so that the communication efficiency is further improved on the basis of ensuring the secure communication.
In order to more clearly understand the method of secure communication provided in the embodiments of the present application, the process of the secure communication method is described in more detail below with reference to fig. 6 and fig. 7. Exemplary, as shown in fig. 6, is a schematic flow chart of a secure communication provided in an embodiment of the present application. This process may be performed by a client (client), such as the electronic device 100 of fig. 1 described above, and a server (server), such as the server 200 of fig. 1 described above.
It should be understood that before the client and the server perform HTTP communication according to the procedure shown in fig. 6, a TCP communication connection needs to be established, that is, an interaction procedure of three-way handshake (TCP handshake) needs to be completed. The specific procedure for this three-way handshake may be found in the existing procedure and will not be described in detail here. After the client and server have completed the TCP connection, HTTP handshake, certificate/key/password negotiation and exchange (authentication/key/ciper spec negotiation and exchange), and handshake completion (handshake complete) stages may be performed according to the procedure shown in fig. 6. Exemplary, the method for secure communication provided by the embodiment of the application includes the following steps:
S601, the client sends a first HTTP request message to the server.
The first HTTP request message may be a client hello message (client-hello) sent by the client to the server. The header (request header) of the first HTTP request message may include an extension field, where information carried in the extension field may be used to indicate relevant parameters supporting the HTTP protocol and the encryption algorithm, and other auxiliary information (e.g., server name indication (server name indication, SNI), etc.).
In some embodiments, the location of the extension field in the first HTTP request message is, for example, the request header location shown in fig. 5. It should be understood that if the format of the extension field meets the specification in the HTTP protocol, the server may successfully read the specific information of the handshake field, so the embodiment of the present application does not limit the more specific location of the extension field in the request header.
Specifically, in this step, the extension field in the first HTTP request message may also be described as a handshake field, which is used for client and server handshake and negotiation to generate a key. The extension field of the header of the first HTTP request message may include a client random number (random-C), a client-supported encryption suite list (cipher suite), and so on. Wherein the client random number (random-C) is used for subsequent negotiations to generate the key.
It should be appreciated that the encryption suite list may also be described as a set of encryption algorithms, which may include at least one encryption algorithm supported by the client. In some embodiments, the encryption suite list may specifically include an authentication algorithm Au, a key-exchange algorithm (key-exchange), a symmetric encryption algorithm Enc, and a digest list Mac, where the authentication algorithm is used for client authentication; the key exchange algorithm is used for negotiating keys between the client and the server; the symmetric encryption algorithm is used for encrypting transmission data by adopting a symmetric encryption mode between the client and the server; the summary list is used by the server to verify the integrity of the received message, and may include, for example, an identification of the message that the client has sent to the server.
In some embodiments, the first HTTP request message may further include client version information (version), a client timestamp, a compression algorithm (compression methods) candidate list, and the like, where the client version information is used to indicate, for example, an HTTP protocol version of the client; the compression algorithm candidate list is used, for example, for subsequent compressed transmissions of information. In other embodiments, the first HTTP request message may further include other information than the above description, which is not limited in this application.
It should be appreciated that the first HTTP request message may be used for the first handshake after the client establishes a TCP connection with the server, and the client may transmit the first HTTP request message in a plaintext manner because the client and the server may not have negotiated to generate the key at this time. For similar reasons, the messages transmitted before negotiating the generation of the key, hereinafter the first HTTP response message, etc. may all be in plain text.
S602, the server side sends a first HTTP response message to the client side.
In some embodiments, a server receives a first HTTP request message sent by a client, establishes a session with the client in response to the first HTTP request message, and stores a random-C (random-C) of the client; and selecting the encryption algorithm supported by the server from the encryption suite candidate list according to the encryption algorithm supported by the server. And then, sending a first HTTP response message to the client, and returning the negotiated information result.
The first HTTP response message may be a server hello response message (server-hello) sent by the server to the client. The header (response header) of the first HTTP response message may include an extension field, where information carried by the extension field may be used to indicate relevant parameters supporting the HTTP protocol and encryption algorithms, and other auxiliary information.
In some embodiments, the extension field of the first HTTP response message header may include a random-S (random-S) sent by the server to the client and a server-supported encryption algorithm.
In some embodiments, the extension field of the first HTTP response message header may further include a service-side-selected encryption suite (including a certificate), such as a certificate of the service side (including a certificate).
In some embodiments, the server may support multiple key exchange algorithms, such as Diffie-hellman key exchange (Diffie-Hellman key exchange, DH) algorithm and RSA algorithm, where when the key exchange algorithm supported by the server is DH algorithm, the first HTTP response message may further include server key exchange (server-key-exchange) information, such as server-key-exchange information carried in an encryption suite (cipher wait), where the key exchange (server-key-exchange) information may include DH algorithm parameters of the server; when the key exchange algorithm supported by the server is an RSA algorithm, the first HTTP response message does not need to include server-key-exchange (server-key-exchange) information.
In some embodiments, if the server requires the client to verify identity using a certificate, the extension field of the first HTTP response message may also include the certificate request (certificate request) information sent by the server. Optionally, the first HTTP response message may further include server-hello-done information. The specific description of each piece of information included in the extension field of the first HTTP response message is as follows:
(1) Random number (random-S) and encryption algorithm supported by the server: for subsequent generation of keys.
(2) Certificate of server (certificate): may be used to indicate to the client the validity and authenticity of the identity of the server, e.g. the identity of the server is not a counterfeited server, the certificate message may specifically comprise a certificate chain of a digital certificate configured by the server to a certificate issuing authority (Certification Authority, CA).
(3) Server-side key exchange (server key exchange) information: determining whether to send the server key exchange information to the client based on a key exchange algorithm supported by the server, where the server may send the key exchange information to the client when the server supports a DH algorithm, where the key exchange information may include a server DH parameter; and when the server side supports the RSA algorithm, the server side can not need to send the key exchange information to the client side.
(4) Certificate request (certificate reuqest) information: for requesting credentials from the client to cause the server to authenticate the client identity.
(5) Server-hello-done) information: can be used to inform the client that the set of messages in the first HTTP corresponding message of the server has been sent, and the client can send the next message.
In some embodiments, the extension field of the first HTTP response message may be located in the header of the first HTTP response message, where the format of the extension field may be located at any position of the header on the basis of meeting the HTTP protocol specification, and the specific position of the extension field is not limited in this application.
It should be understood that the first HTTP response message may also include other information than the above description, which is not limited in this application.
S603, the client sends a second HTTP request message to the server.
The second HTTP request message may be a handshake request message (handshake massage) sent by the client to the server.
In some embodiments, after receiving the first HTTP response message from the server, the client may verify the validity of the server certificate, and if the verification is passed, perform subsequent communication, or make corresponding prompts and operations according to different error conditions. For example, the content of certificate validity verification may include: (1) Trust of certificate chain (trusted certificate path); (2) whether the certificate is revoked; (3) Validity period (expiration), i.e. whether the certificate is in a validity time range; (4) Domain name (domain), i.e., checking whether the certificate domain name matches the current access domain name, etc. And after the client verifies that the server certificate is legal, a second HTTP request message can be sent to the server.
In some embodiments, the server certificate sent by the server to the client may include the public key of the server. After the certificate authentication of the client to the server passes, the public key (or called the certificate public key) of the server can be obtained.
In some embodiments, the extension field of the second HTTP request message header (request header) may include key exchange (client-key-exchange) information. Illustratively, when the server and the client employ an RSA key exchange algorithm, the client may encrypt the randomly generated random number with the public key of the server, generating a client-side preliminary master key (pre-master). At this time, the key exchange (client-key-exchange) information may include a client preliminary master key (pre-master); when the client and the server employ a DH key exchange algorithm, the client key exchange (client-key-exchange) information may include client DH parameters.
In some embodiments, after receiving the certificate request message from the server, the client may use the local private key signature to generate a client certificate (client-certificate) message and a certificate verification (certificate verify) message including the private key signature. The specific description of each message is as follows:
(1) Client certificate (client-certificate) message: the method comprises the steps that the client responds to certificate request information of the server to generate the certificate request information for the client, and the certificate request information is used for verifying the legality of the identity of the client by the server.
(2) Certificate verification (certificate verify) message: for signing the preliminary master key and the random number.
S604, the server calculates a master key.
In some embodiments, the master key may also be described as a negotiation key. After the server receives the second HTTP request message, the master key may be calculated according to the pre-master of the client and the two random numbers random-C and random-S exchanged before.
In one implementation, when the key exchange algorithm adopted by the server and the client is an RAS algorithm, the server may firstly decrypt the client preliminary master key (pre-master) by using the private key stored by the server itself, and then calculate the master key according to the client preliminary master key (pre-master) and the two random numbers random-C and random-S exchanged before, where the master key generated by negotiation may be: enc-key=fnc (random-C, random-S, pre-master).
In another implementation manner, when the key exchange algorithm adopted by the server and the client is DH algorithm, the server may calculate a preliminary master key (pre-master) of the client according to DH parameters, and then calculate a master key according to the preliminary master key (pre-master) of the client and two random numbers random-C and random-S exchanged before, where the master key generated by negotiation may be: enc-key=fnc (random-C, random-S, pre-master).
Optionally, the server may perform step S605 for the second HTTP request message in step S603: and the server side sends a second HTTP response message to the client side.
S606, the client calculates a master key.
In some embodiments, the client calculates a master key (main master) used by the client to encrypt secure communications with the server based on the client' S preliminary master key (pre-master), such as enc-key=fnc (random-C, random-S, pre-master), and the two random numbers random-C and random-S exchanged previously.
It should be understood that the step of calculating the master key by the client based on the client preliminary master key and the random number (i.e., step S606) may also be performed simultaneously with step S604 or before step S604, in other words, after the client acquires the client preliminary master key, the random numbers (random-C and random-S), etc. for calculating the parameters for generating the master key, the master key may be calculated, not limited to performing the steps in the order shown in the embodiment of fig. 6.
S607, the client sends HTTP encrypted message to the server.
The HTTP encrypted message may carry a change password specification field CSS, such as change password specification information. The HTTP encrypted message may also carry a new encryption algorithm (hereinafter referred to as a new algorithm) to negotiate a master key for computing a subsequent data transmission; the HTTP encrypted message may further include a finish message for key generation, to inform the server that the negotiation to generate the master key is completed. The finish message may be a message generated by encrypting a field by the client using a master key generated by negotiation, and is used for verifying that the client generates a correct master key by the server, where a specific encrypted field may be flexibly set according to a currently executed service type, which is not limited in this application.
In some embodiments, the HTTP encrypted message may also include a summary list, which may include, for example, an identification of the request message sent by the client to the server prior to this step. For example, the summary list may include, for example, a name of the first HTTP request message (e.g., client-hello) sent by the client in step S601, a name of the second HTTP request message (e.g., handshake massage) sent by the client in step S603, and so on. The abstract list is used for verifying whether the received message is consistent with the message sent by the client or not by the server so as to prevent a third party from falsifying the transmitted information and ensure the safety of information transmission.
In some embodiments, since the client and the server have negotiated to generate a master key (main master), the client may encrypt specific data important or sensitive in the HTTP encrypted message, such as encrypting information related to a new algorithm, using the master key.
In some embodiments, when a client encrypts part of the information in the HTTP encrypted message using the master key, the client may carry encryption policy information in an extension field of the header of the HTTP encrypted message, where the encryption policy information may be used to indicate what type of information in the HTTP encrypted message is encrypted by the client, or where in the HTTP encrypted message is encrypted, etc.
It should be understood that, according to the method provided in the embodiments of the present application, the client may encrypt not only the specific data in the entity portion of the request message, but also the specific data in the header, for example, when the header extension field carries the relevant parameter of the master key to be used for negotiating to generate the subsequent data transmission, the relevant parameter may be encrypted by using the negotiated master key.
S608, the server performs information verification.
In some embodiments, the server may decrypt the finish message using the negotiated master key, and if successful, indicate that the client generated the correct master key, which may be used by the subsequent communication server to encrypt the transmitted data.
In some embodiments, the server may further verify the summary list to verify whether the received information is consistent with the information sent by the client, so as to prevent a third party from tampering with the transmitted information, and ensure the security of information transmission.
It should be understood that the client and the server may negotiate or preset encryption policies, such as setting a password update period (e.g., transmitting a secret once and a secret, or changing a key after each N consecutive transmissions, where N is an integer greater than 1), using a key to encrypt what portion of data by default (e.g., using a key generated by negotiation to encrypt data of a physical portion without encrypting header data by default), using a key to encrypt what type of data by default, etc. Therefore, if the client and the server need to use the new key in the subsequent communication process, in this step, the server may negotiate to calculate the new master key for subsequent data transmission according to parameters such as a new encryption algorithm carried by the HTTP encrypted message, where the negotiation process of the new master key is similar to steps S601 to S607, and will not be repeated herein.
According to the method for secure communication provided by the embodiment of the application, the client and the server can realize secure communication based on the HTTP protocol by carrying the parameters of the negotiation generation key in the extension field in the message header of the HTTP request message or the HTTP response message, and the message or the specific data in the message transmitted each time can be flexibly encrypted according to the need, so that the communication efficiency is further improved on the basis of ensuring the secure communication.
Exemplary, as shown in fig. 7, is a schematic flow chart of another secure communication provided in an embodiment of the present application. This process may be performed by a client (client), such as the electronic device 100 of fig. 1 described above, and a server (server), such as the server 200 of fig. 1 described above.
S701, the client sends a first HTTP request message to the server.
S702, the server side sends a first HTTP response message to the client side.
S703, the client sends a second HTTP request message to the server.
S704, the server calculates a server master key.
Optionally, the server may perform step S705 for the second HTTP request message in step S703: and the server side sends a second HTTP response message to the client side.
S706, the client calculates the master key.
S707, the client sends HTTP encrypted message to the server.
S708, the server performs information verification.
It should be understood that, in the process of first negotiating the key generation after the handshake between the client and the server in steps S701 to S708, similar to the process shown in the embodiment of fig. 6, the specific description will be referred to the relevant contents of steps S601 to S608, which are not repeated here. Unlike the fig. 6 embodiment, the fig. 7 embodiment further includes: after the client side and the server side negotiate to generate the master key for the first time, encrypting the specific data by using the master key, and negotiating a new master key to be used later. The process may include the steps of:
s709, the server side sends a third HTTP response message to the client side.
It should be appreciated that in order to ensure data security during HTTP transmission, the client and server may change the encryption specification at intervals, such as using new parameters to generate new master keys. Thus, in this step, the third HTTP response message sent by the server may carry a change password specification field CSS, where the change password specification field CSS is used to instruct the client to change the encryption and decryption parameters used by the negotiation to generate the new key.
In some embodiments, the extension field of the HTTP encrypted message header may also include a new algorithm for the server and the client to negotiate a new master key for use in generating subsequent secure communications.
In some embodiments, the HTTP encrypted message may further include a finish message for key generation, to inform the client that the negotiation to generate the master key is completed. The finish message may be a message generated by encrypting a field by the server side by using a master key generated by negotiation, and is used for verifying that the server side generates a correct master key by the client side, and a specific encryption field may be flexibly set according to a currently executed service type, which is not limited in the application.
S710, the client sends a fourth HTTP request message to the server.
In some embodiments, when the fourth HTTP request message includes data that needs to be encrypted, the client may encrypt the specific data in the fourth HTTP request message using the new master key generated by the negotiation. The specific data may be, for example, all entity data of the fourth HTTP request message, or part of entity data (such as any sensitive or important entity data); alternatively, the specific data may be all header data of the fourth HTTP request message, or part of the header data (such as parameters related to negotiating to generate a new master key to be used later in the header extension field).
In some embodiments, the extension field of the fourth HTTP request message header may carry indication information that indicates which (e.g., which locations, which types of data) of the fourth HTTP request message are encrypted.
In some embodiments, when the fourth HTTP request message does not include the data that needs to be encrypted, the client may not encrypt the fourth HTTP request message.
In summary, the client can flexibly determine whether encryption is needed or which data is encrypted according to the importance or sensitivity of the data included in the request message, so that encryption processing resources of the client are saved and the efficiency of data transmission is improved.
S711, the server sends a fourth HTTP response message to the client.
In some embodiments, when the fourth HTTP response message includes data that needs to be encrypted, the server may encrypt the specific data in the fourth HTTP response message using the new master key generated by negotiation. Illustratively, the specific data may be all entity data in the fourth HTTP response message, or part of entity data (such as any sensitive or important entity data); alternatively, the specific data may be all header data in the fourth HTTP response message, or part of the header data (such as parameters related to negotiating to generate a new master key to be used later in the header extension field).
In some embodiments, the extension field of the fourth HTTP response message header may carry indication information that indicates which (e.g., which locations, which types of data) of the fourth HTTP response message are encrypted.
In some embodiments, when the fourth HTTP response message does not include the data that needs to be encrypted, the server side may not encrypt the fourth HTTP response message.
In summary, the server side can flexibly determine whether to encrypt the data in the response message or which data to encrypt according to the importance or sensitivity of the data in the response message, thereby saving encryption processing resources of the client side and improving the efficiency of data transmission.
According to the method for secure communication provided by the embodiment of the application, the client and the server can realize secure communication based on the HTTP protocol by carrying the parameters of the negotiation generation key in the extension field in the message header of the HTTP request message or the HTTP response message, and the message or the specific data in the message transmitted each time can be flexibly encrypted according to the need, so that the communication efficiency is further improved on the basis of ensuring the secure communication.
Exemplary, as shown in fig. 8, a schematic structural diagram of a server device according to an embodiment of the present application is provided. The device 800 comprises a transmitting module 801, a receiving module 802 and a key generating module 803.
In some embodiments, the sending module 801 may be configured to send a first HTTP request packet to a server, where an extension field of the first HTTP request packet header includes a first key negotiation parameter.
The receiving module 802 may be configured to receive a first HTTP response message sent by the server, where an extension field of a header of the first HTTP response message includes a second key negotiation parameter.
The key generation module 803 may be configured to generate a negotiation key according to the first key negotiation parameter and the second key negotiation parameter, where the negotiation key is used for encrypted communication between the client and the server.
The sending module 801 may be further configured to send an HTTP encrypted packet generated by the client to the server, where an extension field of a header of the HTTP encrypted packet includes first encryption policy information, where the first encryption policy information is used to indicate a type of encrypted data or a location of the encrypted data in the HTTP encrypted packet.
In some embodiments, the generating the HTTP encrypted message according to the negotiation key specifically includes: encrypting the data of the target type in the HTTP encryption message according to the negotiation key; or encrypting the data of the target position in the HTTP encrypted message according to the negotiation key.
In some embodiments, the data of the target type includes at least one of: parameters of key negotiation, encryption algorithm set, certificate of the client or the server, and encryption policy information.
In some embodiments, the data for the target location includes at least one of: partial data positioned at the head of the HTTP encrypted message; or, part of data located in the HTTP encrypted message entity part; or, all data in the physical part of the HTTP encryption message.
In some embodiments, the extension field of the HTTP encrypted packet header further includes second encryption policy information, where the second encryption policy information is used to instruct the server to encrypt the data of the target type and/or encrypt the data of the target location.
In some embodiments, the extension field of the HTTP encrypted message header further includes third encryption policy information, where the third encryption policy information is used to indicate at least one of the following information: after the negotiation key is generated, encrypting the message transmitted between the server and the client each time; or, after generating the negotiation key, regenerating a new negotiation key every N transmission intervals, where N is an integer greater than 1.
In some embodiments, the client device 800 may further include an authentication module, where the extension field of the first HTTP response message header further includes a certificate of the server, and the certificate of the server includes a public key of the server, and the authentication module may be configured to authenticate the certificate of the server and obtain the public key of the server.
In some embodiments, the key generation module 803 may be configured to generate a premaster secret of the client according to a public key of the server.
In some embodiments, the sending module 801 may be further configured to send a second HTTP request packet to the server, where an extension field of the header of the second HTTP request packet includes the premaster secret.
In some embodiments, the first key agreement parameter is a first random number generated by the client, and the second key agreement parameter is a second random number generated by the server; the key generation module 803 may be specifically configured to generate the negotiation key according to the first random number, the second random number and the premaster secret key.
In some embodiments, the extension field of the first HTTP request message header further includes a set of encryption algorithms supported by the client.
In some embodiments, the extension field of the first HTTP response message header further includes a first encryption algorithm, where the first encryption algorithm is any encryption algorithm supported by the server in the set of encryption algorithms.
In some embodiments, when the extension field of the first HTTP response message header further includes a certificate request for requesting a certificate of a client, the extension field of the second HTTP request message header further includes the certificate of the client.
In some embodiments, the extension field includes at least one of: handshake field, record field, change password specification field, reserved field.
Exemplary, as shown in fig. 9, a schematic structural diagram of a server device according to an embodiment of the present application is provided. The client device 900 includes a receiving module 901, a transmitting module 902, and a key generating module 903.
In some embodiments, the receiving module 901 may be configured to receive a first HTTP request packet sent by a client, where an extension field of the first HTTP request packet header includes a first key negotiation parameter of the client.
The sending module 902 may be configured to send, in response to the first HTTP request packet, a first HTTP response packet to the client, where an extension field of a header of the first HTTP response packet includes a second key negotiation parameter of the server and a certificate of the server, and the certificate of the server includes a public key of the server.
The receiving module 901 may be further configured to receive a second HTTP request packet sent by the client, where the header extension field of the second HTTP request packet includes a premaster secret key of the client.
The key generation module 903 may be configured to generate a negotiation key according to the first key negotiation parameter, the second key negotiation parameter, and the premaster key, where the negotiation key is used for the client to perform encrypted communication with the server.
In some embodiments, the receiving module 901 may be further configured to receive an HTTP encrypted packet sent by the client, where an extension field of a header of the HTTP encrypted packet includes first encryption policy information, and the first encryption policy information is used to indicate a type of the encrypted data or a location of the encrypted data.
The server device 900 may further include a decryption module configured to decrypt the encrypted data according to the first encryption policy information.
In some embodiments, the server device 900 may further include an encryption module, configured to encrypt the data of the target type and/or the data of the target location according to the second encryption policy information and the negotiation key when the extension field of the HTTP encrypted packet header further includes the second encryption policy information, where the second encryption policy information is used to instruct the server to encrypt the data of the target type and/or encrypt the data of the target location.
In some embodiments, the data of the target type includes at least one of: parameters of key negotiation, encryption algorithm set, certificate of the client or the server, and encryption policy information.
In some embodiments, the data for the target location includes at least one of: partial data located at the header of the HTTP encrypted message; or part of data positioned in the HTTP encrypted message entity part; or all data located in the physical part of the HTTP encrypted message.
In some embodiments, the extension field of the HTTP encrypted message header further includes third encryption policy information for indicating at least one of: after generating the negotiation key, encrypting the message transmitted between the server and the client each time; or, after generating the negotiation key, regenerating a new negotiation key every N transmission intervals, where N is an integer greater than 1.
In some embodiments, the first key agreement parameter is a first random number generated by the client, and the second key agreement parameter is a second random number generated by the server.
In some embodiments, the extension field of the first HTTP request message header further includes a set of encryption algorithms supported by the client; the key generation module 903 may be further configured to select a first encryption algorithm supported by the server according to the encryption algorithm set.
In some embodiments, the extension field of the first HTTP response message header further includes credential request information for requesting credentials of the client.
In some embodiments, the server device 900 may further include an authentication module, where the second HTTP request message further includes a certificate of the client, the authentication module may be configured to verify an identity of the client according to the certificate of the client.
In some embodiments, the receiving module 901 may be further configured to receive an HTTP encrypted packet sent by the client, where the HTTP encrypted packet includes encrypted data encrypted using the negotiation key.
Exemplary, as shown in fig. 10, a schematic hardware structure of a client device according to an embodiment of the present application is provided. The client device 1000 may comprise at least one processor 1001, a memory 1002 and a communication interface 1003, wherein the processor 1001, the memory 1002 and the communication interface 1003 may be connected by a universal serial bus (universal serial bus, USB) 1004, the communication interface 1003 being for communicating with other devices, the memory 1002 comprising computer program instructions which, when executed in the processor 1001, cause the client device to implement a method of secure communication as provided by embodiments of the present application.
Exemplary, as shown in fig. 11, a schematic hardware structure of a server device according to an embodiment of the present application is shown. The server device 1100 may comprise at least one processor 1101, a memory 1102 and a communication interface 1103, wherein the processor 1101, the memory 1102 and the communication interface 1103 may be connected by a universal serial bus (universal serial bus, USB) 1104, the communication interface 1103 being for communicating with other devices, the memory 1102 comprising computer program instructions which, when executed in the processor 1101, cause the client device to implement a method of secure communication as provided by embodiments of the present application.
The embodiment of the application also provides a system for secure communication, which comprises a client device and a server device, wherein the client device is used for executing the function of the method for providing secure communication on the client, and the server device is used for executing the function of the method for providing secure communication on the server.
The embodiment of the application also provides a computer readable storage medium, and the computer readable storage medium stores a computer executable program, and when the computer executable program is called by a computer, the computer realizes the method of secure communication provided by the embodiment of the application.
The embodiment of the application also provides a chip system, which comprises: a communication interface for inputting and/or outputting information; a memory for storing a computer executable program; and the processor is used for executing the computer executable program to enable the device provided with the chip system to realize the method for secure communication provided by the embodiment of the application.
Embodiments of the present application also provide a computer program product comprising computer program instructions which, when run on a computer, cause the computer or processor to perform one or more steps of any of the methods described above, such that the method of secure communication provided by the embodiments of the present application is achieved.
In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted across a computer-readable storage medium. The computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.
Those of ordinary skill in the art will appreciate that implementing all or part of the above-described method embodiments may be accomplished by a computer program to instruct related hardware, the program may be stored in a computer readable storage medium, and the program may include the above-described method embodiments when executed. And the aforementioned storage medium includes: ROM or random access memory RAM, magnetic or optical disk, etc.
The foregoing is merely a specific implementation of the embodiments of the present application, but the protection scope of the embodiments of the present application is not limited thereto, and any changes or substitutions within the technical scope disclosed in the embodiments of the present application should be covered by the protection scope of the embodiments of the present application. Therefore, the protection scope of the embodiments of the present application shall be subject to the protection scope of the claims.

Claims (25)

1. A method of secure communications, for application to a client, comprising:
the system comprises a header custom extension field configured in a hypertext transfer protocol (HTTP) message, a type custom handshake field based on the description content of the extension field, and a handshake communication established between the extension field and a server through the handshake field, wherein the extension field comprises information for negotiating and generating an indication encryption strategy between the client and the server;
After the handshake communication between the client and the server is successfully established, and before the client negotiates with the server to generate a secret key, the client and the server carry out HTTP communication based on a hypertext transfer protocol (HTTP) in a plaintext mode; the corresponding application layer in the HTTP communication process does not comprise a secure transmission encryption protocol SSL or TLS;
based on the extension field, customizing a record field according to the type of the description content of the extension field;
filling a first key negotiation parameter into the record field of the head part of a first HTTP request message, and sending the first HTTP request message to the server according to the plaintext mode;
receiving a second key negotiation parameter sent by the server through the record field of the header of a first HTTP response message, wherein the first HTTP response message is transmitted in the plaintext manner;
generating a negotiation key according to the first key negotiation parameter and the second key negotiation parameter, wherein the negotiation key is used for carrying out encrypted communication between the client and the server;
encrypting data of a target position according to a preset encryption strategy and the negotiation key to generate an HTTP encrypted message, wherein the data of the target position is part of data of the head of the HTTP encrypted message;
The extension field of the HTTP encrypted message header includes: when the server is used for decrypting, the first encryption strategy information indicating the target position of the encrypted data is used for encrypting the data; when the server is used for encrypting, second encryption strategy information indicating the target position of the encrypted data is obtained; and third encryption policy information for indicating that a new negotiation key is regenerated every N transmission intervals after the negotiation key is generated, N being an integer greater than 1;
and sending the HTTP encryption message to the server.
2. The method of claim 1, wherein the HTTP encrypted message further comprises a target type of data, the target type of data comprising at least one of:
parameters of key agreement, encryption algorithm set, certificate of the client or the server.
3. The method according to claim 1 or 2, wherein the data of the target location further comprises:
partial data positioned in the HTTP encrypted message entity part; or,
and all data positioned in the HTTP encryption message entity part.
4. The method of claim 2, wherein the second encryption policy information is further used to instruct the server to encrypt the target type of data.
5. The method according to claim 1 or 2, wherein the third encryption policy information is further used to indicate that after the negotiation key is generated, a message transmitted between the server and the client each time is encrypted.
6. The method according to claim 1 or 2, wherein the extension field of the first HTTP response message header comprises a certificate of the server, the certificate of the server comprising a public key of the server, the method further comprising:
authenticating the certificate of the server and acquiring a public key of the server;
generating a premaster secret key of the client according to the public key of the server;
and sending a second HTTP request message to the server, wherein an extension field of the header of the second HTTP request message comprises the premaster secret key.
7. The method according to claim 1 or 2, wherein the first key agreement parameter is a first random number generated by the client, and the second key agreement parameter is a second random number generated by the server;
the generating a negotiation key according to the first key negotiation parameter and the second key negotiation parameter specifically includes:
And generating the negotiation key according to the first random number, the second random number and a premaster key.
8. The method according to claim 1 or 2, wherein the extension field of the first HTTP request message header further comprises a set of encryption algorithms supported by the client.
9. The method according to claim 1 or 2, wherein the extension field of the first HTTP response message header comprises a first encryption algorithm, the first encryption algorithm being any encryption algorithm supported by the server in the set of encryption algorithms.
10. The method of claim 6, wherein when the extension field of the first HTTP response message header further includes a certificate request for requesting a certificate of the client, the extension field of the second HTTP request message header further includes a certificate of the client.
11. The method according to claim 1 or 2, wherein the extension field comprises at least one of:
the password specification field and the reserved field are changed.
12. A method for secure communications, applied to a server, comprising:
the system comprises a header custom extension field configured in an HTTP message, a type custom handshake field based on the description content of the extension field, and a handshake communication with a client through the handshake field, wherein the extension field comprises information for negotiating and generating an indication encryption strategy by the server and the client;
After the handshake communication between the server and the client is successfully established, and before the client negotiates with the server to generate a secret key, the server and the client carry out HTTP communication based on HTTP in a plaintext mode; the corresponding application layer in the HTTP communication process does not comprise an SSL protocol or a TLS protocol;
based on the extension field, customizing a record field according to the type of the description content of the extension field;
receiving a first key negotiation parameter sent by the client through the record field of the header of a first HTTP request message, wherein the first HTTP request message is transmitted in the plaintext manner;
responding to the first HTTP request message, filling second key negotiation parameters and a certificate of the server into the record field of the head part of a first HTTP response message, sending the first HTTP response message to the client, wherein the certificate of the server comprises a public key of the server, and the first HTTP response message is transmitted in the plaintext mode;
receiving a premaster secret key sent by the client through the record field of the second HTTP request message header;
generating a negotiation key according to the first key negotiation parameter, the second key negotiation parameter and the premaster key, wherein the negotiation key is used for carrying out encrypted communication between the client and the server;
Receiving an HTTP encrypted message sent by the client; the extension field of the HTTP encrypted message header includes: when the server is used for decrypting, the first encryption strategy information indicating the target position of the encrypted data is used for encrypting the data; when the server is used for encrypting, second encryption strategy information indicating the target position of the encrypted data is obtained; and third encryption policy information for indicating that a new negotiation key is regenerated every N transmission intervals after the negotiation key is generated, N being an integer greater than 1; wherein,
the data of the target position is part of the data of the HTTP encryption message head; decrypting the encrypted data of the target position in the header extension field of the HTTP encrypted message according to the first encryption strategy information, encrypting the data of the target position according to the second encryption strategy information, and regenerating a new negotiation key every N transmission intervals after generating the negotiation key according to the third encryption strategy.
13. The method according to claim 12, wherein the method further comprises:
and encrypting the data of the target type according to the second encryption strategy information and the negotiation key.
14. The method of claim 13, wherein the data of the target type comprises at least one of:
parameters of key agreement, encryption algorithm set, certificate of the client or the server.
15. The method according to claim 12 or 13, wherein the data of the target location comprises:
partial data positioned in the HTTP encrypted message entity part; or,
and all data positioned in the HTTP encryption message entity part.
16. The method according to claim 12 or 13, wherein the third encryption policy information is further used to indicate that each transmission of the message between the server and the client is encrypted after the negotiation key is generated.
17. The method according to claim 12 or 13, wherein the first key agreement parameter is a first random number generated by the client and the second key agreement parameter is a second random number generated by the server.
18. The method according to claim 12 or 13, wherein the extension field of the first HTTP request message header comprises a set of encryption algorithms supported by the client, the method further comprising:
And selecting a first encryption algorithm supported by the server according to the encryption algorithm set.
19. The method according to claim 12 or 13, wherein the extension field of the first HTTP response message header includes certificate request information for requesting a certificate of the client.
20. The method according to claim 12 or 13, wherein the second HTTP request message further comprises a certificate of the client, the method further comprising:
and verifying the identity of the client according to the certificate of the client.
21. A client device comprising at least one processor, a memory and a communication interface for communicating with other devices, the memory comprising computer program instructions which, when executed in the processor, cause the client device to implement the method of secure communication of any of claims 1 to 11.
22. A server device comprising at least one processor, a memory and a communication interface for communicating with other devices, the memory comprising computer program instructions which, when executed in the processor, cause the server device to implement the method of secure communication of any of claims 12 to 20.
23. A system for secure communication, comprising a client device for performing the method of secure communication according to any of claims 1 to 11 and a server device for performing the method of secure communication according to any of claims 12 to 20.
24. A computer readable storage medium, characterized in that the computer readable storage medium stores a computer executable program which, when called by a computer, causes the computer to perform the method of any one of claims 1 to 11 or to perform the method of any one of claims 12 to 20.
25. A chip system, comprising:
a communication interface for inputting and/or outputting information;
a memory for storing a computer executable program;
a processor for executing the computer executable program to cause a device on which the chip system is installed to perform the method of any one of claims 1 to 11 or to perform the method of any one of claims 12 to 20.
CN202110594366.6A 2021-05-28 2021-05-28 Method and device for secure communication Active CN113438071B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110594366.6A CN113438071B (en) 2021-05-28 2021-05-28 Method and device for secure communication

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110594366.6A CN113438071B (en) 2021-05-28 2021-05-28 Method and device for secure communication

Publications (2)

Publication Number Publication Date
CN113438071A CN113438071A (en) 2021-09-24
CN113438071B true CN113438071B (en) 2024-04-09

Family

ID=77803244

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110594366.6A Active CN113438071B (en) 2021-05-28 2021-05-28 Method and device for secure communication

Country Status (1)

Country Link
CN (1) CN113438071B (en)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114039723A (en) * 2021-10-22 2022-02-11 苏州浪潮智能科技有限公司 Method and device for generating shared key, electronic equipment and storage medium
CN114143026B (en) * 2021-10-26 2024-01-23 福建福诺移动通信技术有限公司 Data security interface based on asymmetric and symmetric encryption and working method thereof
CN114499969B (en) * 2021-12-27 2023-06-23 天翼云科技有限公司 Communication message processing method and device, electronic equipment and storage medium
CN114465775B (en) * 2021-12-31 2023-10-20 华为技术有限公司 Secure transmission method and device
CN116647330A (en) * 2022-02-16 2023-08-25 华为技术有限公司 Data transmission method and device
CN114629708A (en) * 2022-03-18 2022-06-14 蚂蚁区块链科技(上海)有限公司 Client request encryption transmission method, data decryption method and system
CN114866527B (en) * 2022-04-29 2023-09-15 中国科学院信息工程研究所 Data processing method, device and system
CN115296847B (en) * 2022-07-06 2024-02-13 杭州涂鸦信息技术有限公司 Flow control method, flow control device, computer equipment and storage medium
CN115378660A (en) * 2022-07-29 2022-11-22 天翼云科技有限公司 Data transmission method, device, equipment and medium
CN115333839B (en) * 2022-08-15 2023-11-07 中国电信股份有限公司 Data security transmission method, system, equipment and storage medium
CN116685001B (en) * 2023-06-12 2024-06-11 成都理工大学 Lora ad hoc network communication method with dynamic encryption function
CN116980128B (en) * 2023-09-22 2023-12-26 北京数盾信息科技有限公司 Inter-application data transmission processing method and device

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7249377B1 (en) * 1999-03-31 2007-07-24 International Business Machines Corporation Method for client delegation of security to a proxy
CN101459506A (en) * 2007-12-14 2009-06-17 华为技术有限公司 Cipher key negotiation method, system, customer terminal and server for cipher key negotiation
CN101478755A (en) * 2009-01-21 2009-07-08 中兴通讯股份有限公司 Network security HTTP negotiation method and related apparatus
CN110719161A (en) * 2018-07-13 2020-01-21 杭州海康威视数字技术股份有限公司 Security parameter interaction method, device, equipment and system
CN110798431A (en) * 2018-08-03 2020-02-14 杭州海康威视数字技术股份有限公司 Security parameter interaction method, device, equipment and system
CN111600914A (en) * 2020-07-27 2020-08-28 北京信安世纪科技股份有限公司 Data transmission method, server and client

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040193871A1 (en) * 2003-03-28 2004-09-30 Broadcom Corporation System and method for transmitting data using selective partial encryption
DE102005026982A1 (en) * 2005-06-10 2006-12-14 Siemens Ag Method for agreeing a security key between at least one first and a second communication subscriber for securing a communication connection

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7249377B1 (en) * 1999-03-31 2007-07-24 International Business Machines Corporation Method for client delegation of security to a proxy
CN101459506A (en) * 2007-12-14 2009-06-17 华为技术有限公司 Cipher key negotiation method, system, customer terminal and server for cipher key negotiation
CN101478755A (en) * 2009-01-21 2009-07-08 中兴通讯股份有限公司 Network security HTTP negotiation method and related apparatus
CN110719161A (en) * 2018-07-13 2020-01-21 杭州海康威视数字技术股份有限公司 Security parameter interaction method, device, equipment and system
CN110798431A (en) * 2018-08-03 2020-02-14 杭州海康威视数字技术股份有限公司 Security parameter interaction method, device, equipment and system
CN111600914A (en) * 2020-07-27 2020-08-28 北京信安世纪科技股份有限公司 Data transmission method, server and client

Also Published As

Publication number Publication date
CN113438071A (en) 2021-09-24

Similar Documents

Publication Publication Date Title
CN113438071B (en) Method and device for secure communication
JP6612358B2 (en) Method, network access device, application server, and non-volatile computer readable storage medium for causing a network access device to access a wireless network access point
EP2039199B1 (en) User equipment credential system
JP4603043B2 (en) Method for transmitting sync ML synchronization data
US9137017B2 (en) Key recovery mechanism
CN111556025A (en) Data transmission method, system and computer equipment based on encryption and decryption operations
EP2262164A1 (en) Secure data transfer
EP3633949A1 (en) Method and system for performing ssl handshake
CN112913189B (en) OTA (over the air) upgrading method and device
US11778460B2 (en) Device and method for authenticating transport layer security communications
CN111756529B (en) Quantum session key distribution method and system
US10671717B2 (en) Communication device, communication method and computer program
US11968302B1 (en) Method and system for pre-shared key (PSK) based secure communications with domain name system (DNS) authenticator
CN113207322B (en) Communication method and communication device
CN111756528A (en) Quantum session key distribution method and device and communication architecture
CN104243452A (en) Method and system for cloud computing access control
CN114696999A (en) Identity authentication method and device
CN113872765A (en) Identity credential application method, identity authentication method, equipment and device
EP4270866A1 (en) Identity authentication method and apparatus, device, chip, storage medium, and program
US11818268B2 (en) Hub-based token generation and endpoint selection for secure channel establishment
CN113422753B (en) Data processing method, device, electronic equipment and computer storage medium
CN114707158A (en) Network communication authentication method and network communication authentication system based on TEE
CN114760043A (en) Identity authentication method and device
WO2022178890A1 (en) Key transmission method and apparatus
US12015721B1 (en) System and method for dynamic retrieval of certificates with remote lifecycle management

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