CN118101607A

CN118101607A - Data synchronization method, method for synchronizing fresh values and corresponding system

Info

Publication number: CN118101607A
Application number: CN202211490326.8A
Authority: CN
Inventors: 徐婧
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2022-11-25
Filing date: 2022-11-25
Publication date: 2024-05-28

Abstract

The application discloses a data synchronization method, which is applied to a vehicle-mounted communication system based on bus communication, and comprises the steps that a sender electronic control unit sends a first request, wherein the first request comprises a first certificate preset in the sender electronic control unit; the receiver electronic control unit receives the first request and verifies the first certificate through a root certificate preset in the receiver electronic control unit; in the case of verification passing, the receiving electronic control unit generates a session key and a first random number, encrypts the session key and the first random number with the initial key to form a feedback message and transmits the feedback message; the sender electronic control unit receives and decrypts the feedback message with the initial key, thereby obtaining the session key and the first random number.

Description

Data synchronization method, method for synchronizing fresh values and corresponding system

Technical Field

The present application relates to bus-based communication technology, and more particularly to data synchronization and freshness value synchronization technology.

Background

With the increase of the demand of the automobile for network information, the vehicle-mounted CAN network gradually opens an interface, so that the information security attack from the outside CAN be led into the CAN bus network of the automobile through a wireless network (Bluetooth or wireless local area network) or an online diagnosis interface, thereby causing serious consequences such as illegal monitoring of CAN messages, malicious modification of the CAN messages, rebroadcasting and the like. In this case, an information security protection mechanism for in-vehicle network communication becomes more and more important.

To prevent such attacks of malicious interception, modification, etc., in a secure on-board communication (Secure Onboard Communication, secOC) mechanism, such as an automotive open system architecture (AUTomotive Open System Architecture, AUTOSAR), a method of secure communication under CAN bus protocol is provided. However, these are all common measures, and cannot cope with diversified and evolving attacks.

Publication number CN112688845A discloses a communication method and device of the vehicle network. According to the disclosure of this application, in the communication based on the CAN network, the sender acquires the first key and the current freshness value of the vehicle-mounted CAN network, splices the acquired first key and the current freshness value, then determines the second key with the splicing result and the data length of the CAN data to be sent as references, and finally encrypts the CAN data to be sent by using the second key.

The publication number CN113132082A also discloses a communication method and a device for the in-vehicle network. According to the disclosure, a first ECU generates a key stream based on a first key and a first freshness value, generates a first ciphertext message by exclusive-or operation of the key stream and a message plaintext to be transmitted, and transmits the first ciphertext message to a second ECU. Thus, the first ciphertext message is used for preventing the message from being eavesdropped.

Disclosure of Invention

An aspect of the present application is to provide a data synchronization method applied to a vehicle-mounted communication system based on bus communication. The data synchronization method comprises the following steps: the method comprises the steps that a sender electronic control unit sends a first request, wherein the first request comprises a first certificate preset in the sender electronic control unit; the receiver electronic control unit receives the first request and verifies the first certificate through a root certificate preset in the receiver electronic control unit; in the event that the first certificate is verified, the recipient electronic control unit generates a session key and a first random number Nonce ₁ and encrypts the session key and the first random number Nonce ₁ with an initial key to form a feedback message; the receiver electronic control unit sends the feedback message; the sender electronic control unit receives and decrypts the feedback message with the initial key to obtain the session key and the first random number Nonce ₁. Wherein the initial key is preset at the sender electronic control unit and is included in the first request to be sent to the receiver electronic control unit; or the initial key is preset in the sender electronic control unit and the receiver electronic control unit.

The data synchronization method according to this example, further comprising: the sender electronic control unit generates a fresh value; and the sender electronic control unit sends the fresh value to an electronic control unit to be synchronized in the receiver electronic control unit through the session key. As an example, the sender electronic control unit generating a freshness value includes: generating a freshness value by the sender electronic control unit in case the sender electronic control unit itself is the electronic control unit to be synchronized; and judging the electronic control unit of the receiving party as the electronic control unit to be synchronized at the electronic control unit of the transmitting party, wherein the electronic control unit of the transmitting party generates a fresh value.

Another aspect of the present application is directed to a method of synchronizing freshness values for use in a bus communication based communication system, the method comprising: generating a freshness value by a sender electronic control unit;

The sender electronic control unit sends the freshness value via a session key, wherein the session key is shared by the sender electronic control unit and the receiver electronic control unit.

A further aspect to which the present application relates is to provide an electronic control unit applied to a vehicle-mounted communication system based on bus communication, the electronic control unit comprising: a sending module, configured to send a first request when the electronic control unit is used as a sender electronic control unit, where the first request includes a first certificate preset in the electronic control unit; a receiving module, configured to receive a feedback message for the first request, where the feedback message includes a session key encrypted with an initial key and a first random number Nonce ₁; and a decryption module for decrypting the feedback information with the initial key to obtain the session key. The initial key is preset in the electronic control unit. In one case, the initial key is included in the first request. Alternatively, the initial key need not be included in the first request, in which case the electronic control unit receiving the first request also presets the initial key.

