Lightweight secoc authentication method, device, system and electronic equipment

Abstract

The application provides a lightweight SecOC authentication method, device, system and electronic equipment, and belongs to the field of automobile electronics. The method comprises the following steps: in the process of receiving a SecOC protected message sent by a sending node, a local authentication tag is generated based on a data field of each received SecOC protected message, and a final local authentication tag is generated based on each generated local authentication tag; the SecOC protected message is authenticated based on the final local authentication tag; the message is obtained by the sending node based on the following steps: a journey count value used for representing a vehicle running cycle is spliced with a scheduling table count value used for representing a message sending sequence to obtain a freshness value; and a SecOC protected message is generated based on a PDU payload, PDU data and the freshness value of the to-be-sent message. The application can solve the problems of large communication load overhead and processor load overhead and long authentication delay.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics technology, specifically to a lightweight SecOC certification method, apparatus, system, and electronic device. Background Technology

[0002] As automotive electronic and electrical architectures gradually evolve towards domain-centralized and central computing architectures, the number of interconnected electronic control units (ECUs) in the vehicle network continues to increase. The authenticity, integrity, and anti-replay capability of in-vehicle communication messages have become important safeguards for vehicle network security.

[0003] The AUTOSAR SecOC (Secure Onboard Communication) mechanism protects message integrity and prevents replay attacks by adding Message Authentication Code (MAC) and Freshness Value (FV) to the message. It is now widely used for secure communication between controllers in the powertrain domain, chassis domain, body domain, and intelligent driving domain.

[0004] Existing SecOC schemes typically use the AES-128-CMAC algorithm to generate authentication tags and combine them with an independent freshness counter to achieve message authentication. Their security capabilities mainly rely on the joint verification mechanism of the Freshness Value and the Message Authentication Code (MAC).

[0005] In the existing solution, the sending end needs to maintain a continuously increasing freshness counter and participate in the authentication calculation with the complete freshness value; the receiving end, on the other hand, needs to accurately recover the corresponding freshness value before it can complete the authentication verification. Therefore, as the system runtime increases, the length of the freshness value continues to increase, and the communication load continues to rise.

[0006] In addition, the existing SecOC authentication process typically adopts a serial processing mode of "receiving the complete message → restoring the freshness value → performing authentication calculation → determining the authentication result", which means that the authentication calculation and message reception processes cannot be executed in an overlapping manner, thereby increasing authentication latency and processor load.

[0007] Therefore, the existing SecOC solution suffers from significant communication and processor overhead, as well as long authentication latency in resource-constrained vehicle nodes. Summary of the Invention

[0008] In view of this, it is necessary to provide a lightweight SecOC authentication method, device, system and electronic device to solve the technical problems of large communication load and processor load and long authentication latency in resource-constrained vehicle nodes in existing SecOC schemes.

[0009] To address the aforementioned problems, in a first aspect, the present invention provides a lightweight SecOC authentication method, comprising: During the process of receiving SecOC protection messages sent by the sending node, a local authentication tag is generated based on the data field of each SecOC protection message received, and a final local authentication tag is generated based on the local authentication tag generated each time. The SecOC protected message is authenticated based on the final local authentication tag. The SecOC protection message is obtained by the sending node based on the following steps: The freshness value is obtained by concatenating the trip count value, which represents the vehicle's operating cycle, with the scheduling table count value, which represents the message sending order. A SecOC protection message is generated based on the PDU payload, PDU data, and freshness value of the message to be sent.

[0010] In one possible implementation, the SecOC protected message is authenticated based on the final local authentication tag, including: A data receiving window is constructed based on a preset freshness reference value; If the freshness value of the SecOC protection message is within the data receiving window range, the SecOC protection message is authenticated based on the final local authentication tag and the receiving authentication tag in the SecOC protection message. The freshness reference value is updated based on the freshness value in the current SecOC protection message, and the data receiving window is updated based on the updated freshness reference value.

[0011] In one possible implementation, the maximum value of the data receiving window is the sum of the freshness reference value and a preset allowed window size, and the minimum value of the data receiving window is the freshness reference value.

[0012] In one possible implementation, authenticating the SecOC protected message based on the final local authentication tag further includes: If the freshness value of the SecOC protection message is less than the freshness reference value, and the difference between the freshness reference value and the freshness value is less than or equal to a preset allowed window size, the SecOC protection message is authenticated based on the final local authentication tag and the receive authentication tag in the SecOC protection message.

