WO2016066039A1 - 一种网络安全通信方法及通信装置 - Google Patents

一种网络安全通信方法及通信装置 Download PDF

Info

Publication number
WO2016066039A1
WO2016066039A1 PCT/CN2015/092506 CN2015092506W WO2016066039A1 WO 2016066039 A1 WO2016066039 A1 WO 2016066039A1 CN 2015092506 W CN2015092506 W CN 2015092506W WO 2016066039 A1 WO2016066039 A1 WO 2016066039A1
Authority
WO
WIPO (PCT)
Prior art keywords
service request
service
random number
data
plaintext
Prior art date
Application number
PCT/CN2015/092506
Other languages
English (en)
French (fr)
Inventor
陈虓将
Original Assignee
阿里巴巴集团控股有限公司
陈虓将
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 阿里巴巴集团控股有限公司, 陈虓将 filed Critical 阿里巴巴集团控股有限公司
Priority to JP2017521578A priority Critical patent/JP6641363B2/ja
Priority to EP15854125.0A priority patent/EP3214796B1/en
Publication of WO2016066039A1 publication Critical patent/WO2016066039A1/zh
Priority to US15/499,860 priority patent/US10419409B2/en

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/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/0442—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 asymmetric encryption, i.e. different keys 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a network security communication method and a communication device.
  • HTTPS HyperText Transfer Protocol
  • the process of communication between the client and the server includes a handshake phase.
  • the client and the server negotiate the key first.
  • the server needs to provide the client with a certificate issued by the authority to prove that the client receives the certificate.
  • the response comes from a legitimate server.
  • the client verifies that the certificate requires intensive CPU calculation, and the resulting power pair Mobile terminals are a challenge.
  • the purpose of the embodiment of the present application is to provide a network security communication method and a communication device, which can send a service request and a response in a process of negotiating a key between a client and a server, thereby reducing the number of times of information interaction.
  • an embodiment of the present application provides a network security communication method, including:
  • the handshake request packet carries a first random number encrypted by using the first public key and service request data encrypted by using the first public key, so that the server is configured according to the The first private key corresponding to the first public key decrypts the handshake request packet to obtain a first random number and first service request data, and generates first service response data according to the first service request data;
  • the server And receiving, by the server, a handshake response message, where the handshake response message carries the first service response data encrypted by using the first random number and the second random number encrypted by using the first random number;
  • a session key used for a session with the server is calculated by the first random number and the second random number.
  • the ciphertext service request message carries the identifier of the session key and the second service request data encrypted by using the session key, so that the server is dense according to the session.
  • the identifier of the key is used to search for the corresponding session key, and the ciphertext service request message is decrypted by using the found session key to obtain the second service request data.
  • the method further includes:
  • the plaintext service response message carries the third service response data of the plaintext
  • the third service response data is generated by the server according to the third service request data.
  • the method further includes:
  • Another aspect of the present application also provides a network security communication method, including:
  • a handshake response message carries a first service response data encrypted by using a first random number and a second random number encrypted by using the first random number, so that the The client decrypts the handshake response message by using the first random number, obtains service response data and a second random number, and calculates a session using the first random number and the second random number based on the first key algorithm.
  • Session key carries a first service response data encrypted by using a first random number and a second random number encrypted by using the first random number
  • the session key used by the session is calculated using the first key algorithm according to the first random number and the second random number.
  • the method further includes:
  • the method further includes:
  • the method further includes:
  • the service request message is a ciphertext service request message or a judgment result of the plaintext service request message generates an encrypted identifier
  • the identifier of the service request packet is compared with the first mapping relationship, and the corresponding encrypted identifier is searched for;
  • the encrypted identifier indicates that the service request packet is a ciphertext service request packet, triggering a step of sending a ciphertext service response message to the client;
  • the step of sending a plaintext service response message to the client is triggered.
  • Another aspect of the present application also provides a network security communication device, including:
  • a handshake request sending unit configured to send, to the server, a handshake request packet, where the handshake request packet carries a first random number encrypted by using the first public key and a service encrypted by using the first public key Requesting data, so that the server decrypts the handshake request message according to the first private key corresponding to the first public key to obtain a first random number and first service request data, and according to the first service request
  • the data generates first business response data
  • a handshake response receiving unit configured to receive a handshake response message fed back by the server, where the handshake response message carries the first service response data encrypted by using the first random number and the first encrypted by using the first random number Two random numbers;
  • a handshake response decryption unit configured to decrypt the handshake response message by using the first random number, to obtain first service response data and a second random number;
  • the session key calculation unit is configured to calculate a session key used by the session between the server and the server by using the first random number and the second random number.
  • the apparatus further includes:
  • a ciphertext service request sending unit configured to send a ciphertext service request message to the server, where the ciphertext service request message carries the identifier of the session key and a second service request encrypted by using the session key Data to make the server And searching for the corresponding session key according to the identifier of the session key, and decrypting the ciphertext service request message by using the found session key to obtain second service request data;
  • the ciphertext service response receiving unit is configured to receive a ciphertext service response message fed back by the server, where the ciphertext service response message carries the second service response data encrypted by using the session key, where the second service is The response data is generated by the server according to the second service request data.
  • the apparatus further includes:
  • the plaintext service request sending unit is configured to send a plaintext service request message to the server, where the plaintext service request message carries the third service request data of the plaintext, so that the server sends the message from the plaintext service request message. Obtaining the third service request data of the plaintext;
  • the plaintext service response receiving unit is configured to receive the plaintext service response message fed back by the server, where the plaintext service response message carries the third service response data of the plaintext, where the third service response data is determined by the server The third service request data is generated.
  • a further aspect of the present application provides a network security communication device, including:
  • the handshake request receiving unit is configured to receive a handshake request packet sent by the client, where the handshake request packet carries a first random number encrypted by using the first public key and service request data encrypted by using the first public key;
  • a handshake request decryption unit configured to decrypt the handshake request message by using a first private key corresponding to the first public key, to obtain a first random number and service request data
  • a first service response generating unit configured to generate first service response data according to the first service request data
  • a handshake response sending unit configured to send a handshake response message to the client, where the handshake response message carries first service response data encrypted by using a first random number and second encrypted by using the first random number a random number, so that the client decrypts the handshake response message by using the first random number, obtains service response data and a second random number, and uses the first random number and the second random number based on the first secret
  • the key algorithm calculates the session key used by the session;
  • the session key calculation unit is configured to calculate, according to the first random number and the second random number, the session key used by the session by using the first key algorithm.
  • the apparatus further includes:
  • the ciphertext service request receiving unit is configured to receive the ciphertext service request message sent by the client, where the ciphertext service request message carries the identifier of the session key and the second service encrypted by using the session key Request data;
  • a session key search unit configured to search for a corresponding session key by using the identifier of the session key
  • a service request decryption unit configured to decrypt the ciphertext service request message by using the found session key to obtain second service request data
  • a second service response generating unit configured to generate second service response data according to the second service request data
  • the ciphertext service response sending unit is configured to send a ciphertext service response message to the client, where the ciphertext service response message carries the second service response data encrypted by using the session key.
  • the apparatus further includes:
  • the plaintext service request receiving unit is configured to receive the plaintext service request packet sent by the client, where the plaintext service request packet carries the third service request data of the plaintext;
  • a service request data obtaining unit configured to obtain third service request data from the plaintext service request message
  • a third service response generating unit configured to generate third service response data according to the third service request data
  • the plaintext service response sending unit is configured to send a plaintext service response message to the client, where the plaintext service response message carries the third service response data of the plaintext.
  • the service request data is simultaneously sent in the process of negotiating the session key, and the service response data can be obtained by using the handshake response message in the process of the session key negotiation, thereby saving the subsequent needs.
  • the step of separately transmitting the service request message to the part of the service request data also saves the step of receiving the service response message separately for the corresponding service response data, so the number of message interactions with the server end is reduced relative to the prior art.
  • FIG. 1A is a flowchart of a network security communication method according to an embodiment of the present application.
  • FIG. 1B is a flowchart of a network security communication method according to another embodiment of the present application.
  • FIG. 2 is a schematic diagram of a specific implementation process of a network security communication method in the implementation of the present application
  • FIG. 3 is a schematic diagram of a specific implementation of a handshake request message in the embodiment of the present application.
  • FIG. 4 is a schematic diagram of a specific implementation of a handshake response message in the embodiment of the present application.
  • FIG. 5 is a schematic diagram of a specific implementation of a packet carrying ciphertext service request data
  • FIG. 6 is a schematic diagram of a specific implementation of a service response data packet
  • FIG. 7 is a schematic diagram of a network security communication apparatus according to an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a network security communication device according to another embodiment of the present application.
  • the request and response of the service between the client and the server must be performed after the key is negotiated, which makes the number of message interactions too many and takes too long.
  • the embodiment of the present application provides a network security communication method, as shown in FIG. 1A, the method includes:
  • Step S101A Send a handshake request packet to the server, where the handshake request packet carries a first random number encrypted by using the first public key and service request data encrypted by using the first public key, so that the server is configured according to the server
  • the first private key corresponding to the first public key decrypts the handshake request packet to obtain a first random number and first service request data, and generates first service response data according to the first service request data.
  • Step S102A Receive a handshake response message fed back by the server, where the handshake response message carries the first service response data encrypted by using the first random number and the second random number encrypted by using the first random number.
  • Step S103A Decrypt the handshake response message by using the first random number to obtain first service response data and a second random number.
  • Step S104A Calculate a session key used by the session with the server by using the first random number and the second random number.
  • execution body of the foregoing steps S101 to S104 may be a client.
  • the technical solution in the embodiment shown in FIG. 1A simultaneously sends the service request data in the process of negotiating the session key, and can obtain the service response data by using the handshake response message in the process of the session key negotiation.
  • the step of separately sending a service request message to the part of the service request data is saved, and the step of receiving the service response message for the corresponding service response data is saved, so that the relationship between the server and the server is reduced compared with the prior art.
  • Another embodiment of the present application further provides a network security communication method, as shown in FIG. 1B, the method includes:
  • Step S101B Receive a handshake request packet sent by the client, where the handshake request packet carries a first random number encrypted by using the first public key and service request data encrypted by using the first public key;
  • Step S102 Decrypting the handshake request message by using the first private key corresponding to the first public key, to obtain the first random number and the service request data;
  • Step S103B Generate first service response data according to the first service request data.
  • Step S104B Send a handshake response message to the client, where the handshake response message carries the first service response data encrypted by using the first random number and the second random number encrypted by using the first random number, And causing the client to decrypt the handshake response message by using the first random number, obtaining service response data and a second random number, and calculating, by using the first random number and the second random number, based on the first key algorithm The session key used by the session;
  • Step S105B Calculate the session key used by the session by using the first key algorithm according to the first random number and the second random number.
  • execution body of the above steps may be a server.
  • the service request data is simultaneously received in the process of negotiating the session key with the client, and the service response can be sent through the handshake response message in the process of the session key negotiation.
  • the data saves the subsequent steps of separately receiving the service request message for the part of the service request data, and also saves the step of separately transmitting the service response message for the corresponding service response data, so the user and the client are reduced compared with the prior art.
  • FIG. 2 is a schematic diagram of a specific implementation process of a network security communication method. As shown in FIG. 2, the method includes the following steps:
  • Step S201 The client 201 sends a handshake request packet to the server 202, where the handshake request packet carries a first random number (which can be recorded as nonce1) encrypted by the public key of the asymmetric encryption algorithm and the public key encrypted service. Request data.
  • a first random number which can be recorded as nonce1
  • the public key of the asymmetric encryption algorithm here is a public key widely distributed by the server 202.
  • the device that sends data to the server 202 can use the public key to encrypt the data to be sent, and the server 202 can use the own The private key is decrypted.
  • the handshake request message sent by the client 201 to the server 202 may be in a message format as shown in FIG. 3.
  • Version indicates version and protocol information, for example, if the client 201 and the server 202 perform Above the secure channel of the secure communication is communication based on the http protocol, the Version value is set to 11001B (where B represents the previous number as a binary number), and if it is based on the SPDY protocol, the Version value can be set to 11101B.
  • the type in FIG. 3 represents the type information of the packet.
  • the value of the type in the handshake request packet sent by the client 201 can be set to 0x01, and the value identifies the type of the packet as a handshake request, so that the server 202 When the packet is received, the packet is notified that the packet belongs to the handshake request packet.
  • the length in Figure 3 represents the length of the message.
  • the unit can be the number of network bytes, excluding the first 4 bytes including Version, Type, and Length.
  • the RSA public key (32 bit) in FIG. 3 represents a 32-bit RSA public key, and the RSA public key is the public key of the asymmetric encryption algorithm in step S201.
  • the first random number described above may be a random number calculated by the client 201.
  • Step S202 The server 202 decrypts the received handshake request message according to the private key of the asymmetric algorithm, obtains the first random number and the service request data, and generates service response data according to the service request data.
  • the server 202 also verifies the handshake request message from the client 201. If the verification fails, the connection with the client 201 is directly closed, and the subsequent process is stopped; if the verification is passed, The step of generating business response data based on the service request data is continued.
  • Manner 1 The first bit of the first random number carried in the handshake request message sent by the client 201 to the server 202 is a Magic Code, and if there is a third party tampering report in the process of the client 201 sending to the server 202 In the case of the text, the first bit of the first random number will change. For this reason, the server 202 can verify the handshake request message by checking whether the first bit of the first random number obtained by the decryption is still a Magic Code. Yes, the verification is passed; if not, the verification fails.
  • the Magic Code here is also called the magic number.
  • the magic number technique is to quickly determine the legitimacy of a message by inserting a number of bytes marked as constants at the beginning or the end of the data.
  • the server 202 has a request for the length of the handshake request packet sent by the client 201. If the client 201 performs the amplification attack by the malicious user during the process of sending the handshake request packet to the server 202, the handshake is performed. The length of the request message will be abnormal. For this reason, the server 202 can verify the handshake request packet by checking whether the length of the handshake request packet is abnormal. If the error is abnormal, the verification fails; if not, the verification succeeds.
  • Step S203 The server 202 sends a handshake response message to the client 201, where the handshake response message carries a second random number (which can be recorded as nonce2) encrypted by the first random number as a key and by the first random number.
  • Business response data encrypted as a key.
  • the second random number here may be a random number calculated by the server 202.
  • the handshake response message sent by the server 202 to the client 201 may be in the message format as described in FIG. 4:
  • the Version represents the version and the protocol information. If the secure channel on which the client 201 and the server 202 perform secure communication is based on the HTTP protocol, the Version can be set to 11001B. If the session is based on the spdy protocol, the Version can be Set to 11101B;
  • the type represents the type information of the packet
  • the server 202 sends a handshake response message to the client 201, where the Type value can be set to 0x03, and the value indicates that the type of the packet is a handshake response, so that the client 201 is
  • the packet can be informed that the packet belongs to the handshake response packet.
  • the length in Figure 4 represents the length information of the message.
  • the unit can be the number of network bytes, excluding the first 4 bytes including Version, Type and Length.
  • the ciphertext in Fig. 4 represents the second random number encrypted by the first random number as a key and the service response data encrypted by the first random number as a key.
  • Step S204 The client 201 decrypts the received handshake response message by using the first random number, obtains the second random number and the service response data, and calculates the session by using the first random number and the second random number using a symmetric encryption algorithm.
  • Key Session Key
  • the Session Key can be calculated by the following formula:
  • nonce1 is the first random number and nonce2 is the second random number.
  • the client 201 also decrypts the handshake response message from the server 202 and then verifies the The first bit of the second random number carried in the handshake response message sent by the server 202 to the client 201 is a Magic Code. If the third party tampers with the message during the process sent by the server 202 to the client 201, Appearing, the first bit of the second random number will change. For this reason, the client 201 verifies the handshake response message by checking whether the first bit of the second random number obtained by the decryption is still implemented by Magic Code. If not, Then the verification fails; if yes, the verification passes, and then the calculation of the Session Key is performed.
  • Step S205 The server 202 calculates the Session Key by using the same algorithm as that in Step S204 by using the obtained first random number and the second random number.
  • step S204 and step S205 are interchangeable, and of course, it may be performed simultaneously, as long as the algorithm for calculating the Session Key in step S204 and step S205 is the same.
  • the server 202 and the client 201 obtain the same Session Key.
  • the Session Key is used to encrypt data when the service request message and the service response message are transmitted between the subsequent client 201 and the server 202.
  • the client 201 and the server 202 create a session through the handshake phase.
  • the subsequent service request packet and the service response packet transmission based on the session can be encrypted by using the Session Key obtained by the handshake phase negotiation.
  • the server 202 can be assigned an identifier for the session created as described above, and is recorded as a session ID.
  • the session ID can be carried in the handshake response packet sent by the server 202 to the client 201 as shown in FIG.
  • the handshake response message in FIG. 4 also carries a Session Key validity period.
  • the Session Key can be directly multiplexed even if it is disconnected and disconnected without renegotiation, and degraded when the validity period is zero. For one time, that is, the Session Key is always valid in this connection. Once the connection is disconnected, steps S201 to S205 must be re-executed to renegotiate the Session Key.
  • the duration of the carried session key may be a relative time, for example, the first time length after the time when the server 202 sends the handshake response message to the client 201, and the first time length is The value can be carried as the relative time in the Session Key validity period in Figure 4.
  • the server 202 responds to the message by handshake and delivers the validity period and the session ID of the session key.
  • the session can be sent through a separate packet.
  • the validity period of the Key and the Session ID are given to the client 201.
  • the client 201 and the server 202 perform business data interaction.
  • Step S206 The client 201 sends a service request message to the server 202, where the service request message carries a session ID and service request data encrypted by the Session Key.
  • the packet carrying the ciphertext service request data sent by the client 201 may adopt a format as shown in FIG.
  • the packet carrying the ciphertext service request data sent by the client 201 may adopt a format as shown in FIG.
  • Version represents the version and protocol information. If the security channel for secure communication between the client 201 and the server 202 is based on the http protocol, the Version is set to 11001B, and if the spdy protocol is based, the Version is set to 11101B.
  • the Type represents the type information of the packet, and the Type value of the ciphertext service request sent by the client 201 can be set to 0x02, indicating that the type of the packet is a ciphertext service request;
  • the packet is notified that the packet belongs to the service request packet, and the service request data in the service request packet is encrypted.
  • the client 201 and the server 202 can carry the plaintext data and the ciphertext data in the round-trip between the service request packet and the service response packet in the same session.
  • the service request data carried in the service request packet sent by the client 201 to the server 202 may be in the plain text format, and the type of the packet in the service request packet is passed.
  • the service notification server 202 does not need to carry the decryption operation.
  • the service request packet sent by the client 201 to the server 202 does not need to carry the session ID.
  • Step S207 The server 202 finds the corresponding Session Key and the validity period of the Session Key according to the Session ID in the service request packet, and determines whether the current time exceeds the validity period of the Session Key.
  • the server 202 Since the server 202 has established the correspondence between the session ID and the session key in the negotiation process of the session key, after the server 202 obtains the session ID in the service request packet, the server 202 can find the correct relationship through the corresponding relationship. Session Key.
  • the Session Key is assigned a valid time. Therefore, after the Session Key is found, it is necessary to determine whether the current time exceeds the validity period of the Session Key. In practice, it is also possible to omit the step of assigning a valid time to the Session Key, and accordingly it is no longer necessary to determine whether the current time exceeds the effective time of the Session Key.
  • the server 202 determines that the current time has exceeded the validity period of the Session Key, the server 202 returns a message indicating that the Session Key is invalid to the client 201, so that the client 201 needs to restart the Session Key negotiation with the server 202. process.
  • Step S208 After the server 202 determines that the current time does not exceed the validity period of the Session Key, the server 202 decrypts the service request data in the received service request message by using the session key, and obtains the number of decrypted service requests. According to the data, the business response data is generated according to the decrypted service request data.
  • Step S209 The server 202 sends a service response message to the client 201, where the service response message carries the service response data encrypted by the Session Key found in step S207.
  • the server 202 may encapsulate the foregoing service response message by using a message format as shown in FIG. 6:
  • Version represents the version and protocol information. If the security channel for secure communication between the client 201 and the server 202 is based on the http protocol, the Version is set to 11001B, and if the spdy protocol is based, the Version is set to 11101B.
  • the type represents the type information of the message. When the service response data carried in the service response message sent by the server 202 to the client 201 is encrypted, the type information of the message may be set to 0x05.
  • Length represents the length of the packet.
  • the unit can be the number of network bytes, excluding the first 4 bytes including Version, Type, and Length.
  • the server 202 processes the service response message from the client 201 in a synchronous manner, whether the service response data is encrypted in the service report message returned by the service response message depends on the received service request message.
  • the service request data in the text is encrypted, that is, if the service request data received by the server 202 in the service request message is encrypted by the Session Key, the service response message fed back by the server 202 to the client 201 is also The service response data is encrypted by the session key; if the service request data in the service request message received by the server 202 is not encrypted, the service response data is not carried in the service response message fed back by the server 202 to the client 201. encryption.
  • the server 202 learns whether the service response data in the service request packet is encrypted, and can be obtained by reading the packet type information in the service request packet, for example, when the type information of the packet is found to be 0x05. Then, it is determined that the service request data in the service request message is encrypted.
  • the server 202 can directly know whether the service request data in the original service request message is directly received by the server 202 when feeding back the service response message to the client 201.
  • the server 202 can record the identifier of each service request message sent by the client 201 to the server 202, and whether the service request data in each service request message is encrypted (below) It is recorded as an encrypted identifier, and the relationship between the identifier of each service request packet and the encrypted identifier of the service request packet is maintained.
  • the server 202 When the server 202 needs to feed back a service response message to a service request packet sent by the client 201, the server first searches for the corresponding encrypted identifier of the request message by using the corresponding relationship. If the encrypted identifier indicates that the information is encrypted, the server 202 encrypts the service response data in the service response message. If the encrypted identifier indicates that the information is not encrypted, the server 202 will in the service response message. The business response data is not encrypted.
  • the association between the identifier of each service request packet maintained by the server 202 and the information of the service request data of the request packet may be implemented by a mapping relationship, where the mapping relationship includes at least one mapping relationship.
  • An entry, where each entry contains an identifier of the service request packet and an encrypted identifier of the service request packet for example, when the service request If the service request data of the packet is encrypted, the encryption identifier of the service request packet may be set to "1"; when the service request data of the service request packet is not encrypted, the encrypted identifier of the service request packet Can be set to "0".
  • FIG. 7 is a schematic diagram of a network security communication apparatus according to an embodiment of the present application. As shown in FIG. 7, the apparatus includes: a handshake request sending unit 701, a handshake response receiving unit 702, a handshake response decryption unit 703, and a session secret. Key calculation unit 704.
  • the handshake request sending unit 701 is configured to send a handshake request packet to the server, where the handshake request message carries the first random number encrypted by using the first public key and is encrypted by using the first public key.
  • the service request data so that the server decrypts the handshake request message according to the first private key corresponding to the first public key to obtain a first random number and first service request data, and according to the first
  • the service request data generates the first service response data.
  • the handshake response receiving unit 702 is configured to receive a handshake response message fed back by the server, where the handshake response message carries the first service response data encrypted by using the first random number and the first encrypted by using the first random number. Two random numbers.
  • the handshake response decryption unit 703 is configured to decrypt the handshake response message by using the first random number to obtain first service response data and a second random number.
  • the session key calculation unit 704 is configured to calculate a session key used by the session with the server by using the first random number and the second random number.
  • the network security communication device may further include a ciphertext service request sending unit and a ciphertext service response receiving unit.
  • the ciphertext service request sending unit is configured to send, to the server, a ciphertext service request message, where the ciphertext service request message carries the identifier of the session key and uses the session key. Encrypting the second service request data, so that the server searches for the corresponding session key according to the identifier of the session key, and decrypts the ciphertext service request message by using the found session key to obtain Second service request data;
  • the ciphertext service response receiving unit is configured to receive a ciphertext service response message fed back by the server, where the ciphertext service response message carries the second service response data encrypted by using the session key, where the second service is The response data is generated by the server according to the second service request data.
  • the network security communication device may further include a plaintext service request sending unit and a plaintext service response receiving unit.
  • the plaintext service request sending unit is configured to send a clear text service request message to the server, where the plaintext service request message carries the third service request data of the plaintext, so that the server requests the message from the plaintext service.
  • the third service request data of the plaintext is obtained.
  • the plaintext service response receiving unit is configured to receive a plaintext service response message fed back by the server, where the plaintext service response message is sent.
  • the third service response data of the plaintext is carried in the text, and the third service response data is generated by the server according to the third service request data.
  • the embodiment of the present application further provides a client, including the network security communication device shown in the foregoing embodiment of FIG.
  • the network security communication device includes a handshake request receiving unit 801, a handshake request decryption unit 802, and a first service response generation unit 803.
  • the handshake request receiving unit 801 is configured to receive a handshake request packet sent by the client, where the handshake request packet carries a first random number encrypted by using the first public key and a service request encrypted by using the first public key. data.
  • the handshake request decryption unit 802 is configured to decrypt the handshake request message by using the first private key corresponding to the first public key to obtain a first random number and service request data.
  • the first service response generating unit 803 is configured to generate first service response data according to the first service request data.
  • the handshake response sending unit 804 is configured to send a handshake response message to the client, where the handshake response message carries the first service response data encrypted by using the first random number and the second encrypted by using the first random number. a random number, so that the client decrypts the handshake response message by using the first random number, obtains service response data and a second random number, and uses the first random number and the second random number based on the first secret
  • the key algorithm calculates the session key used by the session.
  • the session key calculation unit 805 is configured to calculate, according to the first random number and the second random number, the session key used by the session by using the first key algorithm.
  • the network security communication device located at the server further includes a ciphertext service request receiving unit, a session key searching unit, a service request decrypting unit, a second service response generating unit, and a ciphertext service response sending unit.
  • the ciphertext service request receiving unit is configured to receive the ciphertext service request message sent by the client, where the ciphertext service request message carries the identifier of the session key and the first session encrypted by using the session key. Two business request data.
  • the session key search unit is configured to search for a corresponding session key by using the identifier of the session key.
  • the service request decryption unit is configured to decrypt the ciphertext service request message by using the found session key to obtain second service request data.
  • the second service response generating unit is configured to generate second service response data according to the second service request data.
  • the ciphertext service response sending unit is configured to send a ciphertext service response message to the client, where the ciphertext service response message carries the second service response data encrypted by using the session key.
  • the network security communication device at the server further includes: a plaintext service request receiving unit, a service request data acquiring unit, a third service response generating unit, and a plaintext service response sending unit.
  • the plaintext service request receiving unit is configured to receive the plaintext service request packet sent by the client, where the plaintext service request packet carries the third service request data of the plaintext.
  • the service request data obtaining unit is configured to obtain third service request data from the plaintext service request message.
  • the third service response generating unit is configured to generate third service response data according to the third service request data.
  • the plaintext service response sending unit is configured to send a plaintext service response message to the client, where the plaintext service response message carries the third service response data of the plaintext.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • the controller can be implemented in any suitable manner, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor.
  • computer readable program code eg, software or firmware
  • examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, memory controller can also be Implemented as part of the control logic of the memory.
  • the controller can be logically programmed by means of logic gates, switches, ASICs, programmable logic controllers, and embedding.
  • Such a controller can therefore be considered a hardware component, and the means for implementing various functions included therein can also be considered as a structure within the hardware component.
  • a device for implementing various functions can be considered as a software module that can be both a method of implementation and a structure within a hardware component.
  • the system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function.
  • the present application can be implemented by means of software plus a necessary general hardware platform. Based on such understanding, portions of the technical solution of the present application that contribute substantially or to the prior art may be embodied in the form of a software product.
  • the computing device includes one or more processors (CPU ), input / output interface, network interface and memory.
  • the computer software product can include instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to perform the methods described in various embodiments or portions of the embodiments.
  • the computer software product can be stored in a memory, which may include non-persistent memory, random access memory (RAM), and/or nonvolatile memory in a computer readable medium, such as read only memory (ROM) or Flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology.
  • the information can be computer readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • ROM read only memory
  • EEPROM electrically erasable programmable read only memory
  • flash memory or other memory technology
  • compact disk read only memory CD-ROM
  • DVD digital versatile disk
  • Magnetic tape cartridges magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include transitory computer readable media, such as modulated data signals and carrier waves.
  • This application can be used in a variety of general purpose or special purpose computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, small computers, mainframe computers, A distributed computing environment, including any of the above systems or devices.
  • the application can be described in the general context of computer-executable instructions executed by a computer, such as a program module.
  • program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types.
  • the present application can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are connected through a communication network.
  • program modules can be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明实施例提供一种网络安全通信方法及通信装置，该方法包括：向服务端发送握手请求报文，所述握手请求报文中携带使用第一公钥加密的第一随机数和使用所述第一公钥加密的业务请求数据，以使所述服务端根据所述第一公钥对应的第一私钥将所述握手请求报文解密得到第一随机数及第一业务请求数据、并根据所述第一业务请求数据生成第一业务应答数据；接收服务端反馈的握手应答报文，所述握手应答报文中携带使用所述第一随机数加密的第一业务应答数据和使用所述第一随机数加密的第二随机数；通过所述第一随机数对所述握手应答报文进行解密，得到第一业务应答数据和第二随机数；通过所述第一随机数和第二随机数计算与服务端之间的会话所使用的会话密钥。

