WO2019114703A1 - 一种安全通信的方法、装置和系统 - Google Patents

一种安全通信的方法、装置和系统 Download PDF

Info

Publication number
WO2019114703A1
WO2019114703A1 PCT/CN2018/120338 CN2018120338W WO2019114703A1 WO 2019114703 A1 WO2019114703 A1 WO 2019114703A1 CN 2018120338 W CN2018120338 W CN 2018120338W WO 2019114703 A1 WO2019114703 A1 WO 2019114703A1
Authority
WO
WIPO (PCT)
Prior art keywords
session ticket
server
client
identifier
session
Prior art date
Application number
PCT/CN2018/120338
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 华为技术有限公司
Publication of WO2019114703A1 publication Critical patent/WO2019114703A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the present application relates to the field of communications, and in particular, to a method, apparatus, and system for secure communication between devices.
  • Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are security protocols for Internet communications developed by the Internet Engineering Task Force (IETF).
  • the TLS or DTLS protocol is roughly divided into two phases, the handshake phase and the data transmission phase.
  • the client and server of the TLS or DTLS protocol negotiate a set of encryption algorithms and integrity verification algorithms for protecting data transmissions during the handshake phase, as well as the keys used by each algorithm.
  • the data is divided into a series of protected records for transmission.
  • the client and the server need multiple round-trip negotiation during the handshake phase, and the Round-Trip Time (RTT) is large; and the client and the server must perform complex and cumbersome key calculations internally.
  • RTT Round-Trip Time
  • the present application proposes a method, device and system for secure communication based on TLS or DTLS protocol, which can not only reduce RTT but also reduce performance consumption of the device.
  • the server and the client need to perform multiple negotiation interactions, and a large number of calculations can obtain information related to secure communication such as the master key, so as to avoid further attacks in the subsequent handshake process.
  • the server For the second interaction and a large number of calculations, the server generates a session ticket to record information related to secure communication such as a master key negotiated successfully with the client in the handshake process, and sends the identifier of the session ticket to the client for subsequent handshake. Used in the process.
  • the client When the client needs to perform the TLS or DTLS handshake with the server again, the client carries the identifier of the session ticket in the handshake request (that is, the ClientHello message), and the server obtains the corresponding session ticket according to the identifier of the session ticket, and reuses the previous TLS or The successful communication-related information has been negotiated in the DTLS handshake process, and the handshake process is completed with the client.
  • the secure communication method can quickly complete the handshake process between the client and the server, and establish a data transmission channel based on TLS or DTLS protection, and reduce the performance consumption of the TLS or DTLS handshake process to the client and the server.
  • the identifier of the session ticket since the identifier of the session ticket only needs to occupy a small number of bytes, the identifier of the session ticket stored by the client does not occupy too much storage space of the client, and the identifier of the session ticket is also transmitted between the client and the server. No communication and transmission resources are wasted.
  • the server determines whether to send the identifier of the session ticket to the client or the session ticket to the client according to the capability of the client. When the client capability is low, the server sends the identifier of the session ticket to the client to save the storage consumption of the client.
  • the server may store the session ticket in the built-in or external storage component of the server. In another possible embodiment, the server may also register the identifier of the session ticket and the corresponding session ticket in the session ticket storage device.
  • the server obtains the corresponding session ticket from the session ticket registration device by using the identifier of the session ticket, and according to the security of the last handshake negotiation recorded in the session ticket. Communication-related information and the client complete the handshake process.
  • the registration of the session ticket may adopt a centralized registration mode, that is, the session ticket storage device is one or several centralized deployment servers, or may be a distributed registration mode, that is, the session ticket storage device is a plurality of distributed deployment devices.
  • the function of the session ticket depositing device can be assumed by the client device with higher performance configuration.
  • the identifier of the session ticket sent by the server to the client is the encrypted ciphertext, and the encryption key is only known by the server.
  • the identifier of the session ticket carried in the handshake request sent by the client to the server is also the identifier of the session ticket encrypted by the server.
  • the session ticket sent by the server to the session ticket registration device is the encrypted ciphertext, and the encryption key is only known by the server.
  • the session ticket sent by the session ticket registration device to the server is also the session ticket encrypted by the server.
  • the transmission channel between the server and the session ticket storage device is a secure channel
  • the message or data transmitted in the channel is the ciphertext encrypted by the key corresponding to the security channel, and the security is performed.
  • the key corresponding to the channel is the key negotiated by the server and the session ticket storage device during the establishment of the secure channel.
  • the method for secure communication proposed by the present application involves at least two devices, a server and a client, and optionally, a session ticket storage device. Accordingly, the present application also provides an apparatus for implementing a server function, an apparatus for implementing a client function, and a session ticket depositing apparatus to implement the secure communication method as described above.
  • the present application also provides a secure communication system comprising the apparatus for implementing server functions as described above and means for implementing client functions, and optionally, a session ticket depositing device.
  • the present application also provides a computer readable storage medium having stored therein instructions that, when run on a computer, cause the computer to perform the method of secure communication described above.
  • the present application provides a computer program product comprising instructions that, when run on a computer, cause the computer to perform the method of secure communication described above.
  • FIG. 1 is a flow chart of a TLS handshake defined by an IETF in the prior art
  • FIG. 2 is a flowchart of establishing a session between a client and a server based on a TLS protocol according to an embodiment of the present invention
  • FIG. 3 is a flowchart of a method for a client and a server to re-use a last session ticket re-establishment session according to an embodiment of the present invention
  • FIG. 4 is a schematic diagram of a computer device according to an embodiment of the present invention.
  • FIG. 5 is a schematic diagram of functional modules of an apparatus for implementing a client function according to an embodiment of the present disclosure
  • FIG. 6 is a schematic diagram of functional modules of an apparatus for implementing a server function according to an embodiment of the present invention.
  • FIG. 7 is a schematic diagram of functional modules of a session ticket depositing apparatus according to an embodiment of the present invention.
  • TLS and DTLS are security protocols developed and published by the IETF standards organization.
  • DTLS is a TLS-based supplement and extension.
  • the protocol flow of TLS and DTLS in the handshake phase is basically the same.
  • the TLS and DTLS protocols are mainly applied to client/server architecture (Client/Server, CS) or CS architecture variants.
  • the two sides of the communication are the client and the server.
  • Figure 1 is a flow chart of the TLS protocol defined in the Request for Comments (RFC) 5246 issued by the IETF.
  • the TLS protocol process includes a handshake phase or a handshake process from a ClientHello message to a Finished message, and a data transfer phase of Application Data.
  • the client and the server should communicate securely based on TLS or DTLS.
  • the handshake process is triggered by the ClientHello message sent by the client to the server.
  • the ClientHello message sent by the client to the server is also called a handshake request.
  • the handshake phase of the algorithm and key negotiation between the client client and the server server has experienced multiple rounds of interaction from the ClientHello message to the Finished message.
  • the round trip delay RTT is large, and the client and the server are internal. Complex key calculations and derivations are also required, and power, storage, and computing resources are expensive.
  • the handshake process of DTLS can be found in RFC 6347, which is basically the same as TLS, and will not be described here. Therefore, in the prior art, since the client and the server establish a session and a connection based on TLS or DTLS each time, a complex handshake process is performed, and the performance of the client and the server device is very severe, and the performance is limited. Devices (such as power or storage or computing-capable devices) cannot deploy or support TLS or DTLS protocols. Only other simpler secure communication schemes or protocols can be used, and transport layer communication security is not guaranteed.
  • the present application proposes a method for secure communication, so that when a session or a connection is established, the client and the server can reuse the information related to the secure communication that has been successfully negotiated in the previous TLS or DTLS handshake process, and quickly establish the client and the server. Between TLS or DTLS-protected data transmission channels, the performance of the TLS or DTLS handshake process is reduced for both client and server.
  • the client and the server are the functional entity names in the TLS and DTLS handshake processes, and do not limit the device types that implement the client and server functions.
  • the device that implements the server function is the server.
  • the device that implements the client function is the terminal; for example, the device that implements the server function is the terminal, and the device that implements the client function is the server; and possibly, the device that implements the server function and the device that implements the client function are terminals. .
  • FIG. 2 is a flowchart showing a session establishment process between a client and a server based on the TLS protocol according to an embodiment of the present invention.
  • the client and the server perform a complete handshake process defined by the TLS protocol, and negotiate the information required for secure communication in this session or this connection.
  • the handshake process of the TLS protocol is described in detail in RFC 5246 and is not described in this document.
  • the server generates a session ticket, and the information recorded in the session ticket may be slightly different in different actual deployments, but at least should include a master key for successfully negotiating between the client and the server, and the master key is used for Enables the client and the server to derive the integrity protection key and encryption key by means of the random number exchanged by ClientHello/ServerHello.
  • the session ticket may also include any one or more of the following information: a protocol version number, a Cipher Suite, a compression method, a client identifier, etc., wherein the key set includes an encryption algorithm, an integrity protection algorithm, and an authentication algorithm.
  • One or more kinds of algorithm information such as a key exchange algorithm and a key derivation algorithm.
  • the session ticket further includes information for verifying the validity of the session ticket, such as the validity time of the session ticket.
  • the server also assigns a corresponding identifier to each session ticket for uniquely indicating a session ticket.
  • the format of the identifier of the session ticket is not limited in this application, and may be a character string or any other form that can uniquely identify the session ticket. The number of bytes of the session ticket identifier is much smaller than the session ticket.
  • the server sends the identifier of the generated session ticket to the client.
  • the message carrying the identity of the session ticket may be the New session ticket message shown in FIG. 2, or may be other message names.
  • the server can also encrypt the identifier of the session ticket.
  • the encrypted ciphertext is sent to the client, and the encrypted key is known only to the server itself. Only the server can decrypt the encrypted ciphertext.
  • the client After receiving the 205 message, the client saves the identifier of the session ticket or the identifier of the session ticket encrypted by the server.
  • the 205 message sent by the server to the client can also be negotiated according to steps 201-203.
  • the successful encryption and integrity algorithm and the key are protected.
  • the client receives the 205 message, decrypts and verifies the successful encryption and integrity algorithm and the key pair 205 message in the steps 201-203, and obtains 205 message by parsing.
  • the server Since the storage of the session ticket needs to consume a large amount of storage, when the storage function of the server is limited, and the storage capacity of the server itself cannot meet the requirement of storing the session ticket, in order to reduce the storage consumption, the server may also be optional.
  • the identification of the session ticket and the corresponding session ticket is selected to be stored in an external session ticket depositor, as shown in step 206.
  • the session ticket carried by the server in the 206 message may be an encrypted session ticket, and the encrypted key is only known by the server itself.
  • the data transmission channel between the server and the session ticket storage device may also be an encrypted transmission channel.
  • the server and the session ticket registration device have completed the negotiation of the session channel key, and the server will 206.
  • the message is encrypted according to the key negotiated by both parties and transmitted.
  • the session ticket depositing device parses the identifier of the encrypted or unencrypted session ticket and the corresponding session ticket in the 206 message.
  • the server in order to be able to retrieve the session ticket subsequently, the server needs to record the address or identifier of the session ticket registration device; if the session ticket registration device is centralized For a single device, the server only needs to record the address or identifier of the session ticket registration device; if the session ticket registration device is a distributed plurality of devices, the server needs to record the identifier of the session ticket, and the session ticket corresponding to the identifier is registered.
  • the address or identification of the session ticket storage device needs to be deployed in a trusted domain or a secure domain to ensure the security of the registered session ticket.
  • the client and the server use the algorithm and key negotiated in the handshake process for secure data transmission.
  • the server can send the session ticket or the encrypted session ticket to the client, and the client saves the session ticket, and the server does not need to generate the identifier of the session ticket, nor does it need to be on the server or in the server. Saving the identifier of the session ticket and the session ticket in the session ticket storage device;
  • the server When the storage capacity of the client device is weak, the server performs the method flow shown in FIG. 2;
  • the server When the storage capacity of the client device is so weak that it is insufficient to hold the identity of the session ticket, the server no longer performs the steps as shown in 204, 205, and 206.
  • the storage capacity described above is “stronger”, “weaker” and “very weak”. It is only a qualitative description. This application does not define and define quantitatively. The judgment conditions can be set according to the specific conditions of deployment.
  • the client may carry the device type in the 201 message to characterize its storage capability, and the server determines whether to execute the method flow shown in FIG. 2 according to the device type, or is adjusted as described above. Method flow.
  • the client may further carry the indication information in the message 201, indicating that the client supports the completion of the handshake process according to the session ticket and the server, and the server determines that the message includes the indication information, and the device type meets the preset condition, and the execution is performed.
  • the session ticket storage device when the session ticket storage device is a device other than the server device, the session ticket storage device may be one or several storage devices that are deployed in a centralized manner, or may be other client devices with strong storage capabilities.
  • the client includes the device type in the handshake request sent to the server.
  • the server After the server authenticates, the client identifies the identifier or address of the client to the session ticket storage device list.
  • the client is selected from the list of session ticket registers.
  • the selected rules are not limited in this application, such as random or round robin, to ensure that the session tickets to be stored by the server are evenly distributed on multiple clients that can be used as session ticket storage devices, and will not be caused to a certain client.
  • the server can also select the client as the session ticket storage device according to the rules adjacent to the IP address segment, and ensure that the IP address of the client as the session ticket registration device and the IP address of the client currently shaking hands with the server It is adjacent.
  • the client may further carry an indication of whether the session ticket registration is supported in the handshake request message, and the server determines, according to the indication, whether to record the client to the session ticket registration device list.
  • the present application does not limit the timing at which the server performs the steps 204-206. As long as the server and the client negotiate the information to be recorded in the session ticket such as the master key in the handshake process, the server does not have to wait for the handshake process. Completely, you can perform steps 204, 205, and 206 at any time. Steps 204-206 may occur before step 203. After the handshake process ends, the server may not send 205 and 206 messages immediately. The server may also perform steps 207. The 205 and 206 messages are sent after the application data transmission or at the same time. In addition, the application does not limit the order of the 205 and 206 messages, that is, the server may also send 206 a message to the session ticket registration first, and then send a message 205 to the client.
  • FIG. 2 shows a method flow for the client and the server to re-use the last session ticket re-establishment session.
  • the client sends a ClientHello message to the server, where the message carries the identifier of the session ticket sent by the server to the client or the identifier of the session ticket encrypted by the server.
  • the server parses the 301 message to obtain the identity of the session ticket. If the 301 message carries the identifier of the session ticket encrypted by the server, the server needs to decrypt using the key known only by the server (in step 205 of FIG. 2) to obtain the identifier of the session ticket.
  • the server obtains a corresponding session ticket according to the identifier of the session ticket. If the session ticket is saved in the session ticket depositing device, the server sends a 302 message to the session ticket hosting device carrying the identity of the session ticket. As described in the above 206, the transmission channel between the server and the session ticket registration may be encrypted, and the 302 and 303 messages need to be encrypted and then sent, and will not be described later.
  • the session ticket registration device determines, according to the identifier of the session ticket received in the 302 message, the session ticket corresponding to the identifier of the session ticket or the session ticket encrypted by the server (as described in 206 message).
  • the session ticket depositing device sends the session ticket or the session ticket encrypted by the server to the server.
  • the server parses 303 the message to obtain the session ticket. If the 303 message carries the server-encrypted session ticket, the server needs to decrypt the key to obtain the session ticket.
  • the server judges that the session ticket is valid, and completes the handshake process with the client directly according to the information related to the security communication successfully negotiated in the previous session recorded in the session ticket. Because the master key, the key set and other information are recorded in the session ticket, the steps and processes of re-negotiating the key and the algorithm between the server and the client are eliminated, thereby reducing the performance consumption of the client and the server in the handshake process, and speeding up The RTT of the handshake process. If the server determines that the session ticket has expired, it performs a complete handshake process with the client to renegotiate the algorithm and key. It should be noted that there are many methods for the server to determine whether the session ticket is valid, and the method is not limited. For example, when the server generates the session ticket in step 204, the session ticket can be recorded in the session ticket, according to the session ticket. The valid time and current time determine whether the session ticket is valid.
  • the server can also update or generate a new session ticket.
  • the server generates an identifier of a new session ticket and a new session ticket; or the server uses the identifier of the old session ticket to update only the session ticket.
  • step 307 If the server generates the identifier of the new session ticket in step 306, the server sends the identifier of the new session ticket to the client. For details, refer to the 205 message, which is not described here.
  • the client receives the identity of the new session ticket, deletes the identity of the old session ticket, and saves the identity of the new session ticket.
  • the server If the server generates the identifier of the new session ticket and the new session ticket in step 306, the server sends a new session ticket, an identifier of the new session ticket, and an identifier of the old session ticket to the session ticket registration device.
  • the session ticket depositing device receives the 308 message, deletes the session ticket corresponding to the identifier of the old session ticket, and records the identifier of the new session ticket and the corresponding session ticket.
  • the server If the server inherits the identifier of the old session ticket in step 306 and only updates the corresponding session ticket, the server sends the identifier of the new session ticket and the old session ticket to the session ticket registration device, and the session ticket registration device receives Up to 308, the session ticket corresponding to the identifier of the old session ticket is updated to a new session ticket.
  • the server may perform encryption processing on the new session ticket included in the 308 step message to ensure the confidentiality of the session ticket; in addition, the 308 message itself may also be transmitted in the encrypted channel.
  • the session ticket registration device fails to find the corresponding session ticket according to the identifier of the session ticket after receiving the 302 message, it indicates in the 303 message that the server does not have a corresponding session ticket record. In this case, the server and the client cannot reuse the information related to the secure communication negotiated by the previous session, and a complete handshake process needs to be performed.
  • the method for secure communication proposed by the present application optimizes the TLS or DTLS protocol, and saves information related to successful communication between the server and the client.
  • the identifiers of the session ticket and the session ticket are stored separately.
  • the session ticket with large memory consumption reduces the consumption of performance of the client and server storage, power, computing resources, etc., and reduces the RTT of the client and server handshake process.
  • the client or server or session ticket registration proposed in this application can be implemented by the computer device in FIG.
  • FIG. 4 is a schematic diagram of a computer device according to an embodiment of the present invention.
  • Computer device 400 includes at least one processor 401, a communication bus 402, a memory 403, and at least one communication interface 404.
  • the processor 401 can be a general purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more for controlling the execution of the program of the present application. integrated circuit.
  • CPU general purpose central processing unit
  • ASIC application-specific integrated circuit
  • Communication bus 402 can include a path for communicating information between the components described above.
  • Communication interface 404 using any type of transceiver, for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc. .
  • RAN radio access network
  • WLAN wireless local area networks
  • the memory 403 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type that can store information and instructions.
  • the dynamic storage device can also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, and a disc storage device. (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or can be used to carry or store desired program code in the form of instructions or data structures and can be Any other media accessed, but not limited to this.
  • the memory can exist independently and be connected to the processor via a bus.
  • the memory can also be integrated with the processor.
  • the memory 403 is used to store application code for executing the solution of the present application, and is executed by the processor 401.
  • the processor 401 is configured to execute application code stored in the memory 403 to implement the functionality of the client or server or session ticket registration in the method of the present invention.
  • the processor 401 may include one or more CPUs, such as CPU0 and CPU1 in FIG.
  • computer device 400 can include multiple processors, such as processor 401 and processor 408 in FIG. Each of these processors can be a single-CPU processor or a multi-core processor.
  • a processor herein may refer to one or more devices, circuits, and/or processing cores for processing data, such as computer program instructions.
  • computer device 400 may also include an output device 405 and an input device 406.
  • Output device 405 is in communication with processor 401 and can display information in a variety of ways.
  • the output device 405 can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. Wait.
  • Input device 406 is in communication with processor 401 and can accept user input in a variety of ways.
  • input device 606 can be a mouse, keyboard, touch screen device, or sensing device, and the like.
  • the computer device 400 described above can be a general purpose computer device or a special purpose computer device.
  • computer device 400 can be a desktop, a portable computer, a dedicated server, a communication device, an embedded device, or a device having a similar structure as in FIG. This application does not limit the type of computer device 400.
  • the application can also divide the function module into the interworking gateway.
  • each function module can be divided according to each function, or two or more functions can be integrated into one module.
  • the above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of the module in the embodiment of the present invention is schematic, and is only a logical function division, and the actual implementation may have another division manner.
  • FIG. 5 shows a functional block diagram of a device that implements the functionality of the client involved in the above embodiments.
  • the device 500 may be a device or a chip in the device, which is not specifically limited in this embodiment of the present application.
  • the device 500 includes a transceiver module 501, a processing module 502, and a storage module 503, wherein:
  • the transceiver module 501 is configured to communicate with a device external to the client by using a wireless or wired connection to receive and transmit data or a message, such as sending and receiving messages between the client and the server in FIG. 2 and FIG.
  • the message or data from the server is forwarded to the processing module 502 for processing; the message or data to be sent by the processing module to the server is also sent to the server through the transceiver module.
  • the processing module 502 is configured to construct a message sent by the client to the server, such as the handshake request message in FIG. 2 and FIG. 3, and also to process a message sent by the server, such as message parsing, derivation of the key and algorithm, and Computing, etc., to complete the handshake process with the server, establish a secure communication with the server, specifically including the processing of the New session ticket message as shown in FIG. 2 and FIG. 3, and parsing the identifier of the session ticket sent by the server. And save it in the storage module.
  • the storage module 503 is configured to store information, including storage of the identifier of the session ticket.
  • the function/implementation process of the transceiver module 501 can also be implemented by using a pin or a circuit or the like.
  • the storage module 503 is a storage unit in the chip, such as a register, a cache, and the like, and the storage unit may also be a storage unit located outside the chip in the terminal.
  • FIG. 6 shows a functional block diagram of another device that implements the functionality of the server involved in the above embodiments.
  • the device 600 may be a device or a chip in the device, which is not specifically limited in this embodiment of the present application.
  • the device 600 includes a transceiver module 601, a processing module 602, and a storage module 603, where:
  • the transceiver module 601 is configured to communicate with a device external to the server by means of a wireless or wired connection, and receive and send data or a message, such as sending and receiving messages between the server and the client or the session ticket storage device in FIG. 2 and FIG. .
  • the storage module 603 is used for storing information.
  • the processing module 602 is configured to construct a message sent by the server to the outside, such as a New session ticket message sent to the client, 206 and 302 messages sent to the session ticket register, and the like. It is also used to process the message received by the transceiver module 601, such as a handshake request message sent by the client, parsing the information contained in the client handshake request message, performing derivation and calculation of the key and the algorithm, or according to the handshake request message.
  • the identifier of the session ticket acquires the session ticket, completes the handshake process with the client, establishes a secure communication with the client, and generates an identifier of the session ticket and the session ticket according to the result of the handshake process negotiation.
  • the processing module 602 saves the generated session ticket and the identifier of the session ticket in the storage module 603; when the server saves the session ticket in the session ticket storage device, the processing module 602 The identification or addressing address of the session ticket registration device is stored in the storage module 603.
  • the processing module 602 further includes the session ticket corresponding to the session ticket held by the session ticket registration device. The identification is saved in the storage module 603.
  • the function/implementation process of the transceiver module 601 can also be implemented by using a pin or a circuit.
  • the storage module 603 is a storage unit in the chip, such as a register, a cache, and the like, and the storage unit may also be a storage unit located outside the chip in the terminal.
  • Fig. 7 shows a functional block diagram of still another apparatus which implements the session ticket registration function involved in the above embodiment.
  • the device 700 may be a device or a chip in the device, which is not specifically limited in this embodiment of the present application.
  • the device 700 includes a transceiver module 701, a processing module 702, and a storage module 703, where:
  • the transceiver module 701 is configured to communicate with a device external to the session ticket registration device by means of a wireless or wired connection to receive and transmit data or a message, such as sending and receiving messages with the server in FIG. 2 and FIG.
  • the processing module 702 is configured to process the message sent by the server, such as processing the session ticket message, saving the identifier of the session ticket and the session ticket sent in the message in the storage module 703, and processing the message of the session ticket, for example, by the server.
  • the message module 703 is queried according to the identifier of the session ticket in the message, and the session ticket corresponding to the identifier of the session ticket is obtained, and the 303 message is constructed and sent to the server through the transceiver module 701.
  • the storage module 703 is configured to store identifiers of the session ticket and the session ticket.
  • the function/implementation process of the transceiver module 701 can also be implemented by using a pin or a circuit.
  • the storage module 703 is a storage unit in the chip, such as a register, a cache, and the like, and the storage unit may also be a storage unit located outside the chip in the terminal.
  • the client can assume the session ticket registration function. Therefore, the client device 500 can also support the function of the session ticket registration device 700, that is, the transceiver module 501 can also be provided with the transceiver module 701.
  • the function of the processing module 502 may also be provided by the processing module 502.
  • the storage module 503 may also have the function of the storage module 703.
  • the above embodiments it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof.
  • software it may be implemented in whole or in part in the form of a computer program product.
  • the computer program product includes one or more computer instructions.
  • the computer program instructions When the computer program instructions are loaded and executed on a computer, the processes or functions described in accordance with embodiments of the present invention are generated in whole or in part.
  • the computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable device.
  • the computer instructions can be stored in a computer readable storage medium or transferred from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be from a website site, computer, server or data center Transfer to another website site, computer, server, or data center by wire (eg, coaxial cable, fiber optic, digital subscriber line (DSL), or wireless (eg, infrared, wireless, microwave, etc.).
  • the computer readable storage medium can be any available media that can be accessed by a computer or a data storage device such as a server, data center, or the like that includes one or more available media.
  • the usable medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (such as a solid state disk (SSD)).
  • a single processor or other unit may fulfill several of the functions recited in the claims. Certain measures are recited in mutually different dependent claims, but this does not mean that these measures are not combined to produce a good effect.

Landscapes

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

Abstract

本申请提出一种安全通信的方法，服务端生成会话票据，用于记录服务端与客户端在握手流程中协商成功的主密钥等安全通信相关的信息，并把会话票据的标识发送给客户端。当客户端需要与服务端再次进行TLS或DTLS握手时，客户端在握手请求中携带会话票据的标识，服务端根据会话票据的标识获取对应的会话票据，重用之前TLS或DTLS握手流程中已经协商成功的与安全通信相关的信息，与客户端完成握手流程。该安全通信的方法，减少了TLS或DTLS握手流程对客户端和服务端的性能消耗，而且，由于会话票据的标识只需要占用较少的字节，因此，即不会占用客户端过多的存储空间，也不会浪费通信资源。

Description

一种安全通信的方法、装置和系统
本申请要求于2017年12月15日提交中国国家知识产权局、申请号为201711354679.4、发明名称为“一种安全通信的方法、装置和系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域，尤其涉及一种设备间安全通信的方法、装置和系统。
背景技术
传输层安全(Transport Layer Security，TLS)和数据包传输层安全(Datagram Transport Layer Security，DTLS)是互联网工程任务组(Internet Engineering Task Force，IETF)制定的一种用于互联网通信的安全协议。TLS或DTLS协议大致分为两个阶段，即握手阶段和数据传输阶段。TLS或DTLS协议的客户端与服务端在握手阶段协商出一组用于保护数据传输的加密算法和完整性验证算法，以及每个算法所使用的密钥。一旦TLS或DTLS握手完成，数据就被分成一系列经过保护的记录进行传输。然而，客户端和服务端在握手阶段需要多次的往返协商，往返时延(Round-Trip Time，RTT)较大；且客户端和服务端内部要进行复杂和繁琐的密钥计算，如非对称解密和昂贵的幂运算，客户端设备和服务端设备的性能(如电量、存储和计算资源等)消耗严重。
发明内容
本申请提出一种基于TLS或DTLS协议的安全通信的方法、装置和系统，不仅可以减少RTT，还可以降低对设备的性能消耗。由于在TLS或DTLS握手流程中，服务端和客户端需要进行多次的协商交互，及大量的计算才能获得主密钥等安全通信相关的信息，为避免在后续的握手流程中，再次进行多次交互和大量计算，服务端生成会话票据以记录在握手流程中与客户端协商成功的主密钥等安全通信相关的信息，并把会话票据的标识发送给客户端，以备在后续的握手流程中使用。后续当客户端需要与服务端再次进行TLS或DTLS握手时，客户端在握手请求(即ClientHello消息)中携带会话票据的标识，服务端根据会话票据的标识获取对应的会话票据，重用之前TLS或DTLS握手流程中已经协商成功的与安全通信相关的信息，与客户端完成握手流程。该安全通信的方法，可以使客户端和服务端之间快速完成握手流程，并建立基于TLS或DTLS保护的数据传输通道，减少TLS或DTLS握手流程对客户端和服务端的性能消耗。进一步的，由于会话票据的标识只需要占用较少的字节，因此，客户端存储的会话票据的标识不会占用客户端过多的存储空间，客户端和服务端间传递会话票据的标识也不会浪费通信和传输资源。
在一种可能的实施例中，服务端根据客户端的能力决定是向客户端发送会话票据的标识，还是向客户端发送会话票据。当客户端能力较低时，服务端向客户端发送会话票据的标识，以节省客户端的存储消耗。
服务端可以将会话票据存储在服务端的内置或外置存储部件中，在另一种可能的实施例中，服务端还可以将会话票据和对应的会话票据的标识寄存在会话票据寄存装置中。当服务端收到的客户端的握手请求中包含会话票据的标识时，服务端使用会话票据的标识从会话票 据寄存装置获取对应的会话票据，并根据该会话票据中记录的上次握手协商的安全通信相关的信息与客户端完成握手流程。需要说明的是，会话票据的寄存可以采用集中寄存方式，即会话票据寄存装置为一个或几个集中部署的服务器，也可以采用分布式寄存方式，即会话票据寄存装置为多个分布部署的装置。在一种可能的实现方式中，可以由性能配置较高的客户端装置承担会话票据寄存装置的功能。
在另一种可能的实施例中，为了保证发送给客户端的会话票据的标识的安全性，服务端发送给客户端的会话票据的标识为加密后的密文，且加密密钥只有服务端知道。后续客户端再次发起握手流程时，客户端发送给服务端的握手请求中所携带的会话票据的标识，也是之前服务端加密的会话票据的标识。
在另一种可能的实施例中，为了保证会话票据的安全性，服务端发送给会话票据寄存装置的会话票据为加密后的密文，且加密密钥只有服务端知道。后续服务端向会话票据寄存装置获取会话票据时，会话票据寄存装置发送给服务端的会话票据也是之前服务端加密后的会话票据。
在又一种可能的实施例中，服务端和会话票据寄存装置间的传输通道为安全通道，该通道中传输的消息或数据为该安全通道对应的密钥加密后的密文，所述安全通道对应的密钥为服务端和会话票据寄存装置在建立安全通道过程中协商出的密钥。
本申请所提出的安全通信的方法，至少涉及服务端和客户端两个装置，可选的，还可以包括会话票据寄存装置。因此，本申请还提供一种实现服务端功能的装置，一种实现客户端功能的装置，和一种会话票据寄存装置，以实现如上所述的安全通信方法。
本申请还提供一种安全通信系统，包括如上所述的实现服务端功能的装置和实现客户端功能的装置，可选的，还包括会话票据寄存装置。
另外，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述安全通信的方法。
最后，本申请提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述安全通信的方法。
附图说明
图1为现有技术中IETF定义的TLS握手流程图；
图2为本发明实施例提供的一种基于TLS协议的客户端和服务端的会话建立流程图；
图3为本发明实施例提供的一种客户端和服务端重用上次会话票据重建会话的方法流程图；
图4为本发明实施例提供的一种计算机设备示意图；
图5为本发明实施例提供的一种实现客户端功能的装置的功能模块示意图；
图6为本发明实施例提供的一种实现服务端功能的装置的功能模块示意图；
图7为本发明实施例提供的一种会话票据寄存装置的功能模块示意图。
具体实施方式
TLS与DTLS为IETF标准组织制定与发布的安全协议，其中DTLS为基于TLS的补充和扩 展，TLS与DTLS在握手阶段的协议流程基本相同。TLS和DTLS协议主要应用于客户端/服务端架构(Client/Server，CS)或CS架构的变体，通信的双方分别为客户端和服务端。图1为IETF发布的征求意见稿(Request For Comments，RFC)5246中定义的TLS协议流程图。该TLS协议流程包括从ClientHello消息到Finished消息的握手阶段或握手流程，和Application Data的数据传输阶段。客户端和服务端要基于TLS或DTLS进行安全通信，首先要通过TLS或DTLS握手流程建立会话或连接，协商出加密算法和完整性保护算法，以及每个算法所使用的密钥等信息，然后双方使用协商出的算法和密钥对传输的数据进行加密和完整性保护，进行安全通信。握手流程由客户端向服务端发送的ClientHello消息触发，在本申请中，客户端向服务端发送的ClientHello消息也被称为握手请求。从图1可以看出，客户端client和服务端server进行算法和密钥协商的握手阶段经历了从ClientHello消息到Finished消息的多轮交互,往返时延RTT较大，而且客户端和服务端内部还要进行复杂的密钥计算和推导，电量、存储和计算资源等消耗较大。DTLS的握手流程可以参见RFC 6347，与TLS基本一致，这里不再赘述。由此可见，现有技术中，由于客户端和服务端每次基于TLS或DTLS建立会话和连接都要经过复杂的握手流程，对客户端和服务端设备的性能消耗非常严重，性能较为受限的设备(如电量或存储或计算能力受限设备)无法部署或支持TLS或DTLS协议，只能选用其它较为简易的安全通信方案或协议，传输层通信安全得不到保障。
本申请提出一种安全通信的方法，使得客户端和服务端在建立会话或连接时，能够重用之前TLS或DTLS握手流程中已经协商成功的与安全通信相关的信息，快速建立客户端和服务端之间的使用TLS或DTLS保护的数据传输通道，减少TLS或DTLS握手流程对客户端和服务端的性能消耗。需要说明的是，本申请中所述客户端和服务端为TLS和DTLS握手流程中的功能实体名称，并不限定实现客户端和服务端功能的装置类型，比如实现服务端功能的装置为服务器，实现客户端功能的装置为终端；又比如，实现服务端功能的装置为终端，实现客户端功能的装置为服务器；还可能，实现服务端功能的装置和实现客户端功能的装置均为终端。
由于TLS和DTLS的消息类型相同，本申请中的实施例均以TLS为例进行撰写，但本领域技术人员应该清楚的是，本申请中所述实施例同样可以适用于基于DTLS的通信。
图2所示为本发明实施例提供的一种基于TLS协议的客户端和服务端的会话建立流程。
201-203：客户端和服务端执行TLS协议定义的完整的握手流程，协商本次会话或本次连接中进行安全通信所需的信息。TLS协议的握手流程在RFC 5246中有详细描述，本申请文件中不再赘述。
204：服务端生成会话票据，会话票据中记录的信息在不同的实际部署中可能略有不同，但至少应该包括客户端和服务端协商成功的主密钥(master secret)，主密钥用于使客户端和服务端借助ClientHello/ServerHello交换的随机数，推导生成完整性保护密钥和加密密钥。会话票据中还可能包括如下任一或多个信息，协议版本号、密钥套(Cipher Suite)、压缩方法、客户端标识等，其中密钥套中包括加密算法、完整性保护算法，认证算法、密钥交换算法、密钥衍生算法等一种或多种算法信息。可选的，会话票据中还包括用于验证会话票据有效性的信息，如会话票据的有效时间等信息。服务端还为每个会话票据分配与其对应的标识，用于唯一指示一个会话票据。会话票据的标识的格式本申请不进行限定，可以是字符串或其它任何可以唯一标识会话票据的形式。相比会话票据，会话票据的标识的字节数要小的多。
205：服务端将生成的会话票据的标识发送给客户端。承载会话票据的标识的消息可以是图2中所示的New session ticket消息，也可以是其它消息名称。为了进一步保证会话票据的标识的机密性，防止会话票据的标识被盗用，如被客户端之外其它设备盗用或被客户端内的其它应用盗用，服务端还可以对会话票据的标识进行加密，将加密后的密文发送给客户端，而加密的密钥只有服务端自己知道，只有服务端可以对加密后的密文进行解密。客户端收到205消息后，保存会话票据的标识或服务端加密的会话票据的标识。另外，由于此时服务端和客户端已经协商出了本次会话的加密和完整性保护的算法和密钥等信息，因此服务端向客户端发送的205消息还可以根据201-203步骤中协商成功的加密和完整性算法和密钥进行保护，客户端接收到205消息，使用201-203步骤中协商成功的加密和完整性算法和密钥对205消息进行解密和校验，解析获得205消息中包含的会话票据的标识或服务端加密的会话票据的标识。
206：由于会话票据的存储需要消耗较大的存储，当服务端存储功能有限，服务端本身的存储能力无法满足存储会话票据的需求时，为了减少存储的消耗，可选的，服务端也可以选择将会话票据和对应的会话票据的标识存储在一个外置的会话票据寄存装置中，如206步骤所示。为了保证会话票据的机密性，服务端在206消息中携带的会话票据可以是加密后的会话票据，且加密的密钥仅服务端自己知道。另外，服务端和会话票据寄存装置间的数据传输通道还可以是加密的传输通道，即在发送206消息之前，服务端和会话票据寄存装置已经完成了会话通道密钥的协商，服务端将206消息根据双方协商后的密钥加密后进行传输。服务端发送206消息后便无需保存会话票据。会话票据寄存装置接收到206消息后，解析获得206消息中的加密或非加密的会话票据和对应的会话票据的标识。需要说明的是，在服务端将会话票据保存在会话票据寄存装置的情况下，为了后续能够找回会话票据，服务端需要记录会话票据寄存装置的地址或标识；如果会话票据寄存装置是集中式的单一设备，则服务端只需要记录会话票据寄存装置的地址或标识；如果会话票据寄存装置是分布式的多个设备，服务端需要记录会话票据的标识，和标识所对应的会话票据所寄存的会话票据寄存装置的地址或标识。需要说明的是，会话票据寄存装置需要部署在可信域或安全域中，以保证寄存的会话票据的安全性。
207：客户端和服务端使用握手流程中协商的算法和密钥进行安全的数据传输。
首先需要说明的是，根据客户端和服务端设备的性能差异，图2所示方法流程还可以进行适当的调整：
当客户端设备的存储能力较强时，服务端可以将会话票据或加密的会话票据发送给客户端，由客户端保存会话票据，服务端无需生成会话票据的标识，也无需在服务端或在会话票据寄存装置中保存会话票据和会话票据的标识；
当客户端设备的存储能力较弱时，服务端执行如图2所示的方法流程；
当客户端设备的存储能力非常弱，以至于不足以保存会话票据的标识时，服务端不再执行如204、205和206所示的步骤。
上述所说的存储能力“较强”、“较弱”、“非常弱”仅为一种定性的描述，本申请不做量化的定义和限定，可以根据部署的具体情况设定判断条件。为了表征客户端设备的存储能力，客户端在201消息中可以携带设备类型，以表征其存储能力，服务端根据设备类型决定是执 行如图2所示的方法流程，还是如上所述调整后的方法流程。
另外，客户端还可以在201消息中携带指示信息，指示客户端支持根据会话票据与服务端完成握手流程，服务端判断201消息中包含所述指示信息，且设备类型满足预设条件时，执行如图2所示的方法流程或如上所述调整后的方法流程。
其次需要说明的是，当会话票据寄存装置为服务端设备之外的设备时，会话票据寄存装置可以是集中部署的一个或几个存储设备，也可以是存储能力较强的其它客户端设备。如上所述，客户端在发给服务端的握手请求中包含设备类型，对于存储能力较强的客户端，服务端对其认证通过后，将该客户端的标识或地址记录到会话票据寄存装置列表，后续需要寄存会话票据时，从会话票据寄存装置列表中挑选客户端。挑选的规则本申请不进行限定，如可以是随机或轮选，以保证服务端要存储的会话票据均衡分布在多个可以作为会话票据寄存装置的客户端上，不会对某一个客户端造成太大的性能压力；服务端还可以根据IP地址段相邻的规则挑选作为会话票据寄存装置的客户端，保证作为会话票据寄存装置的客户端的IP地址与当前和服务端进行握手流程的客户端的IP地址是相邻的。客户端还可以在握手请求消息中携带是否支持会话票据寄存的指示，则服务端根据该指示确定是否将该客户端记录到会话票据寄存装置列表。
还需要说明的是，本申请不限定服务端执行204-206步骤的时机，只要服务端和客户端在握手流程中协商出了主密钥等会话票据要记录的信息，服务端不必等待握手流程完全结束，随时可以执行204、205和206步骤，即204-206步骤有可能在203步骤之前出现；握手流程结束后，服务端也可能不会立即发送205和206消息，服务器还可以在207步骤应用数据传输之后或同时发送205和206消息。另外，本申请也不限定205和206消息的顺序，即服务端也可以先向会话票据寄存发送206消息，再向客户端发送205消息。
通过图2中所示的流程，客户端和服务端在会话握手成功后，服务端在自身或会话票据寄存装置保存了会话票据和会话票据的标识，客户端也保存了会话票据的标识，当客户端和服务端需要再次建立会话或连接时，可以使用保存的会话票据快速建立安全的会话或连接。在图2的基础上，图3所示为客户端和服务端重用上次会话票据重建会话的方法流程。
301：客户端发送ClientHello消息到服务端，消息中携带之前服务端发送给客户端的会话票据的标识或服务端加密的会话票据的标识。服务端解析301消息获得会话票据的标识。如果301消息中携带的是服务端加密的会话票据的标识，服务端需要使用仅服务端可知的密钥解密(与图2中205步骤中)，以获得会话票据的标识。
302：服务端根据会话票据的标识获取对应的会话票据。如果会话票据保存在会话票据寄存装置，则服务端向会话票据寄存装置发送302消息，其中携带会话票据的标识。如上206所述，服务端和会话票据寄存间的传输通道可能是加密的，则302和303消息需要进行加密处理再发送，后续不再赘述。
303：会话票据寄存装置根据302消息中接收到的会话票据的标识，确定与会话票据的标识对应的会话票据或服务端加密后的会话票据(如206消息所述)。会话票据寄存装置向服务端发送会话票据或服务端加密后的会话票据。服务端解析303消息获得会话票据。如果303消息中携带的是服务端加密的会话票据，服务端需要使用密钥解密，以获得会话票据。
304-305：服务端判断会话票据有效，直接根据会话票据中记录的之前会话协商成功的安 全通信相关的信息，与客户端完成握手流程。因为会话票据中记录了主密钥、密钥套等信息，省去了服务端和客户端重新协商密钥和算法的步骤和流程，减少了握手流程中对客户端和服务端的性能消耗，加快了握手流程的RTT。如果服务端判断会话票据已失效，则与客户端执行完整的握手流程，重新协商算法和密钥。需要说明的是，服务端判断会话票据是否有效的方法有很多种，本申请不进行限定，如服务端在204步骤生成会话票据时可以在会话票据中记录会话票据的有效时间，根据会话票据中的有效时间和当前时间判断会话票据是否有效。
306：可选的，出于安全性考虑，如需要更新密钥和算法，或需要更新会话票据的有效时间等，服务端还可以更新或生成新的会话票据。如服务端生成新的会话票据和新的会话票据的标识；或服务端沿用老的会话票据的标识，只更新会话票据。
307：如果服务端在306步骤生成了新的会话票据的标识，则服务端向客户端发送新的会话票据的标识，具体描述参见205消息，这里不再赘述。客户端接收到新的会话票据的标识，删除旧的会话票据的标识，保存新的会话票据的标识。
308：如果服务端在306步骤生成了新的会话票据和新的会话票据的标识，则服务端向会话票据寄存装置发送新的会话票据，新的会话票据的标识和旧的会话票据的标识，会话票据寄存装置接收到308消息，删除旧的会话票据的标识对应的会话票据，并记录新的会话票据的标识和对应的会话票据。如果服务端在306步骤中沿用了旧的会话票据的标识，仅更新了对应的会话票据，则服务端向会话票据寄存装置发送新的会话票据和旧的会话票据的标识，会话票据寄存装置接收到308消息，将旧的会话票据的标识所对应的会话票据，更新为新的会话票据。如206步骤中所述，服务端可以对308步骤消息包括的新的会话票据进行加密处理，以保证会话票据的机密性；另外，308消息本身还可以是在加密通道中传输的。
需要说明的是，如果会话票据寄存装置收到302消息后，无法根据会话票据的标识查找到对应的会话票据，则在303消息中指示服务端没有对应的会话票据记录。在这种情况下，服务端和客户端无法重用之前会话协商的安全通信相关的信息，需要执行完整的握手流程。
通过如上图2和图3所示的方法流程可以看出，本申请所提出的安全通信的方法，对TLS或DTLS协议进行了优化，将服务端和客户端协商成功的安全通信的相关信息保存在会话票据中，并对会话票据和会话票据的标识进行分离存储，在保证传输层安全的前提下，既不需要服务端和客户端进行完整的握手流程，也不需要服务端和客户端保存内存消耗较大的会话票据，降低了对客户端和服务端存储、电量、计算资源等性能的消耗，减少了客户端和服务端握手流程的RTT。
上述主要从方法流程的角度对本申请提出的方案进行了介绍。可以理解的是，各个设备或装置，例如客户端、服务端和会话票据寄存等为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请中所提出的客户端或服务端或会话票据寄存可以通过图4中的计算机设备来实现。
图4所示为本发明实施例提供的一种计算机设备示意图。计算机设备400包括至少一个处理器401，通信总线402，存储器403以及至少一个通信接口404。
处理器401可以是一个通用中央处理器(central processing unit，CPU)，微处理器， 特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。
通信总线402可包括一通路，在上述组件之间传送信息。
通信接口404，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线接入网(radio access network，RAN)，无线局域网(wireless local area networks，WLAN)等。
存储器403可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
其中，存储器403用于存储执行本申请方案的应用程序代码，并由处理器401来执行。处理器401用于执行存储器403中存储的应用程序代码，从而实现本专利方法中客户端或服务端或会话票据寄存的功能。
在具体实现中，作为一种实施例，处理器401可以包括一个或多个CPU，例如图4中的CPU0和CPU1。
在具体实现中，作为一种实施例，计算机设备400可以包括多个处理器，例如图4中的处理器401和处理器408。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
在具体实现中，作为一种实施例，计算机设备400还可以包括输出设备405和输入设备406。输出设备405和处理器401通信，可以以多种方式来显示信息。例如，输出设备405可以是液晶显示器(liquid crystal display，LCD),发光二级管(light emitting diode，LED)显示设备，阴极射线管(cathode ray tube，CRT)显示设备，或投影仪(projector)等。输入设备406和处理器401通信，可以以多种方式接受用户的输入。例如，输入设备606可以是鼠标、键盘、触摸屏设备或传感设备等。
上述的计算机设备400可以是一个通用计算机设备或者是一个专用计算机设备。在具体实现中，计算机设备400可以是台式机、便携式电脑、专用服务器、通信设备、嵌入式设备或有图4中类似结构的设备。本申请不限定计算机设备400的类型。
本申请还可以对互通网关进行功能模块划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以此采用软件功能模块的形式实现。需要说明的是，本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
图5给出了一种装置的功能模块示意图，该装置实现上述实施例中所涉及的客户端的功 能。该装置500可以是设备，也可以是设备内的芯片，本申请实施例对此不作具体限定。装置500包括收发模块501，处理模块502，存储模块503，其中：
收发模块501，用于通过无线或有线连接的方式，与客户端外部的装置通信，接收和发送数据或消息，如图2和图3中客户端与服务端间消息的收发。来自服务端的消息或数据，转给处理模块502处理；处理模块要发给服务端的消息或数据也通过收发模块向服务端发送。
处理模块502，用于构造客户端向服务端发送的消息，如图2和图3中的握手请求消息等；还用于处理服务端发送的消息，如消息解析，密钥和算法的推导和计算等，以完成与服务端间的握手流程，建立与服务端间的安全通信，具体包括如图2和图3中所示New session ticket消息的处理，解析获得服务端发送的会话票据的标识，并保存在存储模块。
存储模块503，用于信息的存储，包括会话票据的标识的存储。
可选的，当该装置500是芯片时，那么收发模块501的功能/实现过程还可以通过管脚或电路等来实现。可选地，所述存储模块503为所述芯片内的存储单元，如寄存器、缓存等，所述存储单元还可以是所述终端内的位于所述芯片外部的存储单元。
图6给出了另一种装置的功能模块示意图，该装置实现上述实施例中所涉及的服务端的功能。该装置600可以是设备，也可以是设备内的芯片，本申请实施例对此不作具体限定。装置600包括收发模块601，处理模块602，存储模块603，其中：
收发模块601，用于通过无线或有线连接的方式，与服务端外部的装置通信，接收和发送数据或消息，如图2和图3中服务端与客户端或会话票据寄存装置间消息的收发。
存储模块603，用于信息的存储。
处理模块602,用于构造服务端向外部发送的消息，如发给客户端的New session ticket消息，发给会话票据寄存装置的206和302消息等。还用于处理收发模块601接收到的消息，如客户端发送的握手请求消息，解析客户端握手请求消息中包含的信息，进行密钥和算法的推导和计算，或根据握手请求消息中包括的会话票据的标识获取会话票据，完成与客户端间的握手流程，建立与客户端间的安全通信，并根据握手流程协商的结果，生成会话票据和会话票据的标识。当服务端自身存储会话票据的情况下，处理模块602将生成的会话票据和会话票据的标识保存在存储模块603中；当服务端将会话票据保存在会话票据寄存装置中时，处理模块602将会话票据寄存装置的标识或寻址地址保存在存储模块603中，当会话票据寄存功能由多个设备承担时，处理模块602还要将会话票据寄存装置所保存的会话票据所对应的会话票据的标识保存在存储模块603中。
可选的，当该装置600是芯片时，那么收发模块601的功能/实现过程还可以通过管脚或电路等来实现。可选地，所述存储模块603为所述芯片内的存储单元，如寄存器、缓存等，所述存储单元还可以是所述终端内的位于所述芯片外部的存储单元。
图7给出了又一种装置的功能模块示意图，该装置实现上述实施例中所涉及的会话票据寄存功能。该装置700可以是设备，也可以是设备内的芯片，本申请实施例对此不作具体限定。装置700包括收发模块701，处理模块702，存储模块703，其中：
收发模块701，用于通过无线或有线连接的方式，与会话票据寄存装置外部的装置通信，接收和发送数据或消息，如图2和图3中与服务端间消息的收发。
处理模块702,用于处理服务端发送的消息，如处理session ticket消息，将消息中发送的会话票据和会话票据的标识保存在存储模块703中，又比如处理服务端获取会话票据的消息(302消息)，根据消息中的会话票据的标识查询存储模块703，获得会话票据的标识所对应的会话票据，并构造303消息，通过收发模块701发送给服务端。
存储模块703，用于存储会话票据和会话票据的标识。
可选的，当该装置700是芯片时，那么收发模块701的功能/实现过程还可以通过管脚或电路等来实现。可选地，所述存储模块703为所述芯片内的存储单元，如寄存器、缓存等，所述存储单元还可以是所述终端内的位于所述芯片外部的存储单元。
需要说明的是，如图2和图3中所述，客户端可以承担会话票据寄存功能，因此客户端装置500还可以支持会话票据寄存装置700的功能，即收发模块501还可以具备收发模块701的功能，处理模块502还可以具备处理模块702的功能，存储模块503还可以具备存储模块703的功能。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了说明，本领域技术人员应该理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本申请的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。方法实施例中所述的消息名称或设备名称仅为示例，不构成对本申请所述方案的限定，只要与本申请所述方法流程或设备的功能相同，则均在本申请保护范围之内。在权利要求中，“包括”一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其它单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能结合起来产生良好的效果。

Claims (38)

  1. 一种安全通信的方法，其特征在于，
    服务端接收客户端发送的第二握手请求，其中包括会话票据(session ticket)的标识，所述会话票据的标识用于唯一标识会话票据，所述会话票据中至少包括所述服务端与所述客户端在第一握手流程中协商成功的主密钥；
    所述服务端根据所述会话票据的标识获取所述会话票据；
    所述服务端根据所述会话票据完成与所述客户端的第二握手流程。
  2. 如权利要求1所述的方法，其特征在于，所述服务端接收客户端发送的第二握手请求前，所述方法还包括，
    所述服务端接收所述客户端发送的第一握手请求，与所述客户端在所述第一握手流程中进行主密钥的协商，协商成功后，生成所述会话票据；
    所述服务端向所述客户端发送所述会话票据的标识。
  3. 如权利要求2所述的方法，其特征在于，所述第一握手请求中包括所述客户端的设备类型，所述设备类型用于表征所述客户端的能力；
    所述服务端向所述客户端发送所述会话票据的标识，具体包括，
    所述服务端判断所述客户端的设备类型满足预设条件，向所述客户端发送所述会话票据的标识。
  4. 如权利要求2或3所述的方法，其特征在于，所述服务端根据所述会话票据的标识获取所述会话票据，具体包括，
    所述服务端向会话票据寄存装置发送获取所述会话票据的请求消息，所述请求消息中包括所述会话票据的标识；
    所述服务端接收所述会话票据寄存装置发送的所述会话票据。
  5. 如权利要求4所述的方法，其特征在于，所述服务端接收客户端发送的第二握手请求前，所述方法还包括，
    所述服务端在所述第一握手流程中，生成所述会话票据后，所述服务端向所述会话票据寄存装置发送所述会话票据的标识和所述会话票据。
  6. 如权利要求4或5所述的方法，其特征在于，所述会话票据寄存装置为其它客户端；
    所述服务端向所述会话票据寄存装置发送所述会话票据的标识和所述会话票据，具体包括，
    所述服务端查询支持会话票据寄存的客户端列表，根据预订的规则选择作为会话票据寄存装置的客户端；
    所述服务端向所述被选定作为会话票据寄存装置的客户端发送所述会话票据的标识 和所述会话票据。
  7. 如权利要求6所述的方法，其特征在于，在所述服务端选择其它客户端作为会话票据寄存装置之前，所述方法还包括，
    所述客户端接收所述被选定作为会话票据寄存装置的客户端的握手请求，所述握手请求中包括所述被选定作为会话票据寄存装置的设备类型；
    在所述被选定作为会话票据寄存装置的设备类型满足预设条件的情况下，所述服务端对所述被选定作为会话票据寄存装置的客户端进行认证，认证通过，则将所述被选定作为会话票据寄存装置的客户端记录在所述支持会话票据寄存的客户端列表。
  8. 如权利要求3所述的方法，其特征在于，所述第一握手请求中还包括指示信息，所述指示信息用于指示所述客户端支持接收会话票据的标识；
    所述服务端向所述客户端发送所述会话票据的标识，具体包括，
    所述服务端判断所述客户端的设备类型满足预设条件，且所述第一握手请求中包括所述指示信息，所述服务端向所述客户端发送所述会话票据的标识。
  9. 如权利要求2-8任一所述的方法，其特征在于，所述服务端与所述客户端间传递的所述会话票据的标识为加密后的密文；
    所述服务端向所述客户端发送所述会话票据的标识，具体包括，所述服务端使用第一密钥对所述会话票据的标识进行加密，所述服务端向所述客户端发送所述第一密钥加密后的会话票据的标识；
    所述服务端接收客户端发送的第二握手请求，其中包括所述会话票据的标识，具体包括，所述服务端接收客户端发送的会话恢复请求，其中包括所述第一密钥加密后的会话票据的标识，所述服务端使用所述第一密钥解析密文并获得所述会话票据的标识。
  10. 如权利要求5-7任一所述的方法，其特征在于，所述服务端与所述会话票据寄存装置间传递的所述会话票据为加密后的密文；
    所述服务端向所述会话票据寄存装置发送所述会话票据的标识和所述会话票据，具体包括：
    所述服务端使用第二密钥对所述会话票据进行加密，所述服务端向会话票据寄存装置发送所述会话票据的标识和所述加密的会话票据。
  11. 如权利要求5-7任一所述的方法，其特征在于，所述服务端与所述会话票据寄存装置间传递的所述会话票据的标识和所述会话票据为加密后的密文；
    所述服务端向所述会话票据寄存装置发送所述会话票据的标识和所述会话票据，具体包括：
    所述服务端使用第二密钥对所述会话票据进行加密，获得一次加密会话票据；
    所述服务端使用第三密钥对所述一次加密会话票据进行二次加密，获得二次加密的会话票据，所述第三密钥为所述服务端与所述会话票据寄存装置协商的双方公知的密钥；
    所述服务端使用所述第三密钥对所述会话票据的标识进行加密；
    所述服务端向会话票据寄存装置发送所述第三密钥加密后的会话票据的标识和所述二次加密的会话票据。
  12. 如权利要求10所述的方法，其特征在于，
    所述服务端接收所述会话票据寄存装置发送的所述会话票据，具体包括，所述服务端接收所述会话票据寄存装置发送的所述加密的会话票据，所述服务端使用所述第二密钥解密所述加密的会话票据并获得所述会话票据。
  13. 如权利要求11所述的方法，其特征在于，
    所述服务端向会话票据寄存装置发送获取所述会话票据的请求消息，所述请求消息中包括所述会话票据的标识，具体包括，所述服务端向会话票据寄存装置发送获取所述会话票据的请求消息，所述请求消息中包括使用所述第三密钥加密的所述会话票据的标识；
    所述服务端接收所述会话票据寄存装置发送的所述会话票据，具体包括，所述服务端接收所述会话票据寄存装置发送的所述二次加密的会话票据，所述服务端使用所述第三密钥和第二密钥解密所述二次加密的会话票据并获得所述会话票据。
  14. 如权利要求1-13任一所述的方法，其特征在于，所述服务端根据所述会话票据完成与所述客户端的握手流程，具体包括，
    所述服务端判断所述会话票据有效，则使用所述会话票据中包含的信息完成与所述客户端的握手流程。
  15. 如权利要求1-14任一所述的方法，其特征在于，所述服务端为物联网服务器或物联网终端。
  16. 一种安全通信的方法，其特征在于，
    客户端向服务端发送第一握手请求，触发所述客户端与所述服务端间的第一握手流程；
    所述客户端接收所述服务端发送的会话票据的标识，所述会话票据的标识用于唯一标识会话票据，所述会话票据中至少包括所述客户端与所述服务端在第一握手流程中协商成功的主密钥；
    所述客户端向所述服务端发送第二握手请求，所述第二握手请求中包括所述会话票据的标识，所述会话票据的标识用于使所述服务端根据所述会话票据完成与所述客户端的第二握手流程。
  17. 如权利要求16所述的方法，其特征在于，所述第一握手请求中包括所述客户端的设备类型，所述设备类型用于表征所述客户端的能力。
  18. 如权利要求16或17所述的方法，其特征在于，所述第一握手请求中包括指示信息，所述指示信息用于指示所述客户端支持接收会话票据的标识。
  19. 如权利要求16-18任一所述的方法，其特征在于，所述服务端发送的会话票据的标识为加密后的密文，所述第二握手请求中包括的所述会话票据的标识为所述加密后的密文。
  20. 如权利要求16-19任一所述的方法，其特征在于，所述客户端为物联网终端或物联网服务器。
  21. 一种实现安全通信的计算机设备，其特征在于，包括：处理器、存储器、总线和通信接口；所述存储器用于存储计算机执行指令，所述处理器与所述存储器通过所述总线连接，当所述计算机设备运行时，所述处理器执行所述存储器存储的计算机执行指令，以使所述计算机设备执行如权利要求1-15任一所述方法中服务端的功能。
  22. 一种实现安全通信的计算机设备，其特征在于，包括：处理器、存储器、总线和通信接口；所述存储器用于存储计算机执行指令，所述处理器与所述存储器通过所述总线连接，当所述计算机设备运行时，所述处理器执行所述存储器存储的计算机执行指令，以使所述计算机设备执行如权利要求16-20任一所述方法中客户端的功能。
  23. 一种实现安全通信的装置，所述装置用于实现安全通信中服务端的功能，其特征在于，包括收发模块，处理模块和存储模块，其中：
    所述收发模块，用于接收客户端发送的消息，还用于向所述客户端发送消息；所述客户端发送的消息包括第二握手请求，所述第二握手请求包括会话票据的标识，所述会话票据的标识用于唯一标识会话票据，所述会话票据中至少包括所述装置与所述客户端在第一握手流程中协商成功的主密钥；
    所述存储模块，用于存储所述会话票据的标识和所述会话票据，或用于存储会话票据寄存装置的标识或地址；
    所述处理模块，用于根据所述第二握手请求中包括的会话票据的标识获取所述会话票据，并根据所述会话票据完成与所述客户端的第二握手流程。
  24. 如权利要求23所述的装置，其特征在于，所述收发模块接收所述第二握手请求之前，所述收发模块接收所述客户端发送的第一握手请求；
    所述处理模块，还用于根据所述第一握手请求，与所述客户端在第一握手流程中进行主密钥的协商，协商成功后，生成所述会话票据，并通过所述收发模块向所述客户端发送所述会话票据的标识。
  25. 如权利要求24所述的装置，其特征在于，所述第一握手请求中包括所述客户端的设备类型，所述设备类型用于表征所述客户端的能力；
    所述处理模块，具体用于判断所述客户端的设备类型满足预设条件，通过所述收发模块向所述客户端发送所述会话票据的标识。
  26. 如权利要求24或25所述的装置，其特征在于，在所述存储模块中存储会话票据寄存装置的标识或地址的情况下，
    所述收发模块，还用于向所述会话票据寄存装置发送消息，接收所述会话票据寄存装置发送的消息；
    所述处理模块，具体用于根据所述第二握手请求中包括的会话票据的标识，通过所述收发模块向所述会话票据寄存装置发送获取所述会话票据的请求消息，所述请求消息中包括所述会话票据的标识，并通过所述收发模块接收所述会话票据寄存装置发送的所 述会话票据。
  27. 如权利要求26所述的装置，其特征在于，在所述第一握手流程中，所述处理模块，还用于向所述会话票据寄存装置发送所述会话票据的标识和所述会话票据。
  28. 如权利要求26或27所述的装置，其特征在于，所述会话票据寄存装置为其它客户端；
    所述处理模块，还用于查询支持会话票据寄存的客户端列表，根据预订的规则选择作为会话票据寄存装置的客户端；通过所述收发模块，向所述被选定作为会话票据寄存装置的客户端发送所述会话票据的标识和所述会话票据。
  29. 如权利要求28所述的装置，其特征在于，在所述处理模块选择其它客户端作为会话票据寄存装置之前，
    所述处理模块，还用于通过所述收发模块接收所述被选定作为会话票据寄存装置的客户端的握手请求，所述握手请求中包括所述被选定作为会话票据寄存装置的设备类型；在所述被选定作为会话票据寄存装置的设备类型满足预设条件的情况下，所述处理模块对所述被选定作为会话票据寄存装置的客户端进行认证，认证通过，则将所述被选定作为会话票据寄存装置的客户端记录在所述支持会话票据寄存的客户端列表。
  30. 如权利要求25所述的装置，其特征在于，所述第一握手请求中还包括指示信息，所述指示信息用于指示所述客户端支持接收会话票据的标识；
    所述处理模块，具体用于判断所述客户端的设备类型满足预设条件，且所述第一握手请求中包括所述指示信息，通过所述收发模块向所述客户端发送所述会话票据的标识。
  31. 一种实现安全通信的装置，所述装置用于实现安全通信中客户端的功能，其特征在于，包括收发模块，处理模块和存储模块，其中：
    所述收发模块，用于向服务端发送消息，还用于接收所述服务端发送的消息；
    所述存储模块，用于存储会话票据的标识，所述会话票据的标识用于唯一标识会话票据，所述会话票据中至少包括所述装置与所述服务端在第一握手流程中协商成功的主密钥；
    所述处理模块，用于通过所述收发模块向所述服务端发送第一握手请求，触发所述装置与所述服务端间的第一握手流程，并通过所述收发模块接收所述服务端发送的会话票据的标识，所述会话票据的标识用于唯一标识会话票据，所述会话票据中至少包括所述装置与所述服务端在第一握手流程中协商成功的主密钥；
    所述处理模块，还用于通过所述收发模块向所述服务端发送第二握手请求，所述第二握手请求中包括所述会话票据的标识，所述会话票据的标识用于使所述服务端根据所述会话票据完成与所述装置的第二握手流程。
  32. 如权利要求31所述的装置，其特征在于，所述第一握手请求中包括所述客户端的设备类型，所述设备类型用于表征所述客户端的能力。
  33. 如权利要求31或32所述的装置，其特征在于，所述第一握手请求中包括指示信息，所述指示信息用于指示所述装置支持接收会话票据的标识。
  34. 如权利要求31-33任一所述的装置，其特征在于，所述服务端发送的会话票据的标识为加密后的密文，所述第二握手请求中包括的所述会话票据的标识为所述加密后的密文。
  35. 一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如权利要求1-15任意一项所述的方法。
  36. 一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如权利要求16-20任意一项所述的方法。
  37. 一种安全通信系统，其特征在于，包括如权利要求23-30任一所述的服务端装置和如权利要求31-34任一所述的客户端装置。
  38. 如权利要求37所述的安全通信系统，其特征在于，所述系统还包括会话票据寄存装置；
    所述会话票据寄存装置，用于寄存所述服务端设备发送的会话票据和会话票据的标识，所述会话票据的标识用于唯一标识所述会话票据，所述会话票据中至少包括所述服务端装置与所述客户端装置协商成功的主密钥；
    所述会话票据寄存装置，还用于根据所述服务端装置发送的所述会话票据的标识，向所述服务端装置发送所述会话票据。
PCT/CN2018/120338 2017-12-15 2018-12-11 一种安全通信的方法、装置和系统 WO2019114703A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201711354679.4 2017-12-15
CN201711354679.4A CN109936529B (zh) 2017-12-15 2017-12-15 一种安全通信的方法、装置和系统

Publications (1)

Publication Number Publication Date
WO2019114703A1 true WO2019114703A1 (zh) 2019-06-20

Family

ID=66818983

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/120338 WO2019114703A1 (zh) 2017-12-15 2018-12-11 一种安全通信的方法、装置和系统

Country Status (2)

Country Link
CN (1) CN109936529B (zh)
WO (1) WO2019114703A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110225135A (zh) * 2019-06-24 2019-09-10 北京字节跳动网络技术有限公司 服务器的连接方法、装置、电子设备及存储介质
CN111245601A (zh) * 2019-12-18 2020-06-05 北京威努特技术有限公司 一种通讯协商方法及装置
CN115714681A (zh) * 2022-11-11 2023-02-24 中国联合网络通信集团有限公司 数据验证方法、装置及存储介质
CN115720176A (zh) * 2022-12-26 2023-02-28 南京汇荣信息技术有限公司 基于Socket通信报文内容的动态加密方法、系统

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110995662B (zh) * 2019-11-13 2020-07-31 北京连山科技股份有限公司 一种基于多路网络媒介的数据传输方法和系统
CN112019374A (zh) * 2020-07-15 2020-12-01 上海趣蕴网络科技有限公司 一种网络通信优化方法和系统
CN112187804B (zh) * 2020-09-29 2023-01-20 北京金山云网络技术有限公司 服务器的通信方法、装置、计算机设备和存储介质
CN114285891B (zh) * 2021-12-15 2024-01-23 北京天融信网络安全技术有限公司 一种基于sslvpn的会话重建方法及系统
CN115484301A (zh) * 2022-08-04 2022-12-16 支付宝(杭州)信息技术有限公司 一种数据传输方法、装置、存储介质及电子设备
CN116055215B (zh) * 2023-03-02 2024-03-15 上海弘积信息科技有限公司 一种基于网络安全传输协议的通信方法、系统及设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103118027A (zh) * 2013-02-05 2013-05-22 中金金融认证中心有限公司 基于国密算法建立tls通道的方法
CN105471896A (zh) * 2015-12-28 2016-04-06 深圳市深信服电子科技有限公司 基于ssl的代理方法、装置及系统
CN106161404A (zh) * 2015-04-22 2016-11-23 阿里巴巴集团控股有限公司 Ssl会话重用的方法、服务器和系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8996873B1 (en) * 2014-04-08 2015-03-31 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
CN105635039B (zh) * 2014-10-27 2019-01-04 阿里巴巴集团控股有限公司 一种网络安全通信方法及通信装置
CN106921721A (zh) * 2015-12-28 2017-07-04 华为软件技术有限公司 一种服务器、会话管理方法和系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103118027A (zh) * 2013-02-05 2013-05-22 中金金融认证中心有限公司 基于国密算法建立tls通道的方法
CN106161404A (zh) * 2015-04-22 2016-11-23 阿里巴巴集团控股有限公司 Ssl会话重用的方法、服务器和系统
CN105471896A (zh) * 2015-12-28 2016-04-06 深圳市深信服电子科技有限公司 基于ssl的代理方法、装置及系统

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110225135A (zh) * 2019-06-24 2019-09-10 北京字节跳动网络技术有限公司 服务器的连接方法、装置、电子设备及存储介质
CN110225135B (zh) * 2019-06-24 2022-02-15 北京字节跳动网络技术有限公司 服务器的连接方法、装置、电子设备及存储介质
CN111245601A (zh) * 2019-12-18 2020-06-05 北京威努特技术有限公司 一种通讯协商方法及装置
CN115714681A (zh) * 2022-11-11 2023-02-24 中国联合网络通信集团有限公司 数据验证方法、装置及存储介质
CN115714681B (zh) * 2022-11-11 2024-05-14 中国联合网络通信集团有限公司 数据验证方法、装置及存储介质
CN115720176A (zh) * 2022-12-26 2023-02-28 南京汇荣信息技术有限公司 基于Socket通信报文内容的动态加密方法、系统
CN115720176B (zh) * 2022-12-26 2023-09-19 南京汇荣信息技术有限公司 基于Socket通信报文内容的动态加密方法、系统、网络设备及计算机可读存储介质

Also Published As

Publication number Publication date
CN109936529A (zh) 2019-06-25
CN109936529B (zh) 2021-12-31

Similar Documents

Publication Publication Date Title
WO2019114703A1 (zh) 一种安全通信的方法、装置和系统
US11792169B2 (en) Cloud storage using encryption gateway with certificate authority identification
AU2021201714B2 (en) Client(s) to cloud or remote server secure data or file object encryption gateway
US10069800B2 (en) Scalable intermediate network device leveraging SSL session ticket extension
US10341118B2 (en) SSL gateway with integrated hardware security module
JP4707992B2 (ja) 暗号化通信システム
JP4746333B2 (ja) コンピューティングシステムの効率的かつセキュアな認証
US11303431B2 (en) Method and system for performing SSL handshake
US11736304B2 (en) Secure authentication of remote equipment
US7631182B1 (en) Secure protocol handshake offload using TNICs
US20150156025A1 (en) Message sending and receiving method, apparatus, and system
CA3066728A1 (en) Cloud storage using encryption gateway with certificate authority identification
US20240146728A1 (en) Access control method, access control system, and related device
WO2017210852A1 (zh) 业务处理方法及装置
TWI828848B (zh) 資料傳送方法、通訊處理方法、通訊裝置以及通訊處理程式
WO2023241331A1 (zh) 物联网系统及其认证与通信方法、相关设备
WO2009030166A1 (fr) Procédé, système et équipement destinés à établir une association de sécurité
US11025728B2 (en) Methods for facilitating secure connections for an operating system kernel and devices thereof
WO2023024540A1 (zh) 处理报文、获取sa信息的方法、装置、系统及介质
US20220255911A1 (en) Method for Secure Communication and Device
JP2024525557A (ja) アクセス制御方法、アクセス制御システム、および関連デバイス
JP6228370B2 (ja) 通信装置、通信方法、及びプログラム

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: 18887331

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18887331

Country of ref document: EP

Kind code of ref document: A1