Method and apparatus for determining truncation policy of freshness value of secure vehicular communication

Abstract

The present application proposes a method and device for determining a truncation policy of a freshness value used by an electronic control unit (ECU) in a secure in-vehicle communication. The method comprises: determining two ECUs participating in the secure in-vehicle communication; determining a truncation length of the freshness value based on parameters related to attributes of the two ECUs using a deep learning network model; generating a truncated freshness value by truncating the freshness value using the truncation length; and generating a secure protocol data unit (PDU) by filling at least the truncated freshness value after the secure PDU transmitted in the secure in-vehicle communication. The method can make a trade-off and balance between security and communication efficiency, and obtain an optimal truncation length of the freshness value and an optimal truncation policy applied based on the truncation length.

Description

Technical Field

[0001] This application relates to data communications, and more specifically, to methods, apparatus, and computer storage media for determining a truncation strategy for freshness values ​​used by an electronic control unit in secure in-vehicle communications. Background Technology

[0002] With the widespread use of vehicle-to-everything (V2X) communication, the demand for data communication security in vehicles has increased significantly. The Security Onboard Communication (SecOC) module, an independent module within AUTOSAR, introduces communication authentication as a vehicle network security bus solution onto the traditional vehicle CAN bus. It provides a resource-efficient and practical security authentication mechanism at the Protocol Data Unit (PDU) level for vehicle data transmission and interaction.

[0003] Replay attacks are a typical type of attack targeting vehicle communications. Currently, secure communication modes implemented by Electronic Control Units (ECUs) based on the SecOC security mechanism can prevent such attacks by filling PDUs with freshness values. However, due to limitations such as communication bandwidth, freshness values ​​are usually truncated. The truncation length and scheme of the freshness value are generally negotiated and determined by the Original Equipment Manufacturer (OEM) and suppliers based on the overall vehicle design and are fixed for secure communication between all ECUs. A fixed freshness value truncation length cannot balance communication efficiency and security in all situations.

[0004] Therefore, there is a need to improve the truncation length and truncation strategy of freshness values ​​used in vehicular safety communications. Summary of the Invention

[0005] In response to the problems mentioned above, this application proposes a method, apparatus, and computer storage medium for determining a truncation strategy for freshness values ​​used by an ECU in secure in-vehicle communication.

[0006] According to one aspect of this application, a method is proposed for determining a truncation strategy for freshness values ​​used by electronic control units (ECUs) in secure in-vehicle communications, comprising: identifying two ECUs participating in secure in-vehicle communications, the two ECUs including a transmitting ECU and a receiving ECU; determining a truncation length for the freshness value using a deep learning network model based on parameters related to attributes of the two ECUs, wherein the deep learning network model is trained based on historical data of the parameters and the truncation length; generating a truncated freshness value by truncating the freshness value using the truncation length; and generating a secure PDU by at least padding the truncated freshness value after a protected protocol data unit (PDU) transmitted in secure in-vehicle communications.

[0007] According to another aspect of this application, an apparatus is proposed for determining a truncation strategy for an electronic control unit (ECU) used in secure in-vehicle communication, comprising a processor and an executable instruction memory for storing the processor, the processor being configured to execute executable instructions to implement the method described above.

[0008] According to another aspect of this application, a computer-readable storage medium is provided that stores a computer program thereon, the computer program including executable instructions that, when executed by a processor, implement the method described above.

[0009] According to another aspect of this application, a vehicle is proposed that uses the method described above for in-vehicle safety communication.

[0010] By employing the truncation strategy proposed in this application for determining the freshness value used by ECUs in secure in-vehicle communication, the resources of the two ECUs implementing the communication can be fully utilized. A deep learning network model is used to determine the appropriate truncation length for the freshness value for different ECU pairs consisting of sending and receiving ECUs. This truncation length determination method can improve the communication efficiency between ECUs without reducing the vehicle's anti-attack performance, especially its anti-replay attack performance. It strikes a trade-off and balance between security and communication efficiency, obtaining the optimal truncation length for the freshness value and applying the optimal truncation strategy based on that truncation length. Attached Figure Description

[0011] The above and other features and advantages of this application will become more apparent from a detailed description of exemplary embodiments thereof with reference to the accompanying drawings.

