CN117413545A

CN117413545A - In-vehicle communication method and device

Info

Publication number: CN117413545A
Application number: CN202180098686.0A
Authority: CN
Inventors: 耿峰
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-05-27
Filing date: 2021-05-27
Publication date: 2024-01-16
Also published as: WO2022246760A1

Abstract

The application discloses an in-vehicle communication method and device, which can be applied to the fields of automatic driving or internet-enabled vehicles and the like, wherein when the method is applied to a receiving end, the receiving end receives a first message, and the first message comprises a sending timestamp of a sending end; the sending timestamp is a fresh value generated by the sending end for the first message; and the receiving end verifies the first message according to the receiving time stamp and the sending time stamp. The method comprises the steps of determining a fresh value by adopting a sending time stamp of a first message, obtaining a receiving time stamp for receiving the first message at a receiving end, completing verification by utilizing the sending time stamp and the receiving time stamp together, enabling a sending end to meet the requirement of preventing replay attack by only sending a time stamp with a limited length, and improving the effective load of message transmission without occupying too many bits for sending the fresh value. According to the scheme, the fresh values can not be synchronized, so that the overhead of in-vehicle communication is effectively reduced, the problem caused by the asynchronous fresh values is avoided, and the replay attack prevention performance is effectively improved.

Description

In-vehicle communication method and device

Technical Field

The application relates to the technical field of intelligent network coupling, in particular to an in-vehicle communication method and device.

Background

In recent years, automobile technology has rapidly developed toward intellectualization, electrodynamic, networking, and sharing, and the number, connection, and interaction of electronic devices in a vehicle have been increased, and vehicle-mounted communication networks typified by a controller area network (controller area network, CAN), a local interconnect network (local interconnection network, LIN), a multimedia transmission system (media oriented systems transport, MOST), a vehicle-mounted ethernet, and the like have been gradually formed. In the existing vehicle-mounted network, most of the data transmission is basically carried out under the condition of no or low security measures, and the data transmission is easy to be attacked by hackers.

The CAN protocol has wide application in vehicle network communication due to the advantages of real-time performance and reliability. However, the CAN bus adopts a message-oriented protocol and an architecture of a broadcast bus network, and it is difficult to directly deploy security measures in the prior art into vehicle network communication. Once an attacker accesses the CAN bus, each frame injected by the attacker may be read as a legitimate frame, thereby implementing functions for controlling the vehicle, such as acceleration or braking operations, thereby causing safety hazards to the vehicle.

For the above problems, the automobile open architecture (automotive open system architecture, AUTOSAR) organization complements the information security component (secure onboard communication, secOC), introduces standards for communication encryption and authentication in the on-board communication bus, provides an effective authentication mechanism for the electronic control unit (electronic control unit, ECU) messages at the protocol data unit (protocol data unit, PDU) message level, ensures the freshness of PDU messages, and prevents message replay attacks. The AUTOSAR SecOC specification gives that fresh values can take both time stamping and monotonic counter alternatives. The time stamping scheme relies on synchronizing universal time (coordinated universal time, UTC) among all ECUs, but the problems of clock jitter and abnormal time stamp synchronization CAN lead to failure of the receiver to receive CAN messages, resulting in system functional security issues.

Disclosure of Invention

The application provides an in-vehicle communication method and device, which enable the transmission of messages between a receiving end and a transmitting end to be independent of the synchronization of fresh values in vehicle-mounted network communication, prevent replay attack and reduce the complexity of data transmission between the receiving end and the transmitting end.

In a first aspect, the present application provides an in-vehicle communication method, applied to a receiving end, including: receiving a first message, wherein the first message comprises a sending timestamp of a sending end; the sending timestamp is a fresh value generated by the sending end for the first message; the first message is validated based on the receive timestamp and the transmit timestamp of the first message.

The transmitting end and the receiving end may be any ECU in the vehicle. The transmitting end may determine a transmission time stamp of the first message according to a timer of the transmitting end. The timer may be a local clock (internal clock), a unidirectional counter (monotonic counter), or the like, which is not limited in this application.

By adopting the method, the sending time stamp of the first message is adopted to determine the fresh value, the receiving time stamp for receiving the first message is obtained at the receiving end, the verification is completed by the sending time stamp and the receiving time stamp, the sending end can meet the requirement of preventing replay attack only by sending the time stamp with limited length, and the sending end does not occupy too many bits for sending the fresh value, so that the effective load of message transmission is improved. In addition, under the condition that the fresh values are not synchronized, the replay attack prevention effect can be ensured, the extra expense possibly caused by adopting the method for synchronizing the fresh values is avoided, the problem that the first message cannot be verified when the synchronization of the fresh values cannot be completed is particularly avoided, and the replay attack prevention effect is improved.

One possible implementation manner, the timer of the transmitting end and the timer of the receiving end do not perform time synchronization operation.

By the method, the sending end and the receiving end can not perform time synchronization operation, and complexity of replay attack prevention is reduced.

One possible implementation, when the transmission time stamp is equal to the historical transmission time stamp, verifies based on the reception time stamp and the historical reception time stamp.

By the method, when the sending time stamp cannot be verified, the receiving end can further verify through the receiving time stamp, and the anti-replay verification effect is improved.

One possible implementation way, the second time precision of receiving the timestamp satisfies the requirement of replay attack validation of the first message; the first time precision of the transmission time stamp of the first message meets the requirements of the bits of the freshness value of the first message.

Considering that the number of bits that the fresh value can occupy during transmission is limited, the requirement of the number of bits of valid data carried by the transmitted first message is met. For example, the number of bits of the first message is 64 bits, the fresh value occupies 32 bits, and the life cycle of the fresh value is 10 to 20 years, the minimum time unit of the transmission timestamp that the fresh value can carry may correspond to seconds. At this time, the first time precision of the transmission time stamp is a time precision of 1 second, and the number of bits of the corresponding freshness value is 32 bits.

By the method, the second time precision of the received time stamp meets the requirement of replay attack verification, and the first time precision of the transmitted time stamp improves the effective load of data in the message and improves the transmission efficiency.

One possible implementation manner, after the first message is verified successfully, verifying the second message according to the received timestamp of the first message and the sending timestamp of the first message; the second message is received after the first message.

By the method, the receiving time stamp of the first message and the sending time stamp of the first message can be used as the verification credential of the second message received next time, so that the complexity of verification is simplified.

One possible implementation stores a receive timestamp and a transmit timestamp of the first message after the first message is successfully authenticated, the receive timestamp and the transmit timestamp of the first message being used to authenticate the second message received after the first message.

By the method, the receiving time stamp of the first message and the sending time stamp of the first message can be stored and used as the verification credentials of the second message received next time, so that the complexity of verification is simplified.

One possible implementation is that the timer on the transmitting side and the timer on the receiving side are related to the whole vehicle life cycle of the vehicle.

By the method, the timer of the transmitting end is guaranteed to be monotonically increased in the whole life cycle of the vehicle, the timer of the receiving end is guaranteed to be monotonically increased in the whole life cycle of the vehicle, and uniqueness of the fresh value and the verification fresh value is achieved.

In a second aspect, the present application provides an in-vehicle communication method, applied to a transmitting end, including: generating a fresh value of the first message according to the sending time stamp of the first message; generating a first message according to the freshness value of the first message; and sending the first message to the receiving end.

The first message is verified by the receiving end according to the receiving time stamp of the received first message and the sending time stamp in the first message.

According to the method, the fresh value is determined by adopting the sending time stamp of the first message, the lower bit of the time stamp is not required to be used in a truncated mode, the problem of overflow overturning is avoided, in addition, the receiving time stamp for receiving the first message is obtained at the receiving end, verification is completed by utilizing the sending time stamp and the receiving time stamp together, the problem that in the prior art, the fact that the first message cannot be verified due to the fact that the timers of the sending end and the receiving end are possibly not synchronous is avoided, the additional expenditure possibly caused by adopting a fresh value synchronization method is required, the fact that the first message cannot be verified due to the fact that the fresh value synchronization cannot be completed is avoided, and the purpose of preventing replay attack is achieved.

One possible implementation manner, the receiving timestamp is used for verifying according to the receiving timestamp and the historical receiving timestamp of the receiving end when the sending timestamp is equal to the historical sending timestamp of the receiving end.

