A V2X communication method and system

Abstract

This application proposes a V2X communication method and system, comprising: a client sending a ClientHello message in SPDU format to a server, the ClientHello message including the client's communication cipher suite and a signature message, the signature message including the client's certificate and client data signature value; the server responding to the client with a ServerHello message in SPDU format based on the ClientHello message, the ServerHello message including a target communication cipher suite determined by the server and the server certificate; the server verifying the client's identity based on the signature message and determining the server's communication transmission key based on the target communication cipher suite; the client determining its own communication transmission key based on the ServerHello message; and the client and server communicating with each other based on the client's communication transmission key and the server's communication transmission key, respectively.

Description

Technical Field

[0001] This application belongs to the field of vehicle networking technology, and in particular relates to a V2X communication method and system. Background Technology

[0002] With the rapid development of the Internet of Vehicles (IoV) technology, in the single-point communication process of vehicle-to-everything (V2X) wireless communication technology, encryption communication, similar to a digital envelope, is typically used to ensure data security during transmission. Single-point communication refers to the communication process where data is typically transmitted between two stations (point-to-point). However, when the client and server use digital envelopes for encryption, each communication requires both asymmetric and symmetric encryption, resulting in low communication efficiency and impacting user experience. Summary of the Invention

[0003] In view of this, embodiments of this application provide a V2X communication method and system to solve the problem of low communication efficiency in the single-point communication process of existing V2X scenarios.

[0004] A first aspect of this application provides a V2X communication method applied to a client in a V2X communication system. The method includes: sending a ClientHello message in SPDU stream format to a server, the ClientHello message including the client's communication cipher suite and a signature message, the signature message including the client certificate and the client data signature value; receiving a ServerHello message in SPDU stream format, the ServerHello message being generated by the server based on the ClientHello message; determining a client communication transmission key based on the ServerHello message; and communicating with the server based on the client communication transmission key.

[0005] In conjunction with the first aspect, in the first possible implementation of the first aspect, determining the client communication transmission key based on the ServerHello message includes: parsing the ServerHello message to obtain the server public key and the plaintext of the ServerHello message; generating a TLS client pre-master key based on the client public key, the server public key, and the plaintext of the ServerHello message; and determining the client communication transmission key based on the client pre-master key.

[0006] In conjunction with the first aspect, in the second possible implementation of the first aspect, before parsing the ServerHello message, the method further includes: if the ServerHello message verification fails, sending a verification error message to the server and disconnecting from the server.

[0007] In conjunction with the first aspect, in the third possible implementation of the first aspect, determining the client communication transmission key based on the client pre-master key includes: generating a client master key based on the client pre-master key; generating a client working key based on the client master key; and determining the client working key as the communication transmission key.

[0008] In conjunction with the first aspect, in the fourth possible implementation of the first aspect, after determining the client communication transmission key based on the ServerHello message and before communicating with the server based on the client communication transmission key, the method further includes: sending a password specification change message to the server, and encrypting the client handshake end message using the client pre-master key and the corresponding algorithm in the client pre-master key before sending it to the server.

[0009] A second aspect of this application provides a V2X communication method applied to a server in a V2X communication system. The method includes: receiving a ClientHello message in SPDU stream format sent by a client, the ClientHello message including the client's communication cipher suite and a signature message, the signature message including the client's certificate and a client data signature value; responding to the client with a ServerHello message in SPDU stream format based on the ClientHello message, the ServerHello message including a target communication cipher suite determined by the server and a server certificate; verifying the client's identity based on the signature message, and then determining a server communication transmission key based on the target communication cipher suite; and communicating with the client based on the client's communication transmission key.

[0010] In conjunction with the second aspect, in the first possible implementation of the second aspect, responding to the client with a ServerHello message based on the ClientHello message includes: parsing the ClientHello message to obtain the communication cipher suite carried in the ClientHello message; if the server successfully verifies the communication cipher suite, it responds to the client with a ServerHello message; if the server fails to verify the communication cipher suite, it sends a verification error message to the client and disconnects from the client.

[0011] In conjunction with the second aspect, in the second possible implementation of the second aspect, determining the server communication transmission key based on the target communication cipher suite includes: parsing the ClientHello message to obtain the client public key and the plaintext of the ClientHello message; generating a TLS server pre-master key based on the server public key, the client public key, the plaintext of the ClientHello message, and the target communication cipher suite, and determining the server communication transmission key based on the server pre-master key.

[0012] In conjunction with the second aspect, in the third possible implementation of the second aspect, determining the server communication transmission key based on the server pre-master key includes: generating a server master key based on the server pre-master key; generating a server working key based on the server master key; and determining the server working key as the communication transmission key.