[0012] Figure 1 This is a schematic flowchart of a method for determining a truncation strategy for a freshness value used by an ECU in secure in-vehicle communication, according to an embodiment of this application.

[0013] Figure 2This is a schematic distribution of the ECU communication cluster implementing the SecOC security mechanism in a vehicle according to an embodiment of this application.

[0014] Figure 3 The data composition structure for freshness values ​​according to embodiments of this application.

[0015] Figure 4 This is a schematic diagram of the message frame structure of a security protocol data unit according to an embodiment of this application.

[0016] Figure 5 This is an exemplary structure of a deep learning network model according to an embodiment of this application.

[0017] Figure 6 This is a schematic structural block diagram of an electronic device for determining a truncation strategy for freshness values ​​used by an ECU in secure in-vehicle communication, according to an embodiment of this application. Detailed Implementation

[0018] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided to make the content of this application comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. In the drawings, the dimensions of some elements may be exaggerated or modified for clarity. The same reference numerals in the drawings denote the same or similar structures, and therefore their detailed description will be omitted.

[0019] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a full understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details described, or other methods, elements, etc., can be employed. In other instances, well-known structures, methods, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0020] As mentioned above, the purpose of the SecOC module is to provide communication authentication for vehicular network security, offering a resource-efficient and practical security authentication mechanism for data transmission and interaction at the Protocol Data Unit (PDU) level. The SecOC module can authenticate data transmitted within the SecOC security mechanism, effectively detecting attacks such as data replay, spoofing, and tampering. In a layered network architecture, each layer of the network transmission system establishes a PDU, which includes information from the upper layer and additional information from entities in the current layer. After adding this information, the PDU is transmitted to the next layer to extract relevant information and data. For example, the SecOC security mechanism can use a MAC (Message Authentication Code) as a authenticator to achieve identity authentication and prevent bus data from being tampered with.

[0021] Replay attacks, also known as replay attacks or rewind attacks, refer to an attacker sending a data packet that the receiver has already received to achieve a deceptive purpose. Replay attacks can compromise the correctness of authentication processes, eavesdrop on data transmission, or use forged data instead of correct data. Replay attacks can be carried out by the packet initiator or by an attacker who intercepts and retransmits the packet. For example, during authentication, an attacker might steal authentication credentials through network eavesdropping or other means and then resend them to the authentication server. Transmitted data is usually encrypted, but if an eavesdropper knows the packet definition, they can mislead the receiver by retransmitting the data without knowing its specific content. For example, a data transmission system might encrypt authentication information or transmitted data before transmission. While an attacker cannot eavesdrop on the password, they can intercept the encrypted password and replay it, causing the receiver to respond with the forged data packet and send data to the attacker.

[0022] Defenses against replay attacks include adding specific supplementary data for authentication and encryption to the transmitted data packets (e.g., PDUs) according to rules pre-agreed upon by the receiver and sender. This specific supplementary data may include, for example: 1) a random number (a pre-agreed, stored random number between the receiver and sender); 2) a timestamp (requiring accurate time synchronization between the receiver and sender); and 3) a counter (e.g., an incrementing integer). According to embodiments of this application, the specific supplementary data used to resist replay attacks generally employs data related to 2) and 3).

[0023] To prevent replay attacks on data transmission in secure in-vehicle communication on the CAN bus, the SecOC security mechanism introduces the concept of Freshness Value (FV). Complex encryption algorithms require significant computational resources and data bandwidth for encryption and decryption, while setting a Freshness Value allows for a trade-off between performance and security, effectively improving bus security to some extent. Therefore, it is primarily used to combat replay attacks.

[0024] There are three main ways to use freshness values: 1) Signal Counter; 2) Timestamp; and 3) Multiple Freshness Counters. Typically, the multiple freshness counter (3) is used to generate the freshness value. The multiple freshness value represents the real-time nature of the information and is generated through two modes: timestamp verification and frame counter verification. The timestamp verification requires accurate time synchronization between the two ECUs involved in vehicle safety communication.

