WO2022246760A1 - 一种车内通信方法及装置 - Google Patents

一种车内通信方法及装置 Download PDF

Info

Publication number
WO2022246760A1
WO2022246760A1 PCT/CN2021/096507 CN2021096507W WO2022246760A1 WO 2022246760 A1 WO2022246760 A1 WO 2022246760A1 CN 2021096507 W CN2021096507 W CN 2021096507W WO 2022246760 A1 WO2022246760 A1 WO 2022246760A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
sending
timestamp
receiving
vehicle
Prior art date
Application number
PCT/CN2021/096507
Other languages
English (en)
French (fr)
Inventor
耿峰
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to CN202180098686.0A priority Critical patent/CN117413545A/zh
Priority to PCT/CN2021/096507 priority patent/WO2022246760A1/zh
Publication of WO2022246760A1 publication Critical patent/WO2022246760A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication

Definitions

  • the present application relates to the technical field of intelligent networked vehicles, in particular to an in-vehicle communication method and device.
  • CAN controller area network
  • LIN local interconnection network
  • MOST multimedia transmission system
  • CAN protocol Due to the advantages of CAN protocol in terms of real-time and reliability, it has been widely used in vehicle network communication.
  • the CAN bus adopts a message-oriented protocol and a broadcast bus network architecture, so it is difficult to directly deploy the security measures in the prior art to the vehicle network communication.
  • each frame injected by the attacker may be read as a legal frame, thereby realizing the functions of controlling the vehicle, such as acceleration or braking operations, thus causing potential safety hazards in the car.
  • the automotive open system architecture automotive open system architecture, AUTOSAR
  • the information security component secure onboard communication, SecOC
  • PDU protocol data unit
  • ECU electronic control unit
  • the AUTOSAR SecOC specification provides two options for fresh values: timestamp and monotonic counter.
  • the time stamping scheme relies on synchronizing the coordinated universal time (UTC) among all ECUs, but problems such as clock jitter and time stamp synchronization anomalies will cause the receiver to fail to receive CAN messages, resulting in system functional safety issues.
  • This application provides an in-vehicle communication method and device, so that in the in-vehicle network communication, the sending of messages between the receiving end and the sending end does not depend on the synchronization of the fresh value, so as to prevent replay attacks and reduce the communication between the receiving end and the sending end. the complexity of data transmission.
  • the present application provides an in-vehicle communication method applied to the receiving end, including: receiving the first message, the first message includes the sending time stamp of the sending end; the sending time stamp is the fresh value generated by the sending end for the first message ; Verifying the first message according to the receiving timestamp and sending timestamp of the first message.
  • the sending end and the receiving end can be any ECU in the vehicle.
  • the sending end may determine the sending time stamp for sending the first message according to the timer of the sending end.
  • the timer may be an internal clock or a monotonic counter, etc., which are not limited in this application.
  • Timestamps can meet the requirements of anti-replay attacks, and do not need to occupy too many bits for sending fresh values, increasing the payload of message delivery.
  • the anti-replay attack effect can be guaranteed, and the additional overhead that may be caused by the method of fresh value synchronization can be avoided, especially the failure that may be caused when the fresh value synchronization cannot be completed.
  • the problem of verifying the first message improves the effect of preventing replay attacks.
  • the timer at the sending end does not perform time synchronization with the timer at the receiving end.
  • the sending end and the receiving end do not need to perform time synchronization operations, which reduces the complexity of preventing replay attacks.
  • the receiving end can further verify by receiving the timestamp, so as to improve the effect of anti-replay verification.
  • the second time precision of the received time stamp meets the requirements of the first message for replay attack verification; the first time precision of the sent time stamp of the first message meets the requirements of the bits of the fresh value of the first message. Require.
  • the number of bits that can be occupied by the fresh value is limited, so as to meet the requirement of the number of bits of the valid data carried in the first message sent.
  • the number of bits of the first message is 64 bits
  • the fresh value occupies 32 bits
  • the life cycle of the fresh value is 10 to 20 years
  • the minimum time unit of the sending timestamp that the fresh value can carry can correspond to seconds.
  • the first time precision of the sending timestamp is a time precision of 1 second
  • the number of bits of the corresponding freshness value is 32 bits.
  • the second time precision of the received time stamp meets the requirements of replay attack verification, and the first time precision of the sent time stamp increases the payload of the data in the message and improves the transmission efficiency.
  • the second message is verified according to the receiving timestamp of the first message and the sending timestamp of the first message; the second message is received after the first message arrived.
  • the receiving timestamp of the first message and the sending timestamp of the first message can be used as a verification credential for the second message received next time, thereby simplifying the complexity of verification.
  • the receiving timestamp and sending timestamp of the first message are stored, and the receiving timestamp and sending timestamp of the first message are used to verify the information received after the first message Second message.
  • the receiving time stamp of the first message and the sending time stamp of the first message can be stored as the verification credential for the next received second message, which simplifies the complexity of verification.
  • the timer at the sending end and the timer at the receiving end are related to the entire vehicle life cycle of the vehicle.
  • the present application provides an in-vehicle communication method applied to the sending end, including: generating the freshness value of the first message according to the sending timestamp of the first message; generating the first message according to the freshness value of the first message ; Send the first message to the receiver.
  • the first message is verified by the receiving end according to the receiving time stamp of the first message and the sending time stamp in the first message.
  • the sending time stamp of the first message is used to determine the fresh value, and the lower bit of the time stamp is not required to be truncated to avoid the problem of overflow and inversion.
  • the receiving time of receiving the first message is obtained at the receiving end Stamp, using the sending timestamp and receiving timestamp to complete the verification together, avoiding the inability to verify that the timers at the sending end and the receiving end may not be synchronized in the prior art, and must adopt the method of fresh value synchronization that may cause additional overhead. Failure to complete fresh value synchronization may result in failure to verify the first message, achieving the purpose of preventing replay attacks.
  • the timer at the sending end does not perform time synchronization with the timer at the receiving end.
  • the receiving timestamp is used for verification 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.
  • the second time precision of the received time stamp meets the requirement for replay attack verification of the first message; the first time precision of the sent time stamp meets the requirement of the bits of the fresh value.
  • the timer at the sending end and the timer at the receiving end are related to the entire vehicle life cycle of the vehicle.
  • the present application provides an in-vehicle communication device applied to a receiving end, including:
  • the receiving unit is configured to receive the first message, the first message includes the sending timestamp of the sending end; the sending timestamp is a fresh value generated by the sending end for the first message;
  • the processing unit is configured to verify the first message according to the receiving time stamp and sending time stamp of the first message.
  • the timer at the sending end does not perform time synchronization with the timer at the receiving end.
  • the processing unit is specifically configured to perform verification according to the receiving timestamp and the historical receiving timestamp when the sending timestamp is equal to the historical sending timestamp.
  • the second time precision of the received time stamp meets the requirement for replay attack verification of the first message; the first time precision of the sent time stamp meets the requirement of the bits of the fresh value.
  • processing unit is also used for:
  • the second message is verified according to the receiving time stamp and sending time stamp of the first message; the second message is received after the first message.
  • the processing unit is configured to store the receiving timestamp and the sending timestamp of the first message, and the receiving timestamp and sending timestamp of the first message are used to verify The second message received later; and/or, after the first message is verified successfully, the sending timestamp and the receiving timestamp are stored.
  • the timer at the sending end and the timer at the receiving end are related to the entire vehicle life cycle of the vehicle.
  • the present application provides an in-vehicle communication device, the device may be a receiving end, and the device includes: the device may include a processor, the processor is connected to a memory, the memory is used to store computer programs, and the processor is used to execute the memory A computer program stored in the device, so that the device executes the method according to any one of the above-mentioned first aspects.
  • the present application provides an in-vehicle communication device, which is applied to the sending end, including:
  • a processing unit configured to generate a freshness value of the first message according to the sending timestamp of the first message; generate the first message according to the freshness value of the first message;
  • a sending unit configured to send the first message to the receiving end.
  • the first message is verified by the receiving end according to the receiving time stamp of the first message and the sending time stamp in the first message.
  • the timer at the sending end does not perform time synchronization with the timer at the receiving end.
  • the receiving timestamp is used for verification 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.
  • the second time precision of the received time stamp meets the requirement for replay attack verification of the first message; the first time precision of the sent time stamp meets the requirement of the bits of the fresh value.
  • the timer at the sending end and the timer at the receiving end are related to the entire vehicle life cycle of the vehicle.
  • the present application provides an in-vehicle communication device, the device may be a receiving end, and the device includes: the device may include a processor, the processor is connected to the memory, the memory is used to store computer programs, and the processor is used to execute the memory A computer program stored in the device, so that the device executes the method according to any one of the above-mentioned second aspects.
  • the present application provides a vehicle, the vehicle includes a sending end and a receiving end, the receiving end is used to implement the method according to any one of the first aspect, and the sending end is used to implement the method according to any one of the second aspect .
  • a computer-readable storage medium stores a computer program. When the computer program is run, the method according to any one of the first aspect or the second aspect is implemented.
  • the present application provides a computer program product, the computer program product includes a computer program, and when the computer program is executed by an in-vehicle communication device, the method according to any one of the first aspect or the second aspect above is realized.
  • the computer program includes computer instructions, and when the computer instructions are executed by the in-vehicle communication device, the method according to any one of the first aspect or the second aspect above is implemented.
  • the embodiment of the present application provides a chip, the chip includes a data interface and a processor, wherein the processor is used to execute the method in the first aspect or any possible implementation of the first aspect or the above-mentioned second aspect any method.
  • the chip is any chip on which software or firmware is installed on the vehicle.
  • the present application provides a system-on-a-chip, which includes at least one processor, configured to support the realization of the functions involved in the above-mentioned first aspect or any possible implementation of the first aspect, the above-mentioned first aspect Any one of the methods or the function involved in any one of the above-mentioned second aspects. For example, such as receiving or processing data and/or information involved in the methods described above.
  • the chip system further includes a memory, the memory is used to store program instructions and data, and the memory is located inside or outside the processor.
  • the system-on-a-chip may consist of chips, or may include chips and other discrete devices.
  • FIG. 1 is a schematic diagram of a possible system architecture applicable to an embodiment of the present application
  • FIG. 2 exemplarily shows a schematic flow chart corresponding to an in-vehicle communication method
  • Fig. 3 exemplarily shows a schematic diagram of generating a first message
  • FIG. 4 exemplarily shows a schematic flow chart corresponding to an in-vehicle communication method provided by an embodiment of the present application
  • FIG. 5 exemplarily shows a schematic diagram of verification of a first message provided by an embodiment of the present application
  • Fig. 6 exemplarily shows a schematic diagram of a first message
  • FIG. 7 exemplarily shows a schematic structural diagram of an in-vehicle communication device provided by an embodiment of the present application.
  • Fig. 8 exemplarily shows a schematic structural diagram of an in-vehicle communication device provided by an embodiment of the present application.
  • V2X vehicle to everything
  • LTE-V long term evolution-vehicle
  • V2V vehicle-to-vehicle
  • a vehicle having an in-vehicle communication function or other devices in a vehicle having an in-vehicle communication function.
  • the other devices include but are not limited to: vehicle-mounted terminals, vehicle-mounted controllers, vehicle-mounted modules, vehicle-mounted modules, vehicle-mounted components, vehicle-mounted chips, vehicle-mounted units, vehicle-mounted radars, or vehicle-mounted cameras.
  • a vehicle-mounted module, 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 implement the communication method provided by the present application.
  • the vehicle can adopt an electrical/electronic (E/E) architecture, which includes three levels, which are gateway electronic control unit (electronic control unit, ECU), Domain controller ECU and intra-domain ECU.
  • E/E electrical/electronic
  • ECU electronic control unit
  • Domain controller ECU Domain controller ECU
  • intra-domain ECU the vehicle can adopt an electrical/electronic (E/E) architecture, which includes three levels, which are gateway electronic control unit (electronic control unit, ECU), Domain controller ECU and intra-domain ECU.
  • the domain controller ECU is used to manage the intra-domain ECUs in the corresponding domain.
  • the gateway ECU is used to manage the domain controller ECU.
  • it can be divided into four domains, namely, vehicle control system domain, entertainment system domain, diagnostic system domain and intelligent driving domain.
  • Each domain corresponds to a domain controller ECU.
  • the above 4 domains correspond to 4 domain controller ECUs in total.
  • the gateway ECU is used to manage the 4 domain controller
  • the entire E/E architecture includes 4 variable-rate CAN (CAN with flexible data-rate, CAN FD) buses, and of course it can also be other buses, taking the CAN FD bus as an example , respectively CAN FD bus 1, CAN FD bus 2, CAN FD bus 3 and CAN FD bus 4.
  • CAN FD variable-rate CAN
  • the four CAN FD buses in Figure 1 may correspond to the four domains in Figure 1.
  • CAN FD bus 1 in Figure 1 can correspond to the vehicle control system domain
  • CAN FD bus 2 can correspond to the entertainment system domain
  • CAN FD bus 3 can correspond to the diagnosis system domain
  • CAN FD bus 4 can correspond to intelligent driving domain etc. This embodiment of the present application does not limit it.
  • ECUs can communicate based on a controller area network (CAN) protocol, and CAN messages can be sent between different ECUs.
  • CAN controller area network
  • the CAN message can be protected with a key.
  • Different types of CAN messages correspond to different keys. In the entire E/E architecture, there are many types of CAN messages, and the corresponding keys are also large, making management difficult.
  • FIG. 1 is only for schematic illustration, and is not intended to limit the embodiment of the present application.
  • the method provided in the embodiment of the present application can be applied to other two-layer or one-layer architectures in addition to the three-layer architecture shown in FIG. 1 above, without limitation.
  • ECU Electronic control unit
  • multiple ECUs can be configured inside the vehicle, such as the ECUs in Figure 1, which can be ECU 1, ECU 2, ..., ECU N, where N is a positive integer.
  • each ECU can have its own specific functions, and also supports simple sensor data processing and complex logic calculation.
  • ECUs include but are not limited to: vehicle sensors, vehicle cameras, multi-domain controllers (multi domain controllers, MDCs), automated-driving control units (automated-driving control units, ADCUs), pre-installed intelligent gateways (telematics boxes, T-Box), intelligent cockpit domain controller (cockpit domain controller, CDC), vehicle gateway, vehicle control unit (vehicle control unit, VCU), battery management system (battery management system, BMS), thermal management system (thermal management system, TMS), power distribution unit (power distribution unit, PDU), etc.
  • MDCs multi domain controllers
  • ADCUs automated-driving control units
  • pre-installed intelligent gateways telematics boxes, T-Box
  • intelligent cockpit domain controller cockpit domain controller, CDC
  • vehicle gateway vehicle control unit (vehicle control unit, VCU), battery management system (battery management system, BMS), thermal management system (thermal management system, TMS), power distribution unit (power distribution unit, PDU), etc.
  • each ECU in the vehicle may rely on the communication technology set when the vehicle leaves the factory to exchange messages.
  • These communication technologies may be, for example, a controller area network (controller area network, CAN) technology, and may also be other communication technologies that implement message interaction.
  • CAN controller area network
  • the vehicle's ECU can be connected to the vehicle's CAN FD bus through the on-board diagnostic port to realize communication with the vehicle's sending end.
  • CAN networks have broadcast capability.
  • each ECU can be connected to the same CAN FD bus, and any ECU can freely read and send CAN message frames on the CAN FD bus.
  • CAN is message-oriented.
  • each CAN message frame on the CAN FD bus only has a message identifier, and does not carry a source address or a destination address.
  • Each ECU connected to the CAN FD bus can choose which one to receive through the message identifier. message frame.
  • the CAN message frame can transmit 8 bytes, and the CAN FD message frame can transmit a data field up to 64 bytes.
  • one frame of data frame can complete the transmission of 128bit advanced encryption standard (AES) key, achieving higher data rate and longer data field space.
  • AES advanced encryption standard
  • CAN FD technology does not have any built-in security functions.
  • each CAN message frame injected by the attacker may be read by the ECU in the vehicle and considered as a legal CAN message frame, so that the attacker can completely Controlling functions of the vehicle, such as braking or accelerating, is very unsafe for the user to use the vehicle.
  • each ECU in the vehicle should also be configured with its own corresponding long-term key.
  • the ECU can also use the pre-configured long-term key to parse the CAN message frame. If the parsing is unsuccessful, it means that the CAN message frame is likely to belong to an illegal control command injected by an illegal device on the CAN FD bus, so the ECU may not perform the corresponding control operation to prevent the illegal device from controlling the vehicle.
  • the parsing is successful, it means that the CAN message frame belongs to a legal control command injected by a legal person (such as a car owner) on the CAN FD bus, so the ECU can perform the corresponding control operation.
  • a legal person such as a car owner
  • the ECU can perform the corresponding control operation.
  • it is helpful to authenticate the control command before actually executing the control, so as to improve the driving safety of the vehicle owner.
  • the gateway is the core part of the vehicle architecture. As the data exchange hub of the vehicle network, the gateway can route network data such as CAN FD in different networks. The gateway can manage domain control devices and devices in the domain. In the embodiment of the present application, the gateway may include a gateway ECU, and the gateway and the gateway ECU are not distinguished from each other.
  • vehicle electronics can be divided into several domains.
  • the power transmission domain the body electronics domain, and the assisted driving domain.
  • There is a domain control device in each domain which is used to manage the devices in the domain.
  • a domain control device may also be referred to as a domain controller.
  • the domain control device includes a domain control ECU, and the domain control device and the domain control device ECU are not distinguished from each other.
  • vehicle electronics can be divided into several domains.
  • the power transmission domain the body electronics domain, and the assisted driving domain.
  • Each domain may include a domain controller and multiple controlled devices, and the devices in the domain may specifically refer to the controlled devices in each domain.
  • the in-domain equipment may include an in-domain ECU, and the in-domain equipment and the in-domain ECU are not distinguished from each other.
  • a key management system (key management system, KMS) may also be configured inside the vehicle.
  • KMS key management system
  • the KMS in the vehicle is mainly responsible for functions such as key generation, key management, and key clearing.
  • These keys include the long-term keys introduced above.
  • EVITA cyber security
  • SHE secure hardware extension
  • the long-term key in the KMS can be set as a symmetric key.
  • the sending and receiving operations between two nodes need to rely on various communication protocols.
  • These two nodes can be the transmitter outside the vehicle and the ECU in the vehicle, or any two ECUs in the vehicle. .
  • SecOC protocol introduces that when the ECUs in the vehicle communicate with each other, the messages transmitted between the ECUs are generated based on the AUTOSAR architecture in the vehicle.
  • the AUTOSAR architecture defines different software layers, such as application software, runtime environment and basic software layer (basic software of AUTOSAR, BSW) (which can include service layer, abstraction layer, driver layer), etc. Wherein, the fresh value management strategy and the key management strategy are implemented in the application software.
  • the application software calls the AUTOSAR interface to generate or verify the message authentication code (MAC) and encrypt or decrypt the AES.
  • the SHE+ driver controls the hardware security peripherals in the hardware security module (HSM) domain and interacts with the host core.
  • SHE+ provides an AUTOSAR interface to integrate HSM security functions into automotive applications, including an interface with AUTOSAR to enable communication between the host core and HSM, key secure storage functions, and secure peripheral device drivers.
  • the CAN driver program provides the service of using the multi-CAN+ (MultiCAN+) unit in the ECU, and utilizes the CAN driver program 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.
  • the SecOC interface is provided through the application software module to request fresh values for sending or receiving security messages.
  • the application software module also provides Interface to transmit or receive messages on failure or success.
  • the SecOC protocol can provide a message integrity authentication mechanism for ECU messages at the PDU level, and can ensure the freshness of ECU messages, preventing illegal devices from replaying historical messages and causing problems with ECU control.
  • the message transmitted on the CAN FD bus can be safely verified by the key generation message authentication code MAC.
  • the key and the freshness value corresponding to the message authentication code MAC are globally unique. Therefore, the receiving end can realize the anti-replay attack through the verification of the fresh value (FV), and ensure that the message authentication code MAC of the sent message is unique within the key life cycle. Verify the integrity of the message by verifying the message authentication code. For example, if the key is not updated during the lifetime of the vehicle, the fresh value guarantees the uniqueness of each message during the lifetime of the vehicle (for example, the time from vehicle production, to vehicle use, or to vehicle retirement) .
  • Step 201 the sender generates a first message according to the first information and a fresh value (FV).
  • FV fresh value
  • the sending end may use a counter to determine the freshness value of the sent message and the received message. Every time the sender sends a message, it can add 1 to the freshness value stored internally. In this way, since the message authentication code sent by the sender is generated based on the current freshness value, even if the illegal device sends the historical message (carrying the historical freshness value) generated by the sender to the receiver, the receiver can also authenticate the code based on the first message. The freshness value carried in the code determines whether the received message is a fresh message. If it is not a fresh message but a historical message, the receiving end may not execute the corresponding control command. This method can better prevent illegal devices from using historical information to control the vehicle, thus helping to improve the vehicle's anti-attack capability.
  • the sender can use the timestamp as the fresh value, and each time the sender sends a message, it can determine the sending timestamp of the message according to the local clock that sends the message, so that the freshness value in the message This can be done based on the sending timestamp of the message.
  • Step 202 the sending end sends a first message to the receiving end.
  • the sender can also truncate the fresh value first, and then assemble the truncated fresh value and the first information to obtain the first message .
  • Fig. 3 exemplarily shows a method of assembling messages provided by the embodiment of the present application.
  • this method first divides the fresh value into the low bit of the fresh value and the high bit of the fresh value, and then takes the low bit of the fresh value ( least significant bit, LSB), sequentially splicing the first information and the low bit of the fresh value to obtain the message.
  • LSB least significant bit
  • taking timestamp generation as an example, that is, sending a message can contain two components: a plain message (n bits) and a truncated timestamp.
  • the truncated timestamp may occupy m bits, and may be a part of truncated lowest bits of the 64bits timestamp, that is, the lowest bits of the FV.
  • Step 203 the receiving end verifies the freshness value in the first message.
  • the receiving end After receiving the first message sent by the sending end, the receiving end parses out the first information and the freshness value (the truncated part of the LSB low order of FV) in the first message respectively.
  • the sending end obtains the first message by concatenating the first message in the manner shown in FIG. 3 above
  • the receiving end will obtain the low bit of the freshness value.
  • the receiving end also needs to restore the complete freshness value based on the low bit of the freshness value carried in the message and the freshness value stored locally at the receiving end, where the locally stored freshness value is based on the history received last time by the receiving end
  • the low bit of the freshness value carried in the message is determined.
  • the receiving end assembles the low-order truncated part of the LSB of the received fresh value FV and the high-order (most significant bit, MSB) part of the locally maintained FV to restore the complete fresh value FV.
  • the low bit of the fresh value carried in the message is smaller than the low bit of the fresh value stored locally, it means that the low bit of the fresh value overflows the value range during the increment process (for example, the low bit of the binary fresh value When increasing from 1 to 1, it will become 0, and the high bit of the fresh value will be incremented by 1), so the receiving end can first add 1 to the high bit of the locally stored fresh value, and then add the high bit of the locally stored fresh value to the message
  • the low bits of the freshness value carried in are spliced together to get the complete freshness value.
  • the low bit of the fresh value carried in the message is not less than the low bit of the fresh value stored locally, it means that the low bit of the fresh value is gradually increasing without overflowing, so the receiving end can directly combine the high bit of the fresh value stored locally with the message
  • the low bits of the carried freshness value are concatenated together to get the complete freshness value.
  • the receiving end can compare the LSB of the freshness value with the LSB of the historical freshness value stored locally to determine whether there may be a replay attack, for example, when the freshness value of the received message is smaller than the locally stored
  • the locally maintained FV MSB value is incremented. For example, if the freshness value is smaller than the locally stored freshness value, it indicates that the message may be an offensive message resent by an illegal device using historical messages. If the freshness value is greater than the locally stored freshness value, the message is not a replayed message.
  • the receiver can refresh the locally maintained FV by overwriting the FV in the last received message.
  • Step 204 the sending end and the receiving end maintain synchronization of the fresh value.
  • the sending end and the receiving end each maintain their own freshness value, which may cause some unpredictable abnormalities to send
  • the freshness value between the end and the receiving end is not synchronized.
  • the sender sent a message to the CAN FD bus
  • the CAN FD bus lost the message due to some kind of failure, such as inconsistent power-on and wake-up sequences between ECUs, abnormal frame loss on the CAN FD bus, etc.
  • the receiving end cannot obtain the message, so the freshness value in the receiving end will be smaller than the freshness value in the sending end.
  • the present application can also set some kind of fault tolerance mechanism between the sending end and the receiving end to maintain accurate fresh value data.
  • the sending end and the receiving end can periodically synchronize their freshness values. Once the freshness value of a certain device is found to be smaller than the freshness value of another device, the device with a small freshness value can be corrected. own freshness value, so that the sender and receiver can always maintain the same freshness value.
  • the fresh value can adopt two optional schemes of time stamp or monotonic counter.
  • the ECU when it determines that it is out of synchronization, it may send a counter synchronization request message to the ECU management device, and the ECU management device broadcasts the counter synchronization message after receiving the synchronization request message.
  • This method can be exploited by attackers to request broadcast spam, leading to security problems of system functions.
  • the sender and receiver will use the local timer's timestamp to determine the freshness value.
  • the timestamp scheme due to the deviation of the clock oscillators on the receiver and transmitter ECU sides, the time at the receiving end and the sending end are not synchronized. It is assumed that the synchronization is only performed during power-on (no re-synchronization), and the clock oscillation of each ECU has Maximum +/-0.02% clock error.
  • ECU_A has a +0.02% error
  • ECU_B has a -0.02% error.
  • Table 1 shows the jitter generated by a clock oscillator corresponding to a fresh value duration.
  • a timestamp synchronization mechanism needs to be used to synchronize UTC time among all ECUs.
  • the time UTC can represent is January 19, 2038 03:14:07.
  • a synchronous CAN message may be sent by broadcast, and the message carries the complete time.
  • the solution for synchronizing time is very complicated.
  • synchronization cannot be performed, which may lead to inability to timely and accurately synchronize.
  • the ECU may not be guaranteed to receive the synchronization message.
  • the receiver needs to wait for the next synchronization message, that is, within the synchronization period (for example: 1 second), this receiver cannot send and receive CAN messages, which will cause system functional safety issues.
  • replay attacks may also occur during synchronization.
  • the master sync ECU e.g. a gateway
  • the master sync ECU can increment the upper 32 bits of the 64-bit sync frame counter by 1, which increases the difficulty of replay.
  • this scheme requires an additional secure non-volatile memory to store the number of key-started counters in the master synchronization ECU, increasing the cost and complexity of fresh value synchronization.
  • the present application provides an in-vehicle communication method, the sending end and the receiving end can be any ECU in the vehicle. As shown in Figure 4, the following steps are included:
  • Step 401 The sender determines the freshness value of the first message according to the sending timestamp of the sender.
  • the sending end may determine the sending time stamp of sending the first message according to the timer of the sending end.
  • the timer may be an internal clock or a monotonic counter, etc., which are not limited in this application.
  • the sending end may use the sending timestamp of the first message as the freshness value of the first message, and each time the sending end sends the first message to the receiving end, it may, according to the local clock that sends the first message, A sending timestamp for sending the first message is determined.
  • the car factory produces a preset key for an ECU, which is used for communication between the ECU and other ECUs.
  • the local clock can only increase in one direction, ensuring the uniqueness of the sending timestamp, so that the fresh value determined according to the sending timestamp can cover the entire vehicle life cycle.
  • the time storage format of the local clock can be in UTC format, and the minimum unit is milliseconds.
  • the minimum time unit of the local clock can also be determined according to the time precision of the local clock.
  • the minimum time unit of the local clock can be milliseconds.
  • the minimum unit that can satisfy the sending timestamp is milliseconds.
  • the minimum unit that can satisfy the sending timestamp is seconds.
  • the sending timestamp determined by the local clock of the sending end may be stored in the timestamp format of UTC time, or may be a simplified timestamp.
  • the sending timestamp stored by the local clock may satisfy: UTC time and predetermined Set the time difference.
  • sending a timestamp could satisfy: UTC time minus 2000 years.
  • the minimum unit that can meet the sending timestamp is milliseconds.
  • the time when the first message is sent is 03:14:07:01:1 on January 19, 2021.
  • the sending timestamp can be set as: January 19, 21 03:14:07:01:1, that is, the sending timestamp can be in the form of 210119031407011. That is, the minimum time unit of the sending timestamp is milliseconds.
  • the first time precision that the corresponding sending timestamp in the freshness value satisfies can be determined. That is, the first time accuracy of the sending time stamp meets the bit requirement of the freshness value transmitted in the first message.
  • the high bit in the sending time determined by the local clock may be selected as the sending timestamp.
  • the sending time of the first message is 03:14:07:01:1 on January 19, 2021, and the sending time stamp can be determined as: 03:14:07 on January 19, 21, that is, the sending time stamp The form can be 210119031407.
  • the replay time window of the sending end and the receiving end during normal operation can be determined accordingly. For example, assuming that the CAN FD bus sends a message time of 1ms, the replay time window is 1s. That is, the sending end and the receiving end can control the replay attack within 1000 times.
  • the sender can also periodically rewrite the local time to the secure non-volatile storage.
  • This method can ensure that after the sender restarts, it can update the local clock after the restart by copying the local time in the secure non-volatile storage, ensuring that the local clock of the sender is monotonically increasing, that is, ensuring that the sending timestamp generated by the sender It is monotonically increasing, thereby ensuring that the fresh value is monotonically increasing.
  • the stored local time may be the smallest unit of time achievable by the local clock. For example, when the minimum time unit of the local clock at the sending end is milliseconds, the millisecond-level local time can be copied to the secure non-volatile storage.
  • the timing of rewriting the local time can be written before the vehicle is powered off or the sending end is in sleep mode.
  • the local clock of the sending end can The local time reset value is read from the non-volatile storage to ensure that the time stamp generated by the vehicle's local clock is monotonically increasing.
  • the time to rewrite the local time can also be periodic writing.
  • the rewriting period can be determined according to the rewriting capability supported by the hardware. For example, the rewriting period value is every second, every minute or every hour, which is not limited in this application.
  • the sending end of the vehicle is restarted.
  • the sending end can reset the local clock of the sending end according to the sending time stamp stored before the sending end restarts to ensure maintenance and replacement.
  • the freshness value generated by the sender is monotonically increasing in the life cycle of the vehicle.
  • the sender can directly concatenate the first information, the freshness value, and the first message authentication code to generate the first message. It is avoided to transmit the truncated freshness value and the truncated first message authentication code in the first message by means of truncation.
  • Step 402 The sender generates a first message authentication code according to the first information, the freshness value and the key.
  • the first information may be information to be sent from the sending end to the receiving end.
  • the key may be a long-term key in the vehicle, or a long-term key between the sending end and the receiving end, which is not limited here.
  • the sender or receiver can be any ECU in the vehicle.
  • a message authentication code generator may also be set in the sending end, and the message authentication code generator is used to process input information according to a preset generation algorithm to obtain a message authentication code and output it.
  • the preset generation algorithm is cipher-based MAC (CMAC) AES128 (compliant with RFC 4493)
  • the message authentication code generator can calculate and output the first message authentication code L1 according to the following formula (1.1):
  • the length of the first message authentication code L1 may also be 128 bits.
  • the first information is the data carried in the first message.
  • " can be understood as splicing, for example, M1 can splice the corresponding bytes of I and FV together.
  • the calculation may be performed after splicing the first information I and the fresh value FV.
  • Step 403 The sending end generates and sends the first message to the receiving end according to the first information, the freshness value and the first message authentication code.
  • the first message includes the sending time stamp of the sending end; the sending time stamp is a fresh value generated by the sending end for the first message.
  • the receiving end receives the first message.
  • the sender in order to transmit the first information smoothly, the sender can first truncate the first message authentication code, and then assemble the truncated first message authentication code. code and the first information to obtain the first message.
  • the security of the first message transmission will decrease linearly as the length of the first message authentication code becomes smaller, and message authentication codes with a length of 64 bits or more generally have sufficient anti-attack capabilities, therefore, the sender truncates
  • the length of the first message authentication code can also be set to be not less than 64 bits.
  • 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, the above step 402 may not be executed, and when step 403 is executed, the sending end may generate and send the first message to the receiving end according to the first information and the freshness value.
  • the first message sent may include a plaintext message (n bits) and a fresh value, which is generated by the sending timestamp.
  • the fresh value may occupy 32 bits
  • the sending timestamp corresponding to the fresh value may be a part of the highest bit of the 64-bit timestamp determined by the timer at the intercepting sending end, that is, the highest bit of the FV.
  • Figure 6 exemplarily shows a method of assembling the first message provided by the embodiment of the present application.
  • the code is divided into the low bit of the first message authentication code and the high bit of the first message authentication code, and then the fresh value and the high bit (MSB) of the first message authentication code are taken, and the first information, the fresh value, and the high bit of the message authentication code are spliced in sequence, to get news.
  • the sent message can contain 3 components: the plaintext message (n bits), the fresh value (generated by the sent timestamp) and the truncated message authentication code.
  • the fresh value may occupy 32 bits
  • the sending timestamp corresponding to the fresh value may be a part of the highest bit of the 64-bit timestamp determined by the timer at the intercepting sending end, that is, the highest bit of the FV.
  • the truncated message authentication code can occupy k bits, which is part of the highest bit of the 128bits message authentication code CMAC.
  • Step 404 The receiving end verifies the first message according to the receiving timestamp and sending timestamp of the first message.
  • the receiving end parses out the first information, the freshness value, and the message authentication code (the truncated part of the MAC) in the first message respectively.
  • the receiving end can first verify the freshness value and the historical freshness value stored locally. If the freshness value is smaller than the freshness value stored locally, it means that the message may be resent by an illegal device using historical messages. Therefore, the receiving end may not execute the corresponding control command, or may return a warning message to the sending end. If the freshness value is greater than the locally stored freshness value, the message is not a replayed message. If the freshness value is equal to the locally stored freshness value, verification may be performed based on the received timestamp and the historical timestamp to determine whether the first message is a replayed message.
  • the timer at the sending end does not perform time synchronization with the timer at the receiving end.
  • the receiving end may determine the receiving time stamp of the first message according to the timer of the receiving end.
  • the timer at the receiving end may be an internal clock at the receiving end or a monotonic counter at the receiving end, etc., which are not limited in this application.
  • the car factory produces a preset key for the receiving end, which is used for communication between the receiving end and the sending end. From the beginning, the local clock at the receiving end can only increase in one direction to ensure the uniqueness of the timestamp, so that the fresh value determined according to the timestamp can cover the entire vehicle life cycle.
  • the time storage format of the local clock of the receiving end may be UTC format, and the minimum unit is milliseconds.
  • the minimum time unit of the local clock can also be determined according to the time precision of the local clock.
  • the minimum time unit of the local clock can be milliseconds. That is, the time precision of the received time stamp is the second time precision. The second time precision is greater than the time precision of the corresponding sending time stamp in the freshness value of the first message.
  • the received timestamp determined by the local clock at the receiving end may be stored in UTC format, or may be a simplified timestamp, for example, the local clock at the receiving end
  • the determined receiving time stamp can satisfy: the difference between UTC time and preset time.
  • the receive timestamp could be: UTC minus 2000.
  • the minimum unit that can satisfy the received timestamp is milliseconds.
  • the receiving time stamp 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 when the receiving end receives the first message is 03:14:40:01:2 on January 19, 2021. Considering the length of the vehicle life cycle, the receiving time stamp can be set as: January 19, 21 03:14:40:01:2, that is, the receiving time stamp can be in the form of 210119031440012. That is, the minimum time unit of the received timestamp is milliseconds.
  • the sending end considering that the time between the sending end and the receiving end may not be synchronized, at this time, taking the same time at the sending end and the receiving end during initialization as an example, when the running time of the sending end and the receiving end is 1 day, the sending end The time drift between the end and the receiver may have amounted to 34 seconds. Therefore, the first message cannot be directly verified for replay attacks by using the receiving time stamp of the first message. In order to enable the receiving end to meet the verification requirements for the replay attack, in this application, the first message may be verified for the replay attack according to the receiving time stamp of the first message and the sending time stamp of the first message.
  • the receiving end may use the sending time stamp in the first message as the first verification part of the first message, and use the receiving time stamp as the second verification part of the first message.
  • the sending time stamp in the first message is greater than the historical sending time stamp of the last received sending end stored by the receiving end, it can be determined that the freshness value verification of the first message is successful, and the first message is not a replay message.
  • the sending time stamp in the first message is smaller than the historical sending time stamp of the last received sending end stored by the receiving end, it may be determined that the freshness value verification of the first message fails, and the first message is a replay message.
  • the sending time stamp in the first message is equal to the historical sending time stamp of the message sent by the sending end last received by the receiving end
  • the receiving time stamp of the first message and the sending time stamp received last time by the receiving end can be further used
  • the first message can be determined Freshness verification succeeds, first message is not a replayed message.
  • the receiving timestamp of the first message is less than or equal to the historical receiving timestamp stored when the receiving end last received the message sent by the sending end, it can be determined that the freshness value verification of the first message fails, and the first message is a replay message .
  • the first message is a replay message by performing combined verification of the receiving time stamp of the first message and the sending time stamp of the first message.
  • the minimum time unit of the local clock at the receiving end as milliseconds
  • the minimum time unit of the sending timestamp corresponding to the freshness value sent by the sending end is: 1/19/21 03:14:07.
  • the receiving time stamp is part of the second verification of the first message.
  • the receiving timestamp of the first message is : 03:14:40:01:2 on January 19, 21, that is, the receiving timestamp of the first message is greater than the historical receiving timestamp of the messages sent by the sending end stored by the receiving end, so it can be determined that the first message is not a replay message , the verification is successful.
  • the receiving timestamp of the first message is: 21 January 19, 03:14:40:01:2, that is, the receiving timestamp of the first message is less than the historical receiving timestamp of the messages sent by the sending end stored by the receiving end, it can be determined that the first message is a replay message, verify fail.
  • the replay time windows of the sending end and the receiving end may be determined based on the minimum time unit of the sending timestamp carried by the freshness value.
  • the first receiving time stamp determined by the local clock of the receiving end is also considered, the number of replay attacks between the sending end and the receiving end can be effectively reduced.
  • the time precision of the first received timestamp is the second time precision, for example, when the minimum time unit of the local clock at the receiving end is milliseconds, the time precision of the first received timestamp is milliseconds, therefore, the replay time window can be controlled within milliseconds level or sub-second level. For example, assuming that the CAN FD bus sends a message for 1ms, and the replay time window is 0.5s, that is, the sender and receiver can control replay attacks within 500 times.
  • the receiving end of the first message can also use the replay time window between the sending end and the receiving end. Timestamp for secondary verification. For example, when the difference between the receiving time stamp of the first message and the historical receiving time stamp of the message sent by the sending end stored at the receiving end is less than or equal to the replay time window, it can be determined that the first message is not a replay message. A message verified successfully.
  • the difference between the receiving timestamp of the first message and the historical receiving timestamp of the message sent by the sending end stored by the receiving end is greater than the replay time window, it can be determined that the first message is a replay message, and the verification of the first message fails .
  • the receiving end can refresh the locally maintained freshness value by overwriting the freshness value in the last received message.
  • the receiving end may rewrite the freshness value in the first message and the freshness value corresponding to the receiving timestamp into the secure non-volatile storage, so as to verify the next received message sent by the sending end.
  • the sending time stamp and the receiving time stamp may be rewritten into a secure non-volatile storage, so as to verify the next received message (for example, the second message) sent by the sending end.
  • the method of overwriting may be to replace the original stored sending timestamp and receiving timestamp of the message sent by the sending end, or to additionally store the sending timestamp and receiving timestamp of the message sent by the sending end.
  • the sending end obtains the first message by concatenating the first message in the manner shown in FIG. 6 above
  • the receiving end will obtain the freshness value and the upper bits of the first message authentication code.
  • the receiving end may generate a second message verification code according to the first information, the key and the freshness value.
  • a message authentication code parser may also be set in the receiving end, and the message authentication code parser is used to process input information according to the same generation algorithm preset by the message authentication code generator in the sending end to obtain message authentication code and output.
  • the preset generation algorithm is CMAC-AES128 (complying with RFC 4493)
  • the message authentication code The parser can calculate and output the second message authentication code L2 according to the above formula (1.1).
  • the second message verification code is the same as the first message verification code, it may be determined that the first message verification is successful.
  • the receiving end judges whether the second message authentication code generated by itself is the same as the first message authentication code carried in the first message. If they are the same, it means that the key stored in the local RAM of the receiving end is the key corresponding to the first message. Similarly, the receiving end belongs to the vehicle-mounted device to execute the first message, and executes corresponding operations on the first message. If they are different, it means that the receiving end does not belong to the vehicle-mounted device to execute the first message, so the receiving end can ignore the first message.
  • the above embodiment authenticates the message by using the message authentication code generated by the fresh value and the key, which can not only prevent the first information from being tampered with during transmission in the vehicle, but also accurately detect the behavior of attacking the vehicle by using historical messages, and also The corresponding operation can be performed under the condition that the authentication information is accurately transmitted, thereby helping to accurately ensure the safety of the vehicle in performing vehicle communication.
  • the receiving end can periodically copy the local time to the secure non-volatile storage during operation.
  • This method can ensure that the receiving end can update and restart after restarting by copying the local time in the secure non-volatile storage.
  • the local clock ensure that the local clock of the receiving end is monotonically increasing, that is, ensure that the receiving timestamp generated by the receiving end is monotonically increasing.
  • the stored local time may be the smallest unit of time that the local clock can achieve. For example, when the minimum time unit of the local clock at the receiving end is milliseconds, the millisecond-level local time can be copied to the secure non-volatile storage.
  • the time for the receiving end to rewrite the local time can be when the vehicle is powered off or the receiving end writes before it goes to sleep.
  • the local clock of the receiving end The local time reset value can be read from secure non-volatile storage to ensure that the time stamp generated by the vehicle's local clock is monotonically increasing.
  • the time to rewrite the local time can also be periodic writing.
  • the rewriting period can be determined according to the rewriting capability supported by the hardware. For example, the rewriting period value is every second, every minute or every hour, which is not limited in this application.
  • the local clock of the receiving end can be reset according to the sending timestamp and receiving timestamp stored before the receiving end restarts.
  • the local clock of the receiving end may also be reset according to the first receiving timestamp and sending timestamp stored before the receiving end is restarted. It is guaranteed that after repairing and replacing parts, the receiving time stamp generated by the receiving end is monotonically increasing in the life cycle of the vehicle.
  • the replay time window of the receiving end can be determined based on the recovery time corresponding to the replication period and the abnormal restart.
  • the replay time window of the receiving end after restarting can satisfy: the sum of the rewriting period and the restarting recovery time of the receiving end. For example: when the rewriting period is 1 minute and the restart recovery time is 10s, it can be determined that the replay time window after the restart is 70s.
  • the replay time window of the receiving end after restarting can satisfy: the sum of the rewriting period and the time of the first legal message received after the receiving end recovers after restarting.
  • the time for the first legal message received by the receiving end after restarting and recovering is 10ms
  • the rewriting period is 1 minute, so it can be determined that the playback time window after restarting can be 60s+10ms.
  • the replay time window of the receiving end after restarting can satisfy: the sum of the rewriting period and the restarting recovery time of the receiving end and the time between the first legal message received after the receiving end restarts and recovers difference.
  • the time to receive the first legal message after the receiver restarts and recovers is 10ms
  • the sum of the rewrite cycle and the receiver's restart and recovery time is 70s
  • the replay time window after restarting is 70s-10ms.
  • the replay time window of the receiving end after restarting can satisfy: the sum of the rewriting period and the restarting recovery time of the receiving end and the time between the first legal message received after the receiving end restarts and recovers min.
  • the time for receiving the first legal message after the receiver restarts and recovers is 1s
  • the sum of the rewrite cycle and the receiver's restart and recovery time is 70s
  • the replay time window after restarting is 1s.
  • the sending timestamp of the first message is used to determine the fresh value, and the receiving timestamp is obtained at the receiving end, and the sending timestamp and receiving timestamp are used to complete the verification.
  • the sending end only needs to send a limited length of timestamp to meet the anti-replay attack requirements, and does not need to occupy too many bits for sending fresh values, improving the payload of message delivery.
  • Fig. 7 is a schematic structural diagram of an in-vehicle communication device provided by the embodiment of the present application.
  • the device can be a receiving end or a sending end, or a chip or a circuit, such as a device that can be set in the receiving end
  • a chip or a circuit is another example of a chip or a circuit that can be installed in the sending end, and another example is a chip or a circuit that can be installed in the sending end.
  • the in-vehicle communication device 701 may further include a bus system, wherein the processor 702, the memory 704, and the transceiver 703 may be connected through the bus system.
  • the above processor 702 may be a chip.
  • the processor 702 may be a field programmable gate array (field programmable gate array, FPGA), may be an application specific integrated circuit (ASIC), may also be a system chip (system on chip, SoC), or It can be a central processing unit (central processor unit, CPU), or a network processor (network processor, NP), or a digital signal processing circuit (digital signal processor, DSP), or a microcontroller (micro controller) unit, MCU), it can also be a programmable controller (programmable logic device, PLD) or other integrated chips.
  • FPGA field programmable gate array
  • ASIC application specific integrated circuit
  • SoC system on chip
  • CPU central processing unit
  • NP network processor
  • DSP digital signal processing circuit
  • microcontroller micro controller
  • MCU microcontroller
  • PLD programmable logic device
  • each step of the above method may be completed by an integrated logic circuit of hardware in the processor 702 or instructions in the form of software.
  • the steps of the methods disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor 702 .
  • the software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register.
  • the storage medium is located in the memory 704, and the processor 702 reads the information in the memory 704, and completes the steps of the above method in combination with its hardware.
  • the processor 702 in the embodiment of the present application may be an integrated circuit chip, which has a signal processing capability.
  • each step of the above-mentioned method embodiments may be completed by an integrated logic circuit of hardware in a processor or instructions in the form of software.
  • the above-mentioned 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 devices, discrete gate or transistor logic devices, discrete hardware components .
  • DSP digital signal processor
  • ASIC application-specific integrated circuit
  • FPGA field-programmable gate array
  • Various methods, steps, and logic block diagrams disclosed in the embodiments of the present application may be implemented or executed.
  • a general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like.
  • the steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in a mature storage medium in the field such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register.
  • the storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps of the above method in combination with its hardware.
  • the memory 704 in this embodiment of the present application may be a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memories.
  • the non-volatile memory can be read-only memory (read-only memory, ROM), programmable read-only memory (programmable ROM, PROM), erasable programmable read-only memory (erasable PROM, EPROM), electrically programmable Erases programmable read-only memory (electrically EPROM, EEPROM) or flash memory.
  • Volatile memory can be random access memory (RAM), which acts as external cache memory.
  • RAM random access memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • DRAM synchronous dynamic random access memory
  • SDRAM double data rate synchronous dynamic random access memory
  • ESDRAM enhanced synchronous dynamic random access memory
  • SLDRAM direct memory bus random access memory
  • direct rambus RAM direct rambus RAM
  • the in-vehicle communication device 701 may include a processor 702 , a transceiver 703 and a memory 704 .
  • the memory 704 is used to store instructions
  • the processor 702 is used to execute the instructions stored in the memory 704 to implement any one or more related solutions at the receiving end of the corresponding methods shown in FIGS. 4 to 6 above.
  • the in-vehicle communication device 701 may be used to execute the method performed by the receiving end in any of the above-mentioned embodiments.
  • the transceiver 703 receives the first message, and the first message includes the sending time stamp of the sending end; the sending time stamp is a fresh value generated by the sending end for the first message; the processor 702 according to the first The receiving timestamp and the sending timestamp of the message are used to verify the first message.
  • the in-vehicle communication device 701 When the in-vehicle communication device 701 is the above-mentioned sending end, the in-vehicle communication device 701 may be used to execute the method performed by the sending end in any of the above-mentioned embodiments.
  • the transceiver 703 is configured to send the first message to the receiving end.
  • the processor 702 generates the freshness value of the first message according to the sending timestamp of the first message; generates the first message according to the freshness value of the first message.
  • FIG. 8 is a schematic diagram of the in-vehicle communication device provided by the embodiment of the present application.
  • the in-vehicle communication device 801 can be a receiving end or a transmitting end, or can be a chip or a circuit , such as a chip or circuit that can be set in the receiving end or the sending end.
  • the in-vehicle communication device may correspond to the receiving end or the sending end in the above method.
  • the in-vehicle communication device may implement the steps performed by the receiving end or the sending end in any one or any number of corresponding methods shown in FIG. 4 to FIG. 6 above.
  • the in-vehicle communication device may include a processing unit 802 .
  • a receiving unit 803 and a sending unit 804 may also be included.
  • the in-vehicle communication device 801 When the in-vehicle communication device 801 is the above-mentioned receiving end, and implements the steps performed by the receiving end in the above-mentioned FIG.
  • the freshness value generated by the sending end for the first message; the processing unit 802 verifies the first message according to the receiving timestamp and sending timestamp of the first message.
  • the timer at the sending end does not perform time synchronization with the timer at the receiving end.
  • the processing unit 802 when the sending timestamp is equal to the historical sending timestamp, the processing unit 802 performs verification according to the receiving timestamp and the historical receiving timestamp.
  • the second time precision of the received time stamp meets the requirement for replay attack verification of the first message; the first time precision of the sent time stamp meets the requirement of the bits of the fresh value.
  • the processing unit 802 verifies the second message according to the receiving time stamp and sending time stamp of the first message; the second message is received after the first message of.
  • the processing unit 802 stores the receiving timestamp and sending timestamp of the first message, and the receiving timestamp and sending timestamp of the first message are used to verify The received second message; and/or, after the first message is successfully verified, the processing unit 802 stores the sending timestamp and the receiving timestamp.
  • the timer at the sending end and the timer at the receiving end are related to the entire vehicle life cycle of the vehicle.
  • the in-vehicle communication device may be the sending end in the vehicle, and the processing unit 802 generates the freshness value of the first message according to the sending timestamp of the first message; generates the first message according to the freshness value of the first message.
  • the sending unit 803 is configured to send the first message to the receiving end.
  • the first message is verified by the receiving end according to the receiving timestamp of the first message and the sending timestamp in the first message.
  • the timer at the sending end does not perform time synchronization with the timer at the receiving end.
  • the receiving timestamp is used for verification 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.
  • the second time precision of the received time stamp meets the requirement for replay attack verification of the first message; the first time precision of the sent time stamp meets the requirement of the bits of the fresh value.
  • the timer at the sending end and the timer at the receiving end are related to the entire vehicle life cycle of the vehicle.
  • the sending unit 804 can be a sending unit or a transmitter when sending information
  • the receiving unit 803 can be a receiving unit or a receiver when receiving information
  • the sending unit 804 and the receiving unit 803 can be transceivers, and the transceiver, transmitter or receiver
  • the device can be a radio frequency circuit.
  • the in-vehicle communication device 801 includes a storage unit
  • the storage unit is used to store computer instructions
  • the processing unit 802 is connected to the storage unit in communication.
  • the processing unit 802 executes the computer instructions stored in the storage unit to enable the in-vehicle communication Apparatus 801 may be configured to execute the method executed by the receiving end or the sending end in the foregoing embodiments.
  • the processing unit 802 may be a general central processing unit (CPU), a microprocessor, or an application specific integrated circuit (Application Specific Integrated Circuit, ASIC).
  • CPU central processing unit
  • ASIC Application Specific Integrated Circuit
  • the sending unit 804 and the receiving unit 803 may be input and/or output interfaces, pins or circuits.
  • the processing unit 802 can execute the computer-executed instructions stored in the storage unit, so that the chip in the in-vehicle communication device 801 executes the method performed in any one of the embodiments.
  • the storage unit is a storage unit in the chip, such as a register, a cache, etc.
  • the storage unit may also be a storage unit located outside the chip in the in-vehicle communication device 801, such as a read-only memory (Read Only Memory, ROM) Or other types of static storage devices that can store static information and instructions, random access memory (Random Access Memory, RAM), etc.
  • ROM Read Only Memory
  • RAM Random Access Memory
  • the present application also provides a computer program product, the computer program product including: computer program code, when the computer program code is run on the computer, the computer is made to execute the computer program described in Fig. 4 to Fig. 6 .
  • the method of any one of the embodiments is illustrated.
  • the present application also provides a computer-readable storage medium, the computer-readable medium stores program codes, and when the program codes are run on a computer, the computer executes the steps shown in Figures 4 to 6. The method of any of the illustrated embodiments.
  • the present application also provides an in-vehicle communication system, which includes the sending end and the receiving end of the foregoing method.
  • An embodiment of the present application further provides a vehicle, and the vehicle includes at least one sending end and receiving end mentioned in the above-mentioned embodiments of the present application.
  • a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer.
  • an application running on a computing device and the computing device can be components.
  • One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers.
  • these components can execute from various computer readable media having various data structures stored thereon.
  • a component may, for example, be based on a signal having one or more packets of data (e.g., data from two components interacting with another component between a local system, a distributed system, and/or a network, such as the Internet via a signal interacting with other systems). Communicate through local and/or remote processes.
  • packets of data e.g., data from two components interacting with another component between a local system, a distributed system, and/or a network, such as the Internet via a signal interacting with other systems.
  • the disclosed systems, devices and methods may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components can be combined or integrated. to another system, or some features may be ignored, or not implemented.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit.
  • the functions described above are realized in the form of software function units and sold or used as independent products, they can be stored in a computer-readable storage medium.
  • the technical solution of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including Several instructions are used to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in the various embodiments of the present application.
  • the aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (read-only memory, ROM), random access memory (random access memory, RAM), magnetic disk or optical disc and other media that can store program codes. .
  • the embodiments of the present application may be provided as methods, systems, or computer program products. 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, etc.) having computer-usable program code embodied therein.
  • These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions
  • the device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Small-Scale Networks (AREA)