[0013] In conjunction with the second aspect, in the fourth possible implementation of the second aspect, after determining the server communication transmission key based on the target communication cipher suite and before communicating with the client based on the client communication transmission key, the method further includes: responding to the client with a cipher specification change message, and encrypting the server handshake end message using the server pre-master key and the corresponding algorithm in the server pre-master key before sending it to the client.

[0014] A third aspect of this application provides a V2X communication system, including a client and a server: a client for sending a ClientHello message in SPDU format to the server, the ClientHello message including the client's communication cipher suite and a signature message, the signature message including the client certificate and the client data signature value; a server for responding to the client with a ServerHello message in SPDU format based on the ClientHello message, the ServerHello message including a target communication cipher suite determined by the server and a server certificate; the server is further configured to verify the client's identity based on the signature message and then determine a server communication transmission key based on the target communication cipher suite; the client is further configured to determine a client communication transmission key based on the ServerHello message; and the client is further configured to communicate with the server based on the client communication transmission key and the server communication transmission key respectively.

[0015] The beneficial effects of the embodiments of this application compared with the prior art are:

[0016] This application provides a V2X communication method and system applied to a client and a server. In this method, during the handshake interaction between the client and server, the ClientHello message sent by the client to the server is in SPDU stream format. This packet format allows the client certificate and signature message protocol fields to be embedded within the message. During interaction, the client and server do not need to send separate certificate and signature authentication messages, thus saving the interaction process. The handshake protocol is then completed based on the SPDU stream format ClientHello message to determine the final communication transmission password. After the client and server determine the communication transmission password, they can directly use the communication transmission key agreed upon during the handshake protocol to communicate. This saves the steps of symmetric and asymmetric encryption in each encrypted communication process, improving communication efficiency and enhancing the user experience. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of a single-point communication interaction process in a V2X scenario provided in one embodiment of this application;

[0019] Figure 2 This is a schematic diagram of an encrypted communication scenario between a client and a server provided in an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of the interaction process of a V2X communication method provided in an embodiment of this application;

[0021] Figure 4 This is a schematic diagram of the communication interaction process between the client and the server during secure data transmission, provided in an embodiment of this application. Detailed Implementation

[0022] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0023] The technical solutions provided in this application will be explained in detail below with reference to specific embodiments.

[0024] With the rapid development of communication technology, vehicles can connect to various electronic devices (such as roadside equipment, servers, and sensors) to form a vehicle network through cellular communication (vehicle-to-everything communication based on cellular technology) or direct communication (dedicated short-range communication technology). When vehicles communicate with individual electronic devices at a single point, such as between an onboard terminal and a server, or between an onboard terminal and roadside equipment, a client / server (C / S) communication model is typically used.

[0025] Figure 1 This is a schematic diagram of a single-point communication interaction process in a V2X scenario provided by an embodiment of this application. See also 5. Figure 1 As shown, the procedure includes the following steps S101 to S107.

[0026] S101. The client generates a client symmetric key based on the client's private key.

[0027] S102. The client uses its client symmetric key to encrypt the plaintext of the session message to be sent to the server, thus obtaining the ciphertext of the session message.

[0028] S103. The client obtains the server certificate and retrieves the server public key from the server certificate.

[0029] 0. When obtaining a server certificate, the client can obtain it from a publicly available certificate on the server side.

[0030] Alternatively, it can be obtained from the server certificate pre-stored on the client itself.

[0031] S104. The client uses the server's public key to encrypt the client's symmetric key, thus obtaining the client's symmetric key ciphertext.

[0032] In this embodiment, the process 5, where the client encrypts its symmetric key using the server's public key, is the process of generating a digital envelope. The server needs this digital envelope for subsequent decryption.

[0033] Decrypt.

[0034] S105. The client sends the ciphertext of the session message and the ciphertext of the client's symmetric key to the server.

[0035] S106. The server decrypts the client's symmetric key ciphertext using the server's private key to obtain the client's symmetric key.

[0036] 0S107. The server decrypts the ciphertext of the session message using the client's symmetric key to obtain the plaintext of the client's session message.

[0037] Figure 2 This is a schematic diagram illustrating an encrypted communication scenario between a client and a server, as provided in an embodiment of this application. See also... Figure 2 As shown, when the client communicates with the server in encrypted form, each communication requires asymmetric encryption (corresponding to...). Figure 1 The process of encrypting the client's symmetric key using the server's public key in the interaction flow is process 5. Figure 2 The digital envelope encryption process shown) and symmetric encryption (corresponding to) Figure 1 The process of generating a client symmetric key during the interaction flow is cumbersome, resulting in low communication efficiency and affecting user experience.