One possible implementation way, the second time precision of receiving the timestamp satisfies the requirement of replay attack validation of the first message; the first time precision of the transmission time stamp meets the requirements of the bits of the freshness value.

The foregoing benefits may be referred to as the benefits of possible implementation manners in the first aspect, which are not described herein.

In a third aspect, the present application provides an in-vehicle communication device, applied to a receiving end, including:

a receiving unit, configured to receive a first message, where the first message includes a transmission timestamp of a transmitting end; the sending timestamp is a fresh value generated by the sending end for the first message;

and the processing unit is used for verifying the first message according to the receiving time stamp and the sending time stamp of the first message.

A possible implementation manner, the processing unit is specifically configured to verify according to the reception timestamp and the historical reception timestamp when the transmission timestamp is equal to the historical transmission timestamp.

A possible implementation manner, the processing unit is further configured to:

after the first message is successfully verified, verifying the second message according to the received time stamp and the sent time stamp of the received first message; the second message is received after the first message.

One possible implementation manner, after the first message is verified successfully, the processing unit is configured to store a reception timestamp and a transmission timestamp of the first message, where the reception timestamp and the transmission timestamp of the first message are used to verify the second message received after the first message; and/or storing the sending time stamp and the receiving time stamp after the first message is successfully verified.

In a fourth aspect, the present application provides an in-vehicle communication device, which may be a receiving end, including: the apparatus may comprise a processor coupled to a memory for storing a computer program, the processor being for executing the computer program stored in the memory to cause the apparatus to perform the method according to any one of the first aspects.

In a fifth aspect, the present application provides an in-vehicle communication device, applied to a transmitting end, including:

a processing unit, configured to generate a freshness value of the first message according to the transmission timestamp of the first message; generating a first message according to the freshness value of the first message;

and the sending unit is used for sending the first message to the receiving end.

In a sixth aspect, the present application provides an in-vehicle communication device, which may be a receiving end, including: the apparatus may comprise a processor coupled to a memory for storing a computer program, the processor being for executing the computer program stored in the memory to cause the apparatus to perform the method according to any one of the second aspects described above.

In a seventh aspect, the present application provides a vehicle, the vehicle comprising a transmitting end and a receiving end, the receiving end being configured to implement the method as in any one of the first aspects, the transmitting end being configured to implement the method as in any one of the second aspects.

In an eighth aspect, a computer readable storage medium storing a computer program which, when executed, implements the method according to any one of the first or second aspects.

In a ninth aspect, the present application provides a computer program product comprising a computer program which, when executed by an in-vehicle communication device, implements a method as in any of the first or second aspects above.

In a possible implementation manner, the computer program comprises computer instructions which, when executed by the in-vehicle communication device, implement the method according to any one of the first or second aspects described above.

In a tenth aspect, embodiments of the present application provide a chip comprising a data interface and a processor, wherein the processor is configured to perform the method of the first aspect or any possible implementation manner of the first aspect or the method of any one of the second aspects. For example, the chip is any chip on which software or firmware is installed on a vehicle.

In an eleventh aspect, the present application provides a chip system comprising at least one processor for supporting the functions involved in implementing the above-mentioned first aspect or any possible implementation of the first aspect, the method of any of the above-mentioned first aspects or the functions involved in any of the above-mentioned second aspects. For example, to receive or process data and/or information involved in the above-described methods.

In one possible design, the system on a chip further includes a memory to hold program instructions and data, the memory being located either within the processor or external to the processor. The chip system can be composed of chips, and can also comprise chips and other discrete devices.

The advantages of the third aspect to the eleventh aspect are specifically referred to the technical effects that can be achieved by the corresponding designs in the first aspect and the second aspect, and the detailed description is not repeated here.

Drawings

FIG. 1 is a schematic diagram of one possible system architecture to which embodiments of the present application are applicable;

fig. 2 schematically illustrates a flow chart corresponding to an in-vehicle communication method;

FIG. 3 illustrates a schematic diagram of a first message generation;

fig. 4 schematically illustrates a flow chart corresponding to an in-vehicle communication method provided in an embodiment of the present application;

FIG. 5 schematically illustrates a verification of a first message provided by an embodiment of the present application;

FIG. 6 illustrates a schematic diagram of a first message;

fig. 7 schematically illustrates a structural diagram of an in-vehicle communication device according to an embodiment of the present application;

fig. 8 schematically illustrates a structural diagram of an in-vehicle communication device according to an embodiment of the present application.

Detailed Description

It should be noted that, the solution in the embodiment of the present application may be applied to the internet of vehicles, such as the vehicle external connection (vehicle to everything, V2X), the long term evolution technology of workshop communication (long term evolution-vehicle, LTE-V), the vehicle-vehicle (vehicle to vehicle, V2V), and the like. For example, the present invention can be applied to a vehicle having an in-vehicle communication function, or other devices having an in-vehicle communication function in a vehicle. Such other devices include, but are not limited to: the communication method provided by the application is implemented by other sensors such as a vehicle-mounted terminal, a vehicle-mounted controller, a vehicle-mounted module, a vehicle-mounted component, a vehicle-mounted chip, a vehicle-mounted unit, a vehicle-mounted radar or a vehicle-mounted camera, and the vehicle can pass through the vehicle-mounted terminal, the vehicle-mounted controller, the vehicle-mounted module, the vehicle-mounted component, the vehicle-mounted chip, the vehicle-mounted unit, the vehicle-mounted radar or the vehicle-mounted camera.

The following description of the technical solutions in the embodiments of the present application will be made with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, but not all embodiments.

In an embodiment of the present application, as shown in fig. 1, the vehicle may employ an electronic/electronic (E/E) architecture that includes three levels, namely a gateway electronic control unit (electronic control unit, ECU), a domain controller ECU, and an intra-domain ECU, respectively. Wherein, according to different functions, the system can be divided into different domains, and each domain has a domain controller ECU. The domain controller ECU is configured to manage the intra-domain ECU within the corresponding domain. The gateway ECU is used for managing the domain controller ECU. For example, referring to fig. 1, 4 domains may be divided according to different functions, namely, a vehicle control system domain, an entertainment system domain, a diagnostic system domain, and an intelligent driving domain. Each domain corresponds to one domain controller ECU. The above 4 domains correspond to a total of 4 domain controller ECUs. The gateway ECU is used to manage the 4 domain controller ECUs.

For example, in the embodiment of the present application, the entire E/E architecture includes 4 variable rate CAN (CAN with flexible data-rate, CAN FD) buses, but other buses are of course also possible, and CAN FD bus 1, CAN FD bus 2, CAN FD bus 3, and CAN FD bus 4 are taken as examples.

Alternatively, 4 CAN FD buses in fig. 1 may have correspondence with 4 domains in fig. 1. For example, CAN FD bus 1 in fig. 1 may correspond to a vehicle control system domain, CAN FD bus 2 may correspond to an entertainment system domain, CAN FD bus 3 may correspond to a diagnostic system domain, CAN FD bus 4 may correspond to an intelligent driving domain, and the like. The embodiments of the present application are not limited in this regard.

In the architecture shown in fig. 1, the ECUs may communicate based on a control area network (controller area network, CAN) protocol, and CAN messages may be sent between different ECUs. To protect the integrity of CAN messages and to protect against replay attacks, CAN messages may be protected with a key. Different types of CAN messages correspond to different keys. In the whole E/E architecture, the types of CAN messages are more, the number of corresponding keys is also more, and management is difficult.

It will be appreciated that the architecture shown in fig. 1 is illustrative only and is not limiting of embodiments of the present application. For example, the method provided in the embodiment of the present application may be used in a three-layer architecture as shown in fig. 1, or may be used in another two-layer or one-layer architecture, and is not limited thereto.

Some communication terms or terminology used in the embodiments of the present application are explained below, and also form part of the content of the present application.

1. Electronic control unit (electronic control unit, ECU)