[0025] Figure 3 This illustrates an exemplary data structure for the freshness value. From the most significant bit (MSB) to the least significant bit (LSB), the freshness value FV 300 is composed of the values ​​of the Trip Counter 301, Reset Counter 302, Message Counter 303, and Reset Flag 304. These data values ​​are a total of 8 bytes (64 bits / bit), with the Reset Flag 304 typically being 1 bit. The Trip Counter 301 is an incrementing counter, initially set to 0, and increments during power-on, wake-up, and other operations. When the Trip Counter 301 increments, the Reset Counter 302 is cleared. The Reset Counter 302 is monotonically incrementing, representing a period set according to the application scenario. When the Reset Counter 302 increments, the Message Counter 303 is cleared. The Message Counter 303 is monotonically incrementing; it increments by 1 for each data packet sent by the sending ECU or master ECU. The reset bit 304 is used to synchronize the value of the reset counter 302 from the sending ECU or the master ECU in real time.

[0026] It's important to note that secure data transmission in the SecOC security mechanism occurs between two or more ECUs, acting as both sender and receiver. In Master-Slave mode, these ECUs are also referred to as slave ECUs. In Master-Slave mode, the master ECU updates settings such as freshness values ​​by sending synchronization messages to the two or more slave ECUs involved in the data transmission. In this mode, the master ECU acts as the security mechanism setter for secure data communication within the SecOC security mechanism. In non-Master-Slave mode, the sender ECU sends synchronization messages to the receiver ECU to transmit settings such as freshness values. In this mode, the sender ECU acts as the security mechanism setter for secure data communication within the SecOC security mechanism. Although data transmission in secure in-vehicle communication can involve two or more ECUs, for each data transmission, the participating ECUs are generally two ECUs (also called an ECU pair): a sender ECU and a receiver ECU (the slave ECU is also divided into a sender ECU and a receiver ECU in a single data transmission). Therefore, the freshness value corresponds to the two ECUs or ECU pairs involved in the data transmission.

[0027] During the synchronization process, the sending ECU or master ECU sends the new synchronization counter and reset counter values ​​in the synchronization message to the receiving ECU or slave ECU. After receiving the synchronization message, the receiving ECU or slave ECU stores and updates the values ​​of these two counters and counts based on the reset counter during the secure communication transmission.

[0028] The SecOC security mechanism uses a Secure PDU (Secured PDU) message frame structure during data transmission. A Secure PDU, from its most significant bit (MSB) to its least significant bit (LSB), includes an optional Secure PDU header, a protected authentic PDU, an optional freshness value, and an authenticator. The protected PDU is the PDU data that needs to be protected against replay attacks in secure in-vehicle communication. Filling the Secure PDU with a freshness value prevents PDU data from being stolen and forged, thereby improving security.

[0029] Those skilled in the art recognize that excessively long data lengths in secure PDU message frames lead to wasted communication resources and decreased communication efficiency. Therefore, it is necessary to shorten the length of secure PDU message frames as much as possible while ensuring sufficient security performance. This is typically achieved by truncating the freshness value and / or validator value data to shorten the overall data length of the secure PDU message frame.

[0030] When truncating the freshness value, the low-order part of the message counter or data of a set length truncated from the least significant bit (LSB) can be used as part of the truncated freshness value. This truncated freshness value is then added to the reset bit value and filled into the protected PDU. The truncated freshness value is generally appended to the end of the protected PDU. Other contents and information in the freshness value are not visible to the receiving ECU or slave ECU in the received protected PDU. In the SecOC safety mechanism vehicle communication message frame data structure, the synchronization counter and reset counter data are transmitted through synchronization messages. Therefore, synchronization messages ensure the consistency of the freshness value (FV) information at both the sending and receiving ECUs.

[0031] In vehicular communication using the SecOC security mechanism, Message Authentication Code (MAC) authentication is employed. The MAC calculated using the AES-128 CMAC algorithm can be used as the verifier's value. When truncating the verifier's value, such as... Figure 4 As shown, the validator value 420 is truncated from its most significant bit (MSB) to a calculated or preset validator truncation length, and this truncated validator value 421 is then filled into the protected PDU. The truncated validator value 421 is typically appended to the truncated freshness value. The remaining low-order bits 422 in the validator are discarded. The truncation length and truncation strategy for the validator are not discussed in detail herein.