[0013] In one possible implementation, the lightweight SecOC authentication method also includes: If the freshness value of the SecOC protection message is less than the difference between the freshness reference value and the preset allowed window size, or if the freshness value is greater than the sum of the freshness reference value and the preset allowed window size, the SecOC protection message is rejected from the network application layer.

[0014] In one possible implementation, a SecOC protection message is generated based on the PDU payload, PDU data, and the freshness value of the message to be sent, including: Based on the PDU payload of the message to be sent and the freshness value, generate a SecOC authentication code; The PDU data, the freshness value, and the SecOC authentication code are encapsulated to form a SecOC protection message.

[0015] In one possible implementation, a SecOC authentication code is generated based on the PDU payload of the message to be sent and the freshness value, including: Based on the PDU payload of the message to be sent and the freshness value, an authentication data block is obtained by splicing them together; Using the key pre-shared during initialization as the authentication key, an authentication operation is performed on the authentication data block to generate an authentication tag; Based on bus bandwidth requirements, the authentication tag is truncated, and a SecOC authentication code is generated based on the truncated authentication tag.

[0016] Secondly, the present invention also provides a lightweight SecOC authentication device, comprising: The authentication tag generation module is used to generate a local authentication tag based on the data field of each SecOC protection message received during the process of receiving SecOC protection messages sent by the sending node, and to generate the final local authentication tag based on the local authentication tag generated each time. The message authentication module is used to authenticate the SecOC protected message based on the final local authentication tag; The SecOC protection message is obtained by the sending node based on the following steps: The freshness value is obtained by concatenating the trip count value, which represents the vehicle's operating cycle, with the scheduling table count value, which represents the message sending order. A SecOC protection message is generated based on the PDU payload, PDU data, and freshness value of the message to be sent.

[0017] Thirdly, the present invention also provides an electronic device, including a memory and a processor, wherein, The memory is used to store programs; The processor, coupled to the memory, is configured to execute the program stored in the memory to implement the steps of the lightweight SecOC authentication method as described in any of the preceding claims.

[0018] Fourthly, the present invention also provides a lightweight SecOC authentication system, including the aforementioned electronic device and a transmitting node communicatively connected to the electronic device.

[0019] The beneficial effects of the above implementation are as follows: The lightweight SecOC authentication method, apparatus, system, and electronic device provided by the present invention, in the process of receiving SecOC protection messages sent by the sending node, generates a local authentication tag based on the data field of each SecOC protection message received, and generates a final local authentication tag based on the generated local authentication tag each time; and authenticates the SecOC protection message based on the final local authentication tag; wherein, the SecOC protection message is obtained by the sending node based on the following steps: concatenating the trip count value used to characterize the vehicle operation cycle with the scheduling table count value used to characterize the message sending order to obtain a freshness value; and generating a SecOC protection message based on the PDU payload, PDU data, and the freshness value of the message to be sent.

[0020] In this invention, the freshness value in the messages sent by the sending node is obtained by concatenating the trip count value, which represents the vehicle's operating cycle, and the scheduling table count value, which represents the message sending order. Through a two-dimensional timing information construction mechanism, the receiving end can complete the timing validity judgment only by relying on the operating cycle information and message order information, thereby reducing the complexity of state synchronization. Moreover, the freshness structure adopted in this invention is compact, reducing the length of the SecOC additional field and thus reducing communication overhead.

[0021] Furthermore, in this invention, the receiving node generates a local authentication tag each time it receives a data field from a message. Once message reception is complete, only final state convergence is required to obtain the authentication result. This transforms the SecOC authentication execution architecture from a serial to a pipelined model, reducing authentication latency, improving processing efficiency, and lowering processor overhead. Therefore, this invention solves the technical problems of existing SecOC solutions in resource-constrained vehicle-mounted nodes, which suffer from high communication and processor load overhead and long authentication latency. Attached Figure Description

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

[0023] Figure 1 A flowchart of an embodiment of the lightweight SecOC authentication method provided by the present invention; Figure 2 A schematic block diagram of an embodiment of the lightweight SecOC authentication device provided by the present invention; Figure 3 A schematic diagram of an embodiment of the lightweight SecOC authentication system provided by the present invention; Figure 4 A flowchart for generating the authentication label provided by this invention; Figure 5 The authentication and verification flowchart provided by this invention; Figure 6 A schematic diagram of an embodiment of the electronic device provided by the present invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0025] In the description of the embodiments of this application, unless otherwise stated, "a plurality of" means two or more.