In the embodiment of the present application, a plurality of ECUs, such as the ECU in fig. 1, may be disposed in the vehicle, and ECU 1, ECU 2, … …, and ECU N, N are positive integers. Wherein each ECU may have its own specific functions and also support simple sensor data processing and complex logic calculations. Currently common ECUs include, but are not limited to: vehicle sensors, vehicle cameras, multi-domain controllers (multi domain controller, MDC), automated-driving control unit, ADCU), front-loading intelligent gateways (T-boxes), intelligent cabin domain controllers (cockpit domain controller, CDC), vehicle gateways, vehicle control units (vehicle control unit, VCU), battery management systems (battery management system, BMS), thermal management systems (thermal management system, TMS), power distribution units (power distribution unit, PDU), and the like.

In the embodiment of the application, each ECU in the vehicle can interact messages depending on the communication technology set when the vehicle leaves the factory. These communication technologies may be, for example, controller area network (controller area network, CAN) technologies, but may also be other communication technologies that enable message interaction. For example, in performing a failure diagnosis on the ECU of the vehicle, the ECU of the vehicle may be connected to the vehicle CAN FD bus through an in-vehicle diagnosis port, and communication with the vehicle transmitting end is achieved. CAN networks have broadcast capabilities. When relying on CAN technology to exchange messages, the various ECUs CAN be connected to the same CAN FD bus, on which CAN FD bus any ECU CAN freely read and send CAN message frames. CAN is message oriented, typically only a message identification is present in each CAN message frame on the CAN FD bus, and does not carry a source or destination address, through which each ECU connected to the CAN FD bus CAN select which message frame to receive. Wherein, CAN message frame CAN transmit 8 bytes, CAN FD message frame CAN transmit the data field of maximum 64 bytes. For example, when using CAN FD frame transmission, one frame of data frame CAN complete transmission of 128bit advanced encryption standard (advanced encryption standard, AES) keys, enabling higher data rates and longer data field space.

Although the message interaction mode based on the CAN FD technology has stronger instantaneity and reliability, the CAN FD technology is not internally provided with any safety function. In this case, once the CAN FD bus is decoded by the attacker, each CAN message frame injected by the attacker may be read by the ECU in the vehicle and considered as a legitimate CAN message frame, so that the attacker CAN fully control the functions of the vehicle, such as braking or acceleration, which is very unsafe for the user to use the vehicle.

Based on this, each ECU in the vehicle should also be configured with a respective corresponding long-term key. When a certain ECU acquires a CAN message frame from the CAN FD bus according to the message identification, the ECU may also parse the CAN message frame using a preconfigured long-term key. If the analysis is unsuccessful, the CAN message frame is indicated to belong to an illegal control command which is injected on the CAN FD bus by illegal equipment in a high probability, so that the ECU CAN not execute corresponding control operation to avoid that the illegal equipment controls the vehicle. If the analysis is successful, the CAN message frame is indicated to belong to a legal control command injected on the CAN FD bus by legal personnel (such as an owner of the vehicle), so that the ECU CAN execute corresponding control operation. Therefore, the authentication operation of the CAN message frame is finished by presetting the long-term key in each ECU, so that the control command is authenticated before the control is truly executed, and the driving safety of the vehicle owner is improved.

2. Gateway (gateway)

The gateway is a core part in the vehicle architecture and is used as a data interaction hub of the whole vehicle network, and network data such as CAN FD and the like CAN be routed in different networks. The gateway may manage the domain control device, the intra-domain device, and the like. In the embodiment of the application, the gateway may include a gateway ECU, and the gateway ECU are not distinguished from each other.

3. Domain control apparatus

The vehicle electronics can be divided into several domains depending on the function of the various parts of the vehicle electronics. Such as power transmission domains, body electronics domains, assisted driving domains, etc. Each domain is provided with a domain control device for managing devices in the domain. The domain control device may also be referred to as a domain controller. In the embodiment of the application, the domain control device includes a domain control ECU, and the domain control device ECU are not distinguished from each other.

4. Intra-domain device

The vehicle electronics can be divided into several domains depending on the function of the various parts of the vehicle electronics. Such as power transmission domains, body electronics domains, assisted driving domains, etc. Each domain may include a domain controller and a plurality of controlled devices, and the devices within the domain may specifically refer to the controlled devices within each domain, and so on. In the embodiment of the application, the in-domain device may include an in-domain ECU, and the in-domain device and the in-domain ECU are not distinguished from each other.

In the embodiment of the application, the interior of the vehicle may also be configured with a key management system (key management system, KMS). KMS is mainly responsible for generating keys, managing keys, and clearing keys, including the long-term keys described above, in vehicles. Unlike conventional information and technology (information and communications technology, ICT), ECUs in the internet of vehicles mostly follow the automotive network security (EVITA) standard and the security hardware extension (secure hardware extension, SHE) standard. Illustratively, the long-term key in the KMS may be set as a symmetric key in consideration of performance and cost of setting keys under the EVITA standard and the SHE standard.

In the technical field of internet of vehicles, the transceiving operation between two nodes needs to depend on various different communication protocols, and the two nodes can be an external transmitting end and an ECU in the vehicle, and also can be any two ECUs in the vehicle. Taking the SecOC protocol as an example, when communication is performed between ECUs in a vehicle, a message transmitted between ECUs is generated based on an AUTOSAR architecture in the vehicle.

The AUTOSAR architecture defines different software layers, e.g., application software, runtime environment and base software layers (basic software of AUTOSAR, BSW) (which may include service layers, abstraction layers, driver layers), etc. Wherein the freshness value management policy and the key management policy are implemented in application software. The application software invokes the AUTOSAR interface to generate or verify a message authentication code (message authentication code, MAC) and AES encrypt or decrypt. The she+ driver controls the hardware security peripherals in the hardware security module (hardware security module, HSM) domain and interacts with the host core. She+ provides an AUTOSAR interface that integrates HSM security functions into automotive applications, including interfacing with the AUTOSAR, enabling communication between the host core and the HSM, key security storage functions, and secure peripheral drivers. The CAN driver provides services using multiple can+ (multi can+) units in the ECU, with the CAN driver being utilized to send and receive CAN messages. The SecOC protocol is an optional software module of the BSW layer in the framework of the AUTOSAR software, and provides an interface for the SecOC to request a fresh value for the transmission or reception of a secure message by the application software module, and also provides an interface for the transmission of a failed or successful transmission or reception message by the application software module. The SecOC protocol can provide a message integrity authentication mechanism for the ECU message at the PDU level, and can ensure the freshness of the ECU message, thereby preventing the problem of ECU control caused by illegal device playback of the history message.

The message transmitted on the CAN FD bus may be securely verified by a key generation message authentication code MAC. Wherein the key and the freshness value corresponding to the message authentication code MAC are globally unique. Therefore, the receiving end can realize replay attack prevention through verification of a Freshness Value (FV), and the message authentication code MAC of the sent message is ensured to be unique in the key life cycle. The message authentication code is verified to verify the integrity of the message. For example, if the key is not updated during the entire vehicle's lifecycle, the freshness value guarantees a unique per message during the entire vehicle's lifecycle (e.g., the time the entire vehicle is produced, used, or scrapped from the vehicle).

The following describes a specific implementation procedure when communication is performed between ECUs in a vehicle, taking the SecOC protocol as an example. As shown in fig. 2, one possible vehicle communication method includes the following steps:

in step 201, the transmitting end generates a first message according to the first information and a Fresh Value (FV).

In step 201, the sender may use a counter to determine the freshness value of the sent message and the received message. Each time the sender sends a message, 1 may be added to the internally stored freshness value. In this way, since the message authentication code transmitted by the transmitting end is generated based on the current freshness value, even if the illegal device transmits the history message (carrying the history freshness value) generated before the transmitting end to the receiving end, the receiving end can determine whether the received message is a freshness message according to the freshness value carried in the first message authentication code, and when the received message is not a freshness message but a history message, the receiving end may not execute the corresponding control command. By the method, illegal equipment can be prevented from controlling the vehicle by using the historical information, so that the anti-attack capability of the vehicle can be improved.

In another possible implementation manner, the sending end may take the timestamp as a fresh value, and each time the sending end sends a message, the sending timestamp of the message may be determined according to a local clock for sending the message, so that the fresh value in the message may be implemented based on the sending timestamp of the message.

Step 202, the transmitting end sends a first message to the receiving end.

In step 202, considering that the data field of the CAN message frame is limited, in one possible implementation manner, the sending end may further truncate the fresh value first, and then assemble the truncated fresh value and the first information to obtain the first message.