[0032] Therefore, one of the key aspects of balancing security and communication efficiency lies in obtaining the optimal truncation length for freshness values ​​and applying the optimal truncation strategy based on that truncation length. An excessively long truncation length for freshness values ​​leads to wasted communication resources and reduced communication efficiency, while an excessively short truncation length negatively impacts security performance against replay attacks. Currently, the truncation length and strategy for freshness values ​​are generally determined by OEMs and suppliers based on the overall vehicle design and the CPU resources of each ECU, and these truncation lengths and strategies are fixed for all ECUs. This application aims to provide a better truncation length and strategy for freshness values, particularly providing a variable truncation length and strategy for the two ECUs involved in secure in-vehicle communication data transmission, achieving optimal system performance.

[0033] The following will be combined with the appendix Figure 1 This application describes a system flow for determining the truncation length and truncation strategy of a freshness value used by an ECU in secure in-vehicle communication, according to embodiments of the present application.

[0034] The process mainly includes step S110 of determining the sending ECU and receiving ECU participating in the safe vehicle communication, step S120 of determining the truncation length of the freshness value using a deep learning network model based on the attribute-related parameters of the two ECUs, step S130 of generating the truncated freshness value based on the determined truncation length, and step S140 of generating a safe PDU by at least filling the truncated freshness value after the transmitted protected PDU.

[0035] First, step S110 identifies an ECU pair consisting of two ECUs participating in secure in-vehicle communication. For example... Figure 2 As shown, a vehicle architecture implementing the SecOC safety mechanism may contain multiple ECUs performing different functions. These ECUs are grouped into different groups in the form of ECU communication clusters according to their implemented functions and the relevance and scope of data communication. The number of ECUs contained in each ECU communication cluster may be the same or different. For example, Figure 2ECUs 210 and 220 form ECU communication cluster 200-1 for the SecOC security mechanism, ECUs 230 and 250 form ECU communication cluster 200-2, and ECUs 230, ECU 240, and ECU 260 form ECU communication cluster 200-3. According to embodiments of this application, a truncation strategy for freshness values ​​is determined only for secure in-vehicle communication between ECU pairs belonging to the same communication cluster. Since there is no need for secure data communication between ECUs belonging to different communication clusters, a truncation strategy for freshness values ​​between these ECUs is not required. Different truncation lengths and strategies for freshness values ​​can be determined for each ECU pair with different ECUs that have in-vehicle secure communication needs, or a uniform truncation length and strategy can be determined for all ECUs within each ECU communication cluster. For example, when secure in-vehicle data communication occurs between any two ECUs, one ECU is the sending ECU and the other is the receiving ECU, and they implement data transmission such as unicast, a specific truncation strategy for freshness values ​​can be determined for this unicast data transmission. When safe in-vehicle data communication involves one ECU and multiple other ECUs, the single ECU is the sending ECU, and the other ECUs are the receiving ECUs. These ECUs implement data transmission methods such as multicast. Therefore, a uniform freshness value truncation strategy can be determined for this multicast data transmission, or a specific freshness value truncation strategy can be determined between the sending ECU and each receiving ECU. The freshness value truncation strategy can be distinguished by the IDs of the ECUs participating in the safe in-vehicle communication. It is understood that in safe in-vehicle communication between two ECUs, regardless of which ECU acts as the sending ECU and the other as the receiving ECU, the truncation length and strategy for the freshness value determined for both ECUs are the same. The following section uses ECUs 210 and 220 in ECU communication cluster 200-1 as examples to illustrate the technical details of calculating the optimal freshness value truncation length and strategy.

[0036] Step S120 is used to determine the truncation length of the freshness values ​​used by the two ECUs participating in the secure communication based on their attributes. Parameters associated with the attributes include load and payload parameters of the sending ECU 210, load and payload parameters of the receiving ECU 220, and other communication efficiency parameters associated with their secure in-vehicle communication.

[0037] Parameters related to the attributes of the sending and receiving ECUs include ECU processing performance, memory capacity, communication bandwidth, and data frame size. Other communication efficiency parameters associated with secure in-vehicle communication between the two ECUs include vehicle system design and performance requirements. These parameters determine the range of truncated freshness values ​​that can be supported for secure data communication between the two ECUs, the optimal truncation length, and the truncation strategy.