[0038] Based on this, this application provides a V2X communication method applied to a client and a server. During the handshake interaction between the client and server, the ClientHello message sent by the client to the server is in SPDU stream format. This packetization method allows the protocol fields of the client certificate and signature message to be embedded within the message. When the client and server interact, they do not need to send separate certificate and signature authentication messages, thus saving the interaction process. The handshake protocol is then completed based on the SPDU stream format ClientHello message to determine the final communication transmission password. After the client and server determine the communication transmission password, they can directly use the communication transmission key negotiated during the handshake protocol to communicate, thereby saving the steps of symmetric and asymmetric encryption in each encrypted communication process, improving communication efficiency and enhancing the user experience.

[0039] Figure 3 This is a schematic diagram of the interaction process of a V2X communication method provided in an embodiment of this application. See also... Figure 3 As shown, this method includes the following steps S301 to S309.

[0040] S301. The client sends a ClientHello message in SPDU stream format to the server.

[0041] In this embodiment, when the client and server interact with each other via hello messages, the ClientHello message sent by the client is composed of packets based on the Secure Protocol Data Unit (SPDU) stream format from the standard "TCCSA 307-2021 Technical Requirements for Security Certificate Management System of LTE-based Vehicle-to-Everything Wireless Communication Technology". The ClientHello message, composed of packets in this SPDU stream format, includes not only a communication cipher suite but also a signature message in SPDU stream format. The communication cipher suite includes client version information, a candidate list of cipher suites, a candidate list of compression algorithms, a client random number, extended fields, and other information.

[0042] The client version information refers to the highest Transport Layer Security (TLS) version supported by the client, ranging from low to high: SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2, etc. The cipher suite candidate list is a list of cipher suites supported by the client, including: authentication algorithm Au (for authentication), key exchange algorithm KeyExchange (for key negotiation), symmetric encryption algorithm Enc (for message encryption), and message digest Mac (for server integrity verification of cipher suites). The compression algorithm candidate list is a list of compression methods supported by the client, used for subsequent compressed message transmission. The random number random_C is used for subsequent key generation. The extensions field includes parameters related to supported protocols and algorithms, as well as other auxiliary information.

[0043] SPDU is a message structure used for transmission between V2X devices. Typically, a signed message in SPDU stream format consists of four parts: (i) a hash algorithm (hashId) indicating the hashing process used for signing and verification; (ii) the hashed data used as the input for signing (tbsData); (iii) the issuer's certificate (signer) used to sign the data; and (iv) the digital signature value (signature). Hashing refers to transforming an input of arbitrary length into a fixed-length output using a hash algorithm; this output is the hash value. In other words, when sending a ClientHello message in SPDU stream format, the protocol fields of the client certificate can be set in the signed message. For example, during the assembly of a ClientHello message using SPDU stream format, the corresponding protocol fields can be embedded in the appropriate message structure. For example, the protocol field of the hash algorithm (hashId) used by the client to hash the message during signing and verification is placed in the message structure of the signing message that indicates the hash algorithm (hashId) used for hashing the message during signing and verification; the protocol field of the client's data as input for signing (i.e., the ClientHello message protocol field) is placed in the message structure of the data (tbsData) used as input for signing after hashing in the signing message; the protocol field of the client's issuer certificate is placed in the message structure of the signing message that determines the issuer certificate (signer) used to sign the data; and the protocol field of the client's digital signature value is placed in the message structure of the digital signature value (signature) in the signing message.

[0044] Based on this, in this embodiment of the application, the ClientHello message is packaged in the form of SPDU code stream. On the one hand, the client certificate and client digital signature value can be embedded in the ClientHello message. On the other hand, the traditional standard communication method based on the TLS handshake protocol can be applied to the single-point communication process in the V2X scenario.

[0045] S302. The server verifies the received ClientHello message and responds to the client with a ServerHello message in SPDU code stream format.

[0046] When the server receives a ClientHello message from the client, it verifies the ClientHello message, which is packetized in SPDU stream format. If the verification fails, a fatal error is generated and the connection with the client is closed. If the verification succeeds, the server responds to the client with a ServerHello message. Similarly, the ServerHello message is also packetized in SPDU stream format.

[0047] When the server verifies the ClientHello message, it can use a 5-factor error code defined by the server itself. For example, if the server defines error code A, and an error code A is generated when verifying the ClientHello message, the verification is considered to have failed, the server and client cannot communicate, and the server will disconnect from the client.