[0026] In this embodiment of the invention, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, apparatus, product or device that includes a series of steps or modules is not necessarily limited to those steps or modules that are explicitly listed, but may include other steps or modules that are not explicitly listed or that are inherent to such process, method, product or device.

[0027] The naming or numbering of steps in the embodiments of the present invention does not mean that the steps in the method flow must be executed in the time / logical order indicated by the naming or numbering. The execution order of the named or numbered process steps can be changed according to the technical purpose to be achieved, as long as the same or similar technical effect can be achieved.

[0028] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0029] This invention provides a lightweight SecOC authentication method, apparatus, system, and electronic device, which are described below.

[0030] This invention provides a lightweight SecOC authentication method, which is implemented by executing an application on the receiving node; such as Figure 1 As shown, the method includes: S101. During the process of receiving SecOC protection messages sent by the sending node, a local authentication tag is generated based on the data field of each SecOC protection message received, and a final local authentication tag is generated based on the local authentication tag generated each time.

[0031] Understandably, unlike traditional SecOC which initiates authentication calculation after fully receiving the message, this invention employs a pre-calculation mechanism for the authentication state. The receiving node synchronously initiates authentication state calculation during the reception of SecOC messages. Each time a data field is received, the current authentication state is updated using the received data, and the authentication state continuously progresses as the message reception process continues.

[0032] Once the last data field has been received, there is no need to re-execute the full authentication calculation; only final state convergence is required to generate a local authentication tag. Therefore, the authentication calculation process and the message reception process are executed in parallel, transforming the authentication execution architecture from serial processing to pipelined processing. After message reception is complete, a local authentication tag is generated based on the final authentication state.

[0033] It should be noted that the local authentication label is a verification value generated by an algorithm.

[0034] S102. Authenticate the SecOC protection message based on the final local authentication tag; The SecOC protection message is obtained by the sending node based on the following steps: The freshness value is obtained by concatenating the trip count value, which represents the vehicle's operating cycle, with the scheduling table count value, which represents the message sending order. A SecOC protection message is generated based on the PDU payload, PDU data, and freshness value of the message to be sent.

[0035] It is understandable that when authenticating the SecOC protection message, the final local authentication tag can be compared with the authentication tag (i.e., the receive authentication tag) carried in the SecOC protection message. If the two match, the authentication is successful.

[0036] The sending node reads the current trip count value. The trip counter increments by 1 when the vehicle enters the running state from the off state and is saved to non-volatile memory.

[0037] The sending node obtains the scheduling table count value corresponding to the current message. Within the same vehicle operation cycle, the scheduling table count value is incremented once for each target message sent. The scheduling table count value is used to reflect the order in which messages are sent within the current operation cycle.

[0038] The freshness value is formed by concatenating the low-order field of the trip counter with the high-order field of the schedule table counter in a predetermined order.

[0039] In some embodiments, authentication of the SecOC protected message is performed based on the final local authentication tag, including: A data receiving window is constructed based on a preset freshness reference value; If the freshness value of the SecOC protection message is within the data receiving window range, the SecOC protection message is authenticated based on the final local authentication tag and the receiving authentication tag in the SecOC protection message. The freshness reference value is updated based on the freshness value in the current SecOC protection message, and the data receiving window is updated based on the updated freshness reference value.

[0040] Understandably, a receiving window is established based on a freshness reference value, and the validity of the received freshness value is judged. When the freshness value is within the window range, it is allowed to enter the authentication process; when it exceeds the window range, it is judged as an abnormal message or a potential replay message.

[0041] The updated freshness reference value updates the data receiving window, and the updated data receiving window will be used the next time a message is authenticated.

[0042] In some embodiments, the maximum value of the data receiving window is the sum of the freshness reference value and a preset allowed window size, and the minimum value of the data receiving window is the freshness reference value.

[0043] It can be understood that, given the current reference freshness value is Fcurrent, the freshness value of the received message is Frecv, and the allowable window size is W. When Fcurrent ≤ Frecv ≤ Fcurrent + W, the message is determined to be within the valid window and allowed to enter the authentication process. The local authentication tag is compared with the received authentication tag, if they match, the message is allowed to enter the application layer; otherwise, the message is rejected, and the reference value is updated to Frecv.

[0044] In some embodiments, authenticating the SecOC-protected message based on the final local authentication tag further comprises: In a case where the freshness value of the SecOC-protected message is less than the freshness reference value, and the difference between the freshness reference value and the freshness value is less than or equal to a preset allowable window size, authenticating the SecOC-protected message based on the final local authentication tag and the received authentication tag in the SecOC-protected message.