The electronic control unit according to this example is further configured to include: the true random number generation module is used for generating a second random number Nonce ₂; a processing module that calculates a function value f ₁(Nonce₁ of a first function f ₁ (x) using the first random number Nonce ₁ as a variable; an encryption module for encrypting a message containing the f ₁(Nonce₁) and the second random number Nonce ₂ using the session key and transmitting through a transmission module.

The electronic control unit according to this example, wherein the processing module is further configured to calculate a current function value f ₂(Nonce₂), compare said current function value f ₂(Nonce₂) with a function value f ₂(Nonce₂) obtained from decryption from said received message representing verification pass, and in case said current function value f ₂(Nonce₂) and said function value f ₂(Nonce₂) are identical, said sender electronic control unit stores said session key.

A further aspect to which the present application relates is to provide an electronic control unit applied to a vehicle-mounted communication system based on bus communication, the electronic control unit comprising: a receiving module for receiving a first request including a first certificate when the electronic control unit is a receiving electronic control unit; the certificate verification module is used for verifying the first certificate through a preset root certificate; the true random number generation module is used for generating a first random number Nonce ₁; the key generation module is used for generating a session key; an encryption module configured to encrypt the session key and the first random number Nonce ₁ with an initial key, thereby forming a feedback message; and the sending module is used for sending the feedback message.

The electronic control unit according to this example, further comprising: a decryption module for decrypting the received message with the session key to obtain a function value f ₁(Nonce₁) and a second random number Nonce ₂; a processing module for judging the reliability of the received message based on one or both of the previously stored second random number Nonce _2-old and the current function value f ₁(Nonce₁), and returning a message representing a confirmation result accordingly, wherein the current function value f ₁(Nonce₁) is a function value calculated by the electronic control unit with the first random number Nonce ₁ as a variable of the first function f ₁ (x).

The electronic control unit according to this example, wherein the processing module is configured to compare a previously stored second random number Nonce _2-old with said second random number Nonce ₂ obtained by decryption; if the comparison result is that the second random number Nonce _2-old is different from the second random number Nonce ₂, comparing the current function value f ₁(Nonce₁) with the function value f ₁(Nonce₁) obtained by decryption; if the current function value f ₁(Nonce₁) is the same as the function value f ₁(Nonce₁) obtained by decryption, the second random number Nonce ₂ obtained by decryption is stored as a new second random number Nonce _2-old. And sending, by the module, the message indicating that the verification is passed.

The present application also provides another exemplary data synchronization method applied to a sender electronic control unit in a vehicle-mounted communication system based on bus communication, the method comprising: issuing a first request, wherein the first request comprises a first certificate preset at the sender control unit; receiving a feedback message for the first request; the feedback message is decrypted with the initial key to obtain the session key and the first random number Nonce ₁. The initial key is preset in the sender electronic control unit. In one case, the initial key is included in the first request. Alternatively, the initial key need not be included in the first request, in which case the electronic control unit receiving the first request also presets the initial key.

The data synchronization method applied to the sender electronic control unit according to this example further includes: generating a second random number Nonce ₂ and calculating a function value f ₁(Nonce₁ of a first function f ₁ (x) using the first random number Nonce ₁ as a variable; encrypting and transmitting a message containing the f ₁(Nonce₁) and the second random number Nonce ₂ using the session key. Further, the method may further comprise: calculating a current function value f ₂(Nonce₂); -comparing said current function value f ₂(Nonce₂) with a function value f ₂(Nonce₂) obtained by decryption from said received message representing verification pass, wherein said current function value f ₂(Nonce₂) is a function value f ₂(Nonce₁) obtained by calculation by the electronic control unit of said second random number Nonce ₂ as a variable of a second function f ₂ (x); in case the current function value f ₂(Nonce₂) and the function value f ₂(Nonce₂) are the same, the sender electronic control unit stores the session key.

The present application also provides another exemplary data synchronization method applied to a receiver electronic control unit in a vehicle-mounted communication system based on bus communication, the method comprising: receiving a first request comprising a first certificate, and verifying the first certificate through a preset root certificate; generating a session key and a first random number Nonce ₁ if the first certificate is authenticated and encrypting the session key and the first random number Nonce ₁ with an initial key to form a feedback message; sending the feedback message; wherein the initial key is preset in the recipient electronic control unit or the initial key is included in the first request.

The data synchronization method applied to the receiving electronic control unit according to this example further includes: decrypting the received message with the session key, thereby obtaining the function value f ₁(Nonce₁) and the second random number Nonce ₂; and judging the reliability of the received message based on one or both of the previously stored second random number Nonce _2-old and the current function value f ₁(Nonce₁), and returning a message representing a confirmation result to the electronic control unit that issued the first request accordingly, wherein the current function value f ₁(Nonce₁) is a function value f ₁(Nonce₁ calculated by the electronic control unit with the first random number Nonce ₁ as a variable of the first function f ₁ (x). Further, judging the reliability of the received message based on one or both of the previously stored second random number Nonce _2-old and the current function value f ₁(Nonce₁), and returning a message representing a confirmation result to the sender electronic control unit accordingly, comprising: comparing a previously stored second random number Nonce _2-old with the second random number Nonce ₂ obtained by decryption; if the comparison result is that the second random number Nonce _2-old is different from the second random number Nonce ₂, comparing the current function value f ₁(Nonce₁) with the function value f ₁(Nonce₁) obtained by decryption; if the current function value f ₁(Nonce₁) is the same as the function value f ₁(Nonce₁) obtained by decryption, storing the second random number Nonce ₂ obtained by decryption as a new second random number Nonce _2-old; and encrypting a message containing a representation of a function value f ₂(Nonce₂) that passes authentication with the session key, wherein the function value f ₂(Nonce₂) is a function value obtained by the electronic control unit with a second random number Nonce ₂ as a variable of a second function f ₂ (x); and transmitting the message indicating that the verification is passed.

According to the present application, there are provided the respective data synchronization methods, the method of synchronizing freshness values, the respective electronic control units, etc. as described above, which are applied to a vehicle employing a secure on-vehicle communication mechanism of an automobile open system architecture.

Other aspects and features of the present application will become apparent from the following detailed description, which refers to the accompanying drawings. It is to be understood that the drawings are designed solely for purposes of illustration and not as a definition of the limits of the application, for which reference should be made to the appended claims. It should be further understood that the drawings are merely intended to conceptually illustrate the structures and procedures described herein and that, unless otherwise indicated, the drawings are not necessarily drawn to scale.

Drawings

The present application will be more fully understood from the following detailed description of the specific embodiments, taken in conjunction with the accompanying drawings, in which like reference numerals refer to like elements throughout the views. Wherein:

FIG. 1 is an exemplary in-vehicle CAN bus communication system;

fig. 2 is a schematic structural view of a TEE module 2 according to an example of the present application;

FIG. 3 is a flow chart of a data synchronization method according to one illustrative example of the application;

fig. 4 is a schematic configuration diagram of a system constituted by a master node ECU and a slave node ECU in a bus-based communication system;

FIG. 5 is a schematic block diagram of another system in which a sender ECU and a receiver ECU are configured in a bus-based communication system;

FIG. 6 is a flow chart of yet another exemplary data synchronization method in accordance with the present application;

FIG. 7 is a flow chart of a data synchronization method according to the present application applied in a vehicle employing SecOC and to a UDS 27 service;

FIG. 8 is a flow chart of a method of synchronizing fresh values according to one illustrative example of the application;

FIG. 9 is a flowchart of a method of synchronizing fresh values in accordance with an illustrative example of the present application;

FIG. 10 is a schematic diagram of the structure of a freshness value according to an illustrative example of the present application;

fig. 11 is a flow chart of a data synchronization method according to the present embodiment;

fig. 12 is a schematic structural view of an electronic control unit according to an illustrative example of the present application; and

Fig. 13 is a schematic structural view of an electronic control unit according to still another illustrative example of the application.

Detailed Description

In order to assist those skilled in the art in a proper understanding of the claimed subject matter, certain embodiments of the present application will be schematically described below with reference to the accompanying drawings.

The present application provides a data synchronization method applied in a communication system based on bus communication. By way of example and not limitation, the synchronization method provided by the present application may be applied in a CAN bus based communication system. Further, the application CAN be applied to in-vehicle communication based on the CAN bus. The following examples illustrate the application of the application to in-vehicle communication based on a CAN bus, i.e. the method may be performed, for example, by an electronic control unit (Electronic Control Unit, ECU) in the vehicle, a gateway provided in the vehicle, etc. It should be noted that other communication means, which may communicate with a control system of the vehicle, such as a smart cabin system or the like, for example, may also perform the synchronization method.

Fig. 1 is an exemplary in-vehicle CAN bus communication system. As shown, the system includes, for example, a gateway 10, a vehicle control system 12, an infotainment system 14, an intelligent cockpit system 16, a diagnostic system 18, and the like. Each system may include one or more ECUs that communicate with each other via a CAN bus.

In the following examples of the application, each ECU is provided with a security module, which is a trusted execution environment (Trusted Execution Environment, TEE). For convenience, the security module of the trusted execution environment will be hereinafter simply referred to as TEE module. Such TEE modules are, for example, hardware security modules (Hardware Security Module, HSM).

According to an example of the present application, TEE modules provided in each ECU may be used to store encryption functions, handle security-sensitive operations. Fig. 2 is a schematic structural view of a TEE module according to an example of the present application. The TEE module includes a certificate verification module 20, a secure data storage module 22, a true random number generation module 24, a key generation module 26, and an encryption and decryption module 28.

The certificate verification module 20 may be used to verify certificates received from other ECUs, such as verification of a first certificate with a root certificate as will be discussed below. The secure data storage module 22 may be used to store data relating to various examples of the present application. The true random number generation module 24 may be used to generate true random numbers. The key generation module 26 may be used to generate keys, session keys as referred to in the discussion below, and the like. Encryption and decryption module 28 may be used to perform encryption or decryption of data or messages.

Fig. 3 is a flow chart of a data synchronization method according to one illustrative example of the application. In this example, the method is applied to an in-vehicle communication system based on bus communication, such as the system shown in fig. 1. Referring to fig. 3, in step S300, a sender electronic control unit (i.e., a sender ECU) issues a first request including a first certificate preset in the sender ECU. In step S302, the receiver electronic control unit (i.e., receiver ECU) receives the first request and verifies the first certificate through a root certificate preset in the receiver ECU. In step S304, when the first certificate passes, the receiving ECU generates a session key and a first random number Nonce ₁, and the flow proceeds to step S306. If the verification is not passed, the recipient ECU may return a message, e.g., "failed," to the sender ECU indicating that the verification is not passed. In step S306, the receiving ECU encrypts the session key and the first random number Nonce ₁ with an initial key to form a feedback message and transmits it. In step S308, the sender ECU receives the feedback message and decrypts the feedback message with the initial key, thereby obtaining the session key and the first random number Nonce ₁ generated by the receiver ECU. As for the initial key, it is set in advance in the sender ECU and is included in the first request to be sent by the sender ECU to the receiver ECU. Or the initial key may be preset in both the sender ECU and the receiver ECU.

The receiving ECU verifies the first certificate transmitted by the transmitting ECU through a preset root certificate to authenticate the transmitting ECU, and the first certificate may be a derivative certificate of the root certificate as an example. In the case that the authentication is passed, the receiving ECU encrypts the session key generated by it with the initial key and transmits it to the transmitting ECU. This allows the sender ECU to obtain a session key that is only between the sender ECU and the receiver ECU after receiving and decrypting the encrypted information. Accordingly, since the session keys belonging only to the two ECUs are employed, secure communication based on the session keys is enabled therebetween.

Herein, the sender ECU refers to an ECU that is not a certain specific ECU of the in-vehicle communication system, but an ECU that arbitrarily issues the first request, and similarly, the receiver ECU is not a certain specific ECU in the vehicle, but an ECU that receives the first request. That is, the ECU that is the sender in the example of the present application may be the sender ECU in a certain session, and the receiver ECU in the case where the first request is initiated thereto by the other ECU another time.

Although the present application is described with one ECU as the receiving-side ECU that receives the first request in connection with the example of fig. 3 and the example to be described later, it is possible that a plurality of ECUs receive the same first request, that is, that a plurality of receiving-side ECUs receive the first request from the same transmitting-side ECU at the same time, in accordance with the spirit of the present application. In this case, the session keys respectively generated by the plurality of ECUs may be the same, and one session key is shared between the sender ECU and the plurality of receiver ECUs; the session keys generated by each of the plurality of ECUs may also be different, and accordingly, there is one session key for each of the sender ECU and the plurality of receiver ECUs.

The sender ECU in each example of the present application may be a master ECU or a slave ECU. The master node ECU may perform the method as described in the present application as a sender and the slave node ECU may perform the method as a sender ECU.

Fig. 4 is a schematic configuration diagram of a system constituted by a master node ECU and a slave node ECU in the bus-based communication system. As shown in the figure, in this configuration, an ECU 40 as a master node (hereinafter referred to as master node ECU) distributes a session key to each slave ECU, such as ECU 41 numbered a, ECU 43 numbered B, and the like. Such a master node ECU may be a gateway or a domain controller. In this example, in the communication process of distributing the session key, the master node ECU 40 is the sender key, and each of the slave node ECUs 41, 43 is the receiver ECU.

Fig. 5 is a schematic structural diagram of a system constructed of another sender ECU and receiver ECU in a bus-based communication system. This example shows four ECUs, ECU 1, ECU 2, ECU 3, and ECU 4, respectively. Each ECU may be either a sender or a receiver, depending on who the session of synchronized data originated from, as described herein, the sender is typically the sender ECU in the session.

Two of each ECU are drawn in fig. 5 for the purpose of more clearly illustrating the communication relationship between each ECU and the other ECU and not for other limitations. As shown in the figure, ECU 1 may establish communication with ECU 2, ECU 3, ECU 4, respectively, as a sender, constructing session keys belonging to each other. Similarly, the ECU 2 may establish communication with the ECU 1, the ECU 3, the ECU 4, respectively, as a sender, constructing session keys belonging to each other; here, the ECU 1 is the receiving ECU and the ECU 2 is the transmitting ECU. The relationship between the ECU 3 and other ECU and the relationship between the ECU 4 and other ECU are similar, and will not be described again.

According to an example of the present application, root certificates may be preset in each ECU and stored in their respective TEE modules. The root certificate may be used to verify a first certificate derived from the root certificate from an ECU of the other party.

Referring to fig. 2 and 3, the certificate verification module 20 in the TEE module of the receiving ECU verifies (S302) the received first certificate of the transmitting ECU with the root certificate stored in the secure storage module 22. If the verification is passed, the true random number generation module 24 in the TEE module of the recipient ECU generates (S304) a first random number Nonce ₁, and the key generation module 26 generates (S304) a session key. Next, the encryption/decryption module 28 in the TEE module of the receiving ECU encrypts the first random number Nonce ₁ and the session key using the initial key (S306) to form a feedback message. The sender ECU receives the feedback message and decrypts (S308) the feedback message using the initial key, thereby obtaining the first random number Nonce ₁ and the session key. In the present example, the session key may still employ a symmetric key.

Fig. 6 is a flow chart of yet another exemplary data synchronization method according to the present application, which example includes further interaction between the sender ECU and the receiver ECU as compared to the data synchronization method shown in fig. 3. Steps S400 to S408 shown in fig. 6 correspond to steps S300 to S308, respectively, and for brevity, these steps will not be described in the description of the present example. Referring to fig. 6, in step S410, the sender ECU generates a second random number Nonce ₂, and calculates a function value f ₁(Nonce₁ using the first random number Nonce ₁ as a variable of a first function f ₁ (x). In step S412, the sender ECU encrypts a message containing the function value f ₁(Nonce₁) and the second random number Nonce ₂ using the session key, and sends the message to the receiver ECU. In step S414, the receiving ECU decrypts the received message with the session key, thereby obtaining the function value f ₁(Nonce₁) and the second random number Nonce ₂. In step S416, the receiving-side ECU judges the reliability of the received message based on the previously stored second random number Nonce _2-old, or based on the current function value f ₁(Nonce₁), or based on both the second random number Nonce _2-old and the current function value f ₁(Nonce₁) and returns a message representing the confirmation result to the transmitting-side ECU in accordance therewith. Reliability refers to whether a received message is subject to modification, replay (replay) attacks, etc. during transmission. In particular examples of the application, reliability refers primarily to whether a transmitted message, information, data, etc. is subject to replay (replay) attacks, and if so, the transmitted message, information, data, etc. is deemed unreliable, and vice versa. The previously stored second random number Nonce _2-old is a second random number Nonce ₂ used when the session of the session key is successfully synchronized between the sender ECU and the receiver ECU, and as an example, the preset value of Nonce _2-old may be 0.

Here, "current function value f ₁(Nonce₁" refers to a function value f ₁(Nonce₁ calculated by the receiving ECU with the first random number Nonce ₁ as a variable of the first function f ₁ (x). Although the function values are all calculated with Nonce ₁ as the variable of the first function f ₁ (x), since the "current function value f ₁(Nonce₁" and the function value f ₁(Nonce₁) are calculated by different ECUs, it is possible to determine whether or not the transmitted message is subject to replay attack by comparing whether or not the two are identical. Specifically, if the function value f ₁(Nonce₁) is the same as the current function value f ₁(Nonce₁), it indicates that the message sent by the sender ECU is not subject to replay attack, and the verification is passed; if the two are different, it is indicated that the message sent by the sender ECU is subject to replay attack, etc., and the verification is not passed. The random number Nonce _2-old is the second random number stored last time the session key was successfully established between the sender ECU and the receiver ECU. In an example of the present application, if the Nonce _2-old is the same as the Nonce ₂, then the explanation may be replay-attacked, verifying as not passing. If Nonce ₂ is different than Nonce _2-old, then the verification passes.

In some examples, in step S416, it may be determined whether the information is under replay attack based only on comparing the previously stored random number Nonce _2-old with the received Nonce ₂.

In other examples, in step S416, it may be determined whether the information is subject to replay attack based on only comparing the current function value f ₁(Nonce₁) and the function value f ₁(Nonce₁).

In a specific example of the present application, the comparison in step S416 is based on both the second random number Nonce ₂ and the function value f (Nonce ₁), and only if the comparison results based on both indicate that the authentication is passed, the message is confirmed not to be subjected to replay attack.

For example, the recipient ECU first compares the previously stored second random number Nonce _2-old with the decrypted second random number Nonce ₂, and confirms whether or not the verification is passed based on the comparison result. If the verification based on the second random number Nonce ₂ is passed, further comparing whether the current function value f ₁(Nonce₁) is the same as the function value f ₁(Nonce₁) obtained by decryption; if the current function value f ₁(Nonce₁) is the same as the function value f ₁(Nonce₁), the verification is passed, and the process proceeds to step S418. Here, if the authentication based on the second random number is not passed, the authentication based on the function value f ₁(Nonce₁) may not be performed any more, and the receiving side ECU may directly return a message indicating that the authentication has failed to the transmitting side ECU. The receiving ECU may also return a message indicating that the authentication failed to the transmitting ECU if the authentication based on the second random number passes but the authentication based on the function value f ₁(Nonce₁) fails.

In step S418, after the authentication performed in step S416 is passed, the receiver ECU marks the second random number Nonce ₂ obtained by decryption as a new Nonce _2-old, encrypts a message indicating that the authentication is passed including the function value f ₂(Nonce₂) with the session key and transmits the message to the sender ECU. Wherein the function value f ₂(Nonce₂) is a function value calculated by the receiving ECU with the second random number Nonce ₂ as a variable of the second function f ₂ (x).

In step S420, the sender ECU calculates a current function value f ₂(Nonce₂) with the second random number Nonce ₂ as a variable of the second function f ₂ (x), compares the current function value f ₂(Nonce₂) with the function value f ₂(Nonce₂) obtained by decryption, and stores the session key in the case where they are the same. The stored session key will be used in the communication of the sender ECU and the receiver ECU before either party initiates a new session key synchronization between the two ECUs.

Furthermore, in examples of the present application, the first function f ₁ (x) and the second function f ₂ (x) may be the same function or may be different depending on the specific application. In the present example, the first function f ₁ (x) and the second function f ₂ (x) are preset in the respective ECUs. In the description herein, function value f ₁(Nonce₁) is also written directly as f ₁(Nonce₁), while function value f ₂(Nonce₂) is also written directly as f ₂(Nonce₂).

The data synchronization method described in connection with fig. 6 can be used in diagnostic services, for example in the 27 (UDS 27) service of UDS diagnostics. Fig. 7 is a flowchart of a data synchronization method according to the present application applied in a vehicle employing SecOC and to a UDS 27 service.

Referring to fig. 7, in step S500, the sender ECU 50 issues an access request to the receiver ECU 52, the access request including the self-ID of the sender ECU 50 and the sender certificate Cert _ECU-sender. For example, in the present application, the sender ECU 50 is a sender, and the format of the access request it sends may be ID _SA-req1+Cert_ECU-sender. In this example, the access request also includes an initial key (hereinafter also referred to as Ikey), which initial key Ikey may be included in the sender credential.

According to an example of the present application, a root certificate, hereinafter also referred to as Cert _Root, is preset in the TEE module of each ECU, while both the sender certificate Cert _ECU-sender and the receiver certificate Cert _ECU-receiver referred to below are sub-certificates derived from the root certificate Cert _Root. Thus, the root certificate Cert _Root is also used to verify the sender certificate Cert _ECU-sender or to verify the receiver certificate Cert _ECU-receiver.

In step S502, the receiver ECU 52 receives the access request transmitted by the sender ECU 50, and verifies the access request by the preset root certificate Cert _Root. If the authentication fails, a message may be returned indicating that the access request failed, such as a "Fail" message. If the verification is passed, the process advances to step S504.

In step S504, the receiver ECU 52 stores the initial key Ikey, and generates a session key (hereinafter also referred to as Skey) and a first random number Nonce ₁.

In step S506, the recipient ECU 52 generates a seed message containing the session key Skey and the first random number Nonce ₁ encrypted with the stored initial key Ikey, as compared to the existing UDS 27 service. Alternatively, the seed message may be encrypted by the initial key Ikey, and the seed message includes the session key Skey and the first random number Nonce ₁.

In step S508, the receiver ECU 52 transmits the seed message to the sender ECU 50 in the format of, for example, ID _SA-feedback+ E( SKey, f(Nonce₁)||Nonce₂.

In step S510, the sender ECU 50 that received the seed message decrypts the seed message with the initial key Ikey, thereby obtaining the session key Skey and the first random number Nonce ₁.

In step S512, the sender ECU 50 generates a second random number Nonce ₂.

In step S514, the sender ECU 50 calculates the function value f ₁(Nonce₁ with the first random number Nonce ₁ as a variable of the function first f ₁ (x).

In step S516, the sender ECU 50 generates a key message including the second random numbers Nonce ₂ and f ₁(Nonce₁ encrypted with the session key Skey, as compared with the existing UDS 27 service. Alternatively, the key message may be encrypted by the session key Skey, and the key message includes the second random numbers Nonce ₂ and f ₁(Nonce₁).

In step S518, the sender ECU 50 transmits the key message generated in step S516 to the receiver ECU 52.

In step S520, the receiver ECU 52 decrypts the received key message using the session key Skey, thereby obtaining the second random numbers Nonce ₂ and f ₁(Nonce₁.

In step S522, the receiver ECU 52 compares the second random number Nonce ₂ obtained by decryption in step S520 with the previously stored second random number Nonce _2-old, and if the two are not identical, passes the verification, and proceeds to step S524; otherwise, a message may be returned indicating that the verification failed.

In step S524, the receiving-side ECU 52 calculates the current function value f ₁(Nonce₁ with the Nonce ₁ as the variable of the first function f ₁ (x), compares it with the decryption-obtained function value f ₁(Nonce₁) in step S520), and if both are identical, indicates that the verification is passed, and proceeds to step S526; otherwise, a message may be returned indicating that the verification failed.

In step S526, the receiver ECU 52 stores the second random number Nonce ₂, which is indicated as the current latest second random number Nonce _2-old, in its TEE module, and calculates the function value f ₂(Nonce₂ with the second random number Nonce ₂ as a variable of the second function f ₂ (x).

In step S528, the receiving ECU 52 approves the access request of the transmitting ECU 50, generates an OK message indicating the passing of the authentication, and transmits the OK message to the transmitting ECU 50; in contrast to the existing UDS 27 service, the OK message generated here includes a function value f ₂(Nonce₂ encrypted with the session key Skey).

In step S530, the sender ECU 50 calculates the current function value f ₂(Nonce₂) with the second random number Nonce ₂ as a variable of the function f ₂ (x), compares it with the function value f ₂(Nonce₂) from the receiver ECU 52, and if both are the same, the sender ECU 50 stores the session key Skey.

As an alternative example, in step S530, if the verification is not passed, a new UDS 27 service access request may be triggered.

The data synchronization method described in accordance with the examples of the application further includes, in the event that the authentication is not passed, returning a message indicating that the authentication has failed to the sender ECU 50.

According to the data synchronization method of each example of the present application, a case where a communication system in a vehicle is to be synchronized can be performed. The cases to be synchronized include, but are not limited to, the following: power up, ECU replaced, ECU firmware refreshed, set synchronization period, etc.

In the existing in-car network communication, an attacker CAN easily capture a large amount of information transmitted on the CAN/CAN-FD and analyze a special symmetric key based on the information. The attacker can thereby falsify or tamper with the information sent to the recipient ECU. At the recipient ECU it is more difficult to discern whether the received message came from a legitimate ECU or an attacker. The data synchronization method provided by the present application is performed in an in-vehicle communication system, there may be a unique session key between the ECUs that communicate with each other, and the session key between each pair of ECUs that communicate with each other may be different. Thus, when the ECU is replaced and the in-vehicle communication system is added with a new ECU and the ECU firmware upgrades wait for the synchronization session key, the data synchronization method provided by the application is automatically triggered due to the occurrence of the to-be-synchronized ECU, so that the ECU and other ECUs of the in-vehicle communication system initiate communication with each other to synchronize the session keys with each other, and the manual synchronization is not needed as in the prior art.

Meanwhile, because the session keys are unique and different, the difficulty of an attacker in analyzing the symmetric key from the intercepted information can be greatly increased. In the examples provided by the present application, both before and after encrypted transmission of data, they are stored in a TEE environment such as HSM, also increasing the security of the data.

The application also provides a method of synchronizing fresh values. Fig. 8 is a flow chart of a method of synchronizing freshness values according to an illustrative example of the present application, the method being applied in a communication system based on bus communication.

As shown in fig. 8, in step S600, a fresh value is generated by the sender ECU. In step S602, the sender ECU transmits the generated freshness value to the receiver ECU to be synchronized through a session key shared by the sender and the receiver. It will be appreciated that the sender ECU may send its message authentication code MAC (Message Authentication Code) to the receiver ECU along with the freshness value. Further, in some examples, the sender ECU may encrypt the freshness value with the session key and then send it. As an example, in step S606, the receiving ECU acquires the updated fresh value after receiving the fresh value transmitted by the transmitting ECU through the session key. It is understood that in the case where the fresh value is encrypted, the recipient ECU will obtain the fresh value after decrypting the received information.

According to one example of the present application, the electronic control unit to which the freshness value is to be synchronized is one or more of a new ECU for replacing an ECU already existing in the communication system, such as after the sender ECU 50 in fig. 7 is replaced with a new ECU, or after the recipient ECU 52 is replaced with a new ECU; a new ECU added to the communication system, such as a new receiver ECU added to fig. 7; an ECU whose firmware of the ECU in the communication system is updated, such as the ECU 52 in fig. 7 updating its firmware, etc.; and other conditions not listed that may cause synchronization requirements.

Step S600 includes a case where the ECU to be synchronized is a sender ECU and a case where the ECU to be synchronized is a receiver ECU. Specifically, after the sender ECU determines that the receiver ECU is the ECU to be synchronized based on a value transmitted by the receiver ECU, such as a Trip Counter (Trip Counter), a new fresh value is generated and transmitted to the receiver ECU. As an example, a value of a Trip Counter (Trip Counter) from a receiving ECU may be transmitted together with a message authentication code MAC of the receiving ECU. And if the receiving ECU is the ECU to be synchronized, the value of the trip counter of the receiving ECU is an initial value confirmed with the transmitting ECU in advance, so the transmitting ECU can determine whether the receiving ECU is the original ECU or the receiving ECU to be synchronized accordingly. In this example, a stroke counter is taken as an example, but the stroke counter is not limited thereto.

Fig. 10 is a schematic diagram of the structure of the freshness value 8. As shown in fig. 10, the freshness value includes a Trip Counter (Trip Counter) 80, a Reset Counter (Reset Counter) 82, a Message Counter (Message Counter) 84, and a Reset flag (RESET FLAG) 86. The trip counter 80 is a monotonically increasing counter that self-increases upon power-up, wakeup, etc. When the trip counter 80 is self-incremented, the reset counter 82 is cleared, and the reset counter is monotonically incremented, and different periods can be set according to practical applications. When the reset counter 82 is self-incrementing, the message counter 84 is, for example, cleared. The structure of the freshness value according to the present application may employ the structure shown in fig. 10, which is the same as the existing structure of the freshness value, for example, AUTOSAR SecOC specifications.

Returning to fig. 8, in the event that an ECU replacement or addition occurs or otherwise causes an ECU to be synchronized to appear, the freshness value synchronization method according to an example of the present application may be timely generated by the sender ECU and updated into the ECUs that communicate with each other. On one hand, the method is easy to realize, and on the other hand, the situation of communication failure or replay attack caused by the fact that the fresh value cannot be updated or cannot be updated in time (the window which can lead to replay attack cannot be updated in time is enlarged) is improved.

FIG. 9 is a flow chart of a method of synchronizing fresh values according to one illustrative example of the application. The method will be described taking as an example an application in a UDS 27 service. As shown in fig. 9, in step S700, the present method starts to be executed. In step S702, both the sender ECU and the receiver ECU acquire a session key. As an example, the session key may be the session key Skey obtained by the data synchronization method described above. In some cases, the session key Skey may be transmitted to each slave node ECU by the master node ECU (the sender ECU is the master node ECU), in which case the session key Skey may be a session key shared by each ECU. The method of synchronizing freshness values according to an example of the present application is not limited to the manner in which the session key SKey is obtained. In step S704, it is determined whether or not the sender ECU is replaced, and if so, the process proceeds to step S706, otherwise the process proceeds to step S707.

In step S706, the new sender ECU generates a random number. In step S708, the sender ECU sets the value of the generated random number to a new fresh value. According to an example of the present application, the sender ECU generates a random number by a true random number generation module 24 (see fig. 2) in its TEE module, and sets it to a fresh value.

In step S710, the sender ECU transmits the generated freshness value to the receiver ECU through the session key Skey. It will be appreciated that the sender ECU may send its message authentication code MAC to the receiver ECU along with the freshness value. Further, in some examples, the sender ECU may encrypt the freshness value with the session key and then send it.

In step S712, the receiving ECU acquires the freshness value from the information transmitted by the transmitting ECU in step S710, for example. It will be appreciated that in the event that the freshness value is encrypted, the receiving party ECU will decrypt the received information to obtain the freshness value sent by the master node ECU.

In step S714, a state of preliminary communication is entered.

In step S707, the receiving side ECU may transmit the count value of the Trip counter Trip to the transmitting side ECU through the session key, and may transmit the message authentication code MAC together as an example.

In step S709, the sender ECU determines whether there is a receiver ECU to be synchronized according to the received information sent by the receiver ECU in step S707; here, the initial value of the trip counter of the receiving-side ECU is previously confirmed with the transmitting-side ECU, so that, as an example, if the transmitting-side ECU judges that the count value in the received information is the initial value confirmed before, that is, it is known that the current receiving-side ECU is the replaced ECU to be synchronized. Otherwise, if the determination result is that no ECU is replaced, the flow proceeds to step S714; otherwise, the flow advances to step S708.

By performing the freshness value synchronization method according to the present application, when an ECU to be synchronized occurs, such as a new ECU replacing the original ECU, a new ECU is added, and ECU firmware update is performed, the communication system will automatically generate new freshness values in the relevant sender nodes in time and synchronize to these ECUs to be synchronized.

According to the present application, there is also provided an exemplary data synchronization method. In contrast to the data synchronization method described above, the data synchronization method in the present embodiment is a method of performing fresh value synchronization after the receiver ECU and the sender ECU synchronize session keys Skey with each other. Fig. 11 is a flow chart of a data synchronization method according to an example of the application.

As shown in fig. 11, in step S900, session keys are exchanged between ECUs to be communicated. The specific implementation of step S900 is, for example, any one of the data synchronization methods illustrated in connection with fig. 3,6 or 7, so long as the session key is confirmed between the sender ECU and the receiver ECU in step S900.

One possible case is that session keys may be distributed to slave node ECUs in turn by one master node ECU, which is different from the manner in which session keys are acquired according to the data synchronization method illustrated in fig. 3, 6 or 7 in that it is possible that all ECUs share the same session key. This applies for example in the architecture shown in fig. 4 or possibly also in the architecture shown in fig. 5.

In step S902, it is confirmed whether or not session keys between the ECUs to be communicated have been exchanged. If so, go to step S904, otherwise return to step S900. At step 904, the ECU to be communicated updates the freshness value, for example by synchronizing the freshness value as described above in connection with fig. 8 or 9. In step S906, it is determined whether or not the fresh values of all the relevant ECUs to be synchronized have been synchronized. If so, go to step S908, wait for subsequent communications; otherwise, it returns to step S904.

According to the data synchronization method of the present application, it is possible to perform synchronization of all required data at power-up (including when the ECU is replaced or a new ECU is added) in an in-vehicle communication system employing a master node ECU and a slave node ECU architecture, and also in an in-vehicle communication system of a point-to-point architecture.

Under the condition of having no influence on the existing SecOC mechanism, the session key and the fresh value can be timely and automatically synchronized by adopting the data synchronization method provided by the application, thereby effectively avoiding replay attack caused by that the data cannot be synchronized or are timely synchronized.

Fig. 12 is a schematic structural view of an Electronic Control Unit (ECU) according to an illustrative example of the present application, wherein the ECU is applied to a communication system based on bus communication. As shown in fig. 12, the ECU includes a transmission module 1000, a reception module 1002, and a decryption module 1004. The transmission module 1000 is configured to issue a first request including a first certificate preset in the electronic control unit ECU. In some examples, the first certificate contains an initial key, which in other examples is pre-stored in each ECU in communication with each other. The receiving module 1002 is configured to receive a feedback message for the first request, where the feedback message includes a session key encrypted with an initial key and a first random number Nonce ₁. The decryption module 1004 is configured to decrypt the feedback message with the initial key to obtain the session key.

The ECU shown in fig. 12 may be implemented as an electronic control unit in the vehicle, for example, as a sender ECU that performs the steps performed by the sender ECU in the data synchronization method shown in fig. 3.

Further, the ECU shown in fig. 12 may further include a true random number generation module, a processing module, and an encryption module. The true random number generation module generates a second random number Nonce ₂. The processing module first random number calculates the function value f ₁(Nonce₁ of the first function f ₁ (x) as a variable. The encryption module encrypts a message containing f ₁(Nonce₁) and Nonce ₂ using the session key and transmits the message by transmission module 1000. The ECU of this example may be implemented as a sender electronic control unit in a vehicle, for example, as a sender ECU that performs the steps performed by the sender ECU in the data synchronization method as shown in fig. 3, 6, or 7. According to an example, the ECU described in connection with fig. 12 has its decryption module, encryption module, true random number generation module all disposed in the TEE environment. A specific example may be that the TEE module described in connection with fig. 2 is implemented in the ECU of this example, and thus the decryption module and the encryption module may be implemented as one and the same encryption/decryption module.

Fig. 13 is a schematic structural view of an Electronic Control Unit (ECU) according to still another illustrative example of the present application, wherein the ECU is applied to a communication system based on bus communication. As shown in fig. 13, the ECU includes a receiving module 1100, a certificate verification module 1101, a true random number generation module 1102, a key generation module 1103, an encryption module 1104, and a transmitting module 1106. The receiving module 1100 receives a first request including a first certificate, and the certificate verification module 1101 verifies the first certificate through a preset root certificate. In some examples, the first certificate includes an initial key. The true random number generation module 1102 is configured to generate a first random number Nonce ₁. The key generation module 1103 is configured to generate a session key. The encryption module 1104 is configured to encrypt the session key and the first random number Nonce ₁ with the initial key, thereby forming a feedback message for the first request. In an example where the first certificate includes an initial key, the initial key is obtained from a first request sent by the sender ECU. In other examples, the initial key may be preset in the recipient ECU. The sending module 1106 is configured to send a feedback message. The ECU shown in fig. 13 may be implemented as a sender electronic control unit in a vehicle, for example, as a receiver ECU that performs the steps performed by the receiver ECU in the data synchronization method shown in fig. 3, 6 or 7.

Further, the ECU shown in fig. 13 may further include a decryption module and a processing module. The decryption module is configured to decrypt the received message with the session key to obtain the function value f ₁(Nonce₁) and the second random number Nonce ₂. The processing module is configured to determine whether the received message is subject to replay attack based on either or both of the previously stored second random number Nonce _2-old and the current function value f ₁(Nonce₁), and return a message representing a confirmation result accordingly. Wherein the current function value f ₁(Nonce₁) is a function value calculated by the receiving ECU with the first random number Nonce ₁ as a variable of the function f ₁ (x), which is consistent with the above description of the current function value f ₁(Nonce₁).

The ECU described in connection with fig. 13 may be implemented as a sender electronic control unit in a vehicle, for example as a receiver ECU that performs the steps performed by the receiver ECU in the data synchronization method as shown in fig. 3, 6 or 7.

According to an example, the ECU described in connection with fig. 13, the certificate verification module, the true random number generation module, the key generation module, the decryption module, the encryption module, and the like thereof may be set as the TEE environment. A specific example is, for example, a TEE module to be described in connection with fig. 2 implemented in the ECU of this example, in which case the encryption module and the decryption module may be implemented as one encryption and decryption module.

According to an example of the present application, there is also provided a data synchronization method applied to a sender ECU in a communication system based on bus communication. The method comprises the following steps: issuing a first request, wherein the first request comprises a first certificate preset at the sender ECU; receiving a feedback message for the first request; decrypting the feedback message with the initial key to obtain a session key and a first random number Nonce ₁; wherein the initial key may be preset at the sender electronic control unit. Further, the method of this example may further comprise: generating a second random number Nonce ₂, and calculating a function value f ₁(Nonce₁ of the first function f ₁ (x) with the first random number Nonce ₁ as a variable; encrypting and transmitting a message containing the f ₁(Nonce₁) and the second random number Nonce ₂ using the session key. As an example, the data synchronization method according to the present application may further implement the steps performed by the sender ECU as shown in, for example, fig. 3, 6 or 7.

According to an example of the present application, there is also provided a data synchronization method applied to a receiver ECU in a communication system based on bus communication, the method including: receiving a first request comprising a first certificate, and verifying the first certificate through a preset root certificate; generating a session key and a first random number Nonce ₁ if the first certificate is authenticated and encrypting the session key and the first random number Nonce ₁ with an initial key to form a feedback message; sending the feedback message; wherein the initial key is preset in the recipient electronic control unit or the initial key is included in the first request. Further, the method of this example further comprises: decrypting the received message including the function value f ₁(Nonce₁) and the second random number Nonce ₂ with the session key; judging the reliability of the received message based on one or both of the previously stored second random number Nonce _{2-old And (3) with} current function value f ₁ (Nonce 1), and accordingly returning a message representing the confirmation result to the sender electronic control unit; the current function value f ₁(Nonce₁) is a function value f ₁(Nonce₁ calculated by the receiver electronic control unit by using the first random number Nonce ₁ as a variable of the first function f ₁ (x). As an example, the data synchronization method according to the present application may further implement the steps performed by the receiving-side ECU as shown in, for example, fig. 3, 6 or 7.

The data synchronization method of the sender ECU applied to the communication system based on the bus communication and the receiver ECU applied to the communication system based on the bus communication described herein may also be implemented in the examples described in connection with the above drawings, and will not be described in detail.

While specific embodiments of the application have been shown and described in detail to illustrate the principles of the application, it will be understood that the application may be embodied otherwise without departing from such principles.

Claims

1. A data synchronization method applied to a vehicle-mounted communication system based on bus communication, the method comprising:

The method comprises the steps that a sender electronic control unit sends a first request, wherein the first request comprises a first certificate preset in the sender electronic control unit;

The receiver electronic control unit receives the first request and verifies the first certificate through a root certificate preset in the receiver electronic control unit;

In the case that the first certificate passes verification, the receiver electronic control unit generates a session key and a first random number Nonce ₁, and encrypts the session key and the first random number Nonce ₁ with an initial key to form a feedback message;

The receiver electronic control unit sends the feedback message;

the sender electronic control unit receives and decrypts the feedback message with the initial key to obtain the session key and the first random number Nonce ₁; and

Wherein the initial key is preset at the sender electronic control unit and is included in the first request to be sent to the receiver electronic control unit; or the initial key is preset in the sender electronic control unit and the receiver electronic control unit.

2. The method of data synchronization according to claim 1, wherein the method further comprises:

The sender electronic control unit generates a second random number Nonce ₂ and calculates a function value f ₁(Nonce₁ of a first function f ₁ (x) with the first random number Nonce ₁ as a variable;

The sender electronic control unit encrypts and sends a message containing the f ₁(Nonce₁) and the second random number Nonce ₂ using the session key;

The receiving electronic control unit decrypting the received message with the session key, thereby obtaining the function value f ₁(Nonce₁) and the second random number Nonce ₂;

The receiving electronic control unit judges the reliability of the received message based on one or both of the previously stored second random number Nonce _2-old and the current function value f ₁(Nonce₁), and returns a message representing a confirmation result to the transmitting electronic control unit accordingly, wherein the current function value f ₁(Nonce₁) is a function value f ₁(Nonce₁ calculated by the receiving electronic control unit with the first random number Nonce ₁ as a variable of the first function f ₁ (x).

3. The data synchronization method according to claim 2, wherein the receiving electronic control unit judges the reliability of the received message based on one or both of the previously stored second random number Nonce _2-old and the current function value f ₁(Nonce₁) and returns a message representing a confirmation result to the transmitting electronic control unit accordingly, comprising the steps of:

The receiver electronic control unit compares a previously stored second random number Nonce _2-old with the second random number Nonce ₂ obtained by decryption;

If the comparison result is that the second random number Nonce _2-old is different from the second random number Nonce ₂, comparing the current function value f ₁(Nonce₁) with the function value f ₁(Nonce₁) obtained by decryption;

If the current function value f ₁(Nonce₁) is the same as the function value f ₁(Nonce₁) obtained by decryption, storing the second random number Nonce ₂ obtained by decryption as a new second random number Nonce _2-old;

Encrypting a message containing a representation of a function value f ₂(Nonce₂) with the session key, wherein the function value f ₂(Nonce₂) is a function value obtained by the receiver electronic control unit with a second random number Nonce ₂ as a variable of a second function f ₂ (x);

the receiving electronic control unit sends the message indicating that the verification is passed.

4. A method of synchronizing data according to claim 3, characterized in that the method further comprises:

the sender electronic control unit calculates a current function value f ₂(Nonce₂);

The sender electronic control unit compares the current function value f ₂(Nonce₂) with a function value f ₂(Nonce₂) obtained by decryption from the received message representing verification pass, wherein the current function value f ₂(Nonce₂) is a function value f ₂(Nonce₁ calculated by the sender electronic control unit with the second random number Nonce ₂ as a variable of a second function f ₂ (x);

in case the current function value f ₂(Nonce₂) and the function value f ₂(Nonce₂) are the same, the sender electronic control unit stores the session key.

5. The data synchronization method according to any one of claims 1 to 4, characterized in that the method further comprises:

The sender electronic control unit generates a fresh value;

And the sender electronic control unit sends the fresh value to an electronic control unit to be synchronized in the receiver electronic control unit through the session key.

6. The data synchronization method of claim 5, wherein the sender electronic control unit generating a freshness value comprises:

in case the sender electronic control unit itself is the electronic control unit to be synchronized, the sender electronic control unit generates a freshness value;

And in the case that the sender electronic control unit judges that the receiver electronic control unit is the electronic control unit to be synchronized, the sender electronic control unit generates a fresh value.

7. A method of synchronizing freshness values for an in-vehicle communication system based on bus communication, the method comprising:

generating a freshness value by a sender electronic control unit; and

8. The method of synchronizing fresh values according to claim 7, wherein the sender electronic control unit generating a fresh value comprises:

9. Method of synchronizing freshness values according to claim 7 or 8, characterized in that the electronic control unit to be synchronized is one or more of the following:

a new electronic control unit for replacing an existing electronic control unit in the in-vehicle communication system;

a new electronic control unit is added to the vehicle-mounted communication system;

and the electronic control unit is used for updating the firmware of the electronic control unit in the vehicle-mounted communication system.

10. An electronic control unit for use in a vehicle communication system based on bus communication, the electronic control unit comprising:

A sending module, configured to send a first request when the electronic control unit is used as a sender electronic control unit, where the first request includes a first certificate preset in the electronic control unit;

A receiving module, configured to receive a feedback message for the first request, where the feedback message includes a session key encrypted with an initial key and a first random number Nonce ₁;

A decryption module for decrypting the feedback information with the initial key to obtain the session key and the first random number Nonce ₁; and

Wherein the initial key is stored in the electronic control unit in advance.

11. The electronic control unit of claim 10, wherein the electronic control unit further comprises:

The true random number generation module is used for generating a second random number Nonce ₂;

A processing module for calculating a function value f ₁(Nonce₁ with the first random number Nonce ₁ as a variable of a first function f ₁ (x);

An encryption module for encrypting a message containing the function value f ₁(Nonce₁) and the second random number Nonce ₂ using the session key;

The sending module is configured to send the message.

12. An electronic control unit for use in a vehicle communication system based on bus communication, the electronic control unit comprising:

A receiving module for receiving a first request including a first certificate when the electronic control unit is a receiving electronic control unit;

The certificate verification module is used for verifying the first certificate through a preset root certificate;

The true random number generation module is used for generating a first random number Nonce ₁;

The key generation module is used for generating a session key;

An encryption module configured to encrypt the session key and the first random number Nonce ₁ with an initial key, thereby forming a feedback message for the first request; and

And the sending module is used for sending the feedback message.

13. The electronic control unit of claim 12, wherein the electronic control unit further comprises:

A decryption module for decrypting the received message with the session key to obtain a function value f ₁(Nonce₁) and a second random number Nonce ₂;

A processing module for judging the reliability of the received message based on one or both of the previously stored second random number Nonce _2-old and the current function value f ₁(Nonce₁), and returning a message representing a confirmation result accordingly, wherein the current function value f ₁(Nonce₁) is a function value calculated by the electronic control unit with the first random number Nonce ₁ as a variable of the first function f ₁ (x).

14. A data synchronization method applied to a sender control unit in a vehicle-mounted communication system based on bus communication, the method comprising:

issuing a first request, wherein the first request comprises a first certificate preset in the sender control unit;

Receiving a feedback message for the first request;

decrypting the feedback message with the initial key to obtain a session key and a first random number Nonce ₁; and

Wherein the initial key is preset in the sender electronic control unit.

15. The method of data synchronization according to claim 14, wherein the method further comprises:

generating a second random number Nonce ₂ and calculating a function value f ₁(Nonce₁ of a first function f ₁ (x) using the first random number as a variable;

Encrypting and transmitting a message containing the function value f ₁(Nonce₁) and the second random number Nonce ₂ using the session key.

16. A data synchronization method applied to a receiver electronic control unit in a vehicle-mounted communication system based on bus communication, the method comprising:

receiving a first request comprising a first certificate, and verifying the first certificate through a preset root certificate;

Generating a session key and a first random number Nonce ₁ if the first certificate passes verification, and encrypting the session key and the first random number Nonce ₁ with an initial key to form a feedback message;

Sending the feedback message; and

Wherein the initial key is preset in the recipient electronic control unit or the initial key is included in the first request.

17. The method of data synchronization according to claim 16, wherein the method further comprises:

decrypting the received message including the function value f ₁(Nonce₁) and the second random number Nonce ₂ with the session key;

Judging the reliability of the received message based on one or both of the previously stored second random number Nonce _2-old current function value f ₁(Nonce₁), and accordingly returning a message representing a confirmation result to the sender electronic control unit;

Wherein the current function value f ₁(Nonce₁) is a function value f ₁(Nonce₁ calculated by the receiver electronic control unit with the first random number Nonce ₁ as a variable of a first function f ₁ (x).