[go: up one dir, main page]

CN110798431A - Security parameter interaction method, device, equipment and system - Google Patents

Security parameter interaction method, device, equipment and system Download PDF

Info

Publication number
CN110798431A
CN110798431A CN201810875609.1A CN201810875609A CN110798431A CN 110798431 A CN110798431 A CN 110798431A CN 201810875609 A CN201810875609 A CN 201810875609A CN 110798431 A CN110798431 A CN 110798431A
Authority
CN
China
Prior art keywords
message
key
expansion
http request
protocol
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.)
Pending
Application number
CN201810875609.1A
Other languages
Chinese (zh)
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.)
Hangzhou Hikvision Digital Technology Co Ltd
Original Assignee
Hangzhou Hikvision Digital Technology 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 Hangzhou Hikvision Digital Technology Co Ltd filed Critical Hangzhou Hikvision Digital Technology Co Ltd
Priority to CN201810875609.1A priority Critical patent/CN110798431A/en
Publication of CN110798431A publication Critical patent/CN110798431A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • 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
    • 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/12—Applying verification of the received information
    • 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]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

The embodiment of the application provides a security parameter interaction method, a security parameter interaction device, a security parameter interaction equipment and a security parameter interaction system, wherein the method comprises the following steps: the equipment executing the scheme constructs a first message based on a key protocol, wherein the first message comprises encrypted security parameters; adding the first message to an expansion field of the HTTP request message to obtain an expansion HTTP request message; sending an expansion HTTP request message; therefore, according to the scheme, the HTTP message is expanded, the security parameters are added to the expansion field of the HTTP request message, and the compatibility of the HTTP and the key protocol is realized.

Description