[0045] It can be understood that, the current reference freshness value is Fcurrent, the freshness value of the received message is Frecv, and the allowable window size is W. When Frecv < Fcurrent and Fcurrent - Frecv ≤ W, the message is determined to be an out-of-order or delayed message within the window, and allowed to enter the authentication process. The local authentication tag is compared with the received authentication tag, if they match, the message is allowed to enter the application layer; otherwise, the message is rejected, and the reference value remains unchanged.

[0046] In some embodiments, the lightweight SecOC authentication method further comprises: Rejecting the SecOC-protected message from entering the network application layer when the freshness value of the SecOC-protected message is less than the difference between the freshness reference value and a preset allowable window size, or the freshness value is greater than the sum of the freshness reference value and the preset allowable window size.

[0047] It can be understood that, the current reference freshness value is Fcurrent, the freshness value of the received message is Frecv, and the allowable window size is W. When Frecv < Fcurrent - W or Frecv > Fcurrent + W, the freshness is determined to be abnormal, and the message is directly rejected.

[0048] In some embodiments, generating a SecOC-protected message based on the PDU payload, PDU data of the message to be sent and the freshness value comprises: Generating a SecOC authentication code based on the PDU payload of the message to be sent and the freshness value; The PDU data, the freshness value, and the SecOC authentication code are encapsulated to form a SecOC protection message.

[0049] Understandably, the sending node encapsulates the PDU data, freshness value, and authentication code into a SecOC protected message and sends it to the target node via the vehicle network.

[0050] The PDU payload is the core data portion of a protocol data unit that, after removing the header / tail control information, actually carries upper-layer service data (SDUs) or specific control commands.

[0051] PDU stands for Protocol Data Unit, which is the basic data block transmitted between peer entities at different layers of network communication.

[0052] In some embodiments, a SecOC authentication code is generated based on the PDU payload of the message to be sent and the freshness value, including: Based on the PDU payload of the message to be sent and the freshness value, an authentication data block is obtained by splicing them together; Using the key pre-shared during initialization as the authentication key, an authentication operation is performed on the authentication data block to generate an authentication tag; Based on bus bandwidth requirements, the authentication tag is truncated, and a SecOC authentication code is generated based on the truncated authentication tag.

[0053] Understandably, the sending node obtains the PDU payload, freshness value, and optional auxiliary authentication data (such as message identifier, node identifier, or protocol control information) of the message to be sent, and combines them according to the pre-agreed field order between the sending and receiving ends to form an authentication data block. The length and order of each field remain fixed to ensure that both parties generate consistent authentication input data and avoid authentication failure due to differences in data parsing.

[0054] Using the key pre-shared during initialization as the authentication key, the ASCON authentication function is called to perform authentication operations on the authentication data block and generate a complete authentication tag.

[0055] Based on the bus bandwidth requirements, the authentication tag is truncated, and the truncated tag is used as the SecOC authentication code.

[0056] like Figure 2 As shown, the present invention also provides a lightweight SecOC authentication device 200, comprising: The authentication tag generation module 201 is used to generate a local authentication tag based on the data field of each SecOC protection message received during the process of receiving SecOC protection messages sent by the sending node, and to generate a final local authentication tag based on the local authentication tag generated each time. The message authentication module 202 is used to authenticate the SecOC protected message based on the final local authentication tag; The SecOC protection message is obtained by the sending node based on the following steps: The freshness value is obtained by concatenating the trip count value, which represents the vehicle's operating cycle, with the scheduling table count value, which represents the message sending order. A SecOC protection message is generated based on the PDU payload, PDU data, and freshness value of the message to be sent.

[0057] The present invention also provides an electronic device, including a memory and a processor, wherein, The memory is used to store programs; The processor, coupled to the memory, is configured to execute the program stored in the memory to implement the steps of the lightweight SecOC authentication method as described in any of the preceding claims.

[0058] The present invention also provides a lightweight SecOC authentication system, including the aforementioned electronic device and a transmitting node communicatively connected to the electronic device.

[0059] In some embodiments, this invention does not improve the authentication algorithm itself, but rather provides a lightweight SecOC authentication architecture for resource-constrained vehicle nodes, the principle block diagram of which can be referred to. Figure 3 As shown.