[0038] This application also uses a deep learning network model to determine the truncation length of the freshness value used by the ECU based on these parameters. The input to the deep learning network model includes a multidimensional input X. n .exist Figure 5 In the example shown, the multidimensional input X n This includes at least the load parameters X1 of the sending ECU 210, the load parameters X2 of the receiving ECU 220, the payload parameters X3 of the sending ECU 210, the payload parameters X4 of the receiving ECU 220, and the communication efficiency parameters X5 related to safe in-vehicle communication. The output of the deep learning network model is Y(x), which takes the form of a truncation length and its probability that can be used for the freshness value of the ECU pair composed of ECUs 210 and 220. The truncation length or the weighted value (integer) of the truncation length with the highest probability value or weighted probability value can be used as the final output Y determined and predicted by the deep learning network model, i.e., the optimal truncation length for the freshness value. The predicted final output can be labeled using the ID combination of the ECU pair. For example, if the labels of ECUs 210 and 220 are a and b respectively, then the optimal truncation length determined and predicted for them can be used using Y. ab This indicates that, according to embodiments of this application, the data in each dimension of the input and output of the deep learning network model can be scalars.

[0039] The size of the input, hidden, and output layers of a deep learning network model, as well as the scale of each layer (e.g., size, number of layers), is correlated with the number of ECUs involved in safe in-vehicle communication and the complexity of the features extracted from these multidimensional inputs. Figure 5 In the example, the network model has two hidden layers.

[0040] The loss function or constraints of the deep learning network model are set based on the requirements of performance against replay attacks and / or communication efficiency in secure in-vehicle communication. For example, the loss function or constraints may be optimal performance against replay attacks or no less than a security performance threshold, and / or optimal communication efficiency between ECUs or no less than a communication efficiency threshold, and / or a truncation length of the freshness value greater than or equal to a minimum length threshold (e.g., 8 bits). Specifically, the loss function can be further set such that, while satisfying that the truncation length of the freshness value is no less than the minimum length threshold, the mean squared error of the communication efficiency between ECUs is lower than a mean squared error threshold.

[0041] Before use, deep learning network models need to be trained on a training dataset consisting of historical data on ECU attribute parameters and / or truncation lengths for freshness values ​​used in safe in-vehicle communication to determine optimal model parameters. The training process is conducted offline. Offline training not only means that the model is trained offline based on historical data before determining and predicting truncation lengths for safe communication between two specific ECUs, rather than predicting in real-time online, but also that the training process is performed on a server / data processor not deployed on the vehicle or located away from the vehicle, or on a server / data processor located at the equipment manufacturer or supplier, while the trained network model is deployed on the vehicle. Alternatively, the deep learning network model may not be deployed on the vehicle but on a server or data processor located away from the vehicle, in which case the training of the network model and the prediction and determination of truncation strategies for each ECU pair or each ECU communication cluster are completed outside the vehicle, and the vehicle only stores the determined truncation strategies for various freshness values. According to embodiments of this application, a deep learning network model can also be installed in the vehicle as part of a safety module or processor of the in-vehicle equipment. Based on historical data, the truncation length and strategy for the optimal freshness value of each ECU pair or ECU communication cluster are calculated and predicted in advance, and used during secure in-vehicle communication between the ECU pairs. The parameters of the deep learning network model can be trained or updated offline at set intervals or as needed.

[0042] In the learning process of deep learning network models, both validated and unvalidated training datasets can be used. When using unvalidated historical data as a training dataset, for example, a deep learning network model that supports unsupervised learning can be employed. This eliminates the need for validation of the training dataset and allows direct use of the network model's inputs (e.g., the truncated parameters related to the ECU's attributes and / or the truncation length of the freshness value mentioned above) for model building, training, and parameter optimization. Deep learning network models can also be further enhanced using reinforcement learning networks.

[0043] The trained deep learning network model continuously optimizes the network model to achieve the best communication efficiency without affecting the performance against replay attacks (e.g., by choosing a freshness value truncation length of no less than 8 bits). Finally, it outputs the optimal freshness value truncation length.