Fig. 3 illustrates a manner of assembling a message provided in an embodiment of the present application, as shown in fig. 3, in which a fresh value is first divided into a low order of the fresh value and a high order of the fresh value, and then the low order (least significant bit, LSB) of the fresh value is taken, and the first information and the low order of the fresh value are sequentially spliced to obtain the message. For example, taking the timestamp to generate a fresh value as an example, i.e. the send message may contain 2 components: a plaintext message (n bits) and a truncated timestamp. The truncated timestamp may occupy m bits, and may be a part of the least significant bits of the truncated 64bits timestamp, i.e., the least significant bits of the FV.

In step 203, the receiving end verifies the fresh value in the first message.

After receiving the first message sent by the sending end, the receiving end respectively analyzes the first information and the fresh value (LSB low-bit truncated part of FV) in the first message.

Illustratively, if the sending end splices to obtain the first message in the manner illustrated in fig. 3, the receiving end may obtain the low order bits of the fresh value. In this case, the receiving end needs to recover the complete fresh value according to the low order of the fresh value carried in the message and the fresh value stored locally by the receiving end, where the locally stored fresh value is determined based on the low order of the fresh value carried in the history message received by the receiving end last time. The receiving end assembles the LSB low order truncated portion of the received fresh value FV with the upper (most significant bit, MSB) portion of the locally maintained FV to recover a complete fresh value FV. In an optional recovery manner, if the low order of the fresh value carried in the message is smaller than the low order of the locally stored fresh value, it is indicated that the low order of the fresh value has value range overflow in the increment process (for example, when the low order of the binary fresh value is incremented by 1 again, it becomes 0, and the high order of the fresh value is correspondingly incremented by 1), so that the receiving end can add 1 to the high order of the locally stored fresh value first, and then splice the high order of the locally stored fresh value and the low order of the fresh value carried in the message together to obtain the complete fresh value. If the low order of the fresh value carried in the message is not less than the low order of the fresh value stored locally, the low order of the fresh value is gradually increased under the condition that the fresh value does not overflow, so that the receiving end can directly splice the high order of the fresh value stored locally with the low order of the fresh value carried in the message to obtain the complete fresh value.

In an alternative embodiment, the receiving end may compare the LSB of the fresh value with the LSB of the locally stored historical fresh value to determine whether a replay attack is likely to exist, e.g., consider an overflow flip scenario of the LSB value range when the fresh value of the received message is less than the fresh value in the locally stored last received message, and increment the locally maintained FV MSB value. For example, if the freshness value is less than the locally stored freshness value, it is an indication that the message may be an offensive message that an illegitimate device has retransmitted using the history message. If the freshness value is greater than the locally stored freshness value, it is an indication that the message does not belong to a replay message. After verification, the receiving end may refresh the FV maintained locally by overlaying the FV in the last received message.

In step 204, the sender and receiver maintain synchronization of the fresh values.

In the embodiment of the application, although the fresh value monotonically increases according to the number of times of message transmission in the whole vehicle life cycle, each maintains own fresh value between the sending end and the receiving end, which may cause the fresh value between the sending end and the receiving end to be unsynchronized due to some unpredictable anomalies. For example, in one case, although the transmitting side transmits a message to the CAN FD bus, the CAN FD bus loses the message due to a fault, for example, the power-up and power-down wake-up sequence is not uniform between ECUs, and the CAN FD bus loses a frame abnormally. In this case, the receiving end cannot acquire the message, so that the fresh value in the receiving end is smaller than the fresh value in the transmitting end. In order to avoid this phenomenon, the present application may also set some fault-tolerant mechanism between the sending end and the receiving end to maintain accurate fresh value data. For example, under an alternative fault-tolerant mechanism, the sending end and the receiving end can be enabled to synchronize their respective fresh values periodically, and once the fresh value of one device is found to be smaller than that of the other device, the device with the smaller fresh value can be enabled to correct its own fresh value, so that the sending end and the receiving end can always keep the same fresh value.

Alternatively, the freshness value may employ both time stamping or monotonic counter alternatives.

In the scheme based on the monotonic counter as the fresh value, because the data frame value field space of the CAN is only 8 bytes, the space allocated to the fresh value FVLSB is only 8 bits, a transmission scheme with shortened fresh value is needed, and the replay attack prevention window is only maintained for about 2.5 seconds if the CAN FD bus is used for transmitting messages every 10ms under high load, the fresh value FVLSB overflows and overturns, and the complete fresh value must be rebuilt at the receiving end according to the prior condition. Therefore, there is a problem that the fresh value may be unsynchronized, and the complete fresh value needs to be periodically transmitted to each ECU. In one possible implementation manner, when determining that the step is out, the ECU may send a synchronization request message of the counter to the management device of the ECU, and after receiving the synchronization request message, the management device of the ECU broadcasts the synchronization message of the counter. This approach may be used by an attacker to broadcast spam messages with requests, resulting in security issues for system functions.

In a scheme based on a time stamp as a fresh value, the sender and receiver will use the time stamp of the local timer to determine the fresh value. In the time stamping scheme, the time of the receiving and transmitting ends is not synchronized due to clock oscillator bias on the receiver and transmitter ECU sides, assuming synchronization only during power-on (not re-synchronization) and clock oscillation of each ECU has a maximum clock error of +/-0.02%. Ecu_a has +0.02% error, while ecu_b has-0.02% error. For example, table 1 shows jitter generated by a clock oscillator corresponding to a duration of a fresh value.

TABLE 1

Duration of freshness value	Maximum jitter
24 hours	34.56 seconds
1 hour	1.44 seconds
For 1 minute	24 ms of
1 second	400 microseconds
1 millisecond (1 millisecond)	0.4 microsecond

Therefore, a time stamp synchronization mechanism needs to be used so that UTC time is synchronized among all ECUs. For example, UTC may be expressed for a time of 2038, 1 month, 19 days 03:14:07. In some embodiments, the synchronous CAN message may be sent by broadcast, with the message carrying the complete time. The scheme of synchronizing time is very complex, and in addition, the transmission of messages needs to be paused during time synchronization, which results in possible data delay and possibly reduced safety of the vehicle. Or, in order to prevent the broadcast time synchronization message from being interfered by other high-priority service messages, synchronization cannot be performed when the high-priority service message is sent on the CAN FD bus, which may result in failure to perform timely and accurate synchronization. In addition, if electromagnetic interference occurs on the CAN FD bus, the ECU may not be guaranteed to receive the synchronization message. In an abnormal situation, the receiver needs to wait for the next synchronization message, i.e. during the synchronization period (e.g. 1 second), the receiver cannot send and receive CAN messages, which would lead to system functional safety problems. Furthermore, replay attacks may also occur during the synchronization process. One way to prevent replay is that the master sync ECU (e.g., gateway) can increment the upper 32 bits of the 64 bit sync frame counter by 1 for each key start event detected, which results in increased replay difficulties. However, this solution requires an additional secure non-volatile memory to store the number of key start counters in the master synchronization ECU, increasing the cost and complexity of the fresh value synchronization.

Based on the above-mentioned problems, the present application provides an in-vehicle communication method, where the transmitting end and the receiving end may be any ECU in the vehicle. As shown in fig. 4, the method comprises the following steps:

step 401: the sending end determines the fresh value of the first message according to the sending time stamp of the sending end.

The sending end may determine the sending timestamp of the first message according to a timer of the sending end. The timer may be a local clock (internal clock), a unidirectional counter (monotonic counter), or the like, which is not limited in this application.

In one possible implementation manner, the sending end may use the sending timestamp of the first message as a fresh value of the first message, and each time the sending end sends the first message to the receiving end, the sending timestamp of the first message may be determined according to a local clock for sending the first message.

The implementation of the transmission timestamp of the first message will be described below using a timer as a local clock. In a possible example, a vehicle factory produces a key of a preset ECU for communication between the ECU and other ECUs, and the key is not updated in the whole vehicle life cycle, so that the local clock can only be increased in one direction from the first power-on operation of the ECU, the uniqueness of the sending time stamp is ensured, and the fresh value determined according to the sending time stamp can cover the whole vehicle life cycle.