Security parameter interaction method, device, equipment and system
Technical Field
The present application relates to the field of communications technologies, and in particular, to a method, an apparatus, a device, and a system for security parameter interaction.
Background
The HyperText Transfer Protocol (HTTP) is a network Protocol widely used on the internet. Messages communicated using HTTP typically include Request messages (requests) and Response messages (responses). Since plaintext is used in HTTP communication, HTTP is not compatible with some key protocols, such as MIKEY (multimedia internet KEYing, a standard protocol for negotiating security parameters).
Disclosure of Invention
An object of the embodiments of the present application is to provide a method, an apparatus, a device, and a system for security parameter interaction, so as to implement compatibility between HTTP and a key protocol.
In order to achieve the above object, an embodiment of the present application provides a security parameter interaction method, where the method includes:
constructing a first message based on a key protocol, wherein the first message comprises encrypted security parameters;
adding the first message to an expansion field of the HTTP request message to obtain an expansion HTTP request message;
and sending the expanded HTTP request message to enable receiving end equipment to acquire the security parameters.
Optionally, constructing the first message based on the key agreement may include:
obtaining an encryption key and an authentication key based on a key protocol;
encrypting the security parameters by using the encryption key to obtain encrypted security parameters;
and generating a message authentication code by using the authentication key to obtain a first message comprising the encrypted security parameter and the message authentication code.
Optionally, the key protocol is an MIKEY protocol, the first Message is an I _ Message, and the extension field is an Entity-Header.
In order to achieve the above object, an embodiment of the present application further provides a security parameter interaction method, where the method includes:
receiving an expansion HTTP request message;
reading an expansion field of the expansion HTTP request message to obtain a first message;
and acquiring the security parameters included in the first message.
Optionally, the method may further include:
obtaining an encryption key and an authentication key based on a key protocol;
the acquiring the security parameter included in the first message includes:
verifying whether the first message is legal or not by using the authentication key;
and if the first message is legal, decrypting the encrypted security parameter in the first message by using the encryption key to obtain the decrypted security parameter.
Optionally, the method may further include:
constructing a second message based on a key protocol and the first message;
adding the second message to an expansion field of the HTTP response message to obtain an expansion HTTP response message;
and sending the expanded HTTP response message.
Optionally, after reading the extension field of the extension HTTP request packet to obtain the first message, the method may further include:
judging whether to respond to the expanded HTTP request message or not according to the first message;
if so, the step of constructing a second message based on the key protocol and the first message is performed.
In order to achieve the above object, an embodiment of the present application further provides a security parameter interaction apparatus, where the apparatus includes:
a first constructing module, configured to construct a first message based on a key protocol, where the first message includes an encrypted security parameter;
the first adding module is used for adding the first message to an expansion field of the HTTP request message to obtain an expansion HTTP request message;
and the first sending module is used for sending the expanded HTTP request message so that the receiving end equipment can obtain the security parameters.
Optionally, the construction module is specifically configured to:
obtaining an encryption key and an authentication key based on a key protocol; encrypting the security parameters by using the encryption key to obtain encrypted security parameters; and generating a message authentication code by using the authentication key to obtain a first message comprising the encrypted security parameter and the message authentication code.
Optionally, the key protocol is an MIKEY protocol, the first Message is an I _ Message, and the extension field is an Entity-Header.
In order to achieve the above object, an embodiment of the present application further provides a security parameter interaction apparatus, where the apparatus includes:
the receiving module is used for receiving an expansion HTTP request message;
the reading module is used for reading the expansion field of the expansion HTTP request message to obtain a first message;
and the acquisition module is used for acquiring the security parameters included in the first message.
Optionally, the apparatus further comprises:
the obtaining module is used for obtaining an encryption key and an authentication key based on a key protocol;
the acquisition module is specifically configured to: verifying whether the first message is legal or not by using the authentication key; and if the first message is legal, decrypting the encrypted security parameter in the first message by using the encryption key to obtain the decrypted security parameter.
Optionally, the apparatus further comprises:
a second constructing module for constructing a second message based on a key protocol and the first message;
the second adding module is used for adding the second message to an expansion field of the HTTP response message to obtain an expansion HTTP response message;
and the second sending module is used for sending the expanded HTTP response message.
Optionally, the apparatus further comprises:
the judging module is used for judging whether to respond to the expanded HTTP request message or not according to the first message; if so, triggering the second construction module.
In order to achieve the above object, an embodiment of the present application further provides an electronic device, including: a processor and a memory;
a memory for storing a computer program;
and the processor is used for realizing any one of the above safety parameter interaction methods when executing the program stored in the memory.
In order to achieve the above object, an embodiment of the present application further provides a security parameter interaction system, including: a first device and a second device, wherein,
the first device is configured to construct a first message based on a key protocol, where the first message includes encrypted security parameters; adding the first message to an expansion field of the HTTP request message to obtain an expansion HTTP request message; sending the expanded HTTP request message to the second device;
the second device is used for receiving the expansion HTTP request message; reading an expansion field of the expansion HTTP request message to obtain a first message; and acquiring the security parameters included in the first message.
When the embodiment of the application is applied to the security parameter interaction, the equipment executing the scheme constructs a first message based on a key protocol, wherein the first message comprises encrypted security parameters; adding the first message to an expansion field of the HTTP request message to obtain an expansion HTTP request message; sending an expansion HTTP request message; therefore, according to the scheme, the HTTP message is expanded, the security parameters are added to the expansion field of the HTTP request message, and the compatibility of the HTTP and the key protocol is realized.
Of course, not all advantages described above need to be achieved at the same time in the practice of any one product or method of the present application.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
Fig. 1 is a schematic flowchart of a security parameter interaction method applied to a first device according to an embodiment of the present disclosure;
fig. 2 is a schematic flowchart of a security parameter interaction method applied to a second device according to an embodiment of the present disclosure;
fig. 3 is a schematic diagram of signaling interaction provided in an embodiment of the present application;
fig. 4 is a schematic structural diagram of a security parameter interaction apparatus applied to a first device according to an embodiment of the present disclosure;
fig. 5 is a schematic structural diagram of a security parameter interaction apparatus applied to a second device according to an embodiment of the present disclosure;
fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure;
fig. 7 is a schematic structural diagram of a security parameter interaction system according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
In order to solve the foregoing technical problem, embodiments of the present application provide a security parameter interaction method and apparatus applied to a first device, a security parameter interaction method and apparatus applied to a second device, and a security parameter interaction device and system. The first device may be a client device, such as a mobile phone, a personal computer, and the like, without limitation, and the second device may be a server device, without limitation.
First, a security parameter interaction method applied to a first device according to an embodiment of the present application is described in detail below. Fig. 1 is a schematic flowchart of a security parameter interaction method applied to a first device according to an embodiment of the present application, including:
s101: constructing a first message based on a key protocol, wherein the first message comprises encrypted security parameters.
For example, the Key Protocol may be MIKEY (Multimedia Internet KEYing, a Multimedia network Key Protocol, a standard Protocol for negotiating security parameters), or may also be PKM (Privacy Key management Protocol), or may also be IKE (Internet Key Exchange Protocol), etc., which are not listed, and the following description will take MIKEY as an example.
The MIKEY Message constructed based on the MIKEY protocol is the MIKEY Message, and for the purpose of description differentiation, the MIKEY Message constructed by the initiating terminal is referred to as I _ Message, and the MIKEY Message constructed by the feedback terminal is referred to as R _ Message.
The first Message is an I _ Message, and the I _ Message includes the encrypted security parameters. The Security parameter may be understood as SA (Security Association, Security parameter set), which includes TEK (Terminal encryption Key) and other parameters. Alternatively, the TEK may be replaced with a TGK (TEK Generation Key), and the security parameter is exemplified as the TEK in the following.
Still in the MIKEY protocol, the MIKEY protocol may include various modes such as a PSK (pre-shared key) mode, a PK (Public key) mode, a DH (Diffie-Hellman key exchange) mode, and the like. For example, in PSK mode, the format of I _ Message may be: i _ Message ═ HDR, T, RAND, IDi, IDr, SP, KEMAC; wherein the explanation of each parameter is as follows:
HDR: common header Payload, universal header load; carries some generic attributes of MIKEY messages.
T: timestamp Payload, Timestamp Payload; time information is carried.
RAND: RAND Payload, random number Payload; carrying random number information.
IDi/IDr: ID Payload, identity Payload; carrying identity information, such as an ID, of the initiator/feedbacker.
SP: security Policy Payload, Security Policy load; and carrying security policy information required to be negotiated.
KEMAC: key data Transport Payload, key information transfer load; carrying key information to be negotiated. The payload is composed of an encr _ key (encryption key) encrypting the TGK and attaching a MAC.
TGK: TEK Generation Key, TEK generates a Key; the key used to generate the TEK. Alternatively, TGK may be replaced with TEK.
MAC: message Authentication Code.
Prior to S101, the digital certificates of the first device and the second device may be distributed to the first device and the second device by a CA (trusted Authority); that is to say, the first device obtains the digital certificate of itself and also obtains the digital certificate of the second device; similarly, the second device obtains the digital certificate of the second device as well as the digital certificate of the first device.
The digital certificate includes information such as a public key and an ID, and the first device may construct an I _ Message based on the digital certificate.
As an embodiment, constructing the first message based on the key agreement may include:
obtaining an encryption key and an authentication key based on a key protocol;
encrypting the encryption parameters by using the encryption key to obtain encrypted security parameters;
and generating a message authentication code by using the authentication key to obtain a first message comprising the encrypted security parameter and the message authentication code.
As described above, the MIKEY protocol may include a plurality of modes, such as PSK mode, DH mode, PK mode, and the like. For example, in the PSK mode, the first device and the second device agree in advance to share a secret key s, and then an encryption key (encr _ key) and an authentication key (auth _ key) are calculated according to s and related parameters in the HDR; under a DH mode, the first device and the second device obtain an encryption key (encr _ key) and an authentication key (auth _ key) through interaction; in the PK mode, the encryption key (encr _ key) and the authentication key (auth _ key) are obtained using the encapsulation key eny _ key.
Then, the TEK (or other security parameters) is encrypted by using the encryption key (encr _ key) to obtain an encrypted TEK (or other security parameters); and calculating the whole first message by using the authentication key (auth _ key) to obtain the MAC.
S102: and adding the first message to an expansion field of the HTTP request message to obtain an expansion HTTP request message.
In this embodiment, the HTTP request message is expanded, the Entity-Header is allowed to be expanded and defined in the HTTP standard, the expansion field is the Entity-Header, and the specific format of the Entity-Header may be:
Key-Mgmt＝“Key-Mgmt”：key-mgmt
key-mgmt：mikey，ACBBBBBBBB……
wherein, after key-mgmt is a character ": "
": followed by a key management protocol type
After the key management protocol type is a character ",
"," is followed by a Security protocol message, MIKEY's message is in Base64 encoded format.
The Entity-Header of the extended definition in this embodiment may be added to the HTTP Request message (Request) or the HTTP Response message (Response). For the purpose of description differentiation, the HTTP request message to which the extension field is added is referred to as an extension HTTP request message, and the HTTP response message to which the extension field is added is referred to as an extension HTTP response message.
In this embodiment, in addition to the MIKEY protocol, security parameters generated based on other key protocols may be added to the extension field of the HTTP request/response packet, which is not specifically limited.
S103: and sending an expanded HTTP request message to enable the receiving terminal equipment to obtain the security parameters.
The receiving end device is the second device. And sending the expansion HTTP request message obtained in the S102 to the second equipment. The second equipment reads an expansion field of the expansion HTTP request message to obtain a first message; and acquiring the security parameters included in the first message. The specific execution flow of the second device is described in detail in the embodiment of fig. 2.
When the embodiment shown in fig. 1 of the present application is applied to perform security parameter interaction, a first device constructs a first message based on a key protocol, where the first message includes encrypted security parameters; adding the first message to an expansion field of the HTTP request message to obtain an expansion HTTP request message; sending an expansion HTTP request message; therefore, according to the scheme, the HTTP message is expanded, the security parameters are added to the expansion field of the HTTP request message, and the compatibility of the HTTP and the key protocol is realized.
Fig. 2 is a first flowchart of a security parameter interaction method applied to a second device according to an embodiment of the present application, where the method includes:
s201: and receiving an expansion HTTP request message.
The first device and the second device communicate based on an HTTP protocol, the expansion HTTP request message is expanded on the basis of the HTTP request message, and the expansion field comprises a first message.
S202: reading an expansion field of the expansion HTTP request message to obtain a first message.
Still taking the MIKEY protocol as an example, the first Message is I _ Message.
S203: and acquiring the security parameters included in the first message.
Specifically, the second device may obtain an encryption key and an authentication key based on a key protocol; thus, S203 may include: verifying whether the first message is legal or not by using the authentication key; and if the first message is legal, decrypting the encrypted security parameter in the first message by using the encryption key to obtain the decrypted security parameter.
Still in the MIKEY protocol, the MIKEY protocol may include various modes such as PSK (pre-shared key), PK (Public key), DH (Diffie-Hellman key exchange), and the like. For example, in the PSK mode, the first device and the second device agree in advance to share a secret key s, and then an encryption key (encr _ key) and an authentication key (auth _ key) are calculated according to s and related parameters in the HDR; under a DH mode, the first device and the second device obtain an encryption key (encr _ key) and an authentication key (auth _ key) through interaction; in the PK mode, the encryption key (encr _ key) and the authentication key (auth _ key) are obtained using the encapsulation key eny _ key.
According to the description in the embodiment of fig. 1: the first device encrypts the TEK (or other security parameters) by using the encryption key (encr _ key) to obtain an encrypted TEK; and calculating the whole first message by using the authentication key (auth _ key) to obtain the MAC.
Correspondingly, the second device firstly uses the authentication key (auth _ key) to calculate the whole first message to obtain the MAC, judges whether the obtained MAC is the same as the MAC in the first message, and if so, indicates that the first message is legal; and then, the encrypted TEK (or other security parameters) is decrypted by using the encryption key (encr _ key) to obtain the decrypted TEK (or other security parameters).
In addition, the second device may also verify whether the IDi included in the I _ Message is legitimate, that is, verify whether the identity of the first device is legitimate.
As an embodiment, the second device may further construct a second message based on a key protocol and the first message; adding the second message to an expansion field of the HTTP response message to obtain an expansion HTTP response message; and sending the expanded HTTP response message.
Still taking the MIKEY protocol as an example, the second Message is the R _ Message. Specifically, the format of the R _ Message may be: r _ Message ═ HDR, T, RAND, IDr, V; wherein the explanation of each parameter is as follows:
HDR: common header Payload, universal header load; carries some generic attributes of MIKEY messages.
T: timestamp Payload, Timestamp Payload; time information is carried.
IDr: carrying identity information of the feedbacker, such as an ID.
V: ver Message Payload, Message verification Payload. The sending end verifies the feedback end message through the load.
Before S201, the digital certificates of the first device and the second device may be distributed to the first device and the second device by a CA (trusted Authority); that is to say, the first device obtains the digital certificate of itself and also obtains the digital certificate of the second device; similarly, the second device obtains the digital certificate of the second device as well as the digital certificate of the first device.
The digital certificate includes information such as a public key and an ID, and the second device may construct an R _ Message based on the digital certificate and the I _ Message. For example, T in R _ Message is the same as T in I _ Message.
In this embodiment, the HTTP response packet is expanded, the Entity-Header is allowed to be expanded and defined in the HTTP standard, the expansion field is the Entity-Header, and the specific format of the Entity-Header may be:
Key-Mgmt＝“Key-Mgmt”：key-mgmt
key-mgmt：mikey，ACBBBBBBBB……
wherein, after key-mgmt is a character ": "
": followed by a key management protocol type
After the key management protocol type is a character ",
"," is followed by a Security protocol message, MIKEY's message is in Base64 encoded format.
The Entity-Header of the extended definition in this embodiment may be added to the HTTP Request message (Request) or the HTTP Response message (Response). For the purpose of description differentiation, the HTTP request message to which the extension field is added is referred to as an extension HTTP request message, and the HTTP response message to which the extension field is added is referred to as an extension HTTP response message.
And the second equipment sends the extended HTTP response message to the first equipment, wherein the extended HTTP response message can be used for mutual authentication between the first equipment and the second equipment.
Alternatively, in other cases, the I _ Message of the first device may not be fed back. In one embodiment, after reading the expansion field of the expansion HTTP request message and obtaining the first message, the second device may further determine whether to respond to the expansion HTTP request message according to the first message; if yes, then executing the steps of constructing a second message based on the key protocol and the first message.
For example, the HDR field in the I _ Message may include information about whether feedback on the I _ Message is needed. For example, the second device may determine whether it is necessary to construct an R _ Message for the I _ Message according to V in the HDR field of the I _ Message: when V in the HDR field is 0, it indicates that feedback is not required, and when V is 1, it indicates that feedback is required.
After the first device and the second device interact to obtain the security parameters, communication can be performed based on the security parameters, and the subsequent communication process is not limited.
In an implementation manner, the embodiment of the present application may be executed once every preset time period to obtain new security parameters interactively. In other words, the security parameters may be updated at intervals to improve communication security. The specific update mechanism is not limited.
Referring now to fig. 3, a manner of interaction between a first device and a second device is described:
firstly, a client initiates a GET request to a server based on an HTTP protocol, that is, the client sends an HTTP request message to the server. The HTTP request message is an expanded HTTP request message, wherein an expanded field Entity-Header is added, and the specific format of the Entity-Header can be as follows:
Key-Mgmt＝“Key-Mgmt”：key-mgmt
key-mgmt：mikey，ACBBBBBBBB……
wherein, after key-mgmt is a character ": "
": followed by a key management protocol type
After the key management protocol type is a character ",
"," is followed by a Security protocol message, MIKEY's message is in Base64 encoded format.
The extension field carries the MIKEY message constructed by the client. The MIKEY Message constructed based on the MIKEY protocol is the MIKEY Message, and for the purpose of description differentiation, the MIKEY Message constructed by the initiating terminal is referred to as I _ Message, and the MIKEY Message constructed by the feedback terminal is referred to as R _ Message.
The I _ Message includes the encrypted security parameters. The security parameter may be understood as SA (security association, security parameter set), which includes TEK (Terminal encryption Key) and other parameters. The following description will be given by taking the security parameter as TEK.
Specifically, the format of the I _ Message may be: i _ Message ═ HDR, T, RAND, IDi, IDr, SP, KEMAC; wherein the explanation of each parameter is as follows:
HDR: common header Payload, universal header load; carries some generic attributes of MIKEY messages.
T: timestamp Payload, Timestamp Payload; time information is carried.
RAND: RAND Payload, random number Payload; carrying random number information.
IDi/IDr: ID Payload, identity Payload; carrying identity information, such as an ID, of the initiator/feedbacker.
SP: security Policy Payload, Security Policy load; and carrying security policy information required to be negotiated.
KEMAC: key data Transport Payload, key information transfer load; carrying key information to be negotiated. The payload is composed of an encr _ key (encryption key) encrypting the TGK and attaching a MAC.
TGK: TEK Generation Key, TEK generates a Key; the key used to generate the TEK. Alternatively, TGK may be replaced with TEK.
MAC: message Authentication Code.
Before the client and the server perform security parameter interaction, the digital certificates of the client and the server may be distributed to the client and the server by a CA (trusted Authority); that is, the client obtains the digital certificate of the client and the digital certificate of the server; similarly, the server obtains the digital certificate of the server and the digital certificate of the client.
The digital certificate includes information such as a public key and an ID, and the client may construct an I _ Message based on the digital certificate.
And secondly, the server receives the GET request based on an HTTP protocol, and reads the I _ Message in the GET request to obtain the security parameters in the I _ Message.
The MIKEY protocol may include various modes such as PSK (pre-shared key), PK (public key), DH (Diffie-Hellman key exchange), and the like. For example, in the PSK mode, the client and the server agree with a shared key s in advance, and then an encryption key (encr _ key) and an authentication key (auth _ key) are calculated according to s and related parameters in the HDR; under a DH mode, a client and a server obtain an encryption key (encr _ key) and an authentication key (auth _ key) through interaction; in the PK mode, the encryption key (encr _ key) and the authentication key (auth _ key) are obtained using the encapsulation key eny _ key.
When the client constructs the I _ Message, encrypting the TEK (or further comprising other security parameters) by using an encryption key (encr _ key) to obtain the encrypted TEK (or further comprising other security parameters); the entire I _ Message is calculated using the authentication key (auth _ key), and the MAC is obtained. Correspondingly, when the server analyzes the I _ Message, the server firstly utilizes the authentication key (auth _ key) to calculate the whole I _ Message to obtain the MAC, judges whether the obtained MAC is the same as the MAC in the I _ Message, and if so, indicates that the I _ Message is legal; and then, the encrypted TEK (or other security parameters) is decrypted by using the encryption key (encr _ key) to obtain the decrypted TEK (or other security parameters).
In addition, the server may also verify whether the IDi included in the I _ Message is legal, that is, verify whether the identity of the client is legal, and perform the subsequent steps if the identity is legal.
Thirdly, the server judges whether R _ Message needs to be constructed for the I _ Message according to V in the HDR field in the I _ Message. If necessary, the server constructs an R _ Message, and specifically, the format of the R _ Message may be: r _ Message ═ HDR, T, RAND, IDr, V; wherein the explanation of each parameter is as follows:
HDR: common header Payload, universal header load; carries some generic attributes of MIKEY messages.
T: timestamp Payload, Timestamp Payload; time information is carried.
IDr: carrying identity information of the feedbacker, such as an ID.
V: ver Message Payload, Message verification Payload. The sending end verifies the feedback end message through the load.
As described above, a CA (trusted Authority) distributes digital certificates of clients and servers to the clients and servers; that is, the client obtains the digital certificate of the client and the digital certificate of the server; similarly, the server obtains the digital certificate of the server and the digital certificate of the client.
The digital certificate includes information such as a public key and an ID, and the server may construct an R _ Message based on the digital certificate and the I _ Message. For example, T in R _ Message is the same as T in I _ Message.
Fourthly, the server sends 200OK response information, namely HTTP response information to the client, wherein the HTTP response information is expanded HTTP response information, an expansion field Entity-Header is added, and MIKEY information constructed by the server is loaded in the expansion field, namely R _ Message.
The specific format of Entity-Header may be:
Key-Mgmt＝“Key-Mgmt”：key-mgmt
key-mgmt：mikey，ACBBBBBBBB……
wherein, after key-mgmt is a character ": "
": followed by a key management protocol type
After the key management protocol type is a character ",
"," is followed by a Security protocol message, MIKEY's message is in Base64 encoded format.
After the client interacts with the server for the security parameters, communication can be performed based on the security parameters, that is, Data (Data) interaction in fig. 3.
In the embodiment of fig. 3, in a first aspect, the client and the server implement the interaction of the security parameters through one request/response interaction. If the server determines that the R _ Message does not need to be constructed for the I _ Message according to V in the HDR field in the I _ Message, only one request is passed, and security parameter interaction between the client and the server is realized. Therefore, the interaction mechanism provided by the embodiment has high efficiency and low resource consumption.
In the second aspect, the client and the server communicate based on the security parameters, for example, the security parameters can be applied in the HTTP communication process, so as to provide security for the HTTP communication.
In the third aspect, in the present embodiment, an MIKEY message is carried in an HTTP message, so that compatibility between an HTTP protocol and an MIKEY protocol is achieved.
In the fourth aspect, in the present embodiment, the security parameters can be updated at regular intervals, thereby further improving the security performance.
The embodiment of the present application further provides a security parameter interaction apparatus applied to a first device, where the first device may be a client device, such as a mobile phone, a personal computer, and the like, and is not limited specifically. As shown in fig. 4, the apparatus includes:
a first constructing module 401, configured to construct a first message based on a key protocol, where the first message includes an encrypted security parameter;
a first adding module 402, configured to add the first message to an expansion field of an HTTP request message, so as to obtain an expansion HTTP request message;
a first sending module 403, configured to send the extended HTTP request packet, so that the receiving end device obtains the security parameter.
As an embodiment, the first configuration module 401 may be specifically configured to:
obtaining an encryption key and an authentication key based on a key protocol; encrypting the security parameters by using the encryption key to obtain encrypted security parameters; and generating a message authentication code by using the authentication key to obtain a first message comprising the encrypted security parameter and the message authentication code.
As an embodiment, the key protocol is MIKEY protocol, the first Message is I _ Message, and the extension field is Entity-Header.
When the embodiment of the application is applied to the security parameter interaction, the equipment executing the scheme constructs a first message based on a key protocol, wherein the first message comprises encrypted security parameters; adding the first message to an expansion field of the HTTP request message to obtain an expansion HTTP request message; sending an expansion HTTP request message; therefore, according to the scheme, the HTTP message is expanded, the security parameters are added to the expansion field of the HTTP request message, and the compatibility of the HTTP and the key protocol is realized.
The embodiment of the present application further provides a security parameter interaction apparatus applied to a second device, where the second device may be a server device, and is not limited specifically. As shown in fig. 5, the apparatus includes:
a receiving module 501, configured to receive an expansion HTTP request message;
a reading module 502, configured to read an expansion field of the expansion HTTP request packet to obtain a first message;
an obtaining module 503, configured to obtain the security parameter included in the first message.
As an embodiment, the apparatus may further include:
an obtaining module (not shown in the figure) for obtaining an encryption key and an authentication key based on a key protocol;
the obtaining module 503 may be specifically configured to: verifying whether the first message is legal or not by using the authentication key; and if the first message is legal, decrypting the encrypted security parameter in the first message by using the encryption key to obtain the decrypted security parameter.
As an embodiment, the apparatus may further include: a second construction module, a second adding module and a second sending module (not shown in the figure), wherein,
a second constructing module for constructing a second message based on a key protocol and the first message;
the second adding module is used for adding the second message to an expansion field of the HTTP response message to obtain an expansion HTTP response message;
and the second sending module is used for sending the expanded HTTP response message.
As an embodiment, the apparatus may further include:
a judging module (not shown in the figure) configured to judge whether to respond to the extended HTTP request packet according to the first message; if so, triggering the second construction module.
An embodiment of the present application further provides an electronic device, as shown in fig. 6, including: a processor 601 and a memory 602;
a memory 602 for storing a computer program;
the processor 601 is configured to implement any one of the above-described security parameter interaction methods when executing the program stored in the memory 602.
The electronic device in this embodiment may be the first device or the second device.
The Memory mentioned in the above electronic device may include a Random Access Memory (RAM) or a Non-Volatile Memory (NVM), such as at least one disk Memory. Optionally, the memory may also be at least one memory device located remotely from the processor.
The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic device, discrete hardware component.
An embodiment of the present application further provides a security parameter interaction system, as shown in fig. 7, including: a first device and a second device, wherein,
the first device is configured to construct a first message based on a key protocol, where the first message includes encrypted security parameters; adding the first message to an expansion field of the HTTP request message to obtain an expansion HTTP request message; sending the expanded HTTP request message to the second device;
the second device is used for receiving the expansion HTTP request message; reading an expansion field of the expansion HTTP request message to obtain a first message; and acquiring the security parameters included in the first message.
The first device may be a client device, such as a mobile phone, a personal computer, and the like, without limitation, and the second device may be a server device, without limitation.
It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, apparatus embodiments, device embodiments, and system embodiments are substantially similar to method embodiments and therefore are described with relative ease, where reference may be had to some descriptions of method embodiments.
The above description is only for the preferred embodiment of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application are included in the protection scope of the present application.