Description

一种网络安全通信方法及通信装置 技术领域
本发明涉及通信技术领域，尤其涉及一种网络安全通信方法及通信装置。
背景技术
随着互联网的快速发展，信息安全问题成为人们必须面对的挑战。在传统的PC上我们采用HTTPS来解决这个问题。采用HTTPS时，客户端和服务端进行通信的过程包括握手阶段，客户端和服务端之间先协商密钥，此时服务端需要向客户端提供由权威机构颁发的证书以证明客户端收到的应答来自于合法的服务端。这就导致客户端和服务端之间的交互次数太多，且每次交互的数据包太大，占用很大的流量开销，客户端验证该证书需要密集的CPU计算，由此引起的电量对移动终端是个挑战。
发明内容
本申请实施例的目的是提供一种网络安全通信方法及通信装置，可以在客户端与服务端协商密钥的过程中发送业务请求和应答，减少了信息交互的次数。
为实现上述目的，本申请实施例提供一种网络安全通信方法，包括：
向服务端发送握手请求报文，所述握手请求报文中携带使用第一公钥加密的第一随机数和使用所述第一公钥加密的业务请求数据，以使所述服务端根据所述第一公钥对应的第一私钥将所述握手请求报文解密得到第一随机数及第一业务请求数据、并根据所述第一业务请求数据生成第一业务应答数据；
接收服务端反馈的握手应答报文，所述握手应答报文中携带使用所述第一随机数加密的第一业务应答数据和使用所述第一随机数加密的第二随机数；
通过所述第一随机数对所述握手应答报文进行解密，得到第一业务应答数据和第二随机数；
通过所述第一随机数和第二随机数计算与服务端之间的会话所使用的会话密钥。
在一个优选的实施例中，所述密文业务请求报文中携带所述会话密钥的标识和使用所述会话密钥加密的第二业务请求数据，以使所述服务端根据该会话密钥的标识查找对应的会话密钥，并使用所述找到的会话密钥对所述密文业务请求报文进行解密，得到第二业务请求数据；
接收服务端反馈的密文业务应答报文，所述密文业务应答报文中携带使用所述会话密钥加密的第二业务应答数据，所述第二业务应答数据是由所述服务端根据所述第二业务请求数 据生成的。
在一个优选的实施例中，所述方法还包括：
向服务端发送明文业务请求报文，所述明文业务请求报文中携带明文的第三业务请求数据，以使所述服务端从所述明文业务请求报文中获取明文的第三业务请求数据；
接收服务端反馈的明文业务应答报文，所述明文业务应答报文中携带明文的第三业务应答数据，所述第三业务应答数据是由所述服务端根据所述第三业务请求数据生成的。
在一个优选的实施例中，所述方法还包括：
接收服务端反馈的会话密钥过期的通知；
返回继续执行向服务端发送握手请求报文的步骤。
本申请另一方面还提供一种网络安全通信方法，包括：
接收客户端发送的握手请求报文，所述握手请求报文中携带使用第一公钥加密的第一随机数和使用所述第一公钥加密的业务请求数据；
使用所述第一公钥对应的第一私钥对所述的握手请求报文进行解密，得到第一随机数和业务请求数据；
根据所述第一业务请求数据生成第一业务应答数据；
向所述客户端发送握手应答报文，所述握手应答报文中携带使用第一随机数加密的第一业务应答数据和使用所述第一随机数加密的第二随机数，以使所述客户端通过所述第一随机数对所述握手应答报文解密，得到业务应答数据和第二随机数，并以第一随机数和第二随机数基于第一密钥算法计算出会话所使用的会话密钥；
根据所述第一随机数和第二随机数使用所述第一密钥算法计算出会话所使用的会话密钥。
在一个优选的实施例中，所述方法还包括：
接收客户端发送的密文业务请求报文，所述密文业务请求报文中携带所述会话密钥的标识和使用所述会话密钥加密的第二业务请求数据；
通过所述会话密钥的标识查找对应的会话密钥；
使用所述找到的会话密钥对所述密文业务请求报文进行解密，得到第二业务请求数据；
根据所述第二业务请求数据生成第二业务应答数据；
向所述客户端发送密文业务应答报文，所述密文业务应答报文中携带使用所述会话密钥加密的第二业务应答数据。
在一个优选的实施例中，所述方法还包括：
接收客户端发送的明文业务请求报文，所述明文业务请求报文中携带明文的第三业务请 求数据；
从所述明文业务请求报文中获取第三业务请求数据；
根据所述第三业务请求数据生成第三业务应答数据；
向所述客户端发送明文业务应答报文，所述明文业务应答报文中携带明文的第三业务应答数据。
在一个优选的实施例中，所述方法还包括：
接收客户端发送的业务请求报文；
判断所述业务请求报文是密文业务请求报文还是明文业务请求报文，
由该业务请求报文是密文业务请求报文还是明文业务请求报文的判断结果生成加密标识；
建立所述业务请求报文的标识与该业务请求报文的加密标识的第一映射关系；
在针对客户端发送的业务请求报文时，通过该业务请求报文的标识与所述第一映射关系，查找对应的加密标识；
如果该加密标识表示该业务请求报文是密文业务请求报文，则触发执行向所述客户端发送密文业务应答报文的步骤；
如果该加密标识表示该业务请求报文是明文业务请求报文，则触发执行向所述客户端发送明文业务应答报文的步骤。
本申请另一方面还提供一种网络安全通信装置，包括：
握手请求发送单元，用于向服务端发送向服务端发送握手请求报文，所述握手请求报文中携带使用第一公钥加密的第一随机数和使用所述第一公钥加密的业务请求数据，以使所述服务端根据所述第一公钥对应的第一私钥将所述握手请求报文解密得到第一随机数及第一业务请求数据、并根据所述第一业务请求数据生成第一业务应答数据；
握手应答接收单元，用于接收服务端反馈的握手应答报文，所述握手应答报文中携带使用所述第一随机数加密的第一业务应答数据和使用所述第一随机数加密的第二随机数；
握手应答解密单元，用于通过所述第一随机数对所述握手应答报文进行解密，得到第一业务应答数据和第二随机数；
会话密钥计算单元，用于通过所述第一随机数和第二随机数计算与服务端之间的会话所使用的会话密钥。
在一个优选的实施例中，所述装置还包括：
密文业务请求发送单元，用于向服务端发送密文业务请求报文，所述密文业务请求报文中携带所述会话密钥的标识和使用所述会话密钥加密的第二业务请求数据，以使所述服务端 根据该会话密钥的标识查找对应的会话密钥，并使用所述找到的会话密钥对所述密文业务请求报文进行解密，得到第二业务请求数据；
密文业务应答接收单元，用于接收服务端反馈的密文业务应答报文，所述密文业务应答报文中携带使用所述会话密钥加密的第二业务应答数据，所述第二业务应答数据是由所述服务端根据所述第二业务请求数据生成的。
在一个优选的实施例中，所述装置还包括：
明文业务请求发送单元，用于向服务端发送明文业务请求报文，所述明文业务请求报文中携带明文的第三业务请求数据，以使所述服务端从所述明文业务请求报文中获取明文的第三业务请求数据；
明文业务应答接收单元，用于接收服务端反馈的明文业务应答报文，所述明文业务应答报文中携带明文的第三业务应答数据，所述第三业务应答数据是由所述服务端根据所述第三业务请求数据生成的。
本申请再一方面还提供一种网络安全通信装置，包括：
握手请求接收单元，用于接收客户端发送的握手请求报文，所述握手请求报文中携带使用第一公钥加密的第一随机数和使用所述第一公钥加密的业务请求数据；
握手请求解密单元，用于使用所述第一公钥对应的第一私钥对所述的握手请求报文进行解密，得到第一随机数和业务请求数据；
第一业务应答生成单元，用于根据所述第一业务请求数据生成第一业务应答数据；
握手应答发送单元，用于向所述客户端发送握手应答报文，所述握手应答报文中携带使用第一随机数加密的第一业务应答数据和使用所述第一随机数加密的第二随机数，以使所述客户端通过所述第一随机数对所述握手应答报文解密，得到业务应答数据和第二随机数，并以第一随机数和第二随机数基于第一密钥算法计算出会话所使用的会话密钥；
会话密钥计算单元，用于根据所述第一随机数和第二随机数使用所述第一密钥算法计算出会话所使用的会话密钥。
在一个优选的实施例中，所述装置还包括：
密文业务请求接收单元，用于接收客户端发送的密文业务请求报文，所述密文业务请求报文中携带所述会话密钥的标识和使用所述会话密钥加密的第二业务请求数据；
会话密钥查找单元，用于通过所述会话密钥的标识查找对应的会话密钥；
业务请求解密单元，用于使用所述找到的会话密钥对所述密文业务请求报文进行解密，得到第二业务请求数据；
第二业务应答生成单元，用于根据所述第二业务请求数据生成第二业务应答数据；
密文业务应答发送单元，用于向所述客户端发送密文业务应答报文，所述密文业务应答报文中携带使用所述会话密钥加密的第二业务应答数据。
在一个优选的实施例中，所述装置还包括：
明文业务请求接收单元，用于接收客户端发送的明文业务请求报文，所述明文业务请求报文中携带明文的第三业务请求数据；
业务请求数据获取单元，用于从所述明文业务请求报文中获取第三业务请求数据；
第三业务应答生成单元，用于根据所述第三业务请求数据生成第三业务应答数据；
明文业务应答发送单元，用于向所述客户端发送明文业务应答报文，所述明文业务应答报文中携带明文的第三业务应答数据。
由以上本申请实施例提供的技术方案可见，在协商会话密钥的过程中同时发送业务请求数据，进而可以在会话密钥协商的过程中通过握手应答报文获得业务应答数据，节省了后续需要对这部分业务请求数据另外发送业务请求报文的步骤，也节省了针对相应业务应答数据另外接收业务应答报文的步骤，所以相对于现有技术减少了与服务端之间的消息交互次数。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1A是本申请实施例提供一种网络安全通信方法的流程图；
图1B是本申请另一实施例提供一种网络安全通信方法的流程图；
图2是本申请实施中一种网络安全通信方法的具体实现过程示意图；
图3是本申请实施例中握手请求报文的一种具体实现的示意图；
图4是本申请实施例中握手应答报文的一种具体实现的示意图；
图5是携带密文业务请求数据的报文的一种具体实现的示意图；
图6是业务应答数据报文的一种具体实现示意图；
图7是本申请实施例提供的一种网络安全通信装置的示意图；
图8是本申请另一实施例提供的一种网络安全通信装置的示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中 的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
现有通信技术中客户端和服务端之间业务的请求和应答必须在协商完密钥后进行，这使得消息交互次数太多，用时太长。
为解决上述问题，本申请实施例提供一种网络安全通信方法，如图1A所示，该方法包括：
步骤S101A：向服务端发送握手请求报文，该握手请求报文中携带使用第一公钥加密的第一随机数和使用所述第一公钥加密的业务请求数据，以使该服务端根据所述第一公钥对应的第一私钥将该握手请求报文解密得到第一随机数及第一业务请求数据、并根据所述第一业务请求数据生成第一业务应答数据。
步骤S102A：接收服务端反馈的握手应答报文，该握手应答报文中携带使用该第一随机数加密的第一业务应答数据和使用该第一随机数加密的第二随机数。
步骤S103A：通过该第一随机数对该握手应答报文进行解密，得到第一业务应答数据和第二随机数。
步骤S104A：通过第一随机数和第二随机数计算与服务端之间的会话所使用的会话密钥。
需要说明的是，上述步骤S101-步骤S104的执行主体可以是客户端。
由此可见，图1A中示出的实施例中的技术方案在协商会话密钥的过程中同时发送业务请求数据，进而可以在会话密钥协商的过程中通过握手应答报文获得业务应答数据，节省了后续需要对这部分业务请求数据另外发送业务请求报文的步骤，也节省了针对相应业务应答数据另外接收业务应答报文的步骤，所以相对于现有技术减少了与服务端之间的消息交互次数。
本申请另一实施例还提供一种网络安全通信方法，如图1B所示，该方法包括：
步骤S101B：接收客户端发送的握手请求报文，该握手请求报文中携带使用第一公钥加密的第一随机数和使用该第一公钥加密的业务请求数据；
步骤S102B：使用第一公钥对应的第一私钥对握手请求报文进行解密，得到第一随机数和业务请求数据；
步骤S103B：根据所述第一业务请求数据生成第一业务应答数据；
步骤S104B：向所述客户端发送握手应答报文，所述握手应答报文中携带使用第一随机数加密的第一业务应答数据和使用所述第一随机数加密的第二随机数，以使所述客户端通过所述第一随机数对所述握手应答报文解密，得到业务应答数据和第二随机数，并以第一随机数和第二随机数基于第一密钥算法计算出会话所使用的会话密钥；
步骤S105B：根据第一随机数和第二随机数使用所述第一密钥算法计算出会话所使用的会话密钥。
需要说明的是，上述步骤的执行主体可以是服务端。
由图1B中示出的实施例中的技术方案可知，在与客户端协商会话密钥的过程中同时接收业务请求数据，进而可以在会话密钥协商的过程中通过握手应答报文发送业务应答数据，节省了后续需要对这部分业务请求数据另外接收业务请求报文的步骤，也节省了针对相应业务应答数据另外发送业务应答报文的步骤，所以相对于现有技术减少了与客户端之间的消息交互次数。
以下通过一个例子详细说明本申请实施例的具体实现
图2示出了一种网络安全通信方法的具体实现过程示意图，如图2所示，该方法包括如下步骤：
步骤S201：客户端201向服务端202发送握手请求报文，该握手请求报文中携带用非对称加密算法的公钥加密的第一随机数(可以记为nonce1)和上述公钥加密的业务请求数据。
这里的非对称加密算法的公钥为服务端202广发的公钥，向该服务端202发送数据的设备可以使用该公钥对要发送的数据进行加密，而服务端202可以利用自身所拥有的私钥进行解密。
客户端201向服务端202发送的握手请求报文可以采用如图3中所示的报文格式，在图3中，Version表示版本和协议信息，例如，如果客户端201和服务端202所进行安全通信的安全信道之上是基于http协议进行的通信，则该Version值设置为11001B(其中，B代表前面的数为二进制数)，如果是基于SPDY协议，则该Version值可以设置为11101B。
图3中的Type代表报文的类型信息，在客户端201发送的握手请求报文中此处的Type值可以上设置为0x01，该值标识此报文的类型为握手请求，这样服务端202在接收到该报文时可以获知该报文属于握手请求报文。
图3中的长度代表报文的长度，单位可以是网络字节数，不包括Version、Type和长度在内的前4个字节。
图3中的RSA公钥(32bit)表示32bit的RSA公钥，该RSA公钥为步骤S201中的非对称加密算法的公钥。
上述的第一随机数可以是由客户端201计算得到的随机数。
步骤S202：服务端202根据非对称算法的私钥对接收到的握手请求报文进行解密，得到第一随机数和业务请求数据，并根据业务请求数据生成业务应答数据。
在实际中，为了在这一过程中保障客户端201和服务端202进行通信的安全性，在一个优 选的实施例中，服务端202还对来自客户端201的握手请求报文进行验证，如果验证不通过，则直接关闭与客户端201之间的连接，停止执行后续流程；如果验证通过，则继续执行根据业务请求数据生成业务应答数据的步骤。
而上述对握手请求报文进行验证可以有两种具体实现方式：
方式一：客户端201发送至服务端202的握手请求报文中携带的第一随机数的第一位为一个Magic Code，如果在客户端201发送至服务端202的过程中存在第三方篡改报文的情况出现，该第一随机数的第一位将发生变化，为此服务端202对握手请求报文进行验证可以通过检查解密得到的第一随机数的第一位是否还是Magic Code，如果是，则验证通过；如果否，则验证不通过。这里的Magic Code又称为魔数，魔数的技术是通过在数据的首部或尾部插入若干标识为常量的字节，以快速判断一个报文的合法性，
方式二：服务端202对客户端201发送过来的握手请求报文的长度有要求，如果在客户端201将握手请求报文发送至服务端202的过程中被恶意用户进行放大攻击，则该握手请求报文的长度会出现异常。为此，服务端202对握手请求报文进行验证也可以通过检查握手请求报文的长度是否异常实现，如果异常，则验证不通过；如果不异常，则验证通过。
步骤S203：服务端202向客户端201发送握手应答报文，该握手应答报文中携带了由第一随机数作为密钥加密的第二随机数(可以记为nonce2)和由第一随机数作为密钥加密的业务应答数据。
这里的第二随机数可以是有服务端202计算得到的随机数。
服务端202向客户端201发送的握手应答报文可以采用如图4所述的报文格式：
其中，Version代表版本和协议信息，如果客户端201和服务端202所进行安全通信的安全信道之上是基于http协议进行的通信，则该Version可以设置为11001B，如果是基于spdy协议则Version可以设置为11101B；
而Type代表报文的类型信息，在服务端202向客户端201发送握手应答报文中，此处的Type值可以设置为0x03，该值表示报文的类型为握手应答，这样客户端201在接收到该报文时可以获知该报文属于握手应答报文。
图4中的长度代表报文的长度信息，单位可以是网络字节数，不包括Version、Type和长度在内的前4个字节。
图4中的密文表示由第一随机数作为密钥加密的第二随机数和由第一随机数作为密钥加密的业务应答数据。
步骤S204：客户端201对接收到的握手应答报文利用第一随机数进行解密，得到第二随机数和业务应答数据，并利用第一随机数和第二随机数使用对称加密算法计算出会话密钥 (Session Key)。
Session Key具体可以通过下式计算得出：
Session Key＝sha256(nonce1，nonce2)
其中，nonce1为第一随机数，nonce2为第二随机数。
在实际中，为了在这一过程客户端201和服务端202进行通信的安全性，在一个优选的实施例中，客户端201还对来自服务端202的握手应答报文解密后进行验证，在服务端202发送至客户端201的握手应答报文中携带的第二随机数的第一位为一个Magic Code，如果在服务端202发送至客户端201的过程中存在第三方篡改报文的情况出现，该第二随机数的第一位将发生变化，为此客户端201对握手应答报文进行验证可以通过检查解密得到的第二随机数的第一位是否还是Magic Code实现，如果否，则验证不通过；如果是，则验证通过，进而进行Session Key的计算。
步骤S205：服务端202将得到的第一随机数和第二随机数用与步骤S204中相同的算法计算出Session Key。
需要说明的是，步骤S204和步骤S205的执行顺序是可以互换的，当然也可以同时进行，只要步骤S204和步骤S205中计算Session Key的算法相同即可。这样服务端202和客户端201就获得了相同的Session Key。该Session Key用于在后续客户端201和服务端202之间传递业务请求报文和业务应答报文时对数据进行加密。
以上步骤S201至步骤S205所涵盖的握手阶段的过程完成了Session Key的协商。
客户端201和服务端202通过上述握手阶段创建了一个会话，基于这个会话的后续业务请求报文和业务应答报文的传递都可以使用握手阶段协商一致得到的Session Key进行加密。服务端202为上述创建的会话可以分配一个标识，记为Session ID，该Session ID可以如4所示由服务端202向客户端201发送的握手应答报文中一并携带下发。
此外，图4中的握手应答报文中还携带有Session Key有效期，当Session Key在有效期内，即使断开后再次连接也可以直接复用该Session Key而不必重新协商，当有效期为零时退化为一次一密，即本次连接内Session Key始终有效，一旦连接断开则必须重新执行步骤S201至S205中以重新协商Session Key。该携带的Session Key有效期可以是一个相对时间，例如相对于服务端202向客户端201发送该握手应答报文的时间后的第一时间长度内都是有效的，此时该第一时间长度的值就可以作为相对时间携带在图4中的Session Key有效期中。
需要说明的是，图4中示出的方案中，服务端202通过握手应答报文一并将Session Key的有效期和Session ID下发，在实际中，也可以再通过单独的报文下发Session Key的有效期和Session ID给客户端201。
握手阶段之后客户端201和服务端202进行业务数据的交互，以下详细描述业务数据的交互过程：
步骤S206：客户端201向服务端202发送业务请求报文，该业务请求报文中携带Session ID和由Session Key加密的业务请求数据。
客户端201所发送的携带密文业务请求数据的报文可以采用如图5中所示的格式。客户端201所发送的携带密文业务请求数据的报文可以采用如图5中所示的格式。
其中，Version代表版本和协议信息，如果客户端201和服务端202所进行安全通信的安全信道之上是基于http协议进行的通信，则该Version设置为11001B，如果是基于spdy协议则Version设置为11101B。
而Type代表报文的类型信息，在客户端201所发送的密文业务请求的报文中此处的Type值可以设置为0x02，表示该报文的类型为密文业务请求；这样服务端202在接收到该报文时可以获知该报文属于业务请求报文，且该业务请求报文中的业务请求数据被加密过了。需要说明的是，在本实施例中，客户端201和服务端202在同一个会话中多次的业务请求报文和业务响应报文的往返可以携带明文的数据也可以携带密文的数据，尤其是对于获取不涉及安全问题的业务数据时，客户端201向服务端202发送的业务请求报文中携带的业务请求数据可以是明文形式，此时通过业务请求报文中的报文的类型信息通知服务端202该业务请求报文中的业务请求数据是明文，不需要进行解密操作，此时客户端201向服务端202发送的业务请求报文中不再需要携带Session ID。
步骤S207：服务端202根据业务请求报文中的Session ID找到对应的Session Key及该Session Key的有效期，判断当前时间是否超过了该Session Key的有效期。
由于在Session Key的协商过程中，服务端202已经建立了Session ID与Session Key之间的对应关系，因此在服务端202获得业务请求报文中的Session ID后，可以通过上述对应关系找到正确的Session Key。
需要说明的是，在本例中，为Session Key分配了有效时间，因此在找到Session Key后还需判断当前时间是否超过了该Session Key的有效期。在实际中，也可以省去为Session Key分配有效时间的步骤，相应地也就不再需要判断当前时间是否超过了Session Key的有效时间。
如果服务端202判断出当前时间已经超过Session Key的有效期，则服务端202会向客户端201返回通知Session Key失效的报文，以促使客户端201需要重启与服务端202之间的Session Key协商过程。
步骤S208：服务端202判断出当前时间未超出Session Key的有效期后，服务端202用该Session Key对接收到的业务请求报文中的业务请求数据进行解密，得到解密后的业务请求数 据，并根据解密后的业务请求数据生成业务应答数据。
步骤S209：服务端202向客户端201发送业务应答报文，该业务应答报文中携带由步骤S207中找到的Session Key加密的业务应答数据。
服务端202可以通过如图6中示出的报文格式封装上述业务应答报文：
其中，Version代表版本和协议信息，如果客户端201和服务端202所进行安全通信的安全信道之上是基于http协议进行的通信，则该Version设置为11001B，如果是基于spdy协议则Version设置为11101B。而Type代表报文的类型信息，当服务端202向客户端201发送的业务应答报文中所携带的业务应答数据被加密过，则该报文的类型信息可以设置为0x05。
Length代表报文长度，单位可以是网络字节数，不包括Version、Type和长度在内的前4个字节。
当服务端202采用同步的方式处理来自客户端201的业务应答报文时，针对该业务应答报文返回的业务应报报文中是否对业务应答数据进行加密，取决于接收到的业务请求报文中的业务请求数据是否被加密，即：如果服务端202接收到业务请求报文中的业务请求数据通过Session Key加密过，则服务端202向客户端201反馈的业务应答报文中也对业务应答数据通过Session Key进行加密；如果服务端202接收到的业务请求报文中的业务请求数据并未被加密，则服务端202向客户端201反馈的业务应答报文中不对业务应答数据进行加密。在实际中，服务端202获知业务请求报文中的业务应答数据是否被加密过可以通过读取该业务请求报文中的报文类型信息获知，例如当发现该报文的类型信息置为0x05时，则判断该业务请求报文中的业务请求数据被加密过。
当服务端202采用异步的方式处理来自客户端201的业务请求报文时，服务端202在向客户端201反馈业务应答报文时很难直接获知原来的业务请求报文中的业务请求数据是否被加密过，为此，服务端202可以记录客户端201发送给服务端202的每一个业务请求报文的标识，并将每一个业务请求报文中的业务请求数据是否被加密的信息(以下称为加密标识)进行记录，进而维护每个业务请求报文的标识与该业务请求报文的加密标识之间的关联关系。在服务端202在需要针对客户端201发送的某个业务请求报文反馈业务应答报文时，首先由该业务请求报文的标识通过上述对应关系，查找到对应的该请求报文的加密标识的信息，如果该加密标识表明表明信息已加密，则服务端202在业务应答报文中将业务应答数据进行加密，如果该加密标识表明信息未加密，则服务端202在业务应答报文中将业务应答数据不进行加密。
在实际中，服务端202维护的每个业务请求报文的标识与该请求报文的业务请求数据是否被加密的信息之间的关联关系可以通过一个映射关系来实现，该映射关系包括至少一个表项，每个表项中存有业务请求报文的标识和该业务请求报文的加密标识，例如当该业务请求 报文的业务请求数据被加密过，则该业务请求报文的加密标识可以设置为“1”；当该业务请求报文的业务请求数据未被加密时，则该业务请求报文的加密标识可以设置为“0”。
图7示出了本申请实施例提供的一种网络安全通信装置的示意图，如图7所示，该装置包括：握手请求发送单元701、握手应答接收单元702、握手应答解密单元703和会话密钥计算单元704。
其中，握手请求发送单元701用于向服务端发送向服务端发送握手请求报文，所述握手请求报文中携带使用第一公钥加密的第一随机数和使用所述第一公钥加密的业务请求数据，以使所述服务端根据所述第一公钥对应的第一私钥将所述握手请求报文解密得到第一随机数及第一业务请求数据、并根据所述第一业务请求数据生成第一业务应答数据。
握手应答接收单元702用于接收服务端反馈的握手应答报文，所述握手应答报文中携带使用所述第一随机数加密的第一业务应答数据和使用所述第一随机数加密的第二随机数。
握手应答解密单元703用于通过所述第一随机数对所述握手应答报文进行解密，得到第一业务应答数据和第二随机数。
会话密钥计算单元704用于通过所述第一随机数和第二随机数计算与服务端之间的会话所使用的会话密钥。
此外，上述网络安全通信装置还可以包括密文业务请求发送单元和密文业务应答接收单元。
其中，密文业务请求发送单元用于向服务端用于向服务端发送密文业务请求报文，所述密文业务请求报文中携带所述会话密钥的标识和使用所述会话密钥加密的第二业务请求数据，以使所述服务端根据该会话密钥的标识查找对应的会话密钥，并使用所述找到的会话密钥对所述密文业务请求报文进行解密，得到第二业务请求数据；
密文业务应答接收单元，用于接收服务端反馈的密文业务应答报文，所述密文业务应答报文中携带使用所述会话密钥加密的第二业务应答数据，所述第二业务应答数据是由所述服务端根据所述第二业务请求数据生成的。
另外，上述网络安全通信装置还可以包括明文业务请求发送单元和明文业务应答接收单元。
其中，明文业务请求发送单元用于向服务端发送明文业务请求报文，所述明文业务请求报文中携带明文的第三业务请求数据，以使所述服务端从所述明文业务请求报文中获取明文的第三业务请求数据。
明文业务应答接收单元用于接收服务端反馈的明文业务应答报文，所述明文业务应答报 文中携带明文的第三业务应答数据，所述第三业务应答数据是由所述服务端根据所述第三业务请求数据生成的。
本申请实施例还提供一种客户端，包括上述图7实施例中示出的网络安全通信装置。
本申请另一方面还提供设置在服务端一侧的网络安全通信装置，如图8所示，该网络安全通信装置包括握手请求接收单元801、握手请求解密单元802、第一业务应答生成单元803、握手应答发送单元804和会话密钥计算单元805。
其中，握手请求接收单元801用于接收客户端发送的握手请求报文，所述握手请求报文中携带使用第一公钥加密的第一随机数和使用所述第一公钥加密的业务请求数据。
握手请求解密单元802用于使用所述第一公钥对应的第一私钥对所述的握手请求报文进行解密，得到第一随机数和业务请求数据。
第一业务应答生成单元803用于根据所述第一业务请求数据生成第一业务应答数据。
握手应答发送单元804用于向所述客户端发送握手应答报文，所述握手应答报文中携带使用第一随机数加密的第一业务应答数据和使用所述第一随机数加密的第二随机数，以使所述客户端通过所述第一随机数对所述握手应答报文解密，得到业务应答数据和第二随机数，并以第一随机数和第二随机数基于第一密钥算法计算出会话所使用的会话密钥。
会话密钥计算单元805用于根据所述第一随机数和第二随机数使用所述第一密钥算法计算出会话所使用的会话密钥。
在一个优选的实施例中，上述位于服务端的网络安全通信装置还包括密文业务请求接收单元、会话密钥查找单元、业务请求解密单元、第二业务应答生成单元和密文业务应答发送单元。
其中，上述密文业务请求接收单元用于接收客户端发送的密文业务请求报文，所述密文业务请求报文中携带所述会话密钥的标识和使用所述会话密钥加密的第二业务请求数据。
会话密钥查找单元用于通过所述会话密钥的标识查找对应的会话密钥。
业务请求解密单元用于使用所述找到的会话密钥对所述密文业务请求报文进行解密，得到第二业务请求数据。
第二业务应答生成单元用于根据所述第二业务请求数据生成第二业务应答数据。
密文业务应答发送单元用于向所述客户端发送密文业务应答报文，所述密文业务应答报文中携带使用所述会话密钥加密的第二业务应答数据。
在一个优选的实施例中，上述的位于服务端的网络安全通信装置还包括：明文业务请求接收单元、业务请求数据获取单元、第三业务应答生成单元、明文业务应答发送单元。
其中，明文业务请求接收单元用于接收客户端发送的明文业务请求报文，所述明文业务请求报文中携带明文的第三业务请求数据。
业务请求数据获取单元用于从所述明文业务请求报文中获取第三业务请求数据。
第三业务应答生成单元用于根据所述第三业务请求数据生成第三业务应答数据。
明文业务应答发送单元用于向所述客户端发送明文业务应答报文，所述明文业务应答报文中携带明文的第三业务应答数据。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片2。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog2。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被 实现为存储器的控制逻辑的一部分。
本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。该计算机软件产品可以包括若干指令用以使得一台计算机设备(可以是个人计算机，服务端，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。该计算机软件产品可以存储在内存中，内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括短暂电脑可读媒体(transitory media)，如调制的数据信号和载波。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务端计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。

Claims (14)

  1. 一种网络安全通信方法，其特征在于，包括：
    向服务端发送握手请求报文，所述握手请求报文中携带使用第一公钥加密的第一随机数和使用所述第一公钥加密的业务请求数据，以使所述服务端根据所述第一公钥对应的第一私钥将所述握手请求报文解密得到第一随机数及第一业务请求数据、并根据所述第一业务请求数据生成第一业务应答数据；
    接收服务端反馈的握手应答报文，所述握手应答报文中携带使用所述第一随机数加密的第一业务应答数据和使用所述第一随机数加密的第二随机数；
    通过所述第一随机数对所述握手应答报文进行解密，得到第一业务应答数据和第二随机数；
    通过所述第一随机数和第二随机数计算与服务端之间的会话所使用的会话密钥。
  2. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    向服务端发送密文业务请求报文，所述密文业务请求报文中携带所述会话密钥的标识和使用所述会话密钥加密的第二业务请求数据，以使所述服务端根据该会话密钥的标识查找对应的会话密钥，并使用所述找到的会话密钥对所述密文业务请求报文进行解密，得到第二业务请求数据；
    接收服务端反馈的密文业务应答报文，所述密文业务应答报文中携带使用所述会话密钥加密的第二业务应答数据，所述第二业务应答数据是由所述服务端根据所述第二业务请求数据生成的。
  3. 根据权利要求2所述的方法，其特征在于，所述方法还包括：
    向服务端发送明文业务请求报文，所述明文业务请求报文中携带明文的第三业务请求数据，以使所述服务端从所述明文业务请求报文中获取明文的第三业务请求数据；
    接收服务端反馈的明文业务应答报文，所述明文业务应答报文中携带明文的第三业务应答数据，所述第三业务应答数据是由所述服务端根据所述第三业务请求数据生成的。
  4. 根据权利要求2所述的方法，其特征在于，所述方法还包括：
    接收服务端反馈的会话密钥过期的通知；
    返回继续执行向服务端发送握手请求报文的步骤。
  5. 一种网络安全通信方法，其特征在于，包括：
    接收客户端发送的握手请求报文，所述握手请求报文中携带使用第一公钥加密的第一随机数和使用所述第一公钥加密的业务请求数据；
    使用所述第一公钥对应的第一私钥对所述的握手请求报文进行解密，得到第一随机数和 业务请求数据；
    根据所述第一业务请求数据生成第一业务应答数据；
    向所述客户端发送握手应答报文，所述握手应答报文中携带使用第一随机数加密的第一业务应答数据和使用所述第一随机数加密的第二随机数，以使所述客户端通过所述第一随机数对所述握手应答报文解密，得到业务应答数据和第二随机数，并以第一随机数和第二随机数基于第一密钥算法计算出会话所使用的会话密钥；
    根据所述第一随机数和第二随机数使用所述第一密钥算法计算出会话所使用的会话密钥。
  6. 根据权利要求5所述的方法，其特征在于，所述方法还包括：
    接收客户端发送的密文业务请求报文，所述密文业务请求报文中携带所述会话密钥的标识和使用所述会话密钥加密的第二业务请求数据；
    通过所述会话密钥的标识查找对应的会话密钥；
    使用所述找到的会话密钥对所述密文业务请求报文进行解密，得到第二业务请求数据；
    根据所述第二业务请求数据生成第二业务应答数据；
    向所述客户端发送密文业务应答报文，所述密文业务应答报文中携带使用所述会话密钥加密的第二业务应答数据。
  7. 根据权利要求6所述的方法，其特征在于，所述方法还包括：
    接收客户端发送的明文业务请求报文，所述明文业务请求报文中携带明文的第三业务请求数据；
    从所述明文业务请求报文中获取第三业务请求数据；
    根据所述第三业务请求数据生成第三业务应答数据；
    向所述客户端发送明文业务应答报文，所述明文业务应答报文中携带明文的第三业务应答数据。
  8. 根据权利要求7所述的方法，其特征在于，所述方法还包括：
    接收客户端发送的业务请求报文；
    判断所述业务请求报文是密文业务请求报文还是明文业务请求报文，
    由该业务请求报文是密文业务请求报文还是明文业务请求报文的判断结果生成加密标识；
    建立所述业务请求报文的标识与该业务请求报文的加密标识的第一映射关系；
    在针对客户端发送的业务请求报文时，通过该业务请求报文的标识与所述第一映射关系，查找对应的加密标识；
    如果该加密标识表示该业务请求报文是密文业务请求报文，则触发执行向所述客户端发送密文业务应答报文的步骤；
    如果该加密标识表示该业务请求报文是明文业务请求报文，则触发执行向所述客户端发送明文业务应答报文的步骤。
  9. 一种网络安全通信装置，其特征在于，包括：
    握手请求发送单元，用于向服务端发送向服务端发送握手请求报文，所述握手请求报文中携带使用第一公钥加密的第一随机数和使用所述第一公钥加密的业务请求数据，以使所述服务端根据所述第一公钥对应的第一私钥将所述握手请求报文解密得到第一随机数及第一业务请求数据、并根据所述第一业务请求数据生成第一业务应答数据；
    握手应答接收单元，用于接收服务端反馈的握手应答报文，所述握手应答报文中携带使用所述第一随机数加密的第一业务应答数据和使用所述第一随机数加密的第二随机数；
    握手应答解密单元，用于通过所述第一随机数对所述握手应答报文进行解密，得到第一业务应答数据和第二随机数；
    会话密钥计算单元，用于通过所述第一随机数和第二随机数计算与服务端之间的会话所使用的会话密钥。
  10. 根据权利要求9所述的装置，其特征在于，所述装置还包括：
    密文业务请求发送单元，用于向服务端发送密文业务请求报文，所述密文业务请求报文中携带所述会话密钥的标识和使用所述会话密钥加密的第二业务请求数据，以使所述服务端根据该会话密钥的标识查找对应的会话密钥，并使用所述找到的会话密钥对所述密文业务请求报文进行解密，得到第二业务请求数据；
    密文业务应答接收单元，用于接收服务端反馈的密文业务应答报文，所述密文业务应答报文中携带使用所述会话密钥加密的第二业务应答数据，所述第二业务应答数据是由所述服务端根据所述第二业务请求数据生成的。
  11. 根据权利要求10所述的装置，其特征在于，所述装置还包括：
    明文业务请求发送单元，用于向服务端发送明文业务请求报文，所述明文业务请求报文中携带明文的第三业务请求数据，以使所述服务端从所述明文业务请求报文中获取明文的第三业务请求数据；
    明文业务应答接收单元，用于接收服务端反馈的明文业务应答报文，所述明文业务应答报文中携带明文的第三业务应答数据，所述第三业务应答数据是由所述服务端根据所述第三业务请求数据生成的。
  12. 一种网络安全通信装置，其特征在于，包括：
    握手请求接收单元，用于接收客户端发送的握手请求报文，所述握手请求报文中携带使用第一公钥加密的第一随机数和使用所述第一公钥加密的业务请求数据；
    握手请求解密单元，用于使用所述第一公钥对应的第一私钥对所述的握手请求报文进行解密，得到第一随机数和业务请求数据；
    第一业务应答生成单元，用于根据所述第一业务请求数据生成第一业务应答数据；
    握手应答发送单元，用于向所述客户端发送握手应答报文，所述握手应答报文中携带使用第一随机数加密的第一业务应答数据和使用所述第一随机数加密的第二随机数，以使所述客户端通过所述第一随机数对所述握手应答报文解密，得到业务应答数据和第二随机数，并以第一随机数和第二随机数基于第一密钥算法计算出会话所使用的会话密钥；
    会话密钥计算单元，用于根据所述第一随机数和第二随机数使用所述第一密钥算法计算出会话所使用的会话密钥。
  13. 根据权利要求12所述的装置，其特征在于，所述装置还包括：
    密文业务请求接收单元，用于接收客户端发送的密文业务请求报文，所述密文业务请求报文中携带所述会话密钥的标识和使用所述会话密钥加密的第二业务请求数据；
    会话密钥查找单元，用于通过所述会话密钥的标识查找对应的会话密钥；
    业务请求解密单元，用于使用所述找到的会话密钥对所述密文业务请求报文进行解密，得到第二业务请求数据；
    第二业务应答生成单元，用于根据所述第二业务请求数据生成第二业务应答数据；
    密文业务应答发送单元，用于向所述客户端发送密文业务应答报文，所述密文业务应答报文中携带使用所述会话密钥加密的第二业务应答数据。
  14. 根据权利要求13所述的装置，其特征在于，所述装置还包括：
    明文业务请求接收单元，用于接收客户端发送的明文业务请求报文，所述明文业务请求报文中携带明文的第三业务请求数据；
    业务请求数据获取单元，用于从所述明文业务请求报文中获取第三业务请求数据；
    第三业务应答生成单元，用于根据所述第三业务请求数据生成第三业务应答数据；
    明文业务应答发送单元，用于向所述客户端发送明文业务应答报文，所述明文业务应答报文中携带明文的第三业务应答数据。
PCT/CN2015/092506 2014-10-27 2015-10-22 一种网络安全通信方法及通信装置 WO2016066039A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2017521578A JP6641363B2 (ja) 2014-10-27 2015-10-22 安全なネットワーク通信用の方法及び機器
EP15854125.0A EP3214796B1 (en) 2014-10-27 2015-10-22 Network secure communication method and communication device
US15/499,860 US10419409B2 (en) 2014-10-27 2017-04-27 Method and apparatus for secure network communications

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410584748.0 2014-10-27
CN201410584748.0A CN105635039B (zh) 2014-10-27 2014-10-27 一种网络安全通信方法及通信装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/499,860 Continuation US10419409B2 (en) 2014-10-27 2017-04-27 Method and apparatus for secure network communications

Publications (1)

Publication Number Publication Date
WO2016066039A1 true WO2016066039A1 (zh) 2016-05-06

Family

ID=55856592

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/092506 WO2016066039A1 (zh) 2014-10-27 2015-10-22 一种网络安全通信方法及通信装置

Country Status (5)

Country Link
US (1) US10419409B2 (zh)
EP (1) EP3214796B1 (zh)
JP (1) JP6641363B2 (zh)
CN (1) CN105635039B (zh)
WO (1) WO2016066039A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108809643A (zh) * 2018-07-11 2018-11-13 飞天诚信科技股份有限公司 一种设备与云端协商密钥的方法、系统及设备
CN114553498A (zh) * 2022-01-28 2022-05-27 郑州信大捷安信息技术股份有限公司 一种适用于芯片的线路保护方法和系统
CN115250450A (zh) * 2021-04-28 2022-10-28 大唐移动通信设备有限公司 一种获取组通信密钥的方法及设备
US12125054B2 (en) 2019-09-25 2024-10-22 Valideck International Corporation System, devices, and methods for acquiring and verifying online information

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106210031A (zh) * 2016-07-06 2016-12-07 北京金山安全软件有限公司 业务执行方法、装置、客户端及服务器
US10433174B2 (en) * 2017-03-17 2019-10-01 Qualcomm Incorporated Network access privacy
CN109802834A (zh) * 2017-11-16 2019-05-24 航天信息股份有限公司 一种对业务层数据进行加密、解密的方法及系统
CN109936529B (zh) * 2017-12-15 2021-12-31 华为技术有限公司 一种安全通信的方法、装置和系统
CN111130750B (zh) * 2018-10-30 2023-09-12 长城汽车股份有限公司 车辆can安全通信方法及系统
CN110719265B (zh) * 2019-09-23 2021-08-17 腾讯科技（深圳）有限公司 一种实现网络安全通信的方法、装置及设备
CN110933672B (zh) * 2019-11-29 2021-11-30 华为技术有限公司 一种密钥协商方法及电子设备
EP3944554A1 (en) * 2020-07-21 2022-01-26 ADVA Optical Networking SE Rollover of encryption keys in a packet-compatible network
CN112182644B (zh) * 2020-09-11 2023-05-12 华控清交信息科技(北京)有限公司 一种数据处理方法、装置和电子设备
CN112333199B (zh) * 2020-11-17 2023-04-21 珠海大横琴科技发展有限公司 一种数据处理的方法和装置
CN112492580B (zh) * 2020-11-25 2023-08-18 北京小米移动软件有限公司 信息处理方法及装置、通信设备及存储介质
CN112653698B (zh) * 2020-12-22 2023-02-28 中国农业银行股份有限公司 一种通信方法及装置
CN112751858B (zh) * 2020-12-30 2023-04-07 恒安嘉新（北京）科技股份公司 数据加密通信终端方法、装置、终端、服务器及存储介质
CN112910878A (zh) * 2021-01-28 2021-06-04 武汉市博畅软件开发有限公司 一种基于串口通信的数据传输方法及系统
CN112765638B (zh) * 2021-01-28 2023-02-24 武汉市博畅软件开发有限公司 一种数据加密通信方法及系统
CN113037720B (zh) * 2021-02-26 2022-07-08 江铃汽车股份有限公司 车辆网络访问方法、装置、可读存储介质及网关
CN113660328B (zh) * 2021-08-13 2024-02-06 京东科技信息技术有限公司 通信连接的建立方法及装置、存储介质及电子设备
CN114553553A (zh) * 2022-02-24 2022-05-27 蓝想大数据科技(上海)有限公司 一种混合加密通讯方法
CN117119449B (zh) * 2023-10-20 2024-01-19 长江量子(武汉)科技有限公司 车云安全通信方法及系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030079143A1 (en) * 2001-10-22 2003-04-24 Dean Mikel One pass security
CN101052033A (zh) * 2006-04-05 2007-10-10 华为技术有限公司 基于ttp的认证与密钥协商方法及其装置
CN100358282C (zh) * 2005-03-23 2007-12-26 西安电子科技大学 Wapi认证机制中的密钥协商方法
US20080292105A1 (en) * 2007-05-22 2008-11-27 Chieh-Yih Wan Lightweight key distribution and management method for sensor networks
US20080294891A1 (en) * 2006-03-10 2008-11-27 Motorola, Inc. Method for Authenticating a Mobile Node in a Communication Network
US20130297939A1 (en) * 2009-02-17 2013-11-07 Alcatel-Lucent Usa, Inc. Identity based authenticated key agreement protocol
US8607315B2 (en) * 2006-04-24 2013-12-10 Ruckus Wireless, Inc. Dynamic authentication in secured wireless networks

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5179591A (en) * 1991-10-16 1993-01-12 Motorola, Inc. Method for algorithm independent cryptographic key management
JPH11331148A (ja) * 1998-05-18 1999-11-30 Nec Eng Ltd 暗号化通信方式
JP2002344438A (ja) * 2001-05-14 2002-11-29 Nippon Telegr & Teleph Corp <Ntt> 鍵共有システム及び装置並びにプログラム
DE10137152A1 (de) * 2001-07-30 2003-02-27 Scm Microsystems Gmbh Verfahren zur Übertragung vertraulicher Daten
JP4395832B2 (ja) * 2003-11-06 2010-01-13 セイコーエプソン株式会社 プリンタ、印刷クライアント及び印刷システム
JP4770227B2 (ja) * 2005-03-28 2011-09-14 株式会社日立製作所 Ｓｉｐメッセージの暗号化方法，および暗号化ｓｉｐ通信システム
JP4733497B2 (ja) * 2005-10-25 2011-07-27 日本放送協会 コンテンツ配信装置、ライセンス発行装置、課金装置およびコンテンツ視聴端末、ならびに、ライセンス要求生成プログラム、ライセンス生成プログラムおよび課金プログラム
CN100450305C (zh) * 2006-01-07 2009-01-07 华为技术有限公司 一种基于通用鉴权框架的安全业务通信方法
CN101001144B (zh) * 2006-01-13 2010-05-12 华为技术有限公司 一种实体认证中心实现认证的方法
JP5328142B2 (ja) * 2007-12-05 2013-10-30 キヤノン株式会社 通信装置、通信装置の制御方法、コンピュータプログラム
EP2211497A1 (fr) * 2009-01-26 2010-07-28 Gemalto SA Procédé d'établissement de communication sécurisée sans partage d'information préalable
CN101754050B (zh) * 2010-02-02 2012-05-23 中国电子科技集团公司第三十研究所 集成化的高时效呼叫连接控制方法
CN102082790B (zh) * 2010-12-27 2014-03-05 北京握奇数据系统有限公司 一种数字签名的加/解密方法及装置
JP5524122B2 (ja) * 2011-04-06 2014-06-18 京セラドキュメントソリューションズ株式会社 情報処理装置及び情報処理方法
JP5845393B2 (ja) * 2011-04-28 2016-01-20 パナソニックＩｐマネジメント株式会社 暗号通信装置および暗号通信システム

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030079143A1 (en) * 2001-10-22 2003-04-24 Dean Mikel One pass security
CN100358282C (zh) * 2005-03-23 2007-12-26 西安电子科技大学 Wapi认证机制中的密钥协商方法
US20080294891A1 (en) * 2006-03-10 2008-11-27 Motorola, Inc. Method for Authenticating a Mobile Node in a Communication Network
CN101052033A (zh) * 2006-04-05 2007-10-10 华为技术有限公司 基于ttp的认证与密钥协商方法及其装置
US8607315B2 (en) * 2006-04-24 2013-12-10 Ruckus Wireless, Inc. Dynamic authentication in secured wireless networks
US20080292105A1 (en) * 2007-05-22 2008-11-27 Chieh-Yih Wan Lightweight key distribution and management method for sensor networks
US20130297939A1 (en) * 2009-02-17 2013-11-07 Alcatel-Lucent Usa, Inc. Identity based authenticated key agreement protocol

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108809643A (zh) * 2018-07-11 2018-11-13 飞天诚信科技股份有限公司 一种设备与云端协商密钥的方法、系统及设备
US12125054B2 (en) 2019-09-25 2024-10-22 Valideck International Corporation System, devices, and methods for acquiring and verifying online information
CN115250450A (zh) * 2021-04-28 2022-10-28 大唐移动通信设备有限公司 一种获取组通信密钥的方法及设备
CN114553498A (zh) * 2022-01-28 2022-05-27 郑州信大捷安信息技术股份有限公司 一种适用于芯片的线路保护方法和系统
CN114553498B (zh) * 2022-01-28 2023-06-23 郑州信大捷安信息技术股份有限公司 一种适用于芯片的线路保护方法和系统

Also Published As

Publication number Publication date
EP3214796A4 (en) 2017-09-06
JP2017533651A (ja) 2017-11-09
EP3214796A1 (en) 2017-09-06
EP3214796B1 (en) 2018-11-28
US20170237718A1 (en) 2017-08-17
CN105635039A (zh) 2016-06-01
CN105635039B (zh) 2019-01-04
US10419409B2 (en) 2019-09-17
JP6641363B2 (ja) 2020-02-05

Similar Documents

Publication Publication Date Title
WO2016066039A1 (zh) 一种网络安全通信方法及通信装置
EP3318037B1 (en) Content security at service layer
CN106470104B (zh) 用于生成共享密钥的方法、装置、终端设备及系统
WO2018014723A1 (zh) 密钥管理方法、装置、设备及系统
US9722795B2 (en) Digitally signing JSON messages
US9923719B2 (en) Location aware cryptography
CN106487765B (zh) 授权访问方法以及使用该方法的设备
JP6731202B2 (ja) アイデンティティ検証方法及びシステム並びにインテリジェントウェアラブルデバイス
TWI642288B (zh) Instant communication method and system
WO2019109852A1 (zh) 一种数据传输方法及系统
WO2021179748A1 (zh) 扫码支付、信息发送及生成收款码的方法、装置和设备
WO2016061819A1 (zh) 一种访问资源的方法及装置
JP2019514314A (ja) 暗号化メッセージを送受信するために動的公開鍵インフラストラクチャを用いる方法、システム、及び媒体
US20230163946A1 (en) Homomorphic encryption offload for lightweight devices
WO2023231817A1 (zh) 数据处理方法、装置、计算机设备及存储介质
US20150350375A1 (en) Information Processing Method, Trusted Server, and Cloud Server
WO2016107458A1 (zh) 恢复会话的方法和服务器、生成会话凭证的方法和装置
JP5755557B2 (ja) 時限暗号システム、時限暗号方法、装置、プログラム
JP2019519176A (ja) 鍵管理システム及び方法
CN106549754A (zh) 管理密钥的方法和装置
CN107229874B (zh) 一种实现VR-Key的方法、装置和服务器
JP6527576B2 (ja) ローカル情報を取得するための方法、機器、及びシステム
CN113163399A (zh) 一种终端与服务器的通信方法和装置
US8312277B2 (en) Method and system for secure communication between computers
WO2018054144A1 (zh) 对称密钥动态生成方法、装置、设备及系统

Legal Events

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

Ref document number: 15854125

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017521578

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2015854125

Country of ref document: EP