[0044] In step S130, the freshness value is truncated based on the optimal truncation length predicted by the network model, generating a truncated freshness value. Returning to... Figure 3 The diagram illustrates the truncated freshness value 306, extracted from freshness value 300 using a determined optimal truncation length to fill the protected PDU. The optimal truncation length predicted by the network model is denoted as L. Based on the freshness value truncation setting, data of length L needs to be truncated from the least significant bit (LSB) of freshness value 300 to form the truncated freshness value 306. Specifically, freshness value 300 consists of, starting from the LSB, a reset bit 304, a message counter 303, a reset counter 302, and a synchronization counter 301. The data length of reset bit 304 is, for example, 1 bit. Since the requirement for anti-replay attack performance is that the truncation length of the freshness value be no less than 8 bits, the truncated freshness value 306 includes not only the reset bit 304 but also a portion of data truncated from the LSB of message counter 303, which is the high-order data portion shown in 305. The length of the high-order data portion 305 of the truncated freshness value 306 is called the message counter truncation length L', where L' = L - the data length (bits) of the reset bit 304.

[0045] Next, in step S140, after filling the protected PDU with the truncated freshness value, a secure PDU is generated. Figure 4 This illustrates the specific method for generating a secure PDU. The secure PDU 400 includes a protected PDU 430, followed by a truncated freshness value 411 and a truncated validator value 421. Figure 3 The truncation strategy for the freshness value shown is similar. Freshness value 410 truncates data of length L starting from the least significant bit (LSB) and uses this data as the truncated freshness value portion in the secure PDU. The remaining truncated high-order data portion 412 in freshness value 410 is discarded. Following the truncated freshness value 411, secure PDU 400 also includes a truncated validator value 421 from validator value 420. Validator value 420 truncates data of a preset validator truncation length starting from the most significant bit (MSB) and uses this data as the truncated validator value portion in the secure PDU. The remaining truncated low-order data portion 422 in validator value 420 is discarded.

[0046] The secure PDU generated through the above process is applied to secure in-vehicle communication between ECU 210 and ECU 220 and configured with corresponding parameters to achieve a trade-off and optimal match between replay attack resistance and communication efficiency between ECUs with secure communication requirements. For all ECUs in the vehicle, this can be used... Figure 1 The method described above determines the optimal truncation length and strategy for freshness values ​​to be used in communication.

[0047] Embodiments of this application also provide vehicles capable of generating secure PDUs for use in secure in-vehicle communication data transmission using a truncation length and truncation strategy determined by the freshness value as described above.

[0048] By employing the truncation strategy proposed in this application for determining the freshness value used by ECUs in secure in-vehicle communication, the resources of the two ECUs implementing the communication can be fully utilized. A deep learning network model is used to determine the appropriate truncation length for the freshness value for different ECU pairs consisting of sending and receiving ECUs. This truncation length determination method can improve the communication efficiency between ECUs without reducing the vehicle's anti-attack performance, especially its anti-replay attack performance. It strikes a trade-off and balance between security and communication efficiency, obtaining the optimal truncation length for the freshness value and applying the optimal truncation strategy based on that truncation length.

[0049] In exemplary embodiments of this application, a computer-readable storage medium is also provided, having stored thereon a computer program including executable instructions that, when executed by, for example, a processor, can implement the steps of the method for determining a truncation strategy for a freshness value used by an ECU in safe in-vehicle communication as described in any of the above embodiments. In some possible implementations, various aspects of this application can also be implemented as a program product including program code that, when run on a terminal device, causes the terminal device to perform the steps described in the various exemplary embodiments of this application in the method for determining a truncation strategy for a freshness value used by an ECU in safe in-vehicle communication.

[0050] The program product for implementing the above-described method according to embodiments of this application may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of this application is not limited thereto. In this document, a readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0051] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0052] The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0053] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0054] In an exemplary embodiment of this application, an electronic device is also provided, which may include a processor and a memory for storing executable instructions of the processor. The processor is configured to perform steps of the method for determining a truncation strategy for a freshness value used by an ECU in secure in-vehicle communication, as described in any of the above embodiments, by executing the executable instructions.