Claims (15)

1. A method for security parameter interaction, the method comprising:
constructing a first message based on a key protocol, wherein the first message comprises encrypted security parameters;
adding the first message to an expansion field of the HTTP request message to obtain an expansion HTTP request message;
and sending the expanded HTTP request message to enable receiving end equipment to acquire the security parameters.
2. The method of claim 1, wherein constructing the first message based on the key agreement comprises:
obtaining an encryption key and an authentication key based on a key protocol;
encrypting the security parameters by using the encryption key to obtain encrypted security parameters;
and generating a message authentication code by using the authentication key to obtain a first message comprising the encrypted security parameter and the message authentication code.
3. The method of claim 1, wherein the key protocol is a MIKEY protocol, the first Message is an I _ Message, and the extension field is an Entity-Header.
4. A method for security parameter interaction, the method comprising:
receiving an expansion HTTP request message;
reading an expansion field of the expansion HTTP request message to obtain a first message;
and acquiring the security parameters included in the first message.
5. The method of claim 4, further comprising:
obtaining an encryption key and an authentication key based on a key protocol;
the acquiring the security parameter included in the first message includes:
verifying whether the first message is legal or not by using the authentication key;
and if the first message is legal, decrypting the encrypted security parameter in the first message by using the encryption key to obtain the decrypted security parameter.
6. The method of claim 5, further comprising:
constructing a second message based on a key protocol and the first message;
adding the second message to an expansion field of the HTTP response message to obtain an expansion HTTP response message;
and sending the expanded HTTP response message.
7. The method according to claim 6, wherein after reading the extension field of the extension HTTP request packet to obtain the first message, the method further comprises:
judging whether to respond to the expanded HTTP request message or not according to the first message;
if so, the step of constructing a second message based on the key protocol and the first message is performed.
8. A security parameter interaction apparatus, the apparatus comprising:
a first constructing module, configured to construct a first message based on a key protocol, where the first message includes an encrypted security parameter;
the first adding module is used for adding the first message to an expansion field of the HTTP request message to obtain an expansion HTTP request message;
and the first sending module is used for sending the expanded HTTP request message so that the receiving end equipment can obtain the security parameters.
9. The device according to claim 8, characterized in that said construction module is particularly adapted to:
obtaining an encryption key and an authentication key based on a key protocol; encrypting the security parameters by using the encryption key to obtain encrypted security parameters; and generating a message authentication code by using the authentication key to obtain a first message comprising the encrypted security parameter and the message authentication code.
10. The apparatus of claim 8, wherein the key protocol is a key protocol, the first Message is an I _ Message, and the extension field is an Entity-Header.
11. A security parameter interaction apparatus, the apparatus comprising:
the receiving module is used for receiving an expansion HTTP request message;
the reading module is used for reading the expansion field of the expansion HTTP request message to obtain a first message;
and the acquisition module is used for acquiring the security parameters included in the first message.
12. The apparatus of claim 11, further comprising:
the obtaining module is used for obtaining an encryption key and an authentication key based on a key protocol;
the acquisition module is specifically configured to: verifying whether the first message is legal or not by using the authentication key; and if the first message is legal, decrypting the encrypted security parameter in the first message by using the encryption key to obtain the decrypted security parameter.
13. The apparatus of claim 12, further comprising:
a second constructing module for constructing a second message based on a key protocol and the first message;
the second adding module is used for adding the second message to an expansion field of the HTTP response message to obtain an expansion HTTP response message;
and the second sending module is used for sending the expanded HTTP response message.
14. The apparatus of claim 13, further comprising:
the judging module is used for judging whether to respond to the expanded HTTP request message or not according to the first message; if so, triggering the second construction module.
15. A security parameter interaction system, comprising: a first device and a second device, wherein,
the first device is configured to construct a first message based on a key protocol, where the first message includes encrypted security parameters; adding the first message to an expansion field of the HTTP request message to obtain an expansion HTTP request message; sending the expanded HTTP request message to the second device;
the second device is used for receiving the expansion HTTP request message; reading an expansion field of the expansion HTTP request message to obtain a first message; and acquiring the security parameters included in the first message.
CN201810875609.1A 2018-08-03 2018-08-03 Security parameter interaction method, device, equipment and system Pending CN110798431A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810875609.1A CN110798431A (en) 2018-08-03 2018-08-03 Security parameter interaction method, device, equipment and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810875609.1A CN110798431A (en) 2018-08-03 2018-08-03 Security parameter interaction method, device, equipment and system