Abstract

本申请公开了一种车内通信方法及装置，可应用于自动驾驶或网联车等领域，在该方法应用于接收端时，接收端接收第一消息，第一消息包括发送端的发送时间戳；发送时间戳是发送端为第一消息生成的新鲜值；接收端根据接收时间戳和发送时间戳，对第一消息进行验证。采用第一消息的发送时间戳确定新鲜值，并在接收端获得接收第一消息的接收时间戳，利用发送时间戳和接收时间戳共同完成验证，发送端只需要发送有限长度的时间戳即可满足防重放攻击的要求，并且无需占用过多的比特位用于发送新鲜值，提高消息传递的有效载荷。该方案可以不对新鲜值进行同步，有效降低了车内通信的开销，避免新鲜值不同步导致的问题，有效提升了防重放攻击的性能。

Description

一种车内通信方法及装置 技术领域
本申请涉及智能网联车技术领域，尤其涉及一种车内通信方法及装置。
背景技术
近些年，汽车技术朝着智能化、电动化、网联化、共享化方向快速发展，车辆内部电子设备的数量、连接和交互也不断增多，逐渐形成了以控制器局域网络(controller area network，CAN)、本地互联网络(local interconnection network，LIN)、多媒体传输系统(media oriented systems transport，MOST)、车载以太等为代表的车载通信网络。在现有的车载网络中，大部分基本都是在没有安全措施或者安全措施较低的情况进行数据传输的，容易受到黑客的恶意攻击。
由于CAN协议在实时性、可靠性方面的优势，在车载网络通信中获得了广泛的应用。然而，CAN总线采用了面向消息的协议和广播总线网络的体系结构，难以将现有技术中的安全措施直接部署到车载网络通信中。一旦发生攻击者访问CAN总线的情况，攻击者注入的每个帧都有可能被读取为合法的帧，从而实现控制车辆的功能，如加速或制动操作，由此导致汽车存在安全隐患。
对于以上问题，汽车开放架构(automotive open system architecture，AUTOSAR)组织补充了信息安全组件(secure onboard communication，SecOC)，在车载通信总线中引入通信加密和验证的标准，为协议数据单元(protocol data unit,PDU)消息级别上电子控制单元(electronic control unit，ECU)消息提供有效的认证机制，确保PDU消息的新鲜度，防止消息重放攻击。AUTOSAR SecOC规范给出新鲜值可采用时间戳和单调计数器两种可选方案。时间戳方案依赖在所有ECU间同步世界标准时间(coordinated universal time，UTC)，但是时钟抖动和时间戳同步异常等问题会导致接收器无法接收CAN消息，导致系统功能安全问题。
发明内容
本申请提供一种车内通信方法及装置，使车载网络通信中，接收端和发送端之间的消息的发送不依赖新鲜值的同步，来防止重放攻击，降低接收端和发送端之间的数据传输的复杂度。
第一方面，本申请提供一种车内通信方法，应用于接收端，包括：接收第一消息，第一消息包括发送端的发送时间戳；发送时间戳是发送端为第一消息生成的新鲜值；根据第一消息的接收时间戳和发送时间戳，对第一消息进行验证。
其中，发送端和接收端可以是车辆内的任一ECU。发送端可以根据发送端的计时器确定发送第一消息的发送时间戳。其中，计时器可以是本地时钟(internal clock)或单向计数器(monotonic counter)等，本申请不做限定。
通过上述方法，采用第一消息的发送时间戳确定新鲜值，并在接收端获得接收第一消息的接收时间戳，利用发送时间戳和接收时间戳共同完成验证，发送端只需要发送有限长度的时间戳即可满足防重放攻击的要求，并且无需占用过多的比特位用于发送新鲜值，提 高消息传递的有效载荷。另外，在不对新鲜值进行同步的情况下，可以保证防重放攻击的效果，避免采用新鲜值同步的方法可能导致的额外的开销，尤其是避免了在无法完成新鲜值同步时可能导致的无法对第一消息进行验证的问题，提高了防重放攻击的效果。
一种可能的实现方式，发送端的计时器与接收端的计时器不进行时间同步的操作。
通过上述方法，发送端和接收端可以不进行时间同步的操作，降低防重放攻击的复杂度。
一种可能的实现方式，在发送时间戳等于历史发送时间戳时，根据接收时间戳与历史接收时间戳进行验证。
通过上述方法，接收端可以在发送时间戳无法验证时，进一步通过接收时间戳进行验证，提高防重放验证的效果。
一种可能的实现方式，接收时间戳的第二时间精度满足第一消息进行重放攻击验证的要求；第一消息的发送时间戳的第一时间精度满足第一消息的新鲜值的比特位的要求。
考虑到在传输过程中，新鲜值可以占用的比特位数有限，以满足发送的第一消息承载的有效数据的比特位数的要求。例如，第一消息的比特位数为64比特，新鲜值占用32比特，新鲜值的生命周期为10～20年，则新鲜值可以携带的发送时间戳的最小时间单位可以对应到秒。此时，发送时间戳的第一时间精度为1秒的时间精度，对应的新鲜值的比特位的数量为32比特。
通过上述方法，通过接收时间戳的第二时间精度满足重放攻击验证的要求，通过发送时间戳的第一时间精度，提高消息中的数据的有效载荷，提高传输效率。
一种可能的实现方式，在第一消息验证成功后，根据接收到第一消息的接收时间戳和第一消息的发送时间戳对第二消息进行验证；第二消息为在第一消息之后接收到的。
通过上述方法，可以基于第一消息的接收时间戳和第一消息的发送时间戳，作为下一次接收到的第二消息的验证凭证，简化验证的复杂度。
一种可能的实现方式，在第一消息验证成功后，存储第一消息的接收时间戳和发送时间戳，第一消息的接收时间戳和发送时间戳用于验证在第一消息之后接收到的第二消息。
通过上述方法，可以存储第一消息的接收时间戳和第一消息的发送时间戳，作为下一次接收到的第二消息的验证凭证，简化验证的复杂度。
一种可能的实现方式，发送端的计时器和接收端的计时器与车辆的整车生命周期有关。
通过上述方法，保证发送端的计时器在车辆的整车生命周期中为单调递增的，保证接收端的计时器在车辆的整车生命周期中为单调递增的，实现新鲜值和验证新鲜值的唯一性。
第二方面，本申请提供一种车内通信方法，应用于发送端，包括：根据第一消息的发送时间戳，生成第一消息的新鲜值；根据第一消息的新鲜值，生成第一消息；向接收端发送第一消息。
其中，第一消息为接收端根据接收到第一消息的接收时间戳和第一消息中的发送时间戳进行验证的。
通过上述方法，采用第一消息的发送时间戳确定新鲜值，无需对发送时间戳进行截短使用时间戳的低位，避免了溢出翻转的问题，另外，在接收端获得接收第一消息的接收时 间戳，利用发送时间戳和接收时间戳共同完成验证，避免了现有技术中发送端和接收端的计时器可能不同步导致的无法验证，必须采用新鲜值同步的方法可能导致的额外的开销，在无法完成新鲜值同步时可能导致的无法对第一消息进行验证，达到防重放攻击的目的。
一种可能的实现方式，发送端的计时器与接收端的计时器不进行时间同步的操作。
一种可能的实现方式，接收时间戳用于在发送时间戳等于接收端的历史发送时间戳时，根据接收时间戳与接收端的历史接收时间戳进行验证。
一种可能的实现方式，接收时间戳的第二时间精度满足第一消息进行重放攻击验证的要求；发送时间戳的第一时间精度满足新鲜值的比特位的要求。
一种可能的实现方式，发送端的计时器和接收端的计时器与车辆的整车生命周期有关。
上述有益效果可以参见第一方面中可能的实现方式的有益效果，在此不再赘述。
第三方面，本申请提供一种车内通信装置，应用于接收端，包括：
接收单元，用于接收第一消息，第一消息包括发送端的发送时间戳；发送时间戳是发送端为第一消息生成的新鲜值；
处理单元，用于根据第一消息的接收时间戳和发送时间戳，对第一消息进行验证。
一种可能的实现方式，发送端的计时器与接收端的计时器不进行时间同步的操作。
一种可能的实现方式，处理单元，具体用于在发送时间戳等于历史发送时间戳时，根据接收时间戳与历史接收时间戳进行验证。
一种可能的实现方式，接收时间戳的第二时间精度满足第一消息进行重放攻击验证的要求；发送时间戳的第一时间精度满足新鲜值的比特位的要求。
一种可能的实现方式，处理单元，还用于：
在第一消息验证成功后，根据接收到第一消息的接收时间戳和发送时间戳对第二消息进行验证；第二消息为在第一消息之后接收到的。
一种可能的实现方式，在第一消息验证成功后，处理单元用于存储第一消息的接收时间戳和发送时间戳，第一消息的接收时间戳和发送时间戳用于验证在第一消息之后接收到的第二消息；和/或，在第一消息验证成功后，存储发送时间戳和接收时间戳。
一种可能的实现方式，发送端的计时器和接收端的计时器与车辆的整车生命周期有关。
第四方面，本申请提供一种车内通信装置，该装置可以为接收端，该装置包括：该装置可以包括处理器，处理器与存储器相连，存储器用于存储计算机程序，处理器用于执行存储器中存储的计算机程序，以使得装置执行如上述第一方面中任一项的方法。
第五方面，本申请提供一种车内通信装置，应用于发送端，包括：
处理单元，用于根据第一消息的发送时间戳，生成第一消息的新鲜值；根据第一消息的新鲜值，生成第一消息；
发送单元，用于向接收端发送第一消息。
其中，第一消息为接收端根据接收到第一消息的接收时间戳和第一消息中的发送时间戳进行验证的。
一种可能的实现方式，发送端的计时器与接收端的计时器不进行时间同步的操作。
一种可能的实现方式，接收时间戳用于在发送时间戳等于接收端的历史发送时间戳时，根据接收时间戳与接收端的历史接收时间戳进行验证。
一种可能的实现方式，接收时间戳的第二时间精度满足第一消息进行重放攻击验证的要求；发送时间戳的第一时间精度满足新鲜值的比特位的要求。
一种可能的实现方式，发送端的计时器和接收端的计时器与车辆的整车生命周期有关。
第六方面，本申请提供一种车内通信装置，该装置可以为接收端，该装置包括：该装置可以包括处理器，处理器与存储器相连，存储器用于存储计算机程序，处理器用于执行存储器中存储的计算机程序，以使得装置执行如上述第二方面中任一项的方法。
第七方面，本申请提供一种车辆，车辆包括发送端和接收端，接收端用于实现如第一方面中任一项的方法，发送端用于实现如第二方面中任一项的方法。
第八方面，一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，当计算机程序被运行时，实现如第一方面或第二方面中任一项的方法。
第九方面，本申请提供一种计算机程序产品，计算机程序产品包括计算机程序，当所述计算机程序被车内通信装置执行时，实现如上述第一方面或第二方面中任一项的方法。
在一种可能的实现方式中，计算机程序包括计算机指令，当计算机指令被车内通信装置执行时，实现如上述第一方面或第二方面中任一项的方法。
第十方面，本申请实施例提供了一种芯片，该芯片包括数据接口和处理器，其中，处理器用于执行第一方面或第一方面的任意可能实现方式中的方法或上述第二方面中任一项的方法。例如，该芯片为车辆上安装有软件或固件的任意芯片。
第十一方面，本申请提供了一种芯片系统，该芯片系统包括至少一个处理器，用于支持实现上述第一方面或第一方面的任意可能实现方式中所涉及的功能，上述第一方面中任一项的方法或上述第二方面中任一项的中所涉及的功能。例如，例如接收或处理上述方法中所涉及的数据和/或信息。
在一种可能的设计中，所述芯片系统还包括存储器，存储器，用于保存程序指令和数据，存储器位于处理器之内或处理器之外。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
上述第三方面至第十一方面的有益效果，具体请参照上述第一方面和第二方面中相应设计可以达到的技术效果，这里不再重复赘述。
附图说明
图1为本申请实施例适用的一种可能的系统架构示意图；
图2示例性示出一种车内通信方法对应的流程示意图；
图3示例性示出一种第一消息生成的示意图；
图4示例性示出本申请实施例提供的一种车内通信方法对应的流程示意图；
图5示例性示出本申请实施例提供的一种第一消息的验证示意图；
图6示例性示出一种第一消息的示意图；
图7示例性示出本申请实施例提供的一种车内通信装置的结构示意图；
图8示例性示出本申请实施例提供的一种车内通信装置的结构示意图。
具体实施方式
需要说明的是，本申请实施例中的方案可以应用于车联网，如车辆外联(vehicle to everything，V2X)、车间通信长期演进技术(long term evolution-vehicle，LTE-V)、车辆-车辆(vehicle to vehicle，V2V)等。例如可以应用于具有车内通信功能的车辆，或者车辆中具有车内通信功能的其它装置。该其它装置包括但不限于：车载终端、车载控制器、车载模块、车载模组、车载部件、车载芯片、车载单元、车载雷达或车载摄像头等其他传感器，车辆可通过该车载终端、车载控制器、车载模块、车载模组、车载部件、车载芯片、车载单元、车载雷达或车载摄像头，实施本申请提供的通信方法。
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。
在本申请实施例中，如图1所示，车辆可采用电子电气(electrical/electronic，E/E)架构，该架构包括三个层级，分别为网关电子控制单元(electronic control unit，ECU)、域控制器ECU和域内ECU。其中，根据功能不同，可划分为不同的域，每个域有一个域控制器ECU。域控制器ECU用于管理对应域内的域内ECU。网关ECU用于对域控制器ECU进行管理。例如，参照图1所示，根据功能不同，可划分4个域，分别为整车控制系统域、娱乐系统域、诊断系统域以及智能驾驶域。每个域对应于一个域控制器ECU。上述4个域，总共对应于4个域控制器ECU。网关ECU用于对4个域控制器ECU进行管理。
例如，在本申请实施例中，整个E/E架构中，包括4个可变速率的CAN(CAN with flexible data-rate，CAN FD)总线，当然还可以是其他总线，以CAN FD总线为例，分别为CAN FD总线1、CAN FD总线2、CAN FD总线3以及CAN FD总线4。
可选的，图1中的4个CAN FD总线可与图1中的4个域存在对应关系。比如，图1中的CAN FD总线1可对应于整车控制系统域，CAN FD总线2可对应于娱乐系统域，CAN FD总线3可对应于诊断系统域，CAN FD总线4可对应于智能驾驶域等。本申请实施例对此不做限定。
其中，在图1所示的架构中，ECU之间可基于控制区域网络(controller area network，CAN)协议进行通信，不同ECU之间可发送CAN消息。为了保护CAN消息的完整性以及防重放攻击，可利用密钥对CAN消息进行保护。不同类型的CAN消息对应于不同的密钥。在整个E/E架构中，CAN消息的类型较多，相应的密钥的数量也较多，管理困难。
可以理解的是，图1所示架构，仅为示意性说明，并不作为对本申请实施例的限定。比如，本申请实施例所提供的方法，除可利用于上述图1所示的三层架构外，还可利用于其它两层或一层架构中等，不作限定。
下面对本申请实施例中所使用到的一些通信名词或术语进行解释说明，该通信名词或术语也作为本申请内容的一部分。
一、电子控制单元(electronic control unit，ECU)
本申请实施例中，车辆的内部可以配置有多个ECU，如图1中的ECU，可以为ECU 1、ECU 2、……、ECU N，N为正整数。其中，每个ECU都可以具有自己特定的功能，且还支持简单的传感器数据处理和复杂的逻辑计算。目前常见的ECU包括但不限于：车载传感器、车载摄像头、多域控制器(multi domain controller，MDC)、自动驾驶域控制单元(automated-driving control unit，ADCU)、前装智能网关(telematics box，T-Box)、智能座舱域控制器(cockpit domain controller，CDC)、车载网关、整车控制单元(vehicle control unit， VCU)、电池管理系统(battery management system，BMS)、热管理系统(thermal management system，TMS)、配电单元(power distribution unit，PDU)等。
本申请实施例中，车辆中的各个ECU可以依赖于车辆出厂时所设置好的通信技术来交互消息。这些通信技术例如可以为控制器局域网(controller area network，CAN)技术，还可以为其它实现消息交互的通信技术。例如，在对车辆的ECU进行故障诊断时，车辆的ECU可以通过车载诊断端口连接至车辆CAN FD总线，实现与车辆发送端之间的通信。CAN网络具有广播能力。当依赖于CAN技术来交互消息时，各个ECU可以连接在同一根CAN FD总线上，任一个ECU都可以自由地在该CAN FD总线上读取和发送CAN消息帧。CAN是面向消息的，CAN FD总线上的每个CAN消息帧中一般只具有消息标识，而不携带源地址或目的地址，连接到该CAN FD总线上的各个ECU可以通过消息标识来选择接收哪个消息帧。其中，CAN消息帧可以传输8字节，CAN FD消息帧中上可以传输最大为64字节的数据字段。例如，在使用CAN FD帧传输时，一帧数据帧即可完成传输128bit高级加密标准(advanced encryption standard，AES)密钥，实现更高的数据速率和更长的数据字段空间。
虽然基于CAN FD技术的消息交互方式具有较强的实时性和可靠性，但是CAN FD技术中并没有内置任何的安全功能。这种情况下，一旦攻击者破译了CAN FD总线，则攻击者注入的每个CAN消息帧都可能会被车辆中的ECU读取并认为是合法的CAN消息帧，这样，攻击者就能够完全控制车辆的功能，例如制动或加速，这对于用户使用车辆来说是非常不安全的。
基于此，车辆中的各个ECU还应该配置有各自对应的长期密钥。当某个ECU根据消息标识从CAN FD总线上获取到一个CAN消息帧时，该ECU还可以使用预先配置的长期密钥来解析该CAN消息帧。如果解析不成功，则说明该CAN消息帧大概率属于非法设备注入在CAN FD总线上的非法的控制命令，因此该ECU可以不执行对应的控制操作，以避免非法设备控制车辆。如果解析成功，则说明该CAN消息帧属于合法人员(例如车主)注入在CAN FD总线上的合法的控制命令，因此该ECU可以执行对应的控制操作。如此，通过在各个ECU中预设长期密钥来完成CAN消息帧的认证操作，有助于在真正执行控制之前先对控制命令进行认证，以提高车主的行车安全。
二、网关(gateway)
网关是车辆架构中的核心部分，其作为整车网络的数据交互枢纽，可将CAN FD等网络数据在不同网络中进行路由。网关可对域控制设备和域内设备等进行管理。在本申请实施例中，网关内可包括网关ECU，网关与网关ECU不作相互区分。
三、域控制设备
根据车辆电子各部分的功能不同，可将车辆电子划分为几个域。比如，动力传动域、车身电子域以及辅助驾驶域等。每个域内设有一个域控制设备，用于对该域内的域内设备进行管理。域控制设备也可称为域控制器。在本申请实施例中，域控制设备内包括域控制ECU，域控制设备与域控制设备ECU不作相互区分。
四、域内设备
根据车辆电子各部分的功能不同，可将车辆电子划分为几个域。比如，动力传动域、车身电子域以及辅助驾驶域等。每个域内可包括一个域控制器和多个被控制设备，域内设备可具体指每个域内的被控制设备等。在本申请实施例中，域内设备中可包括域内ECU， 域内设备与域内ECU不作相互区分。
本申请实施例中，车辆的内部还可以配置有密钥管理系统(key management system，KMS)。KMS在车辆中主要负责生成密钥、管理密钥和清除密钥等功能，这些密钥包括上述介绍的长期密钥。不同于传统的信息与技术(information and communications technology，ICT)，车联网中的ECU大都遵循汽车网络安全(automotive,cyber security，EVITA)标准和安全硬件扩展(secure hardware extension，SHE)标准。示例性地，考虑到EVITA标准和SHE标准下设置密钥的性能和成本，KMS中的长期密钥可以设置为对称密钥。
在车联网技术领域中，两个节点之间的收发操作需要依赖各种不同的通讯协议，这两个节点可以是车外发送端和车内的ECU，也可以是车内的任意两个ECU。以SecOC协议为例，介绍车辆内的ECU之间进行通信时，基于车辆内的AUTOSAR架构生成ECU之间传输的消息。
AUTOSAR架构定义了不同的软件层，例如，应用程序软件，运行时环境和基础软件层(basic software of AUTOSAR，BSW)(可以含服务层、抽象层、驱动层)等。其中，新鲜值管理策略和密钥管理策略在应用程序软件中实现。应用程序软件调用AUTOSAR接口进行消息认证码(message authentication code，MAC)的生成或验证和AES加密或解密。SHE+驱动程序控制硬件安全模块(hardware security module，HSM)域中的硬件安全外围设备，并与主机核心进行交互。SHE+提供了AUTOSAR接口，可将HSM安全功能集成到汽车应用程序中，包括与AUTOSAR的接口，实现主机核心和HSM之间的通信，密钥安全存储功能和安全外围设备驱动程序。CAN驱动程序提供使用ECU中的多CAN+(MultiCAN+)单元的服务，利用CAN驱动程序来发送和接收CAN消息。SecOC协议是AUTOSAR软件中位于框架中的BSW层的一个可选地软件模块，通过应用程序软件模块提供SecOC的接口，以请求新鲜值进行安全消息的发送或接收，通过应用程序软件模块还提供了接口来传输失败或成功的发送或接收消息。SecOC协议可以为PDU级别上的ECU消息提供消息完整性认证机制，并能确保ECU消息的新鲜度，防止非法设备重放历史消息而导致ECU的控制出现问题。
在CAN FD总线上传输的消息可以通过密钥生成消息认证码MAC进行安全验证。其中，消息认证码MAC对应使用的密钥和新鲜值是全局唯一的。从而，接收端可以通过新鲜值(FV)的验证实现防重放攻击，保证发送消息的消息认证码MAC在密钥生命周期内是唯一的。通过对消息认证码进行验证，以校验消息的完整性。例如，如果密钥在整车的生命周期内不更新，则新鲜值在整车的生命周期内(例如，整车从车辆生产、到车辆使用或到车辆报废的时间)保证每个消息的唯一。
下面以SecOC协议为例，介绍车辆内的ECU之间进行通信时的具体实现过程。如图2所示，为一种可能的车辆通信方法，包括以下步骤：
步骤201，发送端根据第一信息、新鲜值(fresh value，FV)，生成第一消息。
在上述步骤201中，发送端可以采用计数器来判定发送消息和接收消息的新鲜值。发送端每发送一次消息，都可以对内部存储的新鲜值加1。这样，由于发送端发送的消息认证码基于当前的新鲜值来生成，因此即使非法设备向接收端发送了发送端之前生成的历史消息(携带历史新鲜值)，接收端也能根据第一消息认证码中携带的新鲜值判定所接收到的消息是否为新鲜的消息，当不是新鲜的消息而是历史消息时，接收端可以不执行对应的控制命令。这种方式能较好地防止非法设备利用历史消息来控制车辆，从而有助于提高车 辆的防攻击能力。
另一种可能的实现方式，发送端可以以时间戳作为新鲜值，发送端每发送一次消息，可以根据发送该消息的本地时钟，确定发送该消息的发送时间戳，从而，消息中的新鲜值可以基于该消息的发送时间戳实现。
步骤202，发送端向接收端发送第一消息。
在上述步骤202中，考虑到CAN消息帧的数据域有限，一种可能的实现方式，发送端还可以先截短新鲜值，再组装截短后的新鲜值和第一信息以得到第一消息。
图3示例性示出本申请实施例提供的一种组装消息的方式，如图3所示，该方式先将新鲜值分割为新鲜值的低位和新鲜值的高位，然后取新鲜值的低位(least significant bit，LSB)，依次拼接第一信息和新鲜值的低位，以得到消息。例如，以时间戳生成新鲜值为例，即发送消息可以包含2个组成部分：明文消息(n个比特bits)和截短时间戳。其中，截短时间戳，可以占用m比特，可以是截取64bits时间戳的最低位的一部分，即FV的最低位。
步骤203，接收端对第一消息中的新鲜值进行验证。
接收端收到发送端发送的第一消息后，分别解析出第一消息中的第一信息和新鲜值(FV的LSB低位截短部分)。
示例性地，如果发送端按照上述图3所示意的方式拼接得到第一消息，则接收端会获取到新鲜值的低位。这种情况下，接收端还需要依据消息中携带的新鲜值的低位和接收端本地存储的新鲜值来恢复出完整的新鲜值，其中，本地存储的新鲜值基于接收端最近一次接收到的历史消息中携带的新鲜值的低位来确定。接收端将收到的新鲜值FV的LSB低位截短部分和本地维护的FV的高位(most significant bit，MSB)部分组装恢复出完整新鲜值FV。在一种可选地恢复方式中，如果消息中携带的新鲜值的低位小于本地存储的新鲜值的低位，则说明新鲜值的低位在递增过程中出现值域溢出(例如二进制的新鲜值的低位从1再递增1时会变为0，而新鲜值的高位则会对应递增1)，因此接收端可以先对本地存储的新鲜值的高位加1，再将本地存储的新鲜值的高位和消息中携带的新鲜值的低位拼接在一起以得到完整的新鲜值。如果消息中携带的新鲜值的低位不小于本地存储的新鲜值的低位，则说明新鲜值的低位在未溢出的情况下逐渐递增，因此接收端可以直接将本地存储的新鲜值的高位和消息中携带的新鲜值的低位拼接在一起以得到完整的新鲜值。
在一种可选地实施方式中，接收端可以对比新鲜值的LSB和本地存储的历史新鲜值的LSB进行比较，确定是否可能存在重放攻击，例如，在接收消息的新鲜值小于本地存储的上一次接收的消息中的新鲜值时，则认为是LSB值域的溢出翻转场景，递增本地维护的FV MSB值。例如，如果新鲜值小于本地存储的新鲜值，则说明该消息可能是非法设备利用历史消息重发的攻击性消息。如果新鲜值大于本地存储的新鲜值，则说明该消息并不属于重放消息。在验证完毕，接收端可以通过覆盖最后收到的消息中的FV来刷新本地维护的FV。
步骤204，发送端和接收端维护新鲜值的同步。
本申请实施例中，虽然新鲜值在整车生命周期中按照消息发送的次数单调递增，但是发送端和接收端之间各自维护自己的新鲜值，这可能会由于某些不可预知的异常导致发送端和接收端之间的新鲜值不同步。例如一种情况下，虽然发送端向CAN FD总线上发送了一个消息，但是CAN FD总线由于某种故障丢失了该消息，例如ECU间上下电唤醒顺序 不一致，CAN FD总线丢帧异常等。这种情况下，接收端就无法获取到该消息，从而接收端中的新鲜值会比发送端中的新鲜值小。为了避免这种现象发生，本申请还可以在发送端和接收端之间设置某种容错机制，以维护准确的新鲜值数据。例如在一种可选地容错机制下，可以让发送端和接收端定期同步各自的新鲜值，一旦发现某一设备的新鲜值小于另一设备的新鲜值，则可以让新鲜值小的设备修正自己的新鲜值，这样，发送端和接收端就能始终保持相同的新鲜值。
可选的，新鲜值可采用时间戳或单调计数器两种可选的方案。
基于单调计数器作为新鲜值的方案中，由于CAN的数据帧值域空间只有8字节，分配给新鲜值FV LSB的空间只有8bit，需采用新鲜值截短的传输方案，假设CAN FD总线高负载每10ms发送消息，则防重放攻击窗口仅维持约2.5秒，新鲜值FV LSB就会溢出翻转，必须在接收端根据先验条件重建完整新鲜值。因此，也会带来新鲜值可能存在不同步的问题，需定期向各ECU传输完整的新鲜值。一种可能的实现方式，ECU在确定失步时，可以向ECU的管理设备发送计数器的同步请求消息，ECU的管理设备收到同步请求消息后，广播计数器的同步消息。这种方式可以被攻击者利用请求广播垃圾消息，导致系统功能的安全问题。
基于时间戳作为新鲜值的方案中，发送者和接收者将使用本地计时器的时间戳来确定新鲜值。时间戳方案中，由于接收器和发送器ECU侧的时钟振荡器偏差，导致接收端和发送端的时间不同步，假设仅在开机(不重新同步)期间进行同步，并且每个ECU的时钟振荡具有最大+/-0.02％的时钟误差。ECU_A具有+0.02％误差，而ECU_B具有-0.02％误差。举例来说，表1中显示了一种新鲜值持续时间对应的时钟振荡器产生的抖动。
表1
新鲜值持续时间 最大抖动
24小时 34.56秒
1小时 1.44秒
1分钟 24毫秒
1秒 400微秒
1毫秒 0.4微秒
因此，需要使用时间戳同步机制，使得在所有ECU间同步UTC时间。例如，UTC可被表示的时间是2038年1月19日03:14:07。在一些实施例中，可以通过广播发送同步CAN消息，该消息中携带完整的时间。同步时间的方案非常复杂，另外，在时间同步时，还需暂停消息的发送，导致可能的数据的延迟，可能导致降低车辆的安全。或者，为防止定期发送广播时间同步消息干扰到其他高优先级业务消息，在CAN FD总线上发送高优先级的业务消息时，则无法进行同步，可能导致无法及时精确的同步。另外，如果CAN FD总线上出现电磁干扰，则ECU可能无法保证会收到同步消息。在异常情况下，接收器需要等待下一个同步消息，即在同步周期内(例如：1秒)，此接收器无法发送和接收CAN消息，这将导致系统功能安全问题。而且，在同步过程中也可能发生重放攻击。一种防止重放的方法是，对于每次检测到密钥启动事件，主同步ECU(例如网关)都可以将64位同步帧计数器的高32位增加1，这带来了增加重放难度。但是，这种方案需要一个额外的安全非易失性存储器来在主同步ECU中存储密钥启动计数器的数量，增加了成本和新鲜值同步的复杂度。
基于上述问题，本申请提供一种车内通信方法，发送端和接收端可以是车辆内的任一ECU。如图4所示，包括以下步骤：
步骤401：发送端根据发送端的发送时间戳，确定第一消息的新鲜值。
其中，发送端可以根据发送端的计时器确定发送第一消息的发送时间戳。其中，计时器可以是本地时钟(internal clock)或单向计数器(monotonic counter)等，本申请不做限定。
一种可能的实现方式，发送端可以将第一消息的发送时间戳作为第一消息的新鲜值，发送端每次向接收端发送第一消息时，可以根据发送该第一消息的本地时钟，确定发送该第一消息的发送时间戳。
下面以计时器为本地时钟为例，说明第一消息的发送时间戳的实现方式。一种可能的例子，车厂生产预置一个ECU的密钥，用于该ECU与其他ECU之间进行通信，该密钥在整车生命周期内不更新，则从ECU第一次上电运行起，本地时钟只能单向递增，保证发送时间戳的唯一性，使得根据发送时间戳确定的新鲜值可以覆盖整车生命周期。
本地时钟的时间存储格式可以为UTC格式，最小单位为毫秒。当然，还可以根据本地时钟的时间精度，确定本地时钟的最小时间单位。例如，本地时钟的最小时间单位可以为毫秒。例如，在发送时间戳对应的新鲜值占用的比特位数为64bit时，可以满足发送时间戳的最小单位为毫秒。在发送时间戳对应的新鲜值占用的比特位数为32bit时，可以满足发送时间戳的最小单位为秒。
在一些实施例中，发送端的本地时钟确定的发送时间戳可以存储为UTC时间的时间戳格式，也可以是简化后的时间戳，例如，本地时钟存储的发送时间戳可以满足：UTC时间与预设时间的差。例如，发送时间戳可以满足：UTC时间减去2000年。在新鲜值占用的比特位数为64bit时，可以满足发送时间戳的最小单位为毫秒。例如，发送第一消息的时刻为2021年1月19日03:14:07:01:1。考虑到整车生命周期可能到达10～20年，可以设置发送时间戳为：21年1月19日03:14:07:01:1，即发送时间戳的形式可以为210119031407011。即该发送时间戳的最小时间单位为毫秒。
考虑到在传输过程中，新鲜值可以占用的比特位数有限。因此，本申请中，可以根据第一消息的新鲜值占用的比特位数，确定新鲜值中对应的发送时间戳满足的第一时间精度。即发送时间戳的第一时间精度满足第一消息传输新鲜值的比特位的要求。结合图5所示，在发送端的本地时钟的时间精度比发送时间戳的时间精度高时，可以选择本地时钟确定的发送时间中的高位，作为发送时间戳。例如，新鲜值占用的比特位数为32bit时，可以满足发送时间戳的最小单位为秒。例如，发送第一消息的发送时间为2021年1月19日03:14:07:01:1，可以确定发送时间戳为：21年1月19日03:14:07，即发送时间戳的形式可以为210119031407。
在确定新鲜值携带的发送时间戳的最小单位后，可以相应确定发送端和接收端在正常运行时的重放时间窗口，例如，假设CAN FD总线发送消息时间1ms，重放时间窗口为1s，即发送端和接收端可以将重放攻击控制在1000次以内。
发送端在运行过程中，还可以定期将本地时间复写到安全非易失存储中。通过该方式可以保证发送端在重启后，通过复写到安全非易失存储中的本地时间，更新重启后的本地时钟，保证发送端的本地时钟是单调递增的，即保证发送端生成的发送时间戳是单调递增的，进而保证新鲜值是单调递增的。存储的本地时间可以是本地时钟可以达到的最小时间 单位。例如，在发送端的本地时钟的最小时间单位为毫秒时，可以将毫秒级的本地时间复写到安全非易失存储中。
在一些实施例中，本地时间的复写的时机可以是在车辆下电或发送端在休眠前写入，相应的，在每次车辆上电或发送端被唤醒时，发送端的本地时钟可以从安全非易失存储中读取本地时间复位值，以保证车辆的本地时钟产生的时间戳为单调递增的。本地时间复写的时机还可以是周期性写入，复写周期可以根据硬件可支持的复写能力确定，例如复写周期值为每秒、每分钟或每小时，本申请不做限定。
考虑另一种车辆的发送端重启的场景，例如，在车辆维修换件场景下，在重启后，发送端可以根据发送端重启前存储的发送时间戳，重置发送端的本地时钟，保证维修换件后，发送端生成的新鲜值在整车生命周期内为单调递增。
以一个CAN FD消息帧支持64字节(bytes)，新鲜值占用的比特位数为32bit为例，新鲜值携带的发送时间戳的最小时间单位为秒。此时，发送端可以直接拼接第一信息、新鲜值和第一消息认证码来生成第一消息。避免通过截短的方式，在第一消息中传输截短后的新鲜值和截短后的第一消息认证码。从而，避免通过定期发送完整新鲜值的方式，实现发送端和接收端之间的新鲜值的同步，节省了发送端和接收端之间由于发送同步新鲜值的消息带来的开销，也避免了接收端可能无法及时接收到同步新鲜值的消息，导致的传输消息无法正常接收等问题，提高了发送端和接收端之间的传输性能。
步骤402：发送端根据第一信息、新鲜值和密钥，生成第一消息认证码。
其中，第一信息可以是发送端向接收端发送的待发送信息。密钥可以是车辆内的长期密钥，也可以是发送端和接收端之间的长期密钥，在此不做限定。发送端或接收端可以是车辆内的任一ECU。
在一种可选地实施方式中，发送端中还可以设置有消息认证码生成器，消息认证码生成器用于按照预设的生成算法处理输入信息以得到消息认证码并输出。当预设的生成算法为基于分组加密的消息认证码(cipher-based MAC，CMAC)AES128(遵从RFC 4493)时，如果发送端将第一信息I、新鲜值FV和密钥{M}一起输入消息认证码生成器，则消息认证码生成器可以按照如下公式(1.1)计算得到第一消息认证码L1并输出：
L1＝CMAC-AES128(I||FV，{M})……(1.1)
根据上述公式(1.1)可知，当密钥{M}为AES128比特长的对称密钥时，第一消息认证码L1的长度也可以为128比特。
其中，第一信息为第一消息中携带的数据。其中“||”可以理解为拼接，例如M1可以为将I以及FV的对应的字节拼接到一起。例如，当计算L1的过程中，可以根据第一信息I和新鲜值FV拼接后进行计算。
步骤403：发送端根据第一信息、新鲜值和第一消息认证码，生成并向接收端发送第一消息。
其中，第一消息包括发送端的发送时间戳；发送时间戳是发送端为第一消息生成的新鲜值。相应的，接收端接收第一消息。
在上述步骤403中，考虑到CAN消息帧的数据域有限，这种情况下，为了顺利传输第一信息，发送端还可以先截短第一消息认证码，再组装截断后的第一消息认证码和第一信息以得到第一消息。考虑到第一信息传输的安全性会随着第一消息认证码的长度变小而线性降低，而64位及以上长度的消息认证码一般具有足够的防攻击能力，因此，发送端 在截短消息认证码时，还可以设置第一消息认证码的长度不小于64位。
需要说明的是，第一消息中也可以不包括第一消息认证码，即第一消息由第一信息和新鲜值组成。即上述步骤402可以不执行，在执行步骤403时，可以是发送端根据第一信息和新鲜值，生成并向接收端发送第一消息。此时，发送的第一消息可以包含明文消息(n bits)和新鲜值，该新鲜值是由发送时间戳生成的。例如，新鲜值可以占用32比特，新鲜值对应的发送时间戳可以是截取发送端的计时器确定的64bits时间戳最高位的一部分，即FV的最高位。
图6示例性示出本申请实施例提供的一种组装第一消息的方式，如图6所示，该方式先将新鲜值分割为新鲜值的低位和新鲜值的高位，将第一消息认证码分割为第一消息认证码的低位和第一消息认证码的高位，然后取新鲜值和第一消息认证码的高位(MSB)，依次拼接第一信息、新鲜值和消息认证码的高位，以得到消息。例如，以时间戳生成新鲜值为例，即发送消息可以包含3个组成部分：明文消息(n bits)，新鲜值(由发送时间戳生成)和截短消息认证码。例如，新鲜值可以占用32比特，新鲜值对应的发送时间戳可以是截取发送端的计时器确定的64bits时间戳最高位的一部分，即FV的最高位。截短消息认证码可以占用k bits，为截取128bits消息认证码CMAC最高位的一部分。在一个CAN帧中，明文消息占用的比特数可以满足n＝64-k-m(bits)。其中，n,m,k为正整数。
步骤404：接收端根据第一消息的接收时间戳和发送时间戳，对第一消息进行验证。
一种可能的实现方式中，接收端收到发送端发送的第一消息后，分别解析出第一消息中的第一信息、新鲜值和消息认证码(MAC的截短部分)。
在一种可选地实施方式中，接收端可以先对比新鲜值和本地存储的历史新鲜值进行验证，如果新鲜值小于本地存储的新鲜值，则说明该消息可能是非法设备利用历史消息重发的攻击性消息，因此接收端可以不执行对应的控制命令，或者还可以向发送端返回警告信息。如果新鲜值大于本地存储的新鲜值，则说明该消息并不属于重放消息。如果新鲜值等于本地存储的新鲜值，可以基于接收时间戳与历史时间戳进行验证，确定该第一消息是否为重放消息。
可以看出，由于该方式中，发送的是高位的新鲜值，因此，不存在图2中的新鲜值的LSB值域溢出的问题，有效提高了新鲜值的可信度。
一种可能的实现方式，发送端的计时器与接收端的计时器不进行时间同步的操作。在该方式下，接收端可以根据接收端的计时器确定第一消息的接收时间戳。其中，接收端的计时器可以是接收端的本地时钟(Internal clock)或接收端的单向计数器(monotonic counter)等，本申请不做限定。
下面以接收端的计时器为本地时钟为例，说明第一消息的接收时间戳的实现方式。一种可能的例子，车厂生产预置一个接收端的密钥，用于接收端与发送端之间进行通信，该密钥在整车生命周期内不更新，则从接收端第一次上电运行起，接收端的本地时钟只能单向递增，保证时间戳的唯一性，使得根据时间戳确定的新鲜值可以覆盖整车生命周期。
在一些实施例中，接收端的本地时钟的时间存储格式可以为UTC格式，最小单位为毫秒。当然，还可以根据本地时钟的时间精度，确定本地时钟的最小时间单位。例如，本地时钟的最小时间单位可以为毫秒。即接收时间戳的时间精度为第二时间精度。第二时间精度大于第一消息的新鲜值中对应的发送时间戳的时间精度。
在一些实施例中，以接收端的本地时钟的最小时间单位为毫秒为例，接收端的本地时 钟确定的接收时间戳可以存储为UTC格式，也可以是简化后的时间戳，例如，接收端的本地时钟确定的接收时间戳可以满足：UTC时间与预设时间的差。例如，接收时间戳可以满足：UTC减去2000年。在接收时间戳的比特位数为64bit时，可以满足接收时间戳的最小单位为毫秒。
结合图5所示，接收端的接收时间戳可以根据接收端的本地时钟接收到第一消息的时间确定。例如，接收端接收第一消息的时间为2021年1月19日03:14:40:01:2。考虑到整车生命周期的长度，可以设置接收时间戳为：21年1月19日03:14:40:01:2，即接收时间戳的形式可以为210119031440012。即该接收时间戳的最小时间单位为毫秒。
在一些实施例中，考虑到发送端和接收端之间的时间可能不同步，此时，以初始化时发送端和接收端的时间一致为例，在发送端和接收端运行时间为1天时，发送端和接收端之间的时间漂移可能达到了34秒。因此，不能直接采用第一消息的接收时间戳对第一消息进行重放攻击的验证。为使接收端可以满足对重放攻击的验证的要求，本申请中，可以根据第一消息的接收时间戳和第一消息的发送时间戳，对第一消息进行重放攻击的验证。
在一些实施例中，接收端可以将第一消息中的发送时间戳作为第一消息的一次验证部分，将接收时间戳作为第一消息的二次验证部分。
例如，在第一消息中的发送时间戳大于接收端存储的上一次接收到的发送端发送的历史发送时间戳时，可以确定第一消息的新鲜值验证成功，第一消息不是重放消息。
在第一消息中的发送时间戳小于接收端存储的上一次接收到的发送端发送的历史发送时间戳时，可以确定第一消息的新鲜值验证失败，第一消息是重放消息。
在第一消息中的发送时间戳等于接收端存储的上一次接收到的发送端发送的消息的历史发送时间戳时，可以进一步通过第一消息的接收时间戳与接收端上一次接收到的发送端发送的消息时存储的历史接收时间戳进行比较，在第一消息的接收时间戳大于接收端上一次接收到的发送端发送的消息时存储的历史接收时间戳时，可以确定第一消息的新鲜值验证成功，第一消息不是重放消息。在第一消息的接收时间戳小于或等于接收端上一次接收到的发送端发送的消息时存储的历史接收时间戳时，可以确定第一消息的新鲜值验证失败，第一消息是重放消息。
即通过第一消息的接收时间戳和第一消息的发送时间戳进行组合验证的方式，确定第一消息是否为重放消息。
结合图5，以接收端的本地时钟的最小时间单位为毫秒，发送端发送的新鲜值对应的发送时间戳的最小时间单元为秒为例。第一消息的发送时间戳为：21年1月19日03:14:07。通过将第一消息中的发送时间戳作为第一消息的首次验证的部分，将接收时间戳作为第一消息的二次验证的部分。
在接收端存储的发送端发送的消息的历史发送时间戳为21年1月19日03:13:01时，可以确定第一消息的发送时间戳大于接收端存储的消息的历史发送时间戳，因此，可以确定第一消息不是重放消息，重放验证成功。
在接收端存储的发送端发送的消息的历史发送时间戳为21年1月19日03:14:07时，可以确定第一消息的发送时间戳等于接收端存储的消息的历史发送时间戳，此时，可以通过接收时间戳进行二次验证。
此时，一种可能的场景，在接收端存储的发送端发送的消息的历史接收时间戳为21年1月19日03:14:38:01:2时，第一消息的接收时间戳为：21年1月19日03:14:40:01:2， 即第一消息的接收时间戳大于接收端存储的发送端发送的消息的历史接收时间戳，可以确定第一消息不是重放消息，验证成功。
另一种可能的场景，在接收端存储的发送端发送的消息的历史接收时间戳为21年1月19日03:14:40:01:3时，第一消息的接收时间戳为：21年1月19日03:14:40:01:2，即第一消息的接收时间戳小于接收端存储的发送端发送的消息的历史接收时间戳，可以确定第一消息是重放消息，验证失败。
再一种可能的场景，还可以通过发送端和接收端的重放时间窗口确定第一消息是否为重放消息。例如，发送端和接收端在正常运行时的重放时间窗口可以是基于新鲜值携带的发送时间戳的最小时间单位确定的。另外，由于还考虑了接收端本地时钟确定的第一接收时间戳，可以有效降低发送端和接收端之间的重放攻击的次数。由于第一接收时间戳的时间精度为第二时间精度，例如，接收端的本地时钟的最小时间单位为毫秒时，第一接收时间戳的时间精度为毫秒，因此，重放时间窗口可以控制在毫秒级或亚秒级。例如，假设CAN FD总线发送消息时间1ms，重放时间窗口为0.5s，即发送端和接收端可以将重放攻击控制在500次以内。
此时，接收端在确定第一消息的发送时间戳等于接收端存储的发送端发送的消息的历史发送时间戳后，还可以通过发送端和接收端的重放时间窗口，对第一消息的接收时间戳进行二次验证。例如，在第一消息的接收时间戳和接收端存储的发送端发送的消息的历史接收时间戳之间的差值小于或等于重放时间窗口时，可以确定第一消息不是重放消息，第一消息验证成功。在第一消息的接收时间戳和接收端存储的发送端发送的消息的历史接收时间戳之间的差值大于重放时间窗口时，可以确定第一消息是重放消息，第一消息验证失败。
在新鲜值验证完毕后，接收端可以通过覆盖最后收到的消息中的新鲜值来刷新本地维护的新鲜值。另外，接收端可以将第一消息中的新鲜值和接收时间戳对应的新鲜值复写到安全非易失存储中，用于对下一次接收到的发送端发送的消息进行验证。或者，可以将发送时间戳和接收时间戳复写到安全非易失存储中，用于对下一次接收到的发送端发送的消息(例如为第二消息)进行验证。其中复写的方式可以是替换原存储的发送端发送的消息的发送时间戳和该消息的接收时间戳，也可以是另外存储发送端发送的消息的发送时间戳和接收时间戳。
示例性地，如果发送端按照上述图6所示意的方式拼接得到第一消息，则接收端会获取到新鲜值和第一消息认证码的高位。进而，接收端可以根据第一信息、密钥和新鲜值，生成第二消息验证码。
本申请实施例中，接收端中还可以设置有消息认证码解析器，消息认证码解析器用于按照与发送端中的消息认证码生成器预设的相同的生成算法处理输入信息以得到消息认证码并输出。当预设的生成算法为CMAC-AES128(遵从RFC 4493)时，如果接收端将第一信息I、新鲜值FV和本地存储的密钥{M}一起输入消息认证码解析器，则消息认证码解析器可以按照上述公式(1.1)计算得到第二消息认证码L2并输出。
在确定第二消息验证码与第一消息验证码相同时，可以确定第一消息验证成功。
例如，接收端判断自己生成的第二消息认证码和第一消息中携带的第一消息认证码是否相同，若相同，则说明接收端的本地RAM中存储的密钥与第一信息对应的密钥相同，接收端属于要执行该第一消息的车载设备，并对该第一消息执行相应的操作。若不同，则 说明接收端不属于要执行该第一消息的车载设备，因此接收端可以忽略该第一消息。
上述实施方式通过使用新鲜值和密钥生成的消息认证码来认证消息，不仅能防止第一信息在车内传输的过程中被篡改，还能准确检测出利用历史消息攻击车辆的行为，且还能在认证信息准确传输的情况下再执行相应的操作，从而有助于准确保证车辆在执行车辆通信的安全性。
另外，接收端在运行过程中，还可以定期将本地时间复写到安全非易失存储中，通过该方式可以保证接收端在重启后，通过复写到安全非易失存储中的本地时间，更新重启后的本地时钟，保证接收端的本地时钟是单调递增的，即保证接收端生成的接收时间戳是单调递增的。存储的本地时间可以是本地时钟可以达到的最小时间单位。例如，在接收端的本地时钟的最小时间单位为毫秒时，可以将毫秒级的本地时间复写到安全非易失存储中。
在一些实施例中，接收端对本地时间进行复写的时机可以是在车辆下电或接收端在休眠前写入，相应的，在每次车辆上电或接收端被唤醒时，接收端的本地时钟可以从安全非易失存储中读取本地时间复位值，以保证车辆的本地时钟产生的时间戳为单调递增的。本地时间复写的时机还可以是周期性写入，复写周期可以根据硬件可支持的复写能力确定，例如复写周期值为每秒、每分钟或每小时，本申请不做限定。
考虑另一种场景，例如，在车辆维修换件场景下，可以根据接收端重启前存储的发送时间戳和接收时间戳，重置接收端的本地时钟。或者，还可以根据接收端重启前存储的第一接收时间戳和发送时间戳，重置接收端的本地时钟。保证维修换件后，接收端生成的接收时间戳在整车生命周期内为单调递增。
当接收端出现重启后，接收端的重放时间窗口可以基于复写周期和异常重启对应的恢复时间确定。
一种可能的实现方式，接收端在重启后的重放时间窗口可以满足：复写周期和接收端的重启恢复时间之和。例如：在复写周期为1分钟，重启恢复时间为10s，则可以确定在重启后的重放时间窗口为70s。
另一种可能的实现方式，接收端在重启后的重放时间窗口可以满足：复写周期与接收端的重启恢复后接收到的第一个合法消息的时间之和。举例来说，接收端的重启恢复后接收到的第一个合法消息的时间为10ms，复写周期为1分钟，可以确定重启后的重放时间窗口可以为60s+10ms。
再一种可能的实现方式，接收端在重启后的重放时间窗口可以满足：复写周期和接收端的重启恢复时间之和与接收端的重启恢复后接收到的第一个合法消息的时间之间的差值。举例来说，接收端的重启恢复后接收到的第一个合法消息的时间为10ms，复写周期和接收端的重启恢复时间之和为70s，则重启后的重放时间窗口为70s-10ms。
再一种可能的实现方式，接收端在重启后的重放时间窗口可以满足：复写周期和接收端的重启恢复时间之和与接收端的重启恢复后接收到的第一个合法消息的时间之间的最小值。举例来说，接收端的重启恢复后接收到的第一个合法消息的时间为1s，复写周期和接收端的重启恢复时间之和为70s，则重启后的重放时间窗口为1s。通过每消息携带完整新鲜值和在接收端时间轴同步机制，不依赖额外的新鲜值同步消息机制，由此规避新鲜值时间戳同步方案带来失步问题和复杂同步消息机制可靠性问题。采用第一消息的发送时间戳确定新鲜值，并在接收端获得接收时间戳，利用发送时间戳和接收时间戳共同完成验证，发送端只需要发送有限长度的时间戳即可满足防重放攻击的要求，并且无需占用过多的比 特位用于发送新鲜值，提高消息传递的有效载荷。
图7为本申请实施例提供的一种车内通信装置的结构示意图，如图7所示，该装置可以为接收端或发送端，也可以为芯片或电路，比如可设置于接收端中的芯片或电路，再比如可设置于发送端中的芯片或电路，再比如可设置于发送端中内的芯片或电路。
进一步的，该车内通信装置701还可以进一步包括总线系统，其中，处理器702、存储器704、收发器703可以通过总线系统相连。
应理解，上述处理器702可以是一个芯片。例如，该处理器702可以是现场可编程门阵列(field programmable gate array，FPGA)，可以是专用集成芯片(application specific integrated circuit，ASIC)，还可以是系统芯片(system on chip，SoC)，还可以是中央处理器(central processor unit，CPU)，还可以是网络处理器(network processor，NP)，还可以是数字信号处理电路(digital signal processor，DSP)，还可以是微控制器(micro controller unit，MCU)，还可以是可编程控制器(programmable logic device，PLD)或其他集成芯片。
在实现过程中，上述方法的各步骤可以通过处理器702中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器702中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器704，处理器702读取存储器704中的信息，结合其硬件完成上述方法的步骤。
应注意，本申请实施例中的处理器702可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
可以理解，本申请实施例中的存储器704可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。应注意， 本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
该车内通信装置701对应上述方法中的接收端的情况下，该车内通信装置可以包括处理器702、收发器703和存储器704。该存储器704用于存储指令，该处理器702用于执行该存储器704存储的指令，以实现如上图4至图6中所示的任一项或多项对应的方法中接收端的相关方案。
当车内通信装置701为上述接收端，车内通信装置701可以用于执行上述实施例中任一实施例中接收端所执行的方法。车内通信装置701为上述接收端时，收发器703接收第一消息，第一消息包括发送端的发送时间戳；发送时间戳是发送端为第一消息生成的新鲜值；处理器702根据第一消息的接收时间戳和发送时间戳，对第一消息进行验证。
当车内通信装置701为上述发送端，车内通信装置701可以用于执行上述实施例中任一实施例中发送端所执行的方法。收发器703用于向接收端发送第一消息。处理器702根据第一消息的发送时间戳，生成第一消息的新鲜值；根据第一消息的新鲜值，生成第一消息。
基于以上实施例以及相同构思，图8为本申请实施例提供的车内通信装置的示意图，如图8所示，该车内通信装置801可以为接收端或发送端，也可以为芯片或电路，比如可设置于接收端或发送端中的芯片或电路。
该车内通信装置可以对应上述方法中的接收端或发送端。该车内通信装置可以实现如上图4至图6中所示的任一项或任多项对应的方法中接收端或发送端所执行的步骤。该车内通信装置可以包括处理单元802。可选的，还可以包括接收单元803和发送单元804。
当车内通信装置801为上述接收端，且实现如上述图4中接收端所执行的步骤时，接收单元803用于接收第一消息，第一消息包括发送端的发送时间戳；发送时间戳是发送端为第一消息生成的新鲜值；处理单元802根据第一消息的接收时间戳和发送时间戳，对第一消息进行验证。
一种可能的实现方式，发送端的计时器与接收端的计时器不进行时间同步的操作。
一种可能的实现方式，在发送时间戳等于历史发送时间戳时，处理单元802根据接收时间戳与历史接收时间戳进行验证。
一种可能的实现方式，接收时间戳的第二时间精度满足第一消息进行重放攻击验证的要求；发送时间戳的第一时间精度满足新鲜值的比特位的要求。
一种可能的实现方式，在第一消息验证成功后，处理单元802根据接收到第一消息的接收时间戳和发送时间戳对第二消息进行验证；第二消息为在第一消息之后接收到的。
一种可能的实现方式，在第一消息验证成功后，处理单元802存储第一消息的接收时间戳和发送时间戳，第一消息的接收时间戳和发送时间戳用于验证在第一消息之后接收到的第二消息；和/或，在第一消息验证成功后，处理单元802存储发送时间戳和接收时间戳。
一种可能的实现方式，发送端的计时器和接收端的计时器与车辆的整车生命周期有关。
在另一些实施例中，车内通信装置可以为车辆中的发送端，处理单元802根据第一消息的发送时间戳，生成第一消息的新鲜值；根据第一消息的新鲜值，生成第一消息；发送单元803用于向接收端发送第一消息。
其中，第一消息为接收端根据接收到第一消息的接收时间戳和第一消息中的发送时间 戳进行验证的。
一种可能的实现方式，发送端的计时器与接收端的计时器不进行时间同步的操作。
一种可能的实现方式，接收时间戳用于在发送时间戳等于接收端的历史发送时间戳时，根据接收时间戳与接收端的历史接收时间戳进行验证。
一种可能的实现方式，接收时间戳的第二时间精度满足第一消息进行重放攻击验证的要求；发送时间戳的第一时间精度满足新鲜值的比特位的要求。
一种可能的实现方式，发送端的计时器和接收端的计时器与车辆的整车生命周期有关。
发送单元804在发送信息时可以为发送单元或发射器，接收单元803在接收信息时可以为接收单元或接收器，发送单元804和接收单元803可以为收发器，此收发器、发射器或接收器可以为射频电路，当车内通信装置801包含存储单元时，该存储单元用于存储计算机指令，处理单元802与存储单元通信连接，处理单元802执行存储单元存储的计算机指令，使车内通信装置801可以用于执行上述实施例中接收端或发送端所执行的方法。其中，处理单元802可以是一个通用中央处理器(CPU)，微处理器，特定应用集成电路(Application Specific Intergrated Circuit，ASIC)。
当车内通信装置801为芯片时，发送单元804和接收单元803可以是输入和/或输出接口、管脚或电路等。处理单元802可执行存储单元存储的计算机执行指令，以使该车内通信装置801内的芯片执行实施例中任一实施例所执行的方法。
可选地，存储单元为芯片内的存储单元，如寄存器、缓存等，存储单元还可以是车内通信装置801内的位于该芯片外部的存储单元，如只读存储器(Read Only Memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(Random Access Memory，RAM)等。
该车内通信装置801所涉及的与本申请实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。
根据本申请实施例提供的方法，本申请还提供一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当该计算机程序代码在计算机上运行时，使得该计算机执行图4至图6所示实施例中任意一个实施例的方法。
根据本申请实施例提供的方法，本申请还提供一种计算机可读存储介质，该计算机可读介质存储有程序代码，当该程序代码在计算机上运行时，使得该计算机执行图4至图6所示实施例中任意一个实施例的方法。
根据本申请实施例提供的方法，本申请还提供一种车内通信系统，其包括前述方法的发送端和接收端。
本申请实施例还提供一种车辆，车辆包括至少一个本申请上述实施例提到的发送端和接收端。
在本说明书中使用的术语“部件”、“模块”、“系统”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如，部件可以是但不限于，在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示，在计算设备上运行的应用和计算设备都可以是部件。一个或多个部件可驻留在进程和/或执行线程中，部件可位于一个计算机上和/或分布在两个或更多个计算机之间。此外，这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可例如根据具 有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一部件交互的二个部件的数据，例如通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各种说明性逻辑块(illustrative logical block)和步骤(step)，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生 一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的保护范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (15)

  1. 一种车内通信方法，其特征在于，应用于接收端，包括：
    接收第一消息，所述第一消息包括发送端的发送时间戳；所述发送时间戳是所述发送端为所述第一消息生成的新鲜值；
    根据所述第一消息的接收时间戳和所述发送时间戳，对所述第一消息进行验证。
  2. 根据权利要求1所述的方法，其特征在于，所述发送端的计时器与所述接收端的计时器不进行时间同步的操作。
  3. 根据权利要求1-2任一项所述的方法，其特征在于，所述根据所述接收时间戳和所述发送时间戳，对所述第一消息进行验证，包括：
    在所述发送时间戳等于历史发送时间戳时，根据所述接收时间戳与历史接收时间戳进行验证。
  4. 根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：
    在所述第一消息验证成功后，根据接收到所述第一消息的接收时间戳和所述发送时间戳对第二消息进行验证；所述第二消息为在所述第一消息之后接收到的。
  5. 根据权利要求1-4任一项所述的方法，其特征在于，所述发送端的计时器和所述接收端的计时器与车辆的整车生命周期有关。
  6. 一种车内通信装置，其特征在于，应用于接收端，包括：
    接收单元，用于接收第一消息，所述第一消息包括发送端的发送时间戳；所述发送时间戳是所述发送端为所述第一消息生成的新鲜值；
    处理单元，用于根据所述第一消息的接收时间戳和所述发送时间戳，对所述第一消息进行验证。
  7. 根据权利要求6所述的装置，其特征在于，所述发送端的计时器与所述接收端的计时器不进行时间同步的操作。
  8. 根据权利要求6-7任一项所述的装置，其特征在于，
    所述处理单元，具体用于在所述发送时间戳等于历史发送时间戳时，根据所述接收时间戳与历史接收时间戳进行验证。
  9. 根据权利要求6-8任一项所述的装置，其特征在于，所述处理单元，还用于：
    在所述第一消息验证成功后，根据接收到所述第一消息的接收时间戳和所述发送时间戳对第二消息进行验证；所述第二消息为在所述第一消息之后接收到的。
  10. 根据权利要求6-9任一项所述的装置，其特征在于，所述发送端的计时器和所述接收端的计时器与车辆的整车生命周期有关。
  11. 一种车内通信装置，其特征在于，包括：
    处理器和接口电路；
    其中，所述处理器通过所述接口电路与存储器耦合，所述处理器用于执行所述存储器中的程序代码，以实现如权利要求1至权利要求5中任一项所述的方法。
  12. 一种车辆，其特征在于，所述车辆包括发送端和接收端，所述接收端用于实现如权利要求1至权利要求5中任一项所述的方法。
  13. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，当所述计算机程序被运行时，实现如上述权利要求1至权利要求5中任一项所述的方 法。
  14. 一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，当所述计算机程序被车内通信装置执行时，实现如上述权利要求1至权利要求5中任一项所述的方法。
  15. 一种芯片，其特征在于，包括：处理器，用于调用存储器中存储的计算机程序，以使得该处理器执行所述存储器中的程序代码，以实现如权利要求1至权利要求5中任一项所述的方法。
PCT/CN2021/096507 2021-05-27 2021-05-27 一种车内通信方法及装置 WO2022246760A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202180098686.0A CN117413545A (zh) 2021-05-27 2021-05-27 一种车内通信方法及装置
PCT/CN2021/096507 WO2022246760A1 (zh) 2021-05-27 2021-05-27 一种车内通信方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/096507 WO2022246760A1 (zh) 2021-05-27 2021-05-27 一种车内通信方法及装置

Publications (1)

Publication Number Publication Date
WO2022246760A1 true WO2022246760A1 (zh) 2022-12-01

Family

ID=84229433

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/096507 WO2022246760A1 (zh) 2021-05-27 2021-05-27 一种车内通信方法及装置

Country Status (2)

Country Link
CN (1) CN117413545A (zh)
WO (1) WO2022246760A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109729056A (zh) * 2017-10-30 2019-05-07 北京长城华冠汽车科技股份有限公司 基于车联网的整车网络安全防护方法及整车网络架构
US20200369242A1 (en) * 2018-02-13 2020-11-26 Denso Corporation Electronic control unit and communication system
CN112753203A (zh) * 2020-10-30 2021-05-04 华为技术有限公司 一种安全通信方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109729056A (zh) * 2017-10-30 2019-05-07 北京长城华冠汽车科技股份有限公司 基于车联网的整车网络安全防护方法及整车网络架构
US20200369242A1 (en) * 2018-02-13 2020-11-26 Denso Corporation Electronic control unit and communication system
CN112753203A (zh) * 2020-10-30 2021-05-04 华为技术有限公司 一种安全通信方法及装置

Also Published As

Publication number Publication date
CN117413545A (zh) 2024-01-16

Similar Documents

Publication Publication Date Title
US20230028255A1 (en) Network timing synchronization
US10834207B2 (en) System and method for updating software in an electronic device
US9288048B2 (en) Real-time frame authentication using ID anonymization in automotive networks
CN111917619B (zh) 通信方法、装置、电子设备和可读存储介质
US20230125937A1 (en) Time-based encryption key derivation
US20230318823A1 (en) Vehicle Diagnostic System, Method, and Apparatus
WO2021168859A1 (zh) 一种控制器区域网can总线安全通信方法及装置
KR102450811B1 (ko) 차량 내부 네트워크의 키 관리 시스템
WO2021217263A1 (en) Method and system for establishing trust for a cybersecurity posture of a v2x entity
JP7558276B2 (ja) イーサネット車載ネットワークの時刻同期を安全にする方法
EP4191940A1 (en) In-vehicle network secure communication method, apparatus and device
WO2014147934A1 (ja) 通信装置、通信システム及び通信方法
Rosenstatter et al. Extending AUTOSAR's Counter-Based Solution for Freshness of Authenticated Messages in Vehicles
Püllen et al. Securing FlexRay-based in-vehicle networks
EP4372595A2 (en) Method and system for data exchange on a network to enhance security measures of the network, vehicle comprising such system
WO2022246760A1 (zh) 一种车内通信方法及装置
KR20190070076A (ko) 분산 네트워크 시스템의 전자 제어 장치 및 상기 전자 제어 장치의 분산 합의 프로토콜 방법
Murvay et al. Accommodating time-triggered authentication to FlexRay demands
CN116318896A (zh) 电子控制单元及其控制方法、电子设备和存储介质
CN116232662B (zh) 车内安全通信的计数器主从翻转处理方法
US20230345239A1 (en) Data transmission method and apparatus
CN114760096B (zh) 网络通讯加密策略mac实现方法、系统、发送端及接收端
Giri A dependable and secure approach for secret key establishment and operation in automotive CPS
Schweppe et al. Deliverable d3. 3: Secure on-board protocols specification

Legal Events

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

Ref document number: 21942336

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202180098686.0

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21942336

Country of ref document: EP

Kind code of ref document: A1