The time storage format of the local clock may be UTC format, with a minimum unit of milliseconds. Of course, the minimum time unit of the local clock may also be determined according to the time precision of the local clock. For example, the minimum time unit of the local clock may be milliseconds. For example, when the number of bits occupied by the fresh value corresponding to the transmission time stamp is 64 bits, the minimum unit of the transmission time stamp can be satisfied as milliseconds. When the number of bits occupied by the fresh value corresponding to the transmission time stamp is 32 bits, the minimum unit of the transmission time stamp can be satisfied as seconds.

In some embodiments, the transmission timestamp determined by the local clock of the transmitting end may be stored in a timestamp format of UTC time, or may be a simplified timestamp, for example, the transmission timestamp stored by the local clock may satisfy: difference between UTC time and preset time. For example, the transmit timestamp may satisfy: UTC time minus 2000. When the number of bits occupied by the fresh value is 64 bits, the minimum unit that can satisfy the transmission time stamp is milliseconds. For example, the first message is sent at 2021, 1 month, 19 days 03:14:07:01:1. Considering that the whole vehicle life cycle may reach 10-20 years, the transmission time stamp may be set as: the transmission time stamp may be 210119031407011 in the form of 21-month 19-day 03:14:07:01:1. I.e. the minimum time unit of the transmission time stamp is milliseconds.

Considering that during transmission the number of bits that a fresh value can occupy is limited. Therefore, in the application, the first time precision met by the corresponding sending time stamp in the fresh value can be determined according to the bit number occupied by the fresh value of the first message. I.e. the first time precision of the transmission time stamp meets the requirements of the bits of the first message transmission freshness value. As shown in fig. 5, when the time precision of the local clock at the transmitting end is higher than the time precision of the transmission time stamp, the higher order bits in the transmission time determined by the local clock may be selected as the transmission time stamp. For example, when the number of bits occupied by the fresh value is 32 bits, the minimum unit of transmission time stamp may be satisfied as seconds. For example, the transmission time for transmitting the first message is 2021, 1 month, 19 days 03:14:07:01:1, and the transmission time stamp may be determined as: the transmission time stamp may be 210119031407, which is the form of 21-year 1-month 19-day 03:14:07.

After determining the minimum unit of the sending timestamp carried by the fresh value, the replay time windows of the sending end and the receiving end in normal operation CAN be correspondingly determined, for example, assuming that the message sending time of the CAN FD bus is 1ms, the replay time windows are 1s, that is, the sending end and the receiving end CAN control replay attack within 1000 times.

The sending end can regularly rewrite local time into the safe nonvolatile storage in the running process. By the method, after the sender is restarted, the local clock after restarting is updated by copying the local time in the safe nonvolatile storage, so that the local clock of the sender is ensured to be monotonically increased, namely, the sending timestamp generated by the sender is ensured to be monotonically increased, and further, the freshness value is ensured to be monotonically increased. The stored local time may be the minimum unit of time that the local clock may reach. For example, when the minimum time unit of the local clock of the transmitting end is milliseconds, the local time of millisecond level may be rewritten into the secure nonvolatile storage.

In some embodiments, the timing of the local time copying may be written before the vehicle is powered down or the transmitting end is dormant, and correspondingly, the local clock of the transmitting end may read the local time reset value from the secure nonvolatile storage every time the vehicle is powered up or the transmitting end is awakened, so as to ensure that the timestamp generated by the local clock of the vehicle is monotonically increasing. The timing of local time copying may also be periodic writing, and the copying period may be determined according to the copying capability supported by hardware, for example, the copying period value is per second, per minute or per hour, which is not limited in this application.

Considering another scene of restarting the transmitting end of the vehicle, for example, in a vehicle maintenance and replacement scene, after restarting, the transmitting end can reset the local clock of the transmitting end according to the transmitting timestamp stored before restarting the transmitting end, so that the fresh value generated by the transmitting end is monotonously increased in the whole vehicle life cycle after maintenance and replacement.

Taking a CAN FD message frame to support 64 bytes (bytes), the number of bits occupied by the fresh value is 32 bits as an example, and the minimum time unit of the transmission timestamp carried by the fresh value is seconds. At this time, the transmitting end may directly splice the first information, the fresh value, and the first message authentication code to generate the first message. And transmitting the truncated fresh value and the truncated first message authentication code in the first message in a truncated mode is avoided. Therefore, the method and the device avoid the synchronization of the fresh value between the sending end and the receiving end by periodically sending the complete fresh value, save the expenditure caused by sending the information of the synchronous fresh value between the sending end and the receiving end, avoid the problems that the receiving end possibly cannot timely receive the information of the synchronous fresh value, the transmission information cannot be normally received, and the like, and improve the transmission performance between the sending end and the receiving end.

Step 402: and the sending end generates a first message authentication code according to the first information, the freshness value and the secret key.

The first information may be information to be sent, which is sent by the sending end to the receiving end. The key may be a long-term key in the vehicle, or may be a long-term key between the transmitting end and the receiving end, which is not limited herein. The transmitting end or the receiving end may be any ECU in the vehicle.

In an alternative embodiment, the sending end may be further provided with a message authentication code generator, where the message authentication code generator is configured to process the input information according to a preset generation algorithm to obtain and output a message authentication code. When the preset generation algorithm is a message authentication code (CMAC) AES128 (compliant with RFC 4493) based on block encryption, if the sender inputs the first information I, the freshness value FV and the key { M } together into the message authentication code generator, the message authentication code generator may calculate and output a first message authentication code L1 according to the following formula (1.1):

L1＝CMAC-AES128(I||FV，{M})……(1.1)

as can be seen from the above formula (1.1), when the key { M } is a symmetric key having an AES 128-bit length, the first message authentication code L1 may also have a length of 128 bits.

The first information is data carried in the first message. Where "||" can be understood as stitching, e.g., M1 can be stitching together corresponding bytes of I and FV. For example, in the process of calculating L1, calculation may be performed after splicing according to the first information I and the freshness value FV.

Step 403: the sending end generates and sends a first message to the receiving end according to the first information, the freshness value and the first message authentication code.

The first message comprises a sending time stamp of the sending end; the transmission time stamp is a fresh value generated by the sender for the first message. Correspondingly, the receiving end receives the first message.

In step 403, in consideration of the limited data field of the CAN message frame, in order to successfully transmit the first message, the transmitting end may truncate the first message authentication code first, and then assemble the truncated first message authentication code and the first message to obtain the first message. Considering that the security of the first information transmission decreases linearly as the length of the first message authentication code becomes smaller, and the message authentication code with the length of 64bits or more generally has sufficient anti-attack capability, the sender may further set the length of the first message authentication code to be not less than 64bits when truncating the message authentication code.

It should be noted that the first message may not include the first message authentication code, that is, the first message is composed of the first information and the freshness value. That is, step 402 may not be performed, and when step 403 is performed, the transmitting end may generate and transmit the first message to the receiving end according to the first information and the freshness value. At this time, the transmitted first message may contain a plaintext message (n bits) and a freshness value, which is generated by the transmission time stamp. For example, the fresh value may occupy 32 bits, and the transmission timestamp corresponding to the fresh value may be a part of the most significant bit of the 64bits timestamp determined by the timer of the intercepting transmitting end, that is, the most significant bit of the FV.

Fig. 6 illustrates a manner of assembling a first message provided in an embodiment of the present application, as shown in fig. 6, where a fresh value is first divided into a low order of the fresh value and a high order of the fresh value, a first message authentication code is divided into a low order of the first message authentication code and a high order of the first message authentication code, and then the first information, the fresh value and the high order of the first message authentication code (MSB) are sequentially spliced to obtain the message. For example, taking the timestamp to generate a fresh value as an example, i.e. the send message may contain 3 components: clear text messages (n bits), fresh values (generated from the transmit timestamp) and truncated message authentication codes. For example, the fresh value may occupy 32 bits, and the transmission timestamp corresponding to the fresh value may be a part of the most significant bit of the 64bits timestamp determined by the timer of the intercepting transmitting end, that is, the most significant bit of the FV. The truncated message authentication code may occupy k bits, which is a portion of the most significant bits of the truncated 128bits message authentication code CMAC. In a CAN frame, the number of bits occupied by a plaintext message may satisfy n=64-k-m (bits). Wherein n, m, k are positive integers.

Step 404: and the receiving end verifies the first message according to the receiving time stamp and the sending time stamp of the first message.