[0060] This architecture reduces communication overhead, synchronization complexity, and authentication computation load by refactoring the freshness management mechanism, authentication verification mechanism, and authentication execution mechanism in SecOC, while maintaining the integrity protection and replay attack protection objectives of SecOC, thereby improving the deployment adaptability of resource-constrained ECUs.

[0061] In this lightweight SecOC authentication architecture, the ASCON algorithm serves as the authentication computation carrier, working in conjunction with the two-dimensional temporal information construction mechanism, the finite window verification mechanism, and the pipelined authentication execution mechanism to achieve lightweight secure communication.

[0062] Unlike traditional SecOC which uses a single incremental freshness counter, this invention decomposes the message timing relationship into two types of timing information: the running cycle dimension and the message order dimension. These are then represented using vehicle running cycle information and message scheduling order information, respectively. This reduces state synchronization complexity and communication overhead while ensuring replay attack detection capabilities.

[0063] To avoid duplicate freshness values ​​caused by the scheduler counter restarting its counting after the ECU is powered off, reset, or powered on again, this invention uses a combination of a trip counter and a scheduler counter to construct the freshness value.

[0064] The trip counter is used to characterize the vehicle's operating cycle. When the vehicle enters the operating state from the off state, the trip counter increments by 1, and the updated count value is saved to non-volatile memory.

[0065] The scheduling table counter is used to represent the message sending order within the current runtime cycle. It is initialized after node startup and is incremented according to the communication scheduling order.

[0066] Since different operating cycles correspond to different travel count values, even if the scheduling table counter restarts counting after the node restarts, the combined freshness value can still maintain global timing differentiation capability, thereby avoiding the problem of freshness value duplication caused by ECU restart.

[0067] The receiver incorporates a freshness window mechanism to handle fault tolerance scenarios such as node restarts, message delays, message out-of-order delivery, and short-term communication anomalies, thereby improving the reliability and robustness of the system.

[0068] The core process of this embodiment is as follows: system initialization phase – freshness value generation phase – authentication tag generation phase – security message sending phase – security message receiving phase – pipeline authentication verification phase – authentication decision phase.

[0069] System initialization phase: 1. Key Configuration: During the vehicle production phase, authentication keys are written to each ECU through a security diagnostic session and stored in a secure storage area or HSM (Hardware Security Module), which can only be accessed by the authentication module.

[0070] 2. Algorithm Deployment: A unified authentication algorithm implementation module and authentication configuration parameters are deployed in the ECUs participating in SecOC communication. In this embodiment, the ASCON authentication algorithm is used as the authentication engine.

[0071] 3. Counter initialization: Each node maintains a trip counter (to record vehicle operation cycles) and a scheduling table counter (to record the order of message transmission within the same cycle), which are used to record vehicle operation cycles and message transmission order, respectively, to provide a basis for the generation of subsequent freshness values.

[0072] Freshness value generation stage: 1. Trip Counter Acquisition: The sending node reads the current trip counter value. The trip counter increments by 1 when the vehicle transitions from the off state to the running state and is saved to non-volatile memory.

[0073] 2. Scheduling Table Counter Acquisition: The sending node acquires the scheduling table counter value corresponding to the current message. Within the same vehicle operation cycle, the scheduling table counter value increments once for each target message sent. The scheduling table counter value is used to reflect the order in which messages are sent within the current operation cycle.

[0074] 3. Freshness value construction: The freshness value is formed by concatenating the low-order field of the trip counter with the high-order field of the schedule table counter in a predetermined order.

[0075] 4. Freshness Value Validity Design: Unlike traditional SecOC which uses an independent, monotonically increasing freshness counter, this invention constructs a freshness value by combining a trip counter and a scheduling table counter. The trip counter represents the vehicle's operating cycle, while the scheduling table counter represents the message sending order. By simultaneously introducing operating cycle information and message order information, the freshness value possesses dual-dimensional temporal characteristics. This enables the identification of historical message replays across operating cycles as well as duplicate messages within the same operating cycle, ensuring replay attack detection capabilities while reducing the complexity of freshness management.

[0076] During the certification label generation stage, refer to Figure 4 As shown: 1. Constructing the authentication data block: The sending node obtains the PDU payload, freshness value, and optional auxiliary authentication data (such as message identifier, node identifier, or protocol control information) of the message to be sent, and combines them according to the pre-agreed field order between the sending and receiving ends to form the authentication data block. The length and order of each field remain fixed to ensure that both parties generate consistent authentication input data and avoid authentication failure due to differences in data parsing.