Publications (1)

Publication Number Publication Date
CN110798431A true CN110798431A (en) 2020-02-14

Family

ID=69425370

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810875609.1A Pending CN110798431A (en) 2018-08-03 2018-08-03 Security parameter interaction method, device, equipment and system

Country Status (1)

Country Link
CN (1) CN110798431A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113438071A (en) * 2021-05-28 2021-09-24 荣耀终端有限公司 Method and device for secure communication

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1859291A (en) * 2005-12-13 2006-11-08 华为技术有限公司 Method for safety packaging network message
CN101156412A (en) * 2005-02-11 2008-04-02 诺基亚公司 Method and apparatus for providing a bootstrap procedure in a communication network
CN101478755A (en) * 2009-01-21 2009-07-08 中兴通讯股份有限公司 Network security HTTP negotiation method and related apparatus
US20110138458A1 (en) * 2009-12-04 2011-06-09 Cisco Technology, Inc. Establishing Internet Protocol Security Sessions Using the Extensible Messaging and Presence Protocol
US8503681B1 (en) * 2005-11-04 2013-08-06 Cisco Technology, Inc. Method and system to securely transport data encryption keys
CN105519028A (en) * 2015-07-01 2016-04-20 海能达通信股份有限公司 A wireless system access control method and device
CN107251476A (en) * 2015-02-13 2017-10-13 维萨国际服务协会 Secret communication is managed

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101156412A (en) * 2005-02-11 2008-04-02 诺基亚公司 Method and apparatus for providing a bootstrap procedure in a communication network
US8503681B1 (en) * 2005-11-04 2013-08-06 Cisco Technology, Inc. Method and system to securely transport data encryption keys
CN1859291A (en) * 2005-12-13 2006-11-08 华为技术有限公司 Method for safety packaging network message
CN101478755A (en) * 2009-01-21 2009-07-08 中兴通讯股份有限公司 Network security HTTP negotiation method and related apparatus
US20110138458A1 (en) * 2009-12-04 2011-06-09 Cisco Technology, Inc. Establishing Internet Protocol Security Sessions Using the Extensible Messaging and Presence Protocol
CN107251476A (en) * 2015-02-13 2017-10-13 维萨国际服务协会 Secret communication is managed
CN105519028A (en) * 2015-07-01 2016-04-20 海能达通信股份有限公司 A wireless system access control method and device

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KARL NORRMAN等: "《RFC3830, IETF, https://datatracker.ietf.org/doc/rfc3830》", 31 August 2004 *
李昕 等: "MIKEY协议在实时流传输中密钥协商模式的研究", 《计算机应用与软件》 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113438071A (en) * 2021-05-28 2021-09-24 荣耀终端有限公司 Method and device for secure communication
CN113438071B (en) * 2021-05-28 2024-04-09 荣耀终端有限公司 Method and device for secure communication