In one possible implementation manner, after the receiving end receives the first message sent by the sending end, the receiving end analyzes the first information, the freshness value and the message authentication code (truncated part of the MAC) in the first message respectively.

In an alternative embodiment, the receiving end may verify the fresh value with the locally stored historical fresh value, and if the fresh value is smaller than the locally stored fresh value, it indicates that the message may be an offensive message retransmitted by the illegal device using the historical message, so the receiving end may not execute the corresponding control command, or may also return a warning message to the sending end. If the freshness value is greater than the locally stored freshness value, it is an indication that the message does not belong to a replay message. If the freshness value is equal to the locally stored freshness value, a verification can be made based on the receipt timestamp and the historical timestamp to determine if the first message is a replay message.

It can be seen that, in this manner, since the high-order fresh value is sent, the problem of LSB value range overflow of the fresh value in fig. 2 does not exist, and the reliability of the fresh value is effectively improved.

One possible implementation manner, the timer of the transmitting end and the timer of the receiving end do not perform time synchronization operation. In this manner, the receiving end may determine the reception timestamp of the first message according to the timer of the receiving end. The timer of the receiving end may be a local clock (Internal clock) of the receiving end, a unidirectional counter (monotonic counter) of the receiving end, or the like, which is not limited in this application.

The implementation of the reception timestamp of the first message will be described below by taking a timer at the receiving end as a local clock. In a possible example, a vehicle factory produces a key preset on a receiving end for communication between the receiving end and a transmitting end, the key is not updated in the whole vehicle life cycle, and the local clock of the receiving end can only be increased in one direction from the first power-on operation of the receiving end, so that the uniqueness of the time stamp is ensured, and the fresh value determined according to the time stamp can cover the whole vehicle life cycle.

In some embodiments, the time storage format of the local clock of the receiving end may be UTC format, with a minimum unit of milliseconds. Of course, the minimum time unit of the local clock may also be determined according to the time precision of the local clock. For example, the minimum time unit of the local clock may be milliseconds. I.e. the time precision of the reception time stamp is the second time precision. The second time precision is greater than the time precision of the corresponding transmit timestamp in the freshness value of the first message.

In some embodiments, taking the minimum time unit of the local clock of the receiving end as a millisecond as an example, the receiving timestamp determined by the local clock of the receiving end may be stored in UTC format, or may be a simplified timestamp, for example, the receiving timestamp determined by the local clock of the receiving end may satisfy: difference between UTC time and preset time. For example, the receive timestamp may satisfy: UTC minus 2000. When the bit number of the reception timestamp is 64 bits, the minimum unit that can satisfy the reception timestamp is milliseconds.

As shown in connection with fig. 5, the reception timestamp of the receiving end may be determined according to the time when the local clock of the receiving end receives the first message. For example, the time for the receiving end to receive the first message is 2021, 1 month, 19 days 03:14:40:01:2. Considering the length of the whole vehicle life cycle, the receiving time stamp can be set as follows: the form of the 21 st month 19 th 03:14:40:01:2, i.e. the reception time stamp may be 210119031440012. I.e. the minimum time unit of the reception timestamp is milliseconds.

In some embodiments, considering that the time between the transmitting end and the receiving end may not be synchronized, at this time, taking the time coincidence of the transmitting end and the receiving end at the time of initialization as an example, when the running time of the transmitting end and the receiving end is 1 day, the time drift between the transmitting end and the receiving end may reach 34 seconds. Therefore, the reception time stamp of the first message cannot be directly used for verification of the replay attack of the first message. In order to enable the receiving end to meet the requirement of replay attack verification, in the application, the first message can be subjected to replay attack verification according to the receiving time stamp of the first message and the sending time stamp of the first message.

In some embodiments, the receiving end may use the transmission time stamp in the first message as a primary authentication portion of the first message and the reception time stamp as a secondary authentication portion of the first message.

For example, when the transmission time stamp in the first message is greater than the last received historical transmission time stamp transmitted by the transmitting end stored by the receiving end, it may be determined that the verification of the freshness value of the first message is successful, and the first message is not a replay message.

When the transmission time stamp in the first message is smaller than the last received historical transmission time stamp transmitted by the transmitting end and stored by the receiving end, the verification failure of the freshness value of the first message can be determined, and the first message is a replay message.

When the sending time stamp in the first message is equal to the historical sending time stamp of the message sent by the sending end and received last time and stored by the receiving end, the receiving time stamp of the first message can be further compared with the historical receiving time stamp stored when the message sent by the sending end and received last time and stored when the receiving time stamp of the first message is greater than the historical receiving time stamp stored when the message sent by the sending end and received last time and received by the receiving end, it can be determined that the fresh value verification of the first message is successful and the first message is not a replay message. When the reception timestamp of the first message is less than or equal to the historical reception timestamp stored when the receiving end last received the message sent by the sending end, it may be determined that the verification of the freshness value of the first message fails, and the first message is a replay message.

That is, it is determined whether the first message is a replay message by means of a combined verification of the reception timestamp of the first message and the transmission timestamp of the first message.

Referring to fig. 5, taking a minimum time unit of a local clock of the receiving end as a millisecond, a minimum time unit of a transmission timestamp corresponding to a fresh value transmitted by the transmitting end as a second as an example. The transmission time stamp of the first message is: 21, 1 month and 19 days 03:14:07. The reception timestamp is used as a second verification part of the first message by using the transmission timestamp in the first message as a first verification part of the first message.

When the historical transmission time stamp of the message transmitted by the transmitting end stored by the receiving end is 03:13:01 of 1 month and 19 days of 21 years, the transmission time stamp of the first message can be determined to be larger than the historical transmission time stamp of the message stored by the receiving end, so that the first message can be determined not to be a replay message, and the replay verification is successful.

When the historical transmission time stamp of the message transmitted by the transmitting end stored by the receiving end is 03:14:07 on the 1 st month and 19 th day of 21 years, the transmission time stamp of the first message can be determined to be equal to the historical transmission time stamp of the message stored by the receiving end, and at the moment, the second verification can be performed through the receiving time stamp.

At this time, in one possible scenario, when the historical reception timestamp of the message sent by the sending end and stored by the receiving end is 21 years 1 month 19 days 03:14:38:01:2, the reception timestamp of the first message is: the first message is determined not to be a replay message, and verification is successful, if the receiving timestamp of the first message is greater than the historical receiving timestamp of the message sent by the sending end and stored by the receiving end, namely, the receiving timestamp of the first message is 1 month and 19 days of 21:14:40:01:2.

In another possible scenario, when the historical reception timestamp of the message sent by the sending end and stored by the receiving end is 21 years 1 month 19 days 03:14:40:01:3, the reception timestamp of the first message is: the first message is a replay message and verification fails, as determined by 1 month and 19 days of 21, 03:14:40:01:2, that is, the receiving timestamp of the first message is smaller than the historical receiving timestamp of the message sent by the sender and stored by the receiver.

In yet another possible scenario, it may also be determined whether the first message is a replay message by a replay time window of the transmitting end and the receiving end. For example, the playback time window of the transmitting end and the receiving end in normal operation may be determined based on the minimum time unit of the transmission time stamp carried by the fresh value. In addition, the first receiving time stamp determined by the local clock of the receiving end is also considered, so that the number of replay attacks between the sending end and the receiving end can be effectively reduced. Since the time precision of the first reception time stamp is the second time precision, for example, when the minimum time unit of the local clock of the receiving end is millisecond, the time precision of the first reception time stamp is millisecond, the playback time window can be controlled at millisecond level or sub second level. For example, assuming that the CAN FD bus transmits a message for 1ms, the playback time window is 0.5s, i.e., the transmitting side and the receiving side CAN control the playback attack within 500 times.

At this time, after determining that the transmission time stamp of the first message is equal to the historical transmission time stamp of the message transmitted by the transmitting end stored by the receiving end, the receiving end may also perform secondary verification on the reception time stamp of the first message through playback time windows of the transmitting end and the receiving end. For example, when the difference between the reception time stamp of the first message and the historical reception time stamp of the message transmitted by the transmitting end stored by the receiving end is less than or equal to the playback time window, it may be determined that the first message is not a playback message, and the first message authentication is successful. When the difference between the reception time stamp of the first message and the historical reception time stamp of the message transmitted by the transmitting end stored by the receiving end is greater than the playback time window, it may be determined that the first message is a playback message, and the first message authentication fails.