[0048] Because the ClientHello message in SPDU format sent by the client to the server carries the client's...

[0049] The client certificate (used by the server to identify the client), the client data signature value (used by the server to authenticate the client), and the hash algorithm (hashId) used to hash the message when indicating signature and verification, along with the hashed data as the signature input, mean that after receiving this ClientHello message, the server does not need to send a certificate request message to the client to verify the client's identity. This is in contrast to the traditional handshake protocol, where the handshake operation between the client and server requires...

[0050] Additionally, a certificate request message for client certificate verification is sent to the client. After receiving the certificate request message from the server, the client also needs to send a certificate message to the server. In this embodiment, this is done after the hello message has already been sent.

[0051] The process of sending and verifying certificates has been completed, saving the protocol handshake process and improving handshake efficiency.

[0052] As can be seen, this embodiment uses the SPDU bitstream format to assemble the ClientHello field (i.e., the ClientHello message) into packets, which allows the client to complete the process with a single interaction between the client and the server.

[0053] The two handshakes between the server and the client, via the ClientHello message and the subsequent certificate exchange request, omit the entire steps of the TLS handshake protocol, shortening the handshake process and improving communication efficiency.

[0054] S303. The server parses the received ClientHello message to obtain the client's public key and the plaintext of the ClientHello message.

[0055] The server parses the ClientHello message in SPDU bitstream format. Because the SPDU bitstream format...

[0056] The ClientHello message contains the client's certificate; therefore, the server can obtain the client's public key based on the parsed client certificate. Then, it can decrypt the ClientHello message using the client's public key.

[0057] Generate a plaintext ClientHello message.

[0058] In addition, the server parses the ClientHello message in SPDU code stream format to obtain the communication cipher suite included in the ClientHello message. Then, based on the communication cipher suite, the server determines the target communication cipher suite, which includes the client version determined by the server, the target cipher suite, the compression algorithm, the random number, and extended fields, etc.

[0059] S304. The server generates a TLS server pre-master key based on the server public key, the client public key, the plaintext of the ClientHello message, and the target communication cipher suite.

[0060] The ServerKeyExchange is used to generate the server master key, server working key, etc. This method can enhance the confidentiality of the communication process.

[0061] S305. The server responds to the client with a password specification change message and encrypts the server handshake end message using the server pre-master key and the corresponding algorithm in the server pre-master key before sending it to the client.

[0062] S306. The client verifies the received ServerHello message.

[0063] The client verifies the received ServerHello message. If verification fails, a fatal error is generated and the connection with the server is closed. If verification succeeds, the client replies with subsequent messages to the server.

[0064] S307. The client parses the received ServerHello message to obtain the server's public key and the plaintext of the ServerHello message.

[0065] Similarly, the ServerHello message returned by the server to the client is also sent in SPDU stream format. Therefore, after receiving the ServerHello message, the client first parses it. Since the server hello message in SPDU stream format also carries the server certificate, the client can obtain the server's public key based on the parsed server certificate. Then, the client uses this server public key to parse the ServerHello message and generate the plaintext ServerHello message.

[0066] S308. The client generates a TLS client pre-master key based on the client's public key, the server's public key, and the plaintext of the ServerHello message.

[0067] Similarly, this client pre-master key is used to generate the client master key, client working key, etc.

[0068] S309. The client sends a password specification change message to the server, and encrypts the client handshake end message using the client pre-master key and the corresponding algorithm in the client pre-master key before sending it to the server.

[0069] In this embodiment, after the client and server send each other a client handshake end message and a server handshake end message, respectively, the client and server are ready for encrypted communication. Then, when the client and server conduct encrypted communication, they can use the key negotiated in the above manner for secure data transmission.

[0070] It should be noted that after the client and server each generate a pre-master key, this pre-master key is used to generate the master key, working key, etc. Therefore, during the key negotiation process, the client and server can choose the type of communication transmission key used for encrypted communication, such as the working key.

[0071] Figure 4 This is a schematic diagram of the communication interaction process between the client and server during secure data transmission, provided in an embodiment of this application. (See attached diagram.) Figure 4 As shown, the method includes the following steps S401 to S403. The following explanation uses the communication transmission key type negotiated between the client and server for encrypted communication as the working key.

[0072] S401. The client encrypts the plaintext of the client session message using the client working key to obtain the ciphertext of the client session message.

[0073] S402. The client sends the encrypted client session message to the server.

[0074] S403. The server decrypts the ciphertext of the client session message using the server working key to obtain the plaintext of the client session message.