Similar Documents

Publication Publication Date Title
CN113438071B (en) Method and device for secure communication
CN108886468B (en) System and method for distributing identity-based key material and certificates
CN104753917B (en) Key management system and method based on ID
CN111030814B (en) Secret key negotiation method and device
WO2017045552A1 (en) Method and device for loading digital certificate in ssl or tls communication
US20140298037A1 (en) Method, apparatus, and system for securely transmitting data
EP2173055A1 (en) A method, a system, a client and a server for key negotiating
JP2019531630A (en) Method and system for data security based on quantum communication and trusted computing
WO2010078755A1 (en) Method and system for transmitting electronic mail, wlan authentication and privacy infrastructure (wapi) terminal thereof
CN110493272B (en) Communication method and communication system using multiple keys
CN114143117B (en) Data processing method and device
CN112637136A (en) Encrypted communication method and system
CN113497778A (en) Data transmission method and device
Bali et al. Lightweight authentication for MQTT to improve the security of IoT communication
Claeys et al. Securing complex IoT platforms with token based access control and authenticated key establishment
KR101765081B1 (en) A secure attribute-based authentication method for cloud computing
JP2016514913A (en) Method and apparatus for establishing a session key
CN115766119A (en) Communication method, communication apparatus, communication system, and storage medium
CN110611679A (en) Data transmission method, device, equipment and system
CN104243452A (en) Method and system for cloud computing access control
CN115766066A (en) Data transmission method, device, secure communication system and storage medium
CN117155564A (en) Bidirectional encryption authentication system and method
CN111756528A (en) Quantum session key distribution method and device and communication architecture
CN119766433A (en) A method, device and system for encrypted communication supporting post-quantum algorithm
CN107104888B (en) A Secure Instant Messaging Method

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
RJ01 Rejection of invention patent application after publication

Application publication date: 20200214

RJ01 Rejection of invention patent application after publication