After the verification of the fresh value is finished, the receiving end can refresh the locally maintained fresh value by covering the fresh value in the last received message. In addition, the receiving end can copy the fresh value in the first message and the fresh value corresponding to the receiving time stamp into the safe nonvolatile storage for verifying the message sent by the sending end which is received next time. Alternatively, the transmission time stamp and the reception time stamp may be rewritten into a secure nonvolatile storage for verifying a message (e.g., a second message) transmitted from the transmitting terminal that is received next. The copying mode may be to replace the original sending time stamp of the message sent by the sending end and the receiving time stamp of the message, or to store the sending time stamp and the receiving time stamp of the message sent by the sending end separately.

Illustratively, if the sending end splices to obtain the first message in the manner illustrated in fig. 6, the receiving end may obtain the freshness value and the high order of the authentication code of the first message. Furthermore, the receiving end can generate a second message verification code according to the first information, the secret key and the freshness value.

In this embodiment of the present application, a message authentication code parser may be further provided in the receiving end, where the message authentication code parser is configured to process input information according to the same generation algorithm preset by the message authentication code generator in the sending end to obtain and output a message authentication code. When the preset generation algorithm is CMAC-AES128 (compliant with RFC 4493), if the receiving end inputs the first information I, the fresh value FV, and the locally stored key { M } together into the message authentication code parser, the message authentication code parser may calculate and output the second message authentication code L2 according to the above formula (1.1).

Upon determining that the second message authentication code is the same as the first message authentication code, a success of the first message authentication may be determined.

For example, the receiving end judges whether the second message authentication code generated by the receiving end is the same as the first message authentication code carried in the first message, if so, the receiving end indicates that the key stored in the local RAM of the receiving end is the same as the key corresponding to the first message, the receiving end belongs to the vehicle-mounted device for executing the first message, and executes corresponding operation on the first message. If the first message is different, the receiving end is not the vehicle-mounted device for executing the first message, so the receiving end can ignore the first message.

According to the embodiment, the message is authenticated by using the message authentication code generated by the fresh value and the secret key, so that the first information can be prevented from being tampered in the process of in-vehicle transmission, the behavior of attacking the vehicle by using the historical message can be accurately detected, and corresponding operation can be executed under the condition that the authentication information is accurately transmitted, and the safety of the vehicle in executing vehicle communication can be guaranteed accurately.

In addition, the receiving end can regularly rewrite the local time into the safe nonvolatile storage in the operation process, and the local time in the safe nonvolatile storage can be rewritten after the receiving end is restarted, so that the local clock after restarting is updated, and the local clock of the receiving end is ensured to be monotonically increased, namely the receiving timestamp generated by the receiving end is ensured to be monotonically increased. The stored local time may be the minimum unit of time that the local clock may reach. For example, when the minimum time unit of the local clock of the receiving end is milliseconds, the local time of millisecond level may be rewritten into the secure nonvolatile storage.

In some embodiments, the time when the receiving end rewrites the local time may be when the vehicle is powered down or the receiving end writes before dormancy, and correspondingly, the local clock of the receiving end may read the local time reset value from the secure nonvolatile storage each time the vehicle is powered up or the receiving end wakes up, so as to ensure that the timestamp generated by the local clock of the vehicle is monotonically increasing. The timing of local time copying may also be periodic writing, and the copying period may be determined according to the copying capability supported by hardware, for example, the copying period value is per second, per minute or per hour, which is not limited in this application.

Consider another scenario, for example, in a vehicle repair replacement scenario, the local clock of the receiving end may be reset based on the transmit timestamp and the receive timestamp stored before the receiving end was restarted. Alternatively, the local clock of the receiving end may be reset according to the first receiving timestamp and the sending timestamp stored before the receiving end is restarted. After maintenance and replacement of the parts are guaranteed, the receiving time stamp generated by the receiving end is monotonically increased in the whole vehicle life cycle.

When the receiving end is restarted, a playback time window of the receiving end can be determined based on the copying period and the recovery time corresponding to the abnormal restart.

One possible implementation manner, the playback time window of the receiving end after restarting may satisfy: the sum of the copying period and the restart recovery time of the receiving end. For example: when the reproduction period is 1 minute and the restart recovery time is 10s, the playback time window after the restart can be determined to be 70s.

In another possible implementation manner, the playback time window of the receiving end after restarting may satisfy: the sum of the copying period and the time of the first legal message received after the restart recovery of the receiving end. For example, the time of the first legal message received after the restart recovery of the receiving end is 10ms, the copying period is 1 minute, and it may be determined that the playback time window after the restart may be 60s+10ms.

In another possible implementation manner, the playback time window of the receiving end after restarting may satisfy: the sum of the copying period and the restart recovery time of the receiving end is different from the time of the first legal message received after the restart recovery of the receiving end. For example, the time of the first legal message received after the restart recovery of the receiving end is 10ms, the sum of the copying period and the restart recovery time of the receiving end is 70s, and the playback time window after the restart is 70s-10ms.

In another possible implementation manner, the playback time window of the receiving end after restarting may satisfy: and the minimum value between the sum of the copying period and the restarting recovery time of the receiving end and the time of the first legal message received after the restarting recovery of the receiving end. For example, the time of the first legal message received after the restart recovery of the receiving end is 1s, and the sum of the copying period and the restart recovery time of the receiving end is 70s, then the playback time window after the restart is 1s. The whole fresh value is carried by each message and the time axis synchronization mechanism at the receiving end is not dependent on an additional fresh value synchronization message mechanism, so that the problem of step out caused by a fresh value timestamp synchronization scheme and the problem of reliability of a complex synchronization message mechanism are avoided. The sending time stamp of the first message is adopted to determine the fresh value, the receiving time stamp is obtained at the receiving end, verification is completed by the sending time stamp and the receiving time stamp, the sending end can meet the requirement of preventing replay attack only by sending the time stamp with a limited length, and excessive bits are not needed to be occupied for sending the fresh value, so that the effective load of message transmission is improved.

Fig. 7 is a schematic structural diagram of an in-vehicle communication device according to an embodiment of the present application, as shown in fig. 7, the device may be a receiving end or a transmitting end, or may be a chip or a circuit, for example, may be disposed in the receiving end, for example, may be disposed in the transmitting end, and for example, may be disposed in the transmitting end.

Further, the in-vehicle communication device 701 may further include a bus system, where the processor 702, the memory 704, and the transceiver 703 may be connected by the bus system.

It should be appreciated that the processor 702 may be a chip. For example, the processor 702 may be a field programmable gate array (field programmable gate array, FPGA), an application specific integrated chip (application specific integrated circuit, ASIC), a system on chip (SoC), a central processing unit (central processor unit, CPU), a network processor (network processor, NP), a digital signal processing circuit (digital signal processor, DSP), a microcontroller (micro controller unit, MCU), a programmable controller (programmable logic device, PLD) or other integrated chip.

In implementation, the steps of the methods described above may be performed by integrated logic circuitry in hardware or instructions in software in the processor 702. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in hardware processor execution or in a combination of hardware and software modules in the processor 702. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in the memory 704, and the processor 702 reads information in the memory 704 and performs the steps of the method described above in connection with its hardware.

It should be noted that the processor 702 in the embodiments of the present application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments may be implemented by integrated logic circuits of hardware in a processor or instructions in software form. The processor may be a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, or discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in hardware, in a decoded processor, or in a combination of hardware and software modules in a decoded processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads the information in the memory and, in combination with its hardware, performs the steps of the above method.

It is to be appreciated that the memory 704 in embodiments of the application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The nonvolatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an electrically Erasable EPROM (EEPROM), or a flash memory. The volatile memory may be random access memory (random access memory, RAM) which acts as an external cache. By way of example, and not limitation, many forms of RAM are available, such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous DRAM (SLDRAM), and direct memory bus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

In the case that the in-vehicle communication device 701 corresponds to the receiving end in the above method, the in-vehicle communication device may include a processor 702, a transceiver 703, and a memory 704. The memory 704 is configured to store instructions, and the processor 702 is configured to execute the instructions stored in the memory 704 to implement aspects related to a receiving end in a corresponding method as shown in any one or more of fig. 4 to 6.