[0077] 2. Perform authentication calculation: Using the key pre-shared during initialization as the authentication key, call the ASCON authentication function to perform authentication calculation on the authentication data block and generate a complete authentication tag.

[0078] 3. Tag truncation: The authentication tag is truncated according to the bus bandwidth requirements, and the truncated tag is used as the SecOC authentication code.

[0079] Message transmission phase: The sending node encapsulates the PDU data, freshness value, and authentication code into a SecOC protected message and sends it to the target node through the vehicle network.

[0080] Message reception phase: 1. Data parsing: The receiving node parses the received SecOC message to obtain the PDU payload, freshness value and authentication code.

[0081] 2. Local Status Acquisition: Acquire the locally maintained trip counter, schedule counter, and current valid freshness reference value.

[0082] During the pipeline certification and verification phase, refer to Figure 5 As shown: 1. Authentication status pre-calculation Unlike traditional SecOC, which initiates authentication calculation only after receiving a complete message, this invention employs a pre-calculation mechanism for the authentication state. The receiving node synchronously initiates authentication state calculation during the reception of SecOC messages. Each time a data field is received, the current authentication state is updated using the received data. The authentication state continuously progresses as the message reception process continues.

[0083] Once the last data field has been received, there is no need to re-execute the full authentication operation; only final state convergence is required to generate a local authentication tag.

[0084] Therefore, the authentication calculation process and the message receiving process are executed in parallel, realizing the transformation of the authentication execution architecture from serial processing to pipelined processing.

[0085] 2. Local authentication tag generation After the message is received, a local authentication tag, i.e. a verification value, is generated based on the final authentication status.

[0086] 3. Freshness window status maintenance The receiving node maintains the currently verified freshness reference value Fcurrent.

[0087] Update the reference value each time authentication is successful.

[0088] The system establishes a receiving window based on Fcurrent and performs validity checks on the received freshness values.

[0089] When the freshness value is within the window range, the certification process is allowed. If the message exceeds the window range, it is considered an abnormal message or a potential replay message.

[0090] Certification decision-making stage: 1. Freshness window verification: Given that the current reference freshness value is Fcurrent, the freshness value of the received message is Frecv, and the allowed window size is W.

[0091] The receiving node makes its judgment according to the following rules: When Fcurrent ≤ Frecv ≤ Fcurrent + W, the message is determined to be within the valid window, allowed to enter the authentication process, and the reference value is updated to Frecv; When Frecv < Fcurrent and Fcurrent - Frecv ≤ W, it is determined as an out-of-order or delayed message within the window, which is allowed to enter the authentication process, but the reference value remains unchanged; When Frecv < Fcurrent - W > 0 or Frecv > Fcurrent + W, the freshness is determined to be abnormal, and the message is directly rejected.

[0092] 2. Tag comparison: compare the local authentication tag with the received authentication tag. If they are consistent, the message is allowed to enter the application layer; otherwise, the message is rejected.

[0093] 3. Security event processing: for authentication failure or freshness abnormal events, record security logs and report to the security management module according to configurations.

[0094] The present invention has the following beneficial effects: 1. Reduce computing resource consumption Through the combination of a lightweight authentication algorithm and an authentication state precomputation mechanism, the CPU operation load and code implementation complexity in the authentication process are reduced, and the deployment adaptability of resource-constrained ECUs is improved.

[0095] 2. Reduce communication overhead The compact freshness value structure is used to reduce the length of the SecOC additional field.

[0096] 3. Simplify synchronization mechanism The finite window verification mechanism reduces complex synchronization logic.

[0097] 4. Reduce authentication delay Parallel execution of authentication calculation and message reception is realized.

[0098] 5. Suitable for resource-constrained nodes It is suitable for low-resource devices such as LIN nodes, body controllers and sensor nodes.

[0099] 6. Balance security and availability Through the two-dimensional freshness information and the window verification mechanism, while ensuring the replay attack detection capability, the system's tolerance for network delay and message out-of-order is improved.

[0100] 7. Realize SecOC architecture-level lightweight optimization This invention not only replaces the authentication algorithm, but also optimizes the freshness management mechanism, synchronous verification mechanism and authentication execution mechanism in SecOC as a whole. While maintaining the original security goals, it achieves a lightweight architecture design, which is more suitable for application scenarios such as resource-constrained ECUs, LIN nodes and low-cost body controllers.

