CN113438071A - Method and device for secure communication - Google Patents

Method and device for secure communication Download PDF

Info

Publication number
CN113438071A
CN113438071A CN202110594366.6A CN202110594366A CN113438071A CN 113438071 A CN113438071 A CN 113438071A CN 202110594366 A CN202110594366 A CN 202110594366A CN 113438071 A CN113438071 A CN 113438071A
Authority
CN
China
Prior art keywords
server
key
client
http
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202110594366.6A
Other languages
Chinese (zh)
Other versions
CN113438071B (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

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • 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

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 a client, and comprises the following steps: sending a first hypertext transfer protocol (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 encrypted communication between the client and the server. According to the method, the client and the server can realize safe communication based on the HTTP protocol by carrying the relevant 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 application relates to the field of channel encryption communication technologies, and in particular, to a method and a device for secure communication.
Background
Currently, in a communication scenario based on a hypertext transfer protocol (HTTP), to achieve secure communication between a client and a server, a mode of upgrading the HTTP to a hypertext transfer protocol over secure keylayer (HTTPs) is generally adopted. The HTTPS establishes a secure channel depending on a Secure Socket Layer (SSL) protocol or a Transport Layer Security (TLS) protocol, completes encryption of transmission content, and guarantees security of data transmission. The existing HTTPS encryption mode can encrypt the head and the entity of a data message, but can not accurately encrypt only specific data needing encryption.
However, in many cases, the data in the header of the message is more and not necessary to be encrypted, and only the entity data is important to be encrypted, so that the existing HTTPS encryption method indiscriminately encrypts the transmitted data message, which may reduce the communication efficiency.
Disclosure of Invention
The application provides a secure communication method and device, which enable a client and a server to realize secure communication based on an HTTP protocol by carrying related 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, which is applied to a client, and includes: sending a first hypertext transfer protocol (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; generating a negotiation key according to the first key negotiation parameter and the second key negotiation parameter, wherein the negotiation key is used for encrypted communication between the client and the server; generating an HTTP encrypted message according to the negotiation key, and sending the HTTP encrypted message to the server, wherein an extension field of a header of the HTTP encrypted message comprises first encryption strategy information, and the first encryption strategy information is used for indicating the type of encrypted data in the HTTP encrypted message or the position of the encrypted data.
The negotiation key may be, for example, a master key used for encryption when the client and the server communicate based on HTTP, and the negotiation key is mainly used for encrypting data in the process of secure communication between the client and the server based on HTTP protocol.
According to the secure communication method provided by the implementation mode, the client and the server negotiate the key in the process of communication based on the HTTP protocol by carrying the related parameters of the key which is generated by calculation of the client and the server in the extension field of the head of the HTTP request message and/or the HTTP response message, so that the secure communication is realized on the basis of the HTTP communication architecture, and the requirements of a user on accuracy and high efficiency of data encryption are met. In addition, the encryption strategy information indicating the type or position of the encrypted data is carried in the extension field of the message header, so that the opposite end can efficiently and accurately decrypt the encrypted data based on the indication information and smoothly read the message, and the communication efficiency is improved.
With reference to the first aspect, in some implementation manners of the first aspect, the generating an HTTP encrypted packet according to the negotiation key specifically includes: encrypting the target type data in the HTTP encrypted message according to the negotiation key; or encrypting the data of the target position in the HTTP encryption message according to the negotiation key.
The type of encrypted data to be encrypted may include important data such as parameters related to negotiating generation of a key, for example.
Illustratively, the data encrypted by using the negotiation key may include entity data (all or part of entity data) of the HTTP encrypted message, or may also include data of a header of the HTTP encrypted message. In other words, after acquiring the negotiation key, the client (or the server) may encrypt specific data in a targeted manner according to communication needs or data types.
According to the method for the secure communication, the specific data can be encrypted in a targeted manner by encrypting the specific data 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 ensuring the security of important data, and the efficiency of the secure communication is improved.
With reference to the first aspect, in certain implementations of the first aspect, the target type of data includes at least one of: parameters of key agreement, an encryption algorithm set, a 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 in the header of the second HTTP request message; or, the partial data is located in the entity part of the second HTTP request message; or, all data located in the entity part of the second HTTP request message.
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 encryption strategy is notified to the opposite communication end, so that the two communication ends can encrypt specific data by adopting the same communication strategy, and the encryption and decryption efficiency of the two communication ends in the communication process is improved.
With reference to the first aspect, in certain implementations of the first aspect, 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 messages transmitted between the server and the client each time; or, after the negotiation key is generated, regenerating a 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 two communication ends can communicate or update the negotiation key according to the same strategy by informing the opposite-end encryption strategy, so that the smooth proceeding of the secure communication is ensured.
With reference to the first aspect, in certain implementation manners of the first aspect, the extension field of the header of the first HTTP response packet 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 pre-master 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 a 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 field of the header of the HTTP request message and/or the HTTP response message may be customized according to the communication requirement, for example, parameters related to generating a key may be carried. Therefore, when the client and the server communicate based on the HTTP protocol, encrypted communication can be realized, and the problem of information security in the conventional HTTP plaintext communication mode is solved.
According to the secure communication method provided by the implementation mode, the extension field in the message header of the HTTP request message or the HTTP response message carries the parameter of the key generated by negotiation, so that the client and the server can realize secure communication based on the HTTP protocol, and the specific data in the message or the message transmitted each time can be flexibly encrypted according to the requirement, thereby further improving the communication efficiency on the basis of ensuring the secure communication.
With reference to the first aspect, in some implementation manners of the first aspect, 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 the pre-master key.
The first key agreement parameter, the second key agreement parameter and the pre-master key all belong to related parameters for generating the agreement key, and can be used for the client and the server to generate the agreement key. The first key agreement parameter may be, for example, a random number randomly generated by the client, such as random-C; the second key may be, for example, a random number randomly generated by the server, such as random-S; the premaster secret key can be encrypted data generated after the client encrypts a certain random number based on the public key of the server.
According to the secure communication method provided by the implementation mode, the extension field in the message header of the HTTP request message or the HTTP response message carries the parameter of the key generated by negotiation, so that the client and the server can realize secure communication based on the HTTP protocol, and the specific data in the message or the message transmitted each time can be flexibly encrypted according to the requirement, thereby further improving the communication efficiency on the basis of ensuring the secure communication.
With reference to the first aspect, in certain implementations of the first aspect, the extension field of the header of the first HTTP request message further includes a set of encryption algorithms supported by the client.
Wherein the set of encryption algorithms may include at least one encryption algorithm supported by the client. The encryption algorithm set is used for the server to select an encryption algorithm which is also supported by the server, such as a first encryption algorithm, so that the client and the server subsequently calculate a negotiation key according to the first encryption algorithm.
According to the secure communication method provided by the implementation mode, the client sends the encryption algorithm set to the server, so that the server can conveniently select the encryption algorithm supported by both the server and the client, the client or the server can successfully calculate the negotiation key based on the encryption algorithm, and the success rate and the efficiency of the 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 header of the first HTTP response packet further includes a first encryption algorithm, and 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 that is also supported by the server side and is selected from the encryption algorithm set, that is, the first encryption algorithm is supported by both the client side and the server side.
According to the secure communication method provided by the implementation mode, the server selects the first encryption algorithm supported by the server, and notifies the client of the selected first encryption algorithm, the client and the server can subsequently calculate the negotiation key by using the same encryption algorithm, the consistency of the master key calculated and obtained by the client and the server is ensured, and therefore the encrypted secure communication based on the HTTP is achieved.
With reference to the first aspect, in certain implementations of the first aspect, when the extension field of the first HTTP response packet header further includes a certificate request, and the certificate request is used to request a certificate of the client, the extension field of the second HTTP request packet header further includes the certificate of the client.
In a second aspect, a method for secure communication is provided, which is applied to a server and includes: receiving a first hypertext transfer protocol (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 the head extension field of the second HTTP request message comprises a premaster secret key of the client; and generating a negotiation key according to the first key negotiation parameter, the second key negotiation parameter and the pre-master key, wherein the negotiation key is used for encrypted communication between the client and the server.
The negotiation key may be, for example, a master key used for encryption when the client and the server communicate based on HTTP, and the negotiation key is mainly used for encrypting data in the process of secure communication between the client and the server based on HTTP protocol.
According to the secure communication method provided by the implementation mode, the client and the server negotiate the key in the process of communication based on the HTTP protocol by carrying the related parameters of the key which is generated by calculation of the client and the server in the extension field of the head of the HTTP request message and/or the HTTP response message, so that the secure communication is realized on the basis of the HTTP communication architecture, and the requirements of a user on 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 a 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 encrypted data to be encrypted may include important data such as parameters related to negotiating generation of a key, for example.
Illustratively, the data encrypted by using the negotiation key may include entity data (all or part of entity data) of the HTTP encrypted message, or may also include data of a header of the HTTP encrypted message. In other words, after acquiring the negotiation key, the client (or the server) may encrypt specific data in a targeted manner according to communication needs or data types.
According to the secure communication method 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 end can efficiently and accurately decrypt the encrypted data based on the indication information and smoothly read the message, and the communication efficiency is improved.
With reference to the second aspect, in certain implementations of the second aspect, the extension field of the HTTP encrypted message 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, 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 target type of data includes at least one of: parameters of key agreement, an encryption algorithm set, a 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 in the head of the HTTP encrypted message; or, the partial data located in the entity part of the HTTP encrypted message; or, all data located in the entity part of the HTTP encrypted message.
With reference to the second aspect, in certain implementations of the second aspect, 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 messages transmitted between the server and the client each time; or, after the negotiation key is generated, regenerating a new negotiation key every N transmission intervals, where N is an integer greater than 1.
With reference to the second aspect, in some implementation manners of the second aspect, 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.
According to the secure communication method provided by the implementation mode, the server selects the first encryption algorithm supported by the server, and notifies the client of the selected first encryption algorithm, the client and the server can subsequently calculate the negotiation key by using the same encryption algorithm, the consistency of the master key calculated and obtained by the client and the server is ensured, and therefore the encrypted secure communication based on the HTTP is achieved.
With reference to the second aspect, in some 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 include at least one encryption algorithm supported by the client. The encryption algorithm set is used for the server to select an encryption algorithm which is also supported by the server, such as a first encryption algorithm, so that the client and the server subsequently calculate a negotiation key according to the first encryption algorithm.
According to the secure communication method provided by the implementation mode, the client sends the encryption algorithm set to the server, so that the server can conveniently select the encryption algorithm supported by both the server and the client, the client or the server can successfully calculate the negotiation key based on the encryption algorithm, and the success rate and the efficiency of the 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 header of the first HTTP response packet 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 some implementations of the second aspect, the second HTTP request packet 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 a legal identity, 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 message header extension field further includes an encryption policy of the negotiated key, where the encryption policy includes at least one of: after the negotiation key is generated, encrypting messages transmitted between the server and the client each time; or, after the negotiation key is generated, regenerating a new negotiation key every N transmission intervals; or when the message transmitted between the server and the client comprises data of a target type, encrypting the data of the target type by using the negotiation key.
According to the secure communication method provided by the implementation mode of the application, after the negotiation key is obtained, the client (or the server) can encrypt specific data in a targeted manner according to communication needs or data types and the like, the encryption is more flexible, and different encryption needs can be met.
In a third aspect, a client device is provided, 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, a server device is provided, comprising at least one processor, a memory and a communication interface, the communication interface being configured to communicate with other devices, the memory comprising computer program instructions, which, when executed in the processor, cause the client device to implement the method for secure communication as described in any one of the implementations of the second aspect.
In a fifth aspect, a system for secure communication is provided, which includes a client device and a server device, where the client device is configured to perform the method for secure communication as described in any implementation manner of the first aspect, and the server device is configured to perform the method for secure communication as described in any implementation manner of the second aspect.
A sixth aspect provides a computer-readable storage medium storing a computer-executable program which, when invoked by a computer, causes the computer to perform the method according to any of the implementations of the first aspect or the method according to any of the second aspects.
In a seventh aspect, a chip system is provided, including: a communication interface for inputting and/or outputting information; a memory for storing a computer executable program; a processor configured to execute the extreme and executable program, so that a device on which the chip system is installed performs the method according to any of the implementations of the first aspect, or performs the method according to any of the implementations of the second aspect.
In an eighth aspect, a computer program product is provided, the computer program product comprising computer program instructions which, when run on a computer, cause the computer to carry out the method according to any of the implementations of the first aspect described above, or the method according to any of the implementations of the second aspect described above.
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 an 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 an 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 the embodiment of the present application.
Fig. 6 is a schematic flow chart of another method for secure communication provided by the embodiment of the present application.
Fig. 7 is a schematic flow chart of still another method for 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 provided in 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 is noted that the terminology used in the description of the embodiments of the present application is for the purpose of describing particular embodiments of the present application only and is not intended to be limiting of the present application. In the description of the embodiments of the present application, "/" means "or" unless otherwise specified, for example, a/B may mean a or B; "and/or" herein is merely an association describing an associated object, and means that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present application, "a plurality" means two or more, and "at least one", "one or more" means one, two or more, unless otherwise specified.
In the following, the terms "first", "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a definition of "a first" or "a second" feature may explicitly or implicitly include one or more of the features.
Reference throughout this 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 present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated 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: a global system for mobile communication (GSM) system, a Code Division Multiple Access (CDMA) system, a Wideband Code Division Multiple Access (WCDMA) system, a General Packet Radio Service (GPRS), a long term evolution (long term evolution, LTE) system, a LTE Frequency Division Duplex (FDD) system, a LTE Time Division Duplex (TDD) system, a universal mobile telecommunications system (universal mobile telecommunications system, UMTS), a Worldwide Interoperability for Microwave Access (WiMAX) communication system, a future fifth generation (5G) system, or a new radio NR (UMTS) system, etc.
As introduced in the background art, in the current HTTPS-based secure communication process, both header data and entity data of a message are encrypted, and thus, the header data and the entity data cannot be accurately encrypted only for specific data that needs to be encrypted. In addition, in the communication process based on the HTTPS protocol, generally, the client and the server encrypt data transmitted in each interaction, and do not determine whether to encrypt data transmitted in 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 low communication efficiency.
In view of the above problems, embodiments of the present application provide a secure communication method, where an encryption negotiation information is carried in a header extension field of an HTTP message, so that a client and a server can negotiate the encryption information in a communication process based on an HTTP protocol, and only specific data with encryption necessity is encrypted, thereby saving encryption computing resources and improving secure communication efficiency.
In order to more clearly understand various implementations in the embodiments of the present application, technical terms referred to in the embodiments of the present application are first defined or explained below.
(1) SSL protocol, TLS protocol: is a secure encrypted transmission protocol of a very wide application layer currently used. Among them, the TLS protocol is an upgraded version of the SSL protocol, both of which are used to protect data of a Transmission Control Protocol (TCP) connection, and thus SSL and TLS may sometimes be used in combination. The HTTPS secure communication method widely used at present can be understood as a secure communication method performed according to the SSL/TLS protocol based on the HTTP protocol.
(2) Packet (packet): in the embodiment of the present application, the packet may also be described as a packet, for example, a data packet is also a message. In the embodiment of the present application, a data stream between a client and a server based on an HTTP protocol may include a plurality of messages.
(3) Handshake packet (handshake packet): and the client and the server are used for establishing a connected message through a secure encryption transmission protocol. In the existing communication process based on the HTTPS protocol, the handshake messages may occur in the handshake phase of the connections such as TLS and SSL. In the method for secure communication provided in the embodiment of the present application, the handshake message 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 further specifically described as a handshake request message and a handshake response message, where the handshake request message may be a message sent by the client to the server to request connection with the server, and the handshake response message may be handshake information fed back by the server to the client.
(4) An extension field: the HTTP protocol works in a request-response (request-response) mode, that is, the client sends an HTTP request message (or HTTP request message) to the server to request a resource, and the server sends an HTTP response message (or HTTP response message) to the client to respond to the request of the client. The HTTP request/response message may include a header and a payload (or payload). Because the HTTP protocol has better extensibility, the header of the HTTP message may have a plurality of extensible fields. During 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 the field content in the HTTP message header. The embodiment of the application describes the extensible field in the HTTP message header as the extended field.
Fig. 1 is a schematic diagram of a system architecture for secure communication according to 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, electronic device 100 may be a computing device with network access capabilities, such as a workstation, desktop or laptop personal computer, Personal Digital Assistant (PDA), Personal Computer (PC), or wireless communication capable computing deviceHandheld devices (e.g., cell phones, tablets), in-vehicle devices, wearable devices, set-top boxes, smart sensors, smart medical devices, smart televisions, etc., or fifth generation mobile communication technologies (5)thgeneration, 5G) network or a Public Land Mobile Network (PLMN) network in the future evolution, and the like, which is not limited in this embodiment of the present application.
In some embodiments, the server 200 may include a processor and a computer readable storage medium having computer readable program code stored thereon, which when executed by the processor, causes the method in the embodiments of the present application to be implemented. Illustratively, the computer readable program code may implement the 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, which may provide network or application services to the client 100 using the HTTP protocol.
Exemplarily, as shown in fig. 2, a schematic structural diagram of an electronic device provided in an embodiment of the present application is shown. 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 a network, the layer defining a path through which the data packets are transmitted to an opposite end, and the layer may include an Internet Protocol (IP). And the link layer is used for processing a hardware part connected with the network, such as a physically visible part for controlling an operating system, a device driver of the hardware, a network card, an optical fiber and the like. In the secure communication process provided by the embodiment of the present application, the HTTP layer data may form an IP packet transmitted over the internet by adding a TCP header and an IP header.
It should be understood that, in the method for secure communication provided in the embodiment of the present application, compared to the existing HTTPS secure communication infrastructure (as shown in fig. 3), the application layer does not need to include SSL secure encrypted transport protocol or TLS secure encrypted transport protocol (such as TLS handshake protocol, TLS change cipher standard protocol, TLS alarm protocol, and TLS recording protocol shown in fig. 3), but instead, the existing HTTP network hierarchy is used as a communication infrastructure, and no modification is required to the existing HTTP network hierarchy architecture.
In order to better understand the secure communication method provided in the embodiment of the present application, the following describes an HTTP message format with reference to the accompanying drawings. Exemplarily, as shown in fig. 4, a schematic diagram of a message format provided in the embodiment of the present application is shown.
In some embodiments, the message format shown in fig. 4 includes an Internet Protocol (IP) header, a 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 can be referred to the existing IP protocol and TCP protocol, and the detailed description thereof is omitted here.
In some embodiments, the HTTP message format may be as shown in the right side of fig. 4, and includes a start line (start line), a header (header), a blank line (CRLF), and an entity (entity/body).
The HTTP message is an HTTP request message, for example, to introduce specific information contents included in each part of the HTTP. 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: a request line (corresponding to the start line in fig. 4), a request header (corresponding to the HTTP message header in fig. 4), an empty line, and a request body (corresponding to the entities in fig. 4). The request line may include information such as a request mode (method), a Uniform Resource Locator (URL), version information (version), and the like, spaces may be separated between each item of information, and the end of the request line is terminated by a carriage return (\ r) and a line feed (\\ n); the request header may include request header parameters; the request head and the request body are separated by an empty line; the requesting entity may include the specific data to be transmitted, and the application does not limit the specific data type in the requesting entity.
It should be noted that, in the embodiment of the present application, a header of an HTTP message (e.g., a request header of an HTTP request message, or a response header of an HTTP response message) may further include an extension field, and during a communication process based on an 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 a requirement of transmitting multiple types of data. For example, the extension field may include a parameter for the client and the server to negotiate a generation key, and information indicating an encryption policy (e.g., information indicating which specific data is encrypted), and the like. In other words, in the secure communication method provided in the embodiment of the present application, the client and the server may fill parameters of a negotiation key in an extension field of a header of an HTTP message, so as to achieve the purposes of encrypting communication based on an HTTP protocol and guaranteeing security of transmission data.
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 client or the server, the extension field may be at any position of the request header.
In some embodiments, the extension field of the HTTP message header can be customized according to the communication requirement; alternatively, the extended field of the HTTP message header may be defined with reference to a field involved in an existing HTTPS communication procedure (e.g., a header field of an HTTPS message), but the present application is not limited thereto. For example, in the embodiment of the present application, the extension field of the HTTP message may be defined according to the following characteristics of the existing HTTPs header field: (1) the case is not distinguished; (2) no blank space appears in the field name and after the field name, a plurality of blank spaces can be arranged after the colon (: and can be used when not used-; (3) the field order is meaningless; (4) fields cannot be repeated, etc.
Illustratively, according to the type of the description content of the extension field, the extension field of the HTTP message 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 communication 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 key generated by negotiation; (3) changing the password specification field can be used for indicating that the key needs to be changed, for example, if the contents of the password specification field and/or the handshake field are changed too much, the contents of the fields can be split, and part of the contents can be indicated by the record field; (4) reserved fields, which may be spare fields, are used to indicate information in other meanings. It should be understood that these four types of fields may be carried in the request message or the response message according to actual needs, and need not be carried at the same time every request/response.
It should be understood that the format of the HTTP response message (response) is similar to that of the request message, and when the server negotiates a key with the client, relevant parameters may be filled in an extension field of the header of the response message. For the sake of brevity, the format of the HTTP response message will not be described in detail here.
It should also be understood that the format of the HTTP request message shown in fig. 5 is only an example, and in practical applications, the HTTP request message may include more types of data than that shown in fig. 5, and may also have a more complex format than that shown in fig. 5, which is not limited in this embodiment of the application.
Illustratively, the method for secure communication provided by the embodiment of the present application may be executed by a client and a server as a main body, and includes the following steps:
s101, sending a first hypertext transfer protocol (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.
The format of the first HTTP request message may be as shown in fig. 5.
In some embodiments, the first key agreement parameter included in the extension field of the first HTTP request packet header may be a first random number randomly generated by the client, for example, random-C, and may be used for the client and the server to generate the agreement key.
In some embodiments, the extension field of the first HTTP request message header may further include a set of encryption algorithms supported by the client, in other words, the set of encryption algorithms may include a plurality of encryption algorithms supported by the client. After the server receives the first HTTP request message, a first encryption algorithm that can be supported by the server may be selected collectively by the encryption algorithm, and the first encryption algorithm may be used to calculate a negotiation key thereafter.
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, the 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 first HTTP response packet header may be a second random number randomly generated by the server, where the second random number is random-S, for example, and the second random number may be used for the client and the server to generate the negotiation key.
In some embodiments, the extension field of the header of the first HTTP response message may further include a certificate (or a public key certificate) of the server, where the certificate of the server includes a public key of the server. In some embodiments, after receiving the first HTTP response packet, the client may authenticate the certificate of the server, and after the authentication is passed, obtain the public key of the server according to the certificate of the server, and then generate the premaster secret key of the client according to the public key of the server. For example, the process of generating the premaster secret by the client may be: the client may encrypt a randomly generated random number (which may be different from the first random number and the second random number) by using the public key of the server, so as to generate a 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 header of the second HTTP request message may include the premaster secret of the client. And the server receives the second HTTP request message and can decrypt the premaster secret key of the client according to the local private key stored in 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. Then, the server side can generate a negotiation key according to the first key negotiation parameter, the second key negotiation parameter and the pre-master key.
In some embodiments, the extension field of the header of the first HTTP response message further includes a first encryption algorithm, and the first encryption algorithm is any encryption algorithm supported by the encryption algorithm set and the server. 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 credential request for requesting a credential 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 packet 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 encrypted communication between the client and the server.
In some embodiments, the client may generate a negotiation key according to the obtained first random number, the second random number, and the generated pre-master key, where the negotiation key may be a master key (or a public key) for secure communication between the client and the candidate server, and the negotiation key may also be described as a master key in the following embodiments.
In some embodiments, after receiving the second HTTP request packet of the client, the server decrypts to obtain the premaster secret key, and then the server may generate the negotiation secret key according to the obtained first random number, the second random number, and the premaster secret key.
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 a header of the HTTP encrypted message comprises first encryption strategy information, and the first encryption strategy information is used for indicating the type of encrypted data in the HTTP encrypted message or the position of the encrypted data.
In some embodiments, after the client generates the negotiation key, the HTTP encryption 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 target type data in the HTTP encrypted message according to a negotiation key; or encrypting the data of the target position in the HTTP encryption message according to the negotiation key. Wherein the target type of data may include at least one of: parameters of key agreement, a set of encryption algorithms, a certificate of the client or the server, encryption policy information (such as first encryption policy information and second encryption policy information, third encryption policy information, etc. mentioned below); the data of the target location may comprise at least one of: partial data positioned in the head of the HTTP encrypted message; or, the partial data located in the entity part of the HTTP encrypted message; or, all data located in the entity 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 may decrypt encrypted data in the HTTP encrypted message according to the first encryption policy information.
It should be understood that the server side can accurately and specifically decrypt the encrypted data in the HTTP encrypted message according to the first encryption policy information, and the decryption efficiency of the server side can be improved.
In some embodiments, the client and the server may preset an encryption policy, such as which types of data need to be encrypted, which locations of data need to be encrypted, a usage period of a key is negotiated, and the like. In the communication process, the client can inform the server of the encryption strategy selected by the client through an HTTP encryption message. Specifically, the extension field of the HTTP encryption message header may further include second encryption policy information, which may be used to instruct the server to encrypt data of the target type and/or encrypt data of the target location. The extension field of the HTTP encrypted message header may further include third encryption policy information, which may be used to indicate at least one of the following information: after the negotiation key is generated, encrypting messages transmitted between the server and the client each time (namely, one-time pad); or, after generating the negotiation key, a new negotiation key is regenerated every N transmission intervals (i.e. one cipher at a time), where N is an integer greater than 1. After receiving the HTTP encryption message, the server may encrypt data of a second encryption policy target type, or may encrypt data of a second encryption policy target location; and according to a third encryption strategy, communicating with the client in a one-time pad mode or communicating with the client in a one-time pad mode for multiple times.
According to the secure communication method provided by the embodiment of the application, the extension field in the message header of the HTTP request message or the HTTP response message carries the parameter of the key generated by negotiation, so that the client and the server can realize secure communication based on the HTTP protocol, and the specific data in the message or the message transmitted each time can be flexibly encrypted according to the requirement, thereby further improving the communication efficiency on the basis of ensuring the secure communication.
In order to more clearly understand the method for secure communication provided by the embodiment of the present application, the following describes the process of the secure communication method in more detail with reference to fig. 6 and fig. 7. Illustratively, as shown in fig. 6, a schematic flow chart of a secure communication provided by the embodiments of the present application is provided. The process may be performed by a client (client), which may be, for example, the electronic device 100 in fig. 1 and a server (server), which may be the server 200 in fig. 1.
It should be understood that before the client and the server perform HTTP communication according to the process shown in fig. 6, a TCP communication connection needs to be established, that is, an interactive process of completing a three-way handshake (TCP handshake) needs to be completed. The specific procedure of the three-way handshake can be referred to the existing flow, and is not detailed here. After the TCP connection is completed between the client and the server, the HTTP handshake, certificate/key/password negotiation and exchange (certificate/key/password negotiation and exchange), and handshake completion (handshake complete) stages may be performed according to the process shown in fig. 6. Illustratively, the method for secure communication provided by the embodiment of the present 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 packet may include an extension field, and information carried in the extension field may be used to indicate related parameters supporting an HTTP protocol and an encryption algorithm and other auxiliary information (e.g., a Server Name Indication (SNI)).
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 conforms to the specification in the HTTP protocol, the server may successfully read the specific information of the handshake field, and thus 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 the client and the server to handshake and negotiate to generate a key. The extension field of the header of the first HTTP request message may include information such as a client random number (random-C), a list of encryption suites (ciphers) supported by the client, and the like. Wherein the client random number (random-C) is used for subsequent negotiations to generate a key.
It should be understood that the encryption suite list, which may include at least one encryption algorithm supported by the client, may also be described as a set of encryption algorithms. 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 identity verification; the key exchange algorithm is used for the client and the server to negotiate a key; the symmetric encryption algorithm is used for encrypting the transmission data by adopting a symmetric encryption mode between the client and the server; the summary list is used for the server to check 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 packet 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 information compression transmission. In other embodiments, the first HTTP request message may further include other information than those described above, which is not limited in this application.
It should be understood that the first HTTP request packet may be used for a first handshake after the client and the server establish a TCP connection, and the client and the server may not negotiate a generation key at this time, so the client may transmit the first HTTP request packet in a plaintext manner. For similar reasons, the messages transmitted before the negotiation to generate the key, such as the first HTTP response message, may all be in clear text.
S602, the server side sends a first HTTP response message to the client side.
In some embodiments, the server receives a first HTTP request message sent by the client, and 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 a negotiated information result.
The first HTTP response packet 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, and information carried by the extension field may be used to indicate relevant parameters for supporting the HTTP protocol and the encryption algorithm, and other auxiliary information.
In some embodiments, the extension field of the header of the first HTTP response message may include a random-S (random-S) number sent by the server to the client and an encryption algorithm supported by the server.
In some embodiments, the extension field of the header of the first HTTP response message may further include a cipher suite (cipher suite) selected by the server, such as a certificate (certificate) of the server.
In some embodiments, the server may support multiple key exchange algorithms, such as 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 packet may further include server-key-exchange (server-key-exchange) information, such as key-exchange (key-exchange) information carried in a cipher suite (cipher suite), and 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 the RSA algorithm, the first HTTP response packet does not need to include server-key-exchange (server-key-exchange) information.
In some embodiments, if the server requires the client to verify the identity using the certificate, the extension field of the first HTTP response packet may further include certificate request (certificate request) information sent by the server. Optionally, the first HTTP response packet may further include server-hello-done (server-hello-done) information. The specific description of each information included in the extension field of the first HTTP response packet is as follows:
(1) random number (random-S) and encryption algorithm supported by the server: for subsequent generation of the key.
(2) Certificate of server (certificate): the certificate message may specifically include a certificate chain from a digital certificate to a certificate issuing Authority (CA) configured by the server, where the certificate chain may be used to indicate, to the client, validity and authenticity of the identity of the server, for example, the identity of the server is not a counterfeit server.
(3) Server key exchange (server key exchange) information: determining whether to send the key exchange information of the server to the client based on a key exchange algorithm supported by the server, for example, when the server supports a DH algorithm, the server may send the key exchange information to the client, where the key exchange information may include a DH parameter of the server; 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 request) information: the system is used for requesting the certificate from the client so as to enable the server to authenticate the identity of the client.
(5) Server-hello-done (server-hello-done) message: the method can be used for informing the client that the group of messages in the first HTTP corresponding message of the server is 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 a header of the first HTTP response message, and the format of the extension field may be located at any position of the header on the basis that the HTTP protocol specification is satisfied, and the application does not limit the specific location of the extension field.
It should be understood that the first HTTP response message may also include more information than the above description, and the application is not limited thereto.
S603, the client sends a second HTTP request message to the server.
The second HTTP request packet may be a handshake request message (handshake message) sent by the client to the server.
In some embodiments, after receiving the first HTTP response packet of the server, the client may verify the validity of the server certificate, and if the verification is passed, perform subsequent communication, otherwise perform corresponding prompt and operation according to different error conditions. Exemplary, the content of certificate validity verification may include: (1) trustworthiness (trusted certificate path) of the certificate chain; (2) whether the certificate is revoked (revocation); (3) validity period (expiry date), i.e. whether the certificate is in the validity time range; (4) domain name (domain), i.e., to check whether the certificate domain name matches the current access domain name, etc. And after the client side verifies that the certificate of the server side is legal, a second HTTP request message can be sent to the server side.
In some embodiments, the server certificate that the server sends to the client may include the server's public key. After the certificate of the client for the server passes the authentication, the public key (or called certificate public key) of the server can be obtained.
In some embodiments, the extension field of the header (request header) of the second HTTP request message may include key-exchange (key-exchange) information. For example, when the server and the client use the RSA key exchange algorithm, the client may encrypt a randomly generated random number with a public key of the server to generate a client-ready master key (pre-master). At this time, the key-exchange information may include a client-prepared master key (pre-master); when the DH key exchange algorithm is used by the client and the server, the client-key-exchange information may include client DH parameters.
In some embodiments, after receiving the certificate request message from the server, the client may generate a client-certificate (client-certificate) message and a certificate-verification (certificate-verification) message including a private-key signature by using a local private-key signature. The specific description of each packet is as follows:
(1) client-side certificate (client-certificate) message: the client side is generated in response to the certificate request information of the server side, and the certificate request information is used for verifying the legality of the identity of the client side by the server side.
(2) Certificate verification (certificate verification) message: for signing the preliminary master key and the random number.
S604, the server calculates the 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 server may calculate the master key according to a pre-master key (pre-master) of the client and two random numbers random-C and random-S exchanged before.
In an implementation manner, when a key exchange algorithm adopted by a server and a client is an RAS algorithm, the server may first decrypt a client preliminary master key (pre-master) by using a private key stored by the server itself, and then calculate to obtain a master key according to the preliminary master key (pre-master) of the client and two random-C and random-S numbers exchanged before, where the master key generated by negotiation may be: enc-key ═ Fnc (random-C, random-S, pre-master).
In another implementation, when the key exchange algorithm adopted by the server and the client is a DH algorithm, the server may calculate a pre-master key (pre-master) of the client according to the DH parameters, and then calculate a master key according to the pre-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 execute step S605 on the second HTTP request packet in step S603: and the server side sends a second HTTP response message to the client side.
S606, the client calculates the master key.
In some embodiments, the client calculates a master key (main master) used by the client for encrypted secure communication with the server based on a pre-master key (pre-master) of the client, such as enc-key Fnc (random-C, random-S, pre-master), and two random numbers random-C and random-S exchanged before.
It should be understood that the step of the client computing the master key according to the client-side prepared 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 obtains the client-side prepared master key, the random number (random-C and random-S), and the like for computing the parameters for generating the master key, the master key may be computed, and the steps are not limited to being performed in the order shown in the embodiment of fig. 6.
S607, the client sends the HTTP encrypted message to the server.
The HTTP encrypted message may carry a changed password specification field CSS, such as changed password specification information. The HTTP encrypted message may also carry a new encryption algorithm (hereinafter referred to as new algorithm) to negotiate a master key for calculating subsequent data transmission; the HTTP encrypted message may further include a finish message generated by the key, and is used to inform the server that the generation of the master key by the negotiation is completed. The finish message may be a message generated by encrypting a field by using a master key generated by negotiation at the client, and is used for verifying that the client generates a correct master key at the server, and the specific encrypted field may be flexibly set according to the currently executed service type, which is not limited in the present application.
In some embodiments, the HTTP encrypted message may also include a digest 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 digest list may include a name of the first HTTP request packet sent by the client in step S601 (e.g., client-hello), a name of the second HTTP request packet sent by the client in step S603 (e.g., hand hash message), and the like. The summary list is used for the server side to verify whether the received message is consistent with the message sent by the client side or not so as to prevent a third party from tampering the transmitted message 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 can encrypt specific data important or sensitive in the HTTP encrypted message by using the master key, such as encrypting information related to a new algorithm.
In some embodiments, when the client encrypts part of information in the HTTP encrypted message by using the master key, the client may carry encryption policy information in an extension field of a 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, where information in the HTTP encrypted message is encrypted, or the like.
It should be understood that according to the method provided in this embodiment of the present application, the client may encrypt not only the specific data in the entity portion of the request message, but also encrypt 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 and generating subsequent data transmission, the master key that has been negotiated may be used to encrypt the relevant parameter.
And S608, the server side carries out information verification.
In some embodiments, the service may decrypt the finish message using the negotiated master key, and if the decryption is successful, it indicates that the client generates the correct master key, and the subsequent communication service may use the master key to encrypt the transmitted data.
In some embodiments, the server may further verify the digest 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 the transmitted information and ensure the security of information transmission.
It should be understood that the client and the server may negotiate or preset an encryption policy, such as setting a password update period (e.g., transmitting a one-time pad; or changing a key after each N consecutive transmissions, where N is an integer greater than 1), using a default key to encrypt which part of data (e.g., using a default negotiated key to encrypt an entity part of data, but not encrypting header data), using a default key to encrypt which type of data, and so on. Therefore, if the client and the server need to use a new key in the subsequent communication process, in this step, the server may also negotiate and calculate a new master key for subsequent data transmission according to parameters such as a new encryption algorithm carried in the HTTP encryption packet, and the negotiation process of the new master key is similar to steps S601 to S607, and is not described here again.
According to the secure communication method provided by the embodiment of the application, the extension field in the message header of the HTTP request message or the HTTP response message carries the parameter of the key generated by negotiation, so that the client and the server can realize secure communication based on the HTTP protocol, and the specific data in the message or the message transmitted each time can be flexibly encrypted according to the requirement, thereby further improving the communication efficiency on the basis of ensuring the secure communication.
Illustratively, as shown in fig. 7, a schematic flow chart of another secure communication provided by the embodiment of the present application is provided. The process may be performed by a client (client), which may be, for example, the electronic device 100 in fig. 1 and a server (server), which may be the server 200 in fig. 1.
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 side calculates the server side master key.
Optionally, the server may execute step S705 for the second HTTP request packet in step S703: and the server side sends a second HTTP response message to the client side.
S706, the client calculates the master key.
And S707, the client sends the HTTP encrypted message to the server.
And S708, the server side carries out information verification.
It should be understood that steps S701 to S708 may be a process of first negotiating and generating a key after handshaking between the client and the server, and the process is similar to the process shown in the embodiment of fig. 6, and for specific description, reference may be made to the relevant contents of steps S601 to S608, and details are not described here again. Unlike the embodiment of fig. 6, the embodiment of fig. 7 further includes: after the client and the server negotiate for the first time to generate a master key, the client and the server encrypt specific data by using the master key, and negotiate a new master key to be used subsequently. The process may include the steps of:
s709, the server sends a third HTTP response packet to the client.
It should be appreciated that to ensure data security during HTTP transmissions, the client and server may change the encryption specification at intervals, such as using new parameters to generate a new master key. Therefore, in this step, the third HTTP response packet sent by the server may carry a change cipher specification field CSS, where the change specification field CSS is used to instruct the client to change the encryption and decryption parameters used by negotiating to generate a new key.
In some embodiments, the extension field of the HTTP encrypted message header may further include a new algorithm for the server and the client to negotiate generation of a new master key for subsequent secure communication.
In some embodiments, the HTTP encryption message may further include a key generation finish message for informing the client that the negotiation of the generation of the master key is completed. The finish message may be a message generated by encrypting a field by using a master key generated by negotiation by the server, and is used for the client to verify that the server generates a correct master key, and the specific encrypted field may be flexibly set according to the currently executed service type, which is not limited in the present 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 negotiation. Illustratively, the specific data may be all entity data of the fourth HTTP request message, or part of the entity data (such as any sensitive or important entity data); alternatively, the specific data may also be all header data of the fourth HTTP request message, or part of the header data (e.g., a parameter in a header extension field related to negotiating generation of a new master key to be used subsequently).
In some embodiments, the extension field of the header of the fourth HTTP request message may carry indication information indicating which data (e.g., which locations and types) of the fourth HTTP request message is encrypted.
In some embodiments, when the fourth HTTP request message does not include data that needs to be encrypted, the client may not encrypt the fourth HTTP request message.
In summary, the client can flexibly determine whether to encrypt or encrypt data according to the importance or sensitivity of the data included in the request message, thereby saving encryption processing resources of the client and improving the efficiency of data transmission.
And 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 specific data in the fourth HTTP response message using a 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 also be all header data in the fourth HTTP response message, or part of the header data (e.g., a parameter in a header extension field related to negotiating generation of a new master key to be used subsequently).
In some embodiments, the extension field of the header of the fourth HTTP response message may carry indication information indicating which data (e.g., which locations and types) of the fourth HTTP response message is encrypted.
In some embodiments, when the fourth HTTP response message does not include data that needs to be encrypted, the server may not encrypt the fourth HTTP response message.
In summary, the server can flexibly determine whether to encrypt the data in the message or which data to encrypt according to the importance or sensitivity of the data in the response message, thereby saving the encryption processing resources of the client and improving the efficiency of data transmission.
According to the secure communication method provided by the embodiment of the application, the extension field in the message header of the HTTP request message or the HTTP response message carries the parameter of the key generated by negotiation, so that the client and the server can realize secure communication based on the HTTP protocol, and the specific data in the message or the message transmitted each time can be flexibly encrypted according to the requirement, thereby further improving the communication efficiency on the basis of ensuring the secure communication.
Exemplarily, as shown in fig. 8, a schematic structural diagram of a server device provided in an embodiment of the present application is shown. The apparatus 800 includes 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 hypertext transfer protocol HTTP request message to the server, where an extension field of a header of the first HTTP request message includes a first key agreement parameter.
The receiving module 802 may be configured to receive a first HTTP response packet sent by the server, where an extension field of a header of the first HTTP response packet includes a second key negotiation parameter.
The key generating 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 message generated by the client to the server, where an extension field of a header of the HTTP encrypted message includes first encryption policy information, and the first encryption policy information is used to indicate a type of encrypted data in the HTTP encrypted message or a location of the encrypted data.
In some embodiments, the generating an HTTP encrypted packet according to the negotiation key specifically includes: encrypting the target type data in the HTTP encrypted message according to the negotiation key; or encrypting the data of the target position in the HTTP encryption message according to the negotiation key.
In some embodiments, the target type of data comprises at least one of: parameters of key agreement, an encryption algorithm set, a certificate of the client or the server, and encryption policy information.
In some embodiments, the data of the target location comprises at least one of: partial data positioned in the head of the HTTP encrypted message; or, the partial data located in the entity part of the HTTP encrypted message; or, all data located in the entity part of the HTTP encrypted 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 packet header further includes third encryption policy information indicating at least one of the following information: after the negotiation key is generated, encrypting messages transmitted between the server and the client each time; or, after the negotiation key is generated, a new negotiation key is generated again 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 header of the first HTTP response packet further includes a certificate of the server, where the certificate of the server includes the 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 key of the client according to the public key of the server.
In some embodiments, the sending module 801 may be further configured to send a second HTTP request message to the server, where an extension field of a header of the second HTTP request message includes the premaster secret key.
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 generating 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 comprises a set of encryption algorithms supported by the client.
In some embodiments, the extension field of the header of the first HTTP response message further includes a first encryption algorithm, and the first encryption algorithm is any encryption algorithm supported by the server side in the encryption algorithm set.
In some embodiments, when the extension field of the first HTTP response message header further comprises a certificate request for requesting a certificate of the client, the extension field of the second HTTP request message header further comprises the certificate of the client.
In some embodiments, the extension field includes at least one of: handshake field, record field, change cipher specification field, reserved field.
Exemplarily, as shown in fig. 9, a schematic structural diagram of a server device provided in an embodiment of the present application is shown. The client device 900 comprises a receiving module 901, a sending module 902 and a key generating module 903.
In some embodiments, the receiving module 901 may be configured to receive a first hypertext transfer protocol HTTP request message sent by a client, where an extension field of a header of the first HTTP request message includes a first key agreement 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 pre-master 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 message sent by the client, where an extension field of a header of the HTTP encrypted message 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 encryption 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 target type of data comprises at least one of: parameters of key agreement, an encryption algorithm set, a certificate of the client or the server, and encryption policy information.
In some embodiments, the data of the target location comprises at least one of: partial data positioned in the head of the HTTP encrypted message; or, the partial data located in the entity part of the HTTP encrypted message; or, all data located in the entity part of the HTTP encrypted message.
In some embodiments, the extension field of the HTTP encrypted message header further includes third encryption policy information indicating at least one of the following information: after the negotiation key is generated, encrypting messages 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 comprises a set of encryption algorithms supported by the client; the key generation module 903 may further be configured to select, according to the encryption algorithm set, a first encryption algorithm supported by the server.
In some embodiments, the extension field of the first HTTP response packet header further includes certificate request information for requesting a certificate of the client.
In some embodiments, the server device 900 may further include an authentication module, and when the second HTTP request packet further includes the certificate of the client, the authentication module may be configured to verify the 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 message sent by the client, where the HTTP encrypted message includes encrypted data encrypted by using the negotiation key.
Exemplarily, as shown in fig. 10, a schematic diagram of a hardware structure of a client device provided in an embodiment of the present application is shown. 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 via a Universal Serial Bus (USB) 1004, the communication interface 1003 being configured to communicate with other devices, the memory 1002 comprising computer program instructions that, when executed in the processor 1001, cause the client device to implement the method for secure communication as provided by embodiments of the present application.
Exemplarily, as shown in fig. 11, a hardware structure diagram of a server device provided in the embodiment of the present application is shown. The server device 1100 may include at least one processor 1101, a memory 1102 and a communication interface 1103, where the processor 1101, the memory 1102 and the communication interface 1103 may be connected through a Universal Serial Bus (USB) 1104, the communication interface 1103 is used for communicating with other devices, and the memory 1102 includes computer program instructions, which, when executed in the processor 1101, cause the client device to implement the method for secure communication as provided in the embodiments of the present application.
The embodiment of the present application further provides a system for secure communication, where the communication system includes a client device and a server device, the client device is configured to execute the function of the method for providing secure communication in the embodiment of the present application on the client, and the server device is configured to execute the function of the method for providing secure communication in the embodiment of the present application on the server.
The embodiment of the application also provides a computer-readable storage medium, wherein a computer-executable program is stored in the computer-readable storage medium, and when the computer-executable program is called by a computer, the computer is enabled to realize the method for secure communication provided by the embodiment of the application.
An embodiment of the present application further provides a chip system, where the chip system includes: 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, so that the device provided with the chip system realizes the method for secure communication provided by the embodiment of the application.
Embodiments of the present application further provide a computer program product, where the computer program product includes computer program instructions, which, when executed on a computer, cause the computer or a processor to execute one or more steps of any of the above methods, so as to implement the method for secure communication provided by the embodiments of the present application.
In the above embodiments, the implementation may be wholly or partially realized 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, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in or transmitted over a computer-readable storage medium. The computer instructions may be transmitted from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optics, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.
One of ordinary skill in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by hardware related to instructions of a computer program, which may be stored in a computer-readable storage medium, and when executed, may include the processes of the above method embodiments. And the aforementioned storage medium includes: various media capable of storing program codes, such as ROM or RAM, magnetic or optical disks, etc.
The above description is only a specific implementation of the embodiments of the present application, but the 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 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 (28)

1. A method for secure communication, applied to a client, includes:
sending a first hypertext transfer protocol (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;
generating a negotiation key according to the first key negotiation parameter and the second key negotiation parameter, wherein the negotiation key is used for encrypted communication between the client and the server;
generating an HTTP encrypted message according to the negotiation key, and sending the HTTP encrypted message to the server, wherein an extension field of a header of the HTTP encrypted message comprises first encryption strategy information, and the first encryption strategy information is used for indicating the type of encrypted data in the HTTP encrypted message or the position of the encrypted data.
2. The method according to claim 1, wherein the generating an HTTP encrypted packet according to the negotiation key specifically includes:
encrypting the target type data in the HTTP encrypted message according to the negotiation key; alternatively, the first and second electrodes may be,
and encrypting the data of the target position in the HTTP encrypted message according to the negotiation key.
3. The method of claim 2, wherein the target type of data comprises at least one of:
parameters of key agreement, an encryption algorithm set, a certificate of the client or the server, and encryption policy information.
4. A method according to claim 2 or 3, wherein the data of the target location comprises at least one of:
partial data positioned in the head of the HTTP encrypted message; alternatively, the first and second electrodes may be,
partial data located in the entity part of the HTTP encrypted message; alternatively, the first and second electrodes may be,
and all data positioned in the entity part of the HTTP encrypted message.
5. The method according to any of claims 2-4, wherein the extension field of the HTTP encrypted message header further comprises second encryption policy information for instructing the server to encrypt the data of the target type and/or encrypt the data of the target location.
6. The method according to any of claims 1-5, wherein the extension field of the HTTP encrypted message header further comprises third encryption policy information indicating at least one of the following information:
after the negotiation key is generated, encrypting messages transmitted between the server and the client each time; alternatively, the first and second electrodes may be,
and after the negotiation key is generated, regenerating a new negotiation key every N transmission intervals, wherein N is an integer greater than 1.
7. The method according to any of claims 1-6, wherein the extension field of the first HTTP response packet header further 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 pre-master 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 a header of the second HTTP request message comprises the premaster secret key.
8. The method of claim 7, 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 the pre-master key.
9. The method according to any of claims 1-8, wherein the extension field of the first HTTP request message header further comprises a set of cryptographic algorithms supported by the client.
10. The method according to claim 9, wherein the extension field of the header of the first HTTP response message further comprises a first encryption algorithm, and the first encryption algorithm is any encryption algorithm supported by the server side in the set of encryption algorithms.
11. The method according to any of claims 7-10, wherein when the extension field of the first HTTP response message header further comprises a certificate request for requesting the client's certificate, the extension field of the second HTTP request message header further comprises the client's certificate.
12. The method of any one of claims 1-11, wherein the extension field comprises at least one of:
handshake field, record field, change cipher specification field, reserved field.
13. A method for secure communication, applied to a server, 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 the head extension field of the second HTTP request message comprises a premaster secret key of the client;
and generating a negotiation key according to the first key negotiation parameter, the second key negotiation parameter and the pre-master key, wherein the negotiation key is used for encrypted communication between the client and the server.
14. The method of claim 13, further comprising:
receiving an HTTP encrypted message sent by the client, wherein an extension field of a 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.
15. The method according to claim 13 or 14, wherein the extension field of the HTTP encrypted message header further includes second encryption policy information for instructing the server to encrypt data of a target type and/or data of a target location, and the method further comprises:
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.
16. The method of claim 15, wherein the target type of data comprises at least one of:
parameters of key agreement, an encryption algorithm set, a certificate of the client or the server, and encryption policy information.
17. The method according to claim 15 or 16, wherein the data of the target position comprises at least one of:
partial data positioned in the head of the HTTP encrypted message; alternatively, the first and second electrodes may be,
partial data located in the entity part of the HTTP encrypted message; alternatively, the first and second electrodes may be,
and all data positioned in the entity part of the HTTP encrypted message.
18. The method according to any of claims 13-17, wherein the extension field of the HTTP encrypted message header further comprises third encryption policy information indicating at least one of the following information:
after the negotiation key is generated, encrypting messages transmitted between the server and the client each time; alternatively, the first and second electrodes may be,
and after the negotiation key is generated, regenerating a new negotiation key every N transmission intervals, wherein N is an integer greater than 1.
19. The method according to any of claims 13-18, 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.
20. The method according to any of claims 13-19, wherein the extension field of the first HTTP request message header further comprises a set of cryptographic 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.
21. The method according to any of claims 13-20, wherein the extension field of the first HTTP response packet header further comprises credential request information for requesting the client's credentials.
22. The method according to any of claims 13-21, 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.
23. A client device comprising at least one processor, 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 carry out a method of secure communication according to any one of claims 1 to 12.
24. A server device comprising at least one processor, 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 carry out a method of secure communication according to any one of claims 13 to 22.
25. A system for secure communication, comprising a client device for performing the method for secure communication according to any one of claims 1 to 12 and a server device for performing the method for secure communication according to any one of claims 13 to 22.
26. A computer-readable storage medium, characterized in that it stores a computer-executable program which, when invoked by a computer, causes the computer to perform the method of any one of claims 1 to 12 or to perform the method of any one of claims 13 to 22.
27. 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 such that a device on which the system-on-chip is installed performs the method of any of claims 1 to 12 or performs the method of any of claims 13 to 22.
28. A computer program product, characterized in that it comprises computer program instructions which, when run on a computer, cause the computer to carry out the method of any one of claims 1 to 12, or carry out the method of any one of claims 13 to 22.
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 true CN113438071A (en) 2021-09-24
CN113438071B 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)

Cited By (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
CN114143026A (en) * 2021-10-26 2022-03-04 福建福诺移动通信技术有限公司 Data security interface based on asymmetric and symmetric encryption and working method thereof
CN114465775A (en) * 2021-12-31 2022-05-10 华为技术有限公司 Secure transmission method and device
CN114499969A (en) * 2021-12-27 2022-05-13 天翼云科技有限公司 Communication message processing method and device, electronic equipment and storage medium
CN114629708A (en) * 2022-03-18 2022-06-14 蚂蚁区块链科技(上海)有限公司 Client request encryption transmission method, data decryption method and system
CN114866527A (en) * 2022-04-29 2022-08-05 中国科学院信息工程研究所 Data processing method, device and system
CN115296847A (en) * 2022-07-06 2022-11-04 杭州涂鸦信息技术有限公司 Flow control method and device, computer equipment and storage medium
CN115333839A (en) * 2022-08-15 2022-11-11 中国电信股份有限公司 Data security transmission method, system, device and storage medium
WO2023155599A1 (en) * 2022-02-16 2023-08-24 华为技术有限公司 Data transmission method and apparatus
CN116685001A (en) * 2023-06-12 2023-09-01 成都理工大学 Lora ad hoc network communication method with dynamic encryption function
CN116980128A (en) * 2023-09-22 2023-10-31 北京数盾信息科技有限公司 Inter-application data transmission processing method and device
WO2024021478A1 (en) * 2022-07-29 2024-02-01 天翼云科技有限公司 Data transmission method and apparatus, device, and medium

Citations (8)

* 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
US7249377B1 (en) * 1999-03-31 2007-07-24 International Business Machines Corporation Method for client delegation of security to a proxy
US20090132806A1 (en) * 2004-06-10 2009-05-21 Marc Blommaert Method for agreeing between at least one first and one second communication subscriber to security key for securing communication link
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

Patent Citations (8)

* 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
US20040193871A1 (en) * 2003-03-28 2004-09-30 Broadcom Corporation System and method for transmitting data using selective partial encryption
US20090132806A1 (en) * 2004-06-10 2009-05-21 Marc Blommaert Method for agreeing between at least one first and one second communication subscriber to security key for securing communication link
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

Cited By (20)

* 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
CN114143026A (en) * 2021-10-26 2022-03-04 福建福诺移动通信技术有限公司 Data security interface based on asymmetric and symmetric encryption and working method thereof
CN114143026B (en) * 2021-10-26 2024-01-23 福建福诺移动通信技术有限公司 Data security interface based on asymmetric and symmetric encryption and working method thereof
CN114499969A (en) * 2021-12-27 2022-05-13 天翼云科技有限公司 Communication message processing method and device, electronic equipment and storage medium
CN114499969B (en) * 2021-12-27 2023-06-23 天翼云科技有限公司 Communication message processing method and device, electronic equipment and storage medium
CN114465775A (en) * 2021-12-31 2022-05-10 华为技术有限公司 Secure transmission method and device
CN114465775B (en) * 2021-12-31 2023-10-20 华为技术有限公司 Secure transmission method and device
WO2023125865A1 (en) * 2021-12-31 2023-07-06 华为技术有限公司 Secure transmission method and apparatus
WO2023155599A1 (en) * 2022-02-16 2023-08-24 华为技术有限公司 Data transmission method and apparatus
CN114629708A (en) * 2022-03-18 2022-06-14 蚂蚁区块链科技(上海)有限公司 Client request encryption transmission method, data decryption method and system
CN114866527A (en) * 2022-04-29 2022-08-05 中国科学院信息工程研究所 Data processing method, device and system
CN114866527B (en) * 2022-04-29 2023-09-15 中国科学院信息工程研究所 Data processing method, device and system
CN115296847A (en) * 2022-07-06 2022-11-04 杭州涂鸦信息技术有限公司 Flow control method and device, computer equipment and storage medium
CN115296847B (en) * 2022-07-06 2024-02-13 杭州涂鸦信息技术有限公司 Flow control method, flow control device, computer equipment and storage medium
WO2024021478A1 (en) * 2022-07-29 2024-02-01 天翼云科技有限公司 Data transmission method and apparatus, device, and medium
CN115333839A (en) * 2022-08-15 2022-11-11 中国电信股份有限公司 Data security transmission method, system, device and storage medium
CN115333839B (en) * 2022-08-15 2023-11-07 中国电信股份有限公司 Data security transmission method, system, equipment and storage medium
CN116685001A (en) * 2023-06-12 2023-09-01 成都理工大学 Lora ad hoc network communication method with dynamic encryption function
CN116980128A (en) * 2023-09-22 2023-10-31 北京数盾信息科技有限公司 Inter-application data transmission processing method and device
CN116980128B (en) * 2023-09-22 2023-12-26 北京数盾信息科技有限公司 Inter-application data transmission processing method and device

Also Published As

Publication number Publication date
CN113438071B (en) 2024-04-09

Similar Documents

Publication Publication Date Title
CN113438071B (en) Method and device for secure communication
CN110380852B (en) Bidirectional authentication method and communication system
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
US9137017B2 (en) Key recovery mechanism
WO2017045552A1 (en) Method and device for loading digital certificate in ssl or tls communication
EP2262164A1 (en) Secure data transfer
EP3633949A1 (en) Method and system for performing ssl handshake
CN111756529B (en) Quantum session key distribution method and system
CN112913189B (en) OTA (over the air) upgrading method and device
CN110493272B (en) Communication method and communication system using multiple keys
EP4231680A1 (en) Identity authentication system, method and apparatus, device, and computer readable storage medium
CN111756528B (en) Quantum session key distribution method, device and communication architecture
JP2020533853A (en) Methods and equipment for managing digital certificates
CN113207322B (en) Communication method and communication device
CN104243452A (en) Method and system for cloud computing access control
CN109960935B (en) Method, device and storage medium for determining trusted state of TPM (trusted platform Module)
US20240113885A1 (en) Hub-based token generation and endpoint selection for secure channel establishment
US10671717B2 (en) Communication device, communication method and computer program
CN113872765A (en) Identity credential application method, identity authentication method, equipment and device
US20240064011A1 (en) Identity authentication method and apparatus, device, chip, storage medium, and program
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
CN113796058B (en) Key transmission method and device
CN112929871A (en) OTA upgrade package acquisition method, electronic device and storage medium
EP4044553A1 (en) Method and device to provide a security level for communication

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