When the in-vehicle communication device 701 is the receiving end, the in-vehicle communication device 701 may be configured to perform the method performed by the receiving end in any of the above embodiments. When the in-vehicle communication device 701 is the receiving end, the transceiver 703 receives a first message, where the first message includes a transmission timestamp of the transmitting end; the sending timestamp is a fresh value generated by the sending end for the first message; the processor 702 validates the first message based on the receive timestamp and the transmit timestamp of the first message.

When the in-vehicle communication device 701 is the transmitting end, the in-vehicle communication device 701 may be configured to perform the method performed by the transmitting end in any of the above embodiments. The transceiver 703 is configured to send a first message to a receiving end. Processor 702 generates a freshness value for the first message based on the transmission time stamp of the first message; a first message is generated based on the freshness value of the first message.

Based on the above embodiments and the same concept, fig. 8 is a schematic diagram of an in-vehicle communication device provided in the embodiments of the present application, and as shown in fig. 8, the in-vehicle communication device 801 may be a receiving end or a transmitting end, or may be a chip or a circuit, for example, may be a chip or a circuit disposed in the receiving end or the transmitting end.

The in-vehicle communication device may correspond to the receiving end or the transmitting end in the above method. The in-vehicle communication device may implement the steps performed by the receiving end or the transmitting end in any one or any methods corresponding to any one or more of the above-described methods shown in fig. 4 to 6. The in-vehicle communication device may include a processing unit 802. Optionally, a receiving unit 803 and a transmitting unit 804 may also be included.

When the in-vehicle communication device 801 is the receiving end and the steps performed by the receiving end in fig. 4 are implemented, the receiving unit 803 is configured to receive a first message, where the first message includes a transmission timestamp of the transmitting end; the sending timestamp is a fresh value generated by the sending end for the first message; the processing unit 802 validates the first message based on the receive timestamp and the transmit timestamp of the first message.

In one possible implementation, when the transmission time stamp is equal to the historical transmission time stamp, the processing unit 802 verifies the historical reception time stamp according to the reception time stamp.

In one possible implementation, after the first message is verified, the processing unit 802 verifies the second message according to the reception timestamp and the transmission timestamp of the received first message; the second message is received after the first message.

In one possible implementation, after the first message is verified successfully, the processing unit 802 stores a reception timestamp and a transmission timestamp of the first message, where the reception timestamp and the transmission timestamp of the first message are used to verify the second message received after the first message; and/or, after the first message is successfully authenticated, the processing unit 802 stores the transmit timestamp and the receive timestamp.

In other embodiments, the in-vehicle communication device may be a transmitting end in the vehicle, and the processing unit 802 generates the freshness value of the first message according to the transmission timestamp of the first message; generating a first message according to the freshness value of the first message; the sending unit 803 is configured to send a first message to a receiving end.

The transmitting unit 804 may be a transmitting unit or a transmitter when transmitting information, the receiving unit 803 may be a receiving unit or a receiver when receiving information, the transmitting unit 804 and the receiving unit 803 may be transceivers, and the transceivers, the transmitter or the receiver may be radio frequency circuits, where when the in-vehicle communication device 801 includes a storage unit, the storage unit is used to store computer instructions, and the processing unit 802 is communicatively connected to the storage unit, and the processing unit 802 executes the computer instructions stored by the storage unit, so that the in-vehicle communication device 801 may be used to execute the method performed by the receiving end or the transmitting end in the foregoing embodiment. The processing unit 802 may be a general-purpose Central Processing Unit (CPU), microprocessor, application specific integrated circuit (Application Specific Intergrated Circuit, ASIC).

When the in-vehicle communication device 801 is a chip, the transmitting unit 804 and the receiving unit 803 may be input and/or output interfaces, pins, circuits, or the like. The processing unit 802 may execute computer-executable instructions stored by the storage unit to cause a chip within the in-vehicle communication device 801 to perform the method performed by any of the embodiments.

Alternatively, the storage unit is an on-chip storage unit, such as a register, a cache, or the like, and the storage unit may also be an on-chip storage unit located outside the chip in the in-vehicle communication apparatus 801, such as a Read Only Memory (ROM) or other type of static storage device that can store static information and instructions, a random access Memory (Random Access Memory, RAM), or the like.

The concepts related to the technical solutions provided in the embodiments of the present application related to the in-vehicle communication device 801 are explained and detailed in the foregoing methods or descriptions of the contents in other embodiments, and are not repeated herein.

According to the method provided by the embodiment of the application, the application further provides a computer program product, which comprises: computer program code which, when run on a computer, causes the computer to perform the method of any of the embodiments shown in fig. 4 to 6.

According to the method provided in the embodiments of the present application, there is further provided a computer readable storage medium storing a program code, which when run on a computer, causes the computer to perform the method of any one of the embodiments shown in fig. 4 to 6.

According to the method provided by the embodiment of the application, the application also provides an in-vehicle communication system which comprises a transmitting end and a receiving end of the method.

The embodiment of the application also provides a vehicle, which comprises at least one transmitting end and at least one receiving end.

As used in this specification, the terms "component," "module," "system," and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Furthermore, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from two components interacting with one another in a local system, distributed system, and/or across a network such as the internet with other systems by way of the signal).

Those of ordinary skill in the art will appreciate that the various illustrative logical blocks (illustrative logical block) and steps (steps) described in connection with the embodiments disclosed herein can be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of elements is merely a logical functional division, and there may be additional divisions of actual implementation, e.g., multiple elements or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims. It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present application without departing from the scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims and the equivalents thereof, the present application is intended to cover such modifications and variations.

Claims

An in-vehicle communication method, which is applied to a receiving end, includes:

receiving a first message, wherein the first message comprises a sending time stamp of a sending end; the sending timestamp is a fresh value generated by the sending end for the first message;

and verifying the first message according to the receiving time stamp and the sending time stamp of the first message.
The method of claim 1, wherein the timer of the transmitting end and the timer of the receiving end do not perform time synchronization.
The method according to any of claims 1-2, wherein said validating said first message based on said receive timestamp and said transmit timestamp comprises:

and when the sending time stamp is equal to the historical sending time stamp, verifying according to the receiving time stamp and the historical receiving time stamp.
A method according to any one of claims 1-3, wherein the method further comprises:

after the first message is successfully verified, verifying a second message according to the received time stamp and the sent time stamp of the received first message; the second message is received after the first message.
The method of any of claims 1-4, wherein the timer of the transmitting end and the timer of the receiving end are related to a complete vehicle life cycle of the vehicle.
An in-vehicle communication device, applied to a receiving end, comprising:

a receiving unit, configured to receive a first message, where the first message includes a transmission timestamp of a transmitting end; the sending timestamp is a fresh value generated by the sending end for the first message;

and the processing unit is used for verifying the first message according to the receiving time stamp and the sending time stamp of the first message.
The apparatus of claim 6, wherein the timer at the transmitting end and the timer at the receiving end do not perform time synchronization.
The apparatus according to any one of claims 6 to 7, wherein,

the processing unit is specifically configured to verify according to the reception timestamp and the historical reception timestamp when the transmission timestamp is equal to the historical transmission timestamp.
The apparatus according to any one of claims 6-8, wherein the processing unit is further configured to:

after the first message is successfully verified, verifying a second message according to the received time stamp and the sent time stamp of the received first message; the second message is received after the first message.
The apparatus of any of claims 6-9, wherein the timer of the transmitting end and the timer of the receiving end are related to a complete vehicle life cycle of the vehicle.
An in-vehicle communication device, comprising:

a processor and interface circuit;

wherein the processor is coupled to a memory through the interface circuit, the processor being configured to execute the program code in the memory to implement the method of any one of claims 1 to 5.
A vehicle comprising a transmitting end and a receiving end, the receiving end being configured to implement the method of any one of claims 1 to 5.
A computer readable storage medium, characterized in that it stores a computer program, which, when executed, implements the method of any one of the preceding claims 1 to 5.
A computer program product, characterized in that it comprises a computer program which, when executed by an in-vehicle communication device, implements the method according to any of the preceding claims 1 to 5.
A chip, comprising: a processor for invoking a computer program stored in a memory to cause the processor to execute program code in the memory to implement the method of any of claims 1-5.