[0101] It should be noted that the core improvements in this embodiment include the following points: 1. Lightweight SecOC certification architecture for resource-constrained ECUs This invention does not simply replace the authentication algorithm in SecOC, but rather, while maintaining the SecOC security objectives, it collaboratively reconstructs the freshness management mechanism, authentication verification mechanism, and authentication execution mechanism to form a lightweight SecOC authentication architecture suitable for resource-constrained vehicle nodes.

[0102] 2. Freshness management mechanism based on dual-dimensional time-series information Traditional SecOC uses a single incrementing counter to describe message timing relationships.

[0103] This invention decomposes message timing relationships into two dimensions: runtime cycle and message order. Through a dual-dimensional timing information construction mechanism, the receiving end can determine timing validity solely based on runtime cycle information and message order information, thereby reducing the complexity of state synchronization.

[0104] 3. Asynchronous recovery verification mechanism based on a limited window The validity of freshness is determined by using a limited window mechanism.

[0105] When message delays, message out-of-order delivery, or short-term communication anomalies occur, authentication verification can be completed without executing the complex synchronization recovery process in traditional SecOC.

[0106] Improve system robustness and reduce software complexity.

[0107] 4. Pipeline SecOC execution mechanism based on authentication state pre-computation The receiving node simultaneously performs authentication status calculation during the message reception process.

[0108] The authentication status is updated synchronously with message reception.

[0109] Once the message has been received, the authentication result can be obtained simply by performing final state convergence.

[0110] This enables the SecOC authentication execution architecture to shift from a serial mode to a pipelined mode, reducing authentication latency and improving processing efficiency.

[0111] The lightweight SecOC authentication device provided in the above embodiments can implement the technical solutions described in the above lightweight SecOC authentication method embodiments. The specific implementation principles of each module or unit can be found in the corresponding content in the above lightweight SecOC authentication method embodiments, and will not be repeated here.

[0112] like Figure 6 As shown, the present invention also provides an electronic device 600. The electronic device 600 includes a processor 601, a memory 602, and a display 603. Figure 6 Only some components of the electronic device 600 are shown, but it should be understood that it is not required to implement all the components shown, and more or fewer components may be implemented instead.

[0113] In some embodiments, memory 602 may be an internal storage unit of electronic device 600, such as a hard disk or memory of electronic device 600. In other embodiments, memory 602 may also be an external storage device of electronic device 600, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. equipped on electronic device 600.

[0114] Furthermore, the memory 602 may include both internal storage units of the electronic device 600 and external storage devices. The memory 602 is used to store application software and various types of data installed on the electronic device 600.

[0115] In some embodiments, processor 601 may be a central processing unit (CPU), microprocessor, or other data processing chip for running program code stored in memory 602 or processing data, such as the lightweight SecOC authentication method of the present invention.

[0116] In some embodiments, display 603 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. Display 603 is used to display information from electronic device 600 and to display a visual user interface. Components 601-603 of electronic device 600 communicate with each other via a system bus.

[0117] In some embodiments of the present invention, when the processor 601 executes the lightweight SecOC authentication program in the memory 602, the following steps may be implemented: During the process of receiving SecOC protection messages sent by the sending node, a local authentication tag is generated based on the data field of each SecOC protection message received, and a final local authentication tag is generated based on the local authentication tag generated each time. The SecOC protected message is authenticated based on the final local authentication tag. The SecOC protection message is obtained by the sending node based on the following steps: The freshness value is obtained by concatenating the trip count value, which represents the vehicle's operating cycle, with the scheduling table count value, which represents the message sending order. A SecOC protection message is generated based on the PDU payload, PDU data, and freshness value of the message to be sent.

[0118] It should be understood that when the processor 601 executes the lightweight SecOC authentication program in the memory 602, in addition to the functions mentioned above, it can also perform other functions, as detailed in the description of the corresponding method embodiments above.

[0119] Furthermore, the embodiments of the present invention do not specifically limit the type of electronic device 600 mentioned. Electronic device 600 can be a mobile phone, tablet computer, personal digital assistant (PDA), wearable device, laptop computer, or other portable electronic device. Exemplary embodiments of portable electronic devices include, but are not limited to, portable electronic devices running iOS, Android, Microsoft, or other operating systems. The aforementioned portable electronic device can also be other portable electronic devices, such as a laptop computer with a touch-sensitive surface (e.g., a touch panel). It should also be understood that in some other embodiments of the present invention, electronic device 600 may not be a portable electronic device, but rather a desktop computer with a touch-sensitive surface (e.g., a touch panel).