[0075] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0076] This application also provides a V2X communication system applied to a client and a server in a V2X communication system: The client is used to send a ClientHello message in SPDU code stream format to the server. The ClientHello message includes the client's communication cipher suite and a signature message, the signature message including the client certificate and the client data signature value; The server is used to respond to the client with a ServerHello message in SPDU format based on the ClientHello message. The ServerHello message includes a target communication cipher suite determined by the server and a server certificate; The server is also used to verify the client's identity based on the signature message and then determine the server communication transmission key based on the target communication cipher suite; The client is also used to determine the client communication transmission key based on the ServerHello message; The client is also used to communicate with the server based on the client communication transmission key and the server communication transmission key respectively.

[0077] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0078] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0079] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0080] In the embodiments provided in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0081] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0082] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0083] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by hardware related to computer program instructions. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0084] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A V2X communication method, characterized in that, The method, applied to a client in a V2X communication system, includes: Send a ClientHello message in SPDU stream format to the server. The ClientHello message includes the client's communication cipher suite and signature message. The signature message includes the client certificate and the client data signature value. Receive a ServerHello message in SPDU bitstream format, wherein the ServerHello message is generated by the server based on the ClientHello message; The ServerHello message is parsed to obtain the server public key and the plaintext of the ServerHello message; Generate a TLS client pre-master key based on the client public key, the server public key, and the plaintext of the ServerHello message; Generate a client master key based on the client pre-master key; A client working key is generated based on the client master key, and the client working key is determined as the client communication transmission key; Send a password specification change message to the server, and encrypt the client handshake end message using the client pre-master key and the corresponding algorithm in the client pre-master key before sending it to the server; The client communicates with the server using the communication transmission key.

2. The method according to claim 1, characterized in that, Before parsing the ServerHello message, the method further includes: If the ServerHello message fails to be verified, a verification error message is sent to the server, and the connection with the server is disconnected.

3. A V2X communication method, characterized in that, The method, applied to a server in a V2X communication system, includes: Receive a ClientHello message in SPDU code stream format sent by the client. The ClientHello message includes the client's communication cipher suite and signature message. The signature message includes the client certificate and the client data signature value. Based on the ClientHello message, the server responds to the client with a ServerHello message in SPDU stream format, the ServerHello message including the target communication cipher suite determined by the server and the server certificate; After verifying the client's identity based on the signature message, the ClientHello message is parsed to obtain the client's public key and the plaintext of the ClientHello message; Based on the server public key, the client public key, the plaintext of the ClientHello message, and the target communication cipher suite, a TLS server pre-master key is generated, and the server communication transmission key is determined based on the server pre-master key. The server responds to the client with a password specification change message and encrypts the server handshake end message using the server pre-master key and the corresponding algorithm in the server pre-master key before sending it to the client; The server communicates with the client using the communication transmission key.

4. The method according to claim 3, characterized in that, The method further includes: If the server fails to verify the communication cipher suite, it sends a verification error message to the client and disconnects from the client.

5. The method according to claim 4, characterized in that, The step of determining the server communication transmission key based on the server pre-master key includes: Generate the server master key based on the server pre-master key; A server working key is generated based on the server master key, and the server working key is determined as the server communication transmission key.

6. A V2X communication system, characterized in that, Including clients and servers in a V2X communication system: The client is used to send a ClientHello message in SPDU code stream format to the server. The ClientHello message includes the client's communication cipher suite and a signature message. The signature message includes the client certificate and the client data signature value. The server is configured to respond to the client with a ServerHello message in SPDU format based on the ClientHello message. The ServerHello message includes the target communication cipher suite determined by the server and the server certificate. The client is also used to parse the ServerHello message to obtain the server public key and the plaintext of the ServerHello message; and to generate a TLS client pre-master key based on the client public key, the server public key, and the plaintext of the ServerHello message. Generate a client master key based on the client pre-master key; A client working key is generated based on the client master key, and the client working key is determined as the client communication transmission key; a password specification change message is sent to the server, and the client handshake end message is encrypted using the client pre-master key and the corresponding algorithm in the client pre-master key before being sent to the server; The server is further configured to: verify the client's identity based on the signature message; parse the ClientHello message to obtain the client's public key and the plaintext of the ClientHello message; generate a TLS server pre-master key based on the server's public key, the client's public key, the plaintext of the ClientHello message, and the target communication cipher suite; determine the server communication transmission key based on the server pre-master key; respond to the client with a cipher specification change message; and encrypt the server handshake end message using the server pre-master key and the corresponding algorithm in the server pre-master key before sending it to the client. The client is also used to communicate with the server using the client communication transmission key and the server communication transmission key, respectively.

Images