[0055] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0056] The following reference Figure 6 To describe an electronic device 600 according to this embodiment of the present application. Figure 6 The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0057] like Figure 6 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0058] The storage unit stores program code that can be executed by the processing unit 610, causing the processing unit 610 to perform the steps described in the method for determining the truncation strategy of freshness values ​​used by an ECU in safe in-vehicle communication, according to various exemplary embodiments of this application. For example, the processing unit 610 can perform actions such as... Figure 1 The steps are shown in the figure.

[0059] The storage unit 620 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 6201 and / or a cache storage unit 6202, and may further include a read-only memory unit (ROM) 6203.

[0060] The storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0061] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0062] Electronic device 600 can also communicate with one or more external devices 700 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0063] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the truncation strategy for determining the freshness value used by the ECU in safe in-vehicle communication according to the embodiments of this application.

[0064] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the appended claims.

Claims

1. A method for determining a truncation strategy for freshness values ​​used by an electronic control unit (ECU) in secure in-vehicle communication, comprising: Two ECUs are identified to participate in the secure in-vehicle communication, the two ECUs including a sending ECU and a receiving ECU; The truncation length of the freshness value is determined using a deep learning network model based on parameters related to the attributes of the two ECUs, wherein the deep learning network model is trained based on historical data of the parameters and the truncation length. A truncated freshness value is generated by truncating the freshness value using the truncated length. A secure PDU is generated by filling in at least the truncated freshness value after the protected protocol data unit (PDU) transmitted in the secure in-vehicle communication. The parameters include the load parameters and payload parameters of the sending ECU, the load parameters and payload parameters of the receiving ECU, and the communication efficiency parameters related to the secure vehicle communication.

2. The method according to claim 1, characterized in that, The load parameters and payload parameters of the sending ECU and the receiving ECU are respectively related to at least one of the processing performance, memory capacity, communication bandwidth and data frame size of the sending ECU and the receiving ECU, and the communication efficiency parameter is related to the design and performance requirements of the vehicle.

3. The method according to claim 2, characterized in that, The input to the deep learning network model is the parameters, and the output of the deep learning network model is the truncation length that enables the secure vehicle communication to meet the requirements related to anti-replay attack performance and / or communication efficiency.

4. The method according to claim 3, characterized in that, The deep learning network model is an unsupervised reinforcement learning network.

5. The method according to claim 1, characterized in that, The freshness value includes at least a message counter value and a reset bit value. Generating a truncated freshness value by truncating the freshness value using the truncation length includes: The first truncated data is the data truncated from the least significant bit of the message counter value, where the message counter truncated length is the truncated length minus the data length of the reset bit value. The truncated freshness value is generated by combining the first truncated data and the reset bit value.

6. The method according to claim 1, characterized in that, Generating a secure PDU by filling in at least the truncated freshness value after the protected protocol data unit (PDU) transmitted in the secure vehicle communication includes: The secure PDU is generated by filling the protected protocol data unit (PDU) with the truncated freshness value and the truncated validator value.

7. The method according to claim 1, characterized in that, The two ECUs belong to the same ECU communication cluster, which is located in the vehicle implementing the secure in-vehicle communication and includes at least the two ECUs.

8. The method according to claim 7, characterized in that, The freshness value is updated via a synchronization message sent by the sending ECU to the receiving ECU, or via a synchronization message sent by the master ECU in the ECU communication cluster that manages the sending ECU and the receiving ECU.

9. The method according to claim 7, characterized in that, An ECU pair consisting of any two ECUs in the ECU communication cluster has a different cutoff length.

10. The method according to claim 9, characterized in that, The different truncation lengths are determined based on the same trained deep learning network model.

11. The method according to claim 9, characterized in that, Different cutoff lengths are determined using different deep learning network models, which are trained based on the parameters of the ECUs in the corresponding ECU pair and historical data of the cutoff length.

12. An apparatus for determining a truncation strategy for freshness values ​​used by an electronic control unit (ECU) in secure in-vehicle communications, comprising: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the executable instructions to implement the method according to any one of claims 1 to 11.

13. A computer-readable storage medium having a computer program stored thereon, the computer program including executable instructions that, when executed by a processor, implement the method according to any one of claims 1 to 11.

14. A vehicle that performs in-vehicle security communication using the method according to any one of claims 1 to 11.

Images