[0120] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the lightweight SecOC authentication method provided by the methods described above, the method comprising: During the process of receiving SecOC protection messages sent by the sending node, a local authentication tag is generated based on the data field of each SecOC protection message received, and a final local authentication tag is generated based on the local authentication tag generated each time. The SecOC protected message is authenticated based on the final local authentication tag. The SecOC protection message is obtained by the sending node based on the following steps: The freshness value is obtained by concatenating the trip count value, which represents the vehicle's operating cycle, with the scheduling table count value, which represents the message sending order. A SecOC protection message is generated based on the PDU payload, PDU data, and freshness value of the message to be sent.

[0121] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0122] The lightweight SecOC authentication method, apparatus, system, and electronic device provided by this invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A lightweight SecOC authentication method, characterized in that, include: During the process of receiving SecOC protection messages sent by the sending node, a local authentication tag is generated based on the data field of each SecOC protection message received, and a final local authentication tag is generated based on the local authentication tag generated each time. The SecOC protected message is authenticated based on the final local authentication tag. The SecOC protection message is obtained by the sending node based on the following steps: The freshness value is obtained by concatenating the trip count value, which represents the vehicle's operating cycle, with the scheduling table count value, which represents the message sending order. A SecOC protection message is generated based on the PDU payload, PDU data, and freshness value of the message to be sent.

2. The lightweight SecOC authentication method according to claim 1, characterized in that, The SecOC protected message is authenticated based on the final local authentication tag, including: A data receiving window is constructed based on a preset freshness reference value; If the freshness value of the SecOC protection message is within the data receiving window range, the SecOC protection message is authenticated based on the final local authentication tag and the receiving authentication tag in the SecOC protection message. The freshness reference value is updated based on the freshness value in the current SecOC protection message, and the data receiving window is updated based on the updated freshness reference value.

3. The lightweight SecOC authentication method according to claim 2, characterized in that, The maximum value of the data receiving window is the sum of the freshness reference value and the preset allowed window size, and the minimum value of the data receiving window is the freshness reference value.

4. The lightweight SecOC authentication method according to claim 3, characterized in that, Authentication of the SecOC protected message based on the final local authentication label also includes: If the freshness value of the SecOC protection message is less than the freshness reference value, and the difference between the freshness reference value and the freshness value is less than or equal to a preset allowed window size, the SecOC protection message is authenticated based on the final local authentication tag and the receive authentication tag in the SecOC protection message.

5. The lightweight SecOC authentication method according to claim 3, characterized in that, Also includes: If the freshness value of the SecOC protection message is less than the difference between the freshness reference value and the preset allowed window size, or if the freshness value is greater than the sum of the freshness reference value and the preset allowed window size, the SecOC protection message is rejected from the network application layer.

6. The lightweight SecOC authentication method according to claims 1-5, characterized in that, Generate a SecOC protection message based on the PDU payload, PDU data, and freshness value of the message to be sent, including: Based on the PDU payload of the message to be sent and the freshness value, generate a SecOC authentication code; The PDU data, the freshness value, and the SecOC authentication code are encapsulated to form a SecOC protection message.

7. The lightweight SecOC authentication method according to claim 6, characterized in that, Based on the PDU payload of the message to be sent and the freshness value, a SecOC authentication code is generated, including: Based on the PDU payload of the message to be sent and the freshness value, an authentication data block is obtained by splicing them together; Using the key pre-shared during initialization as the authentication key, an authentication operation is performed on the authentication data block to generate an authentication tag; Based on bus bandwidth requirements, the authentication tag is truncated, and a SecOC authentication code is generated based on the truncated authentication tag.

8. A lightweight SecOC authentication device, characterized in that, include: The authentication tag generation module is used to generate a local authentication tag based on the data field of each SecOC protection message received during the process of receiving SecOC protection messages sent by the sending node, and to generate the final local authentication tag based on the local authentication tag generated each time. The message authentication module is used to authenticate the SecOC protected message based on the final local authentication tag; The SecOC protection message is obtained by the sending node based on the following steps: The freshness value is obtained by concatenating the trip count value, which represents the vehicle's operating cycle, with the scheduling table count value, which represents the message sending order. A SecOC protection message is generated based on the PDU payload, PDU data, and freshness value of the message to be sent.

9. An electronic device, characterized in that, Including memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is configured to execute the program stored in the memory to implement the steps of the lightweight SecOC authentication method as described in any one of claims 1 to 7.

10. A lightweight SecOC authentication system, characterized in that, It includes the electronic device as described in claim 9, and a transmitting node that is communicatively connected to the electronic device.

Images