Cluster remote attestation method and system suitable for in-vehicle network

Abstract

The invention provides a cluster remote certification method and system suitable for an in-vehicle network, and provides three authentication modes including passive certification, active certification and offline certification for security challenges in a heterogeneous network environment in which a vehicle-mounted Ethernet and a CAN bus coexist. According to the authentication mechanism provided by the invention, remote identity verification and firmware integrity verification of various ECUs in the vehicle-mounted network are realized through a flexible authentication strategy, malicious node or firmware tampering is effectively prevented, and the security and reliability of the vehicle-mounted network are ensured. And the integrity and the credibility of the ECU can be ensured no matter in the limit scenes of normal networking, real-time data exchange or network disconnection, so that an efficient and reliable safety protection scheme is provided for a vehicle-mounted network environment.

Description

Technical Field

[0001] The present invention belongs to the field of authentication technology, and in particular relates to a cluster remote authentication method and system suitable for an in-vehicle network. Background Art

[0002] With the rapid development of smart car technology, the role of on-board electronic control units (ECUs) in modern vehicles is becoming increasingly important. ECUs are not only responsible for the basic sensing and control functions of the vehicle, but also for transmitting information in the in-vehicle network (IVN). However, due to security vulnerabilities in the in-vehicle network design, many ECU nodes and IVN communications are not effectively protected, allowing attackers to easily perform malicious operations, such as forging legitimate ECU nodes or injecting malicious data into the IVN bus, thereby threatening the safety of the vehicle and even endangering the lives of drivers and passengers. Therefore, it has become a top priority to design a collective remote attestation (RA) scheme to ensure the legitimacy of ECU nodes and provide a secure communication environment for IVN.

[0003] Remote Attestation (RA) is a technology for device integrity verification, which usually consists of verification nodes and proving nodes. Verification nodes are responsible for verifying the integrity of proving nodes. Verification nodes usually have powerful computing and storage capabilities, while proving nodes are vulnerable to attacks due to limited resources. Collective remote attestation reduces communication overhead by introducing an aggregator, which is responsible for collecting and forwarding evidence from all proving nodes, thereby improving authentication efficiency.

[0004] In the field of IoT, remote attestation technology has been widely used to detect infected nodes. There have been some studies on collective RA schemes, which proposed methods such as formal analysis of collective RA models, design of collective RA protocols, and hybrid RA schemes to ensure the security of nodes. In addition, there are software protection schemes for IoT devices, such as remote attestation methods based on delayed observation mechanisms to prevent proxy attacks. However, these schemes still have certain problems, such as failure to achieve device identity authentication and inability to resist physical attacks. To enhance security, studies have also proposed secure asynchronous remote attestation schemes based on asynchronous communication, and reduced the risk of single point failures through many-to-one authentication and distributed attestation. Although these methods can effectively improve security, many collective authentication schemes still require devices to have certain hardware support (such as memory protection units or read-only memories), which makes them unsuitable for resource-constrained IoT devices.

[0005] Similar to IoT devices, in-vehicle network (IVN) nodes are also resource-constrained devices. Therefore, the application of remote attestation (RA) technology in IVN is also crucial. Although some IVN authentication schemes have been proposed, such as node authentication based on authentication keys, decentralized attestation schemes, and verification of firmware integrity using hash functions and challenge-response mechanisms, these schemes still face problems such as high computational and communication overheads, failure to consider the actual IVN network topology, lack of cross-domain support, and node identity authentication. In addition, many existing schemes assume that the vehicle gateway is only connected to a single CAN bus, but modern vehicles are usually equipped with multiple buses and transmit data to the vehicle gateway via automotive Ethernet, which makes it difficult for traditional authentication methods to fully adapt to the needs of modern vehicles.

[0006] With the development of vehicle-to-everything (V2X) and 5G / 6G networks, the connection between vehicles and the Internet has become more convenient, and cloud servers can communicate with vehicles in real time to distribute policies and diagnose abnormal situations. At the same time, with the popularization of Firmware Over-The-Air (FOTA) technology, firmware updates for IVN nodes have become more frequent to support new features or fix security vulnerabilities. However, since FOTA is performed through public wireless networks and the in-vehicle network (IVN) lacks effective security protection, ECU nodes face greater security risks. Therefore, for resource-constrained IVN nodes, it is necessary to develop a lightweight remote attestation solution to verify the integrity of the ECU firmware to improve overall security.

[0007] In addition, as the automotive electrical / electronic (E / E) architecture develops from distributed to centralized, traditional IVN authentication schemes have become difficult to adapt to the needs of modern vehicles. Traditional schemes are usually based on a decentralized architecture, where the vehicle gateway is directly connected to the ECU via the CAN bus, but in modern vehicles, the ECU communicates with the sub-controller via the CAN bus, and the sub-controller is connected to the vehicle gateway via automotive Ethernet. Therefore, existing authentication schemes are difficult to provide effective security protection for actual vehicles. To address this problem, a new collective remote attestation method is proposed, which can ensure the integrity of IVN nodes and achieve ECU authentication through pre-set key correction, thereby providing more practical identity authentication and security protection for modern vehicles.

[0008] Prior art document 1 (J.Cao, T.Zhu, R.Ma, Z.Guo, Y.Zhang, and H.Li, “A software-based remote attestation scheme for internet of things devices,” IEEE Transactions on Dependable and Secure Computing, vol.20, no.2, pp.1422–1434, 2022.) discloses a detailed plan for a software-based remote attestation scheme tailored for Internet of Things (IoT) devices. The following are the key components of the proposed plan:

[0009] Latency Observation Mechanism: This mechanism is introduced to address the challenges of software-based remote attestation in wireless networks. It allows the verification node to select the observation node based on distance and reputation, which helps to monitor the network latency effectively.

[0010] Remote Attestation Request Phase: In this phase, the verification node notifies the attestation node to perform remote attestation. It also selects an observation node to monitor network latency. The attestation node fills its memory with the specified seed to prevent memory copy attacks, ensuring that malicious code cannot hide in RAM.

[0011] Data backup and integrity: To ensure the integrity of the proving node data during the authentication process, the scheme includes a mechanism to back up and encrypt the data before transmitting it to the validating node. This data will be restored after the authentication is completed.

[0012] Phased approach: The authentication process is divided into several phases, including: (1) Registration phase: Prepare the nodes for authentication by distributing keys. (2) Request phase: Start authentication and select observation nodes. (3) Checksum challenge phase: Verify memory integrity through checksum response. (4) Decision phase: Determine whether to accept the attestation node based on the collected data. (5) Simulation experiment: The protocol designed in this application is tested on the UNO-R3 development board to prove its practicality and effectiveness.

[0013] The above-mentioned IVN remote attestation (RA) solution has the following defects:

[0014] 1. Over-reliance on computing and communication resources, which makes it difficult for them to run effectively in resource-constrained ECU nodes (electronic control units). For example, although the RSA signature-based authentication scheme has high security in traditional computing environments, it requires a large amount of computing resources and memory during execution, which is a huge burden for low-computing devices such as low-end ECUs in vehicle networks. Therefore, existing security solutions often cannot meet the needs of low-computing and low-power devices in vehicle networks.

[0015] 2. Failure to fully consider the complex network topology in modern vehicles. Many solutions assume that the vehicle gateway is only connected to a single CAN bus, but the network architecture of modern vehicles usually includes multiple independent bus systems and is connected to multiple domain controllers through vehicle Ethernet. This multi-level, multi-protocol network environment requires the authentication mechanism to have higher flexibility and adaptability.

[0016] 3. Although it can provide a certain degree of software integrity verification, it often lacks effective identity authentication mechanisms or hardware security measures, making the system vulnerable to various attacks and tampering. The lack of strong identity authentication may allow malicious devices to enter the network disguised as legitimate ECUs, while the lack of hardware security measures allows attackers to tamper with firmware or data through physical means, thereby weakening the overall system's security protection capabilities.

[0017] 4. Collective proof schemes usually require extensive participation from neighboring nodes. This participation method increases the implementation complexity of the system, especially when there are a large number of nodes or the network environment is unstable. Since these schemes often rely on collaboration and information sharing between nodes, the failure or malicious behavior of any single node may cause the interruption or failure of the collective proof process. Summary of the invention

[0018] In order to solve the above problems existing in the prior art, the present invention provides a cluster remote certification method and system applicable to an in-vehicle network. The technical problem to be solved by the present invention is achieved through the following technical solutions:

[0019] A cluster remote attestation method applicable to an in-vehicle network includes:

[0020] In the passive authentication mode: the cloud server actively triggers the passive authentication process and sends a request message to the corresponding sub-controller through the gateway; the sub-controller responds to the request message and notifies the corresponding ECU to cooperate in completing the identity authentication, generates a first response message and notifies the cloud server through the gateway; the cloud server performs hash verification based on the first response message, and if the verification fails, notifies the sub-controller through the gateway to shut down the corresponding ECU;

[0021] In active proof mode: the cloud server sends a request message to the gateway, and the gateway generates a subscription message and sends it to the corresponding sub-controller; if the ECU is successfully subscribed, the sub-controller sends a confirmation message to the cloud server, and then responds to the request message to notify the corresponding ECU to cooperate in completing identity authentication, generates a second response message and notifies the cloud server through the gateway; the cloud server performs hash verification based on the second response message, and if the authentication fails, notifies the sub-controller through the gateway to shut down the corresponding ECU;

[0022] In offline proof mode: the gateway generates a request message and sends it to the corresponding sub-controller. The sub-controller responds to the request message and notifies the corresponding ECU to cooperate in completing identity authentication, and generates a third response message to notify the gateway. The gateway verifies the ECU based on the third response message. If the verification fails, the sub-controller is notified to shut down the corresponding ECU.

[0023] A cluster remote attestation system suitable for an in-vehicle network includes:

[0024] In the passive authentication mode: the cloud server actively triggers the passive authentication process and sends a request message to the corresponding sub-controller through the gateway; the sub-controller responds to the request message and notifies the corresponding ECU to cooperate in completing the identity authentication, generates a first response message and notifies the cloud server through the gateway; the cloud server performs hash verification based on the first response message, and if the verification fails, notifies the sub-controller through the gateway to shut down the corresponding ECU;

[0025] In active proof mode: the cloud server sends a request message to the gateway, and the gateway generates a subscription message and sends it to the corresponding sub-controller; if the ECU is successfully subscribed, the sub-controller sends a confirmation message to the cloud server, and then responds to the request message to notify the corresponding ECU to cooperate in completing identity authentication, generates a second response message and notifies the cloud server through the gateway; the cloud server performs hash verification based on the second response message, and if the authentication fails, notifies the sub-controller through the gateway to shut down the corresponding ECU;

[0026] In offline proof mode: the gateway generates a request message and sends it to the corresponding sub-controller. The sub-controller responds to the request message and notifies the corresponding ECU to cooperate in completing identity authentication, and generates a third response message to notify the gateway. The gateway verifies the ECU based on the third response message. If the verification fails, the sub-controller is notified to shut down the corresponding ECU.

[0027] Beneficial effects:

[0028] 1. This application designs a set of message structures that can adapt to CAN bus and automotive Ethernet, realizing seamless data conversion between two different types of networks. This enables different types of IVN nodes to exchange data smoothly and provides stable and efficient support for cross-domain transmission.

[0029] 2. This application proposes a collective remote attestation scheme specifically for in-vehicle networks (IVNs), covering multiple authentication modes such as active authentication, passive authentication, and offline authentication. Through flexible authentication strategies, the scheme can adapt to different authentication requirements and ensure the integrity and security of ECU nodes in various working states.

[0030] 3. Based on the preset authentication key, this application proposes an efficient identity authentication scheme, which enables the ECU node to complete identity authentication without adding additional computing burden. This scheme effectively reduces the computing overhead of the system, and is particularly suitable for resource-constrained vehicle network environments, ensuring the efficiency and reliability of identity authentication.

[0031] 4. This application proposes a collective remote attestation (RA) mechanism, which enables it to run efficiently on ECUs with lower computing power. Through an optimized authentication process, the dependence on computing resources in traditional authentication schemes is reduced, so that low-end ECUs can complete identity authentication and firmware integrity verification without adding significant computing overhead, ensuring the security of low-computing devices in the vehicle network, improving the overall security and reliability of IVN, and is particularly suitable for resource-constrained vehicle environments.

[0032] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 It is a flow chart of a cluster remote certification method applicable to an in-vehicle network provided by the present invention;

[0034] Figure 2 It is a schematic diagram of the process of passive proof provided by the present invention;

[0035] Figure 3 It is a schematic diagram of the process of active certification provided by the present invention;

[0036] Figure 4 It is a schematic diagram of the process of offline proof provided by the present invention. DETAILED DESCRIPTION

[0037] The present invention is further described in detail below with reference to specific embodiments, but the embodiments of the present invention are not limited thereto.

[0038] In view of the problems existing in the prior art, the present invention proposes a cluster remote attestation mechanism suitable for vehicle-mounted heterogeneous networks. Aiming at the security challenges in the heterogeneous network environment where vehicle-mounted Ethernet and CAN bus coexist, three authentication modes including passive attestation, active attestation and offline attestation are proposed. Through flexible authentication strategies, this mechanism realizes remote identity authentication and firmware integrity verification of various ECUs (electronic control units) in the vehicle network, effectively prevents malicious nodes or firmware tampering, and ensures the security and reliability of the vehicle network. Whether in normal networking, real-time data exchange or extreme scenarios of network disconnection, the integrity and trust of the ECU can be guaranteed, thereby providing an efficient and reliable security protection solution for the vehicle network environment.

[0039] like Figure 1 As shown, the present invention provides a cluster remote certification method applicable to an in-vehicle network, including:

[0040] In the passive authentication mode: the cloud server actively triggers the passive authentication process and sends a request message to the corresponding sub-controller through the gateway; the sub-controller responds to the request message and notifies the corresponding ECU to cooperate in completing the identity authentication, generates a first response message and notifies the cloud server through the gateway; the cloud server performs hash verification based on the first response message, and if the verification fails, notifies the sub-controller through the gateway to shut down the corresponding ECU;

[0041] The passive proof of this application is triggered by the cloud server, such as Figure 2 As shown. In this mode, the vehicle gateway acts as a client and subscribes to the domain controller as a server using the METHOD class in the SOME / IP protocol. Therefore, after the gateway request, the ECU sends the attested CAN data frame to the domain controller, and the domain controller aggregates the attestation frame into a SOME / IP response data packet and sends it to the gateway, which then aggregates these data packets into a message and sends it to the cloud server.

[0042] refer to Figure 2 , the proof process of this application in passive proof mode is as follows:

[0043] a1, the cloud server actively triggers the passive authentication process for the predetermined domain or predetermined ECU, and sends a CRA request message to the vehicle gateway through a secure channel;

[0044] a2. After receiving the CRA request message, the gateway generates a SOME / IP METHOD message and sends a RA message to the sub-controller of the relevant domain.

[0045] a3, the sub-controller that receives the RA message generates a timestamp T and a RACAN RTR frame;

[0046] a4, the sub-controller that receives the RA message distributes the RA CAN RTR frame to the predetermined ECUs in each bus;

[0047] a5, the ECU that receives the RA CAN RTR frame generates a time stamp T i and the hash value HMAC of its own ID i =HMAC ak (ID ECU ||firmware), the data load of the RA CAN data frame is set to T i ||HMAC i ;HMAC i Represents a message authentication code, HMAC ak Indicates a hash operation on the message, ID ECU Indicates the ID of the scheduled ECU, firmware indicates the device firmware, and || indicates the message connector;

[0048] a6, the ECU that receives the RA CAN RTR frame sends the RA CAN data frame in a5 to the sub-controller;

[0049] a7, the sub-controller that receives the RA CAN data frame collects the RA CAN data frames of all ECUs; calculates the preset key of each ECU to authenticate each ECU, thereby generating a RA SOME / IP METHOD response message; the RA SOME / IP METHOD response message is represented as:

[0050]

[0051] If the ECU k If the authentication fails, the ECU will be considered untrusted and will be replaced with an untrusted tag, telling the gateway that the ECU is untrusted. The untrusted ECU will then be reported and shut down.

[0052] in, Represents the reply message of the child controller. Indicates the ID of the child controller.

[0053] Indicates the ID of ECU1, Indicates the ID of ECU2, Indicates the firmware of ECU1, Indicates the firmware of ECU2;

[0054] a8, all RA SOME / IP METHOD response messages are sent to the gateway;

[0055] a9, the gateway collects all RA SOME / IP METHOD response messages, extracts the payloads therefrom and aggregates them into the first CRA response message, expressed as:

[0056]

[0057] in, Indicates the gateway ID, T j Indicates the timestamp, Indicates that a hash operation is performed on the reply message of the child controller.

[0058] a10, the gateway sends the first CRA response message to the cloud server;

[0059] a11, the cloud server verifies the hash value in the received first CRA response message;

[0060] a12, if the hash verification fails, the cloud server sends a verification failure message to the gateway, indicating the index of the failed domain;

[0061] a13, the gateway locates the ECU that failed verification based on the index, and sends the ID of the ECU that failed verification to the sub-controller;

[0062] a14, the sub-controller shuts down the failed ECU.

[0063] Next, we will use a specific example to illustrate the above process. Assume that there are three ECUs in domain A, namely ECU1, ECU2 and ECU3. Assume that ECU1 is an impersonated ECU, ECU2 is a compromised ECU, and ECU3 is a legitimate ECU. At this time, passive proof is performed to find all illegal ECUs. In a1, domain A is requested to be proved. According to the passive proof process, ECU1 will be identified as an untrusted ECU in a7 and will stop immediately due to the failure of the pre-set key authentication. According to The gateway will be notified in a9 by the untrusted tag in domain A. Subsequently, the cloud server will verify the mismatch of domain A in a11 and notify the gateway in a12. The compromised ECU2 will then be located and shut down in a13 and a14.

[0064] In active proof mode: the cloud server sends a request message to the gateway, and the gateway generates a subscription message and sends it to the corresponding sub-controller; if the ECU is successfully subscribed, the sub-controller sends a confirmation message to the cloud server, and then responds to the request message to notify the corresponding ECU to cooperate in completing identity authentication, generates a second response message and notifies the cloud server through the gateway; the cloud server performs hash verification based on the second response message, and if the authentication fails, notifies the sub-controller through the gateway to shut down the corresponding ECU;

[0065] Active attestation is similar to the passive process, the main difference is that active attestation uses the EVENT class in the SOME / IP protocol. Therefore, the cloud server can periodically verify the ECU through the notification operation of the SOME / IP protocol without sending a verification request. In this mode, the domain controller acts as a client and subscribes to the ECU as a server. The ECU actively sends messages to the domain controller in the form of event notifications, such as Figure 3 The proof process of this application in active proof mode is as follows:

[0066] b1, the cloud server sends a CRA request message to the vehicle gateway through a secure channel for a predetermined domain or predetermined ECU;

[0067] b2, after receiving the CRA request message, the gateway generates and sends the RA SOME / IP EVENT SUBSCRIPTION event subscription message to the sub-controller of the relevant domain;

[0068] b3, if the sub-controller successfully subscribes to the predetermined ECU, it sends an ACK confirmation message to the gateway;

[0069] b4, the sub-controller generates a timestamp T and a RA CAN RTR frame;

[0070] b5, the sub-controller distributes the RA CAN RTR frame to the predetermined ECUs in each bus;

[0071] b6, the ECU that receives the RA CAN RTR frame generates a time stamp T i and the hash value HMAC of its own ID i =HMAC ak (ID ECU ||firmware), the data load of the RA CAN data frame is set to T i ||HMAC i .

[0072] b7, the ECU that receives the RA CAN RTR frame sends the RA CAN data frame in b6 to the sub-controller;

[0073] b8, the sub-controller that receives the RA CAN data frame collects the RA CAN data frames of all ECUs; calculates the preset key of each ECU to authenticate each ECU, thereby generating a RA SOME / IP EV ENT response message, which is expressed as:

[0074]

[0075] b9, the sub-controller that receives the RA CAN data frame sends all RA SOME / IP EVENT response messages to the gateway.

[0076] b10, the gateway collects all RA SOME / IP EVENT response messages, extracts the payloads therefrom and aggregates them into a second CRA response message, which is represented as:

[0077]

[0078] b11, the gateway sends the second CRA response message to the cloud server;

[0079] b12, the cloud server verifies the hash value in the received second CRA response message;

[0080] b13, if the hash verification fails, the cloud server sends a verification failure message to the gateway, indicating the index of the failed domain;

[0081] b14, the gateway locates the ECU that failed verification based on the index, and sends the ID of the ECU that failed verification to the sub-controller;

[0082] b15, the sub-controller shuts down the failed ECU.

[0083] In offline proof mode: the gateway generates a request message and sends it to the corresponding sub-controller. The sub-controller responds to the request message and notifies the corresponding ECU to cooperate in completing identity authentication, and generates a third response message to notify the gateway. The gateway verifies the ECU based on the third response message. If the verification fails, the sub-controller is notified to shut down the corresponding ECU.

[0084] Offline attestation is designed for situations where the vehicle is disconnected from the cloud server. For example, when the vehicle is traveling through a desert or forest, the network cannot be connected. In this case, remote attestation must be performed through the vehicle gateway. The detailed protocol is as follows: Figure 4 The certification process of this application in offline certification mode is as follows:

[0085] c1, the gateway sends a RA SOME / IP METHODSUBSCRIPTION message to the sub-controller for a predetermined domain or a predetermined ECU;

[0086] c2, after receiving the RA SOME / IP METHOD SUBSCRIPTION message, the sub-controller generates a timestamp and a RACAN RTR frame;

[0087] c3, the sub-controller distributes the RA CAN RTR frame to the predetermined ECUs in each bus;

[0088] c4, the ECU that receives the RA CAN RTR frame generates a message carrying a timestamp T i and the hash value HMAC of its own ID i =HMAC ak (ID ECU ||firmware)'s RA CAN data frame;

[0089] c5, the ECU that receives the RA CAN RTR frame sends the RA CAN data frame in c4 to the sub-controller;

[0090] c6, the sub-controller that receives the RA CAN data frame collects the RA CAN data frames of all ECUs; calculates the preset key of each ECU to authenticate each ECU, thereby generating a RA SOME / IP EVENT response message, which is expressed as:

[0091]

[0092] If an ECU fails authentication, the ECU will be considered untrusted and will be replaced with a flag to inform the gateway that the ECU is not trusted. The untrusted ECU will then be reported and shut down.

[0093] c7, the sub-controller that receives the RA CAN data frame sends all RA SOME / IP EVENT response messages to the gateway.

[0094] c8, the gateway collects all RA SOME / IP EVENT response messages, extracts payloads from them and aggregates them into a third CRA response message, verifies the hash value in the received third CRA response message, and if the verification fails, locates the ECU that failed the verification based on the index of the failure domain of the failed verification, and sends the ID of the ECU that failed the verification to the sub-controller, thereby shutting down the failed ECU.

[0095] The vehicle ECU unit can reflect the vehicle's operating status. This application can upload the vehicle's operating status to the cloud for storage to support event analysis when an accident occurs. By tracking and analyzing the vehicle's operating status, it can help post-accident investigators restore the process of the accident, thereby providing a basis for accident responsibility tracking and safety protection.

[0096] In a second aspect, the present invention provides a cluster remote attestation system applicable to an in-vehicle network, comprising:

[0097] In the passive authentication mode: the cloud server actively triggers the passive authentication process and sends a request message to the corresponding sub-controller through the gateway; the sub-controller responds to the request message and notifies the corresponding ECU to cooperate in completing the identity authentication, generates a first response message and notifies the cloud server through the gateway; the cloud server performs hash verification based on the first response message, and if the verification fails, notifies the sub-controller through the gateway to shut down the corresponding ECU;

[0098] In active proof mode: the cloud server sends a request message to the gateway, and the gateway generates a subscription message and sends it to the corresponding sub-controller; if the ECU is successfully subscribed, the sub-controller sends a confirmation message to the cloud server, and then responds to the request message to notify the corresponding ECU to cooperate in completing identity authentication, generates a second response message and notifies the cloud server through the gateway; the cloud server performs hash verification based on the second response message, and if the authentication fails, notifies the sub-controller through the gateway to shut down the corresponding ECU;

[0099] In offline proof mode: the gateway generates a request message and sends it to the corresponding sub-controller. The sub-controller responds to the request message and notifies the corresponding ECU to cooperate in completing identity authentication, and generates a third response message to notify the gateway. The gateway verifies the ECU based on the third response message. If the verification fails, the sub-controller is notified to shut down the corresponding ECU.

[0100] The technical effects of this application are described below.

[0101] This application uses an Arduino series development board with computing power similar to that of the actual nodes in the in-vehicle network to conduct comprehensive performance testing to verify the execution efficiency of the proposed protocol in different hardware environments, ensuring that the protocol can still provide good performance on real vehicle equipment and meet the performance and response speed requirements in actual applications. A comprehensive attack test is performed using the formal security verification tool Tamarin to simulate various common security threats and attack scenarios (such as replay attacks, tampering attacks, etc.) to verify that the proposed protocol can effectively resist these attacks in actual applications and ensure the security and reliability of network communications.

[0102] The present application has obvious advantages in terms of communication overhead and delay as shown in Table 1. Specifically, compared with other related methods, the present application can effectively reduce bandwidth overhead, especially when the number of nodes increases, the bandwidth overhead grows slowly. Specifically, in the present application, the bandwidth of a single node can be expressed as 192+11+75+192=470 bits. For a vehicle with n nodes, it will be 192+(11+75)·n+192=384+86·n bits. The SRA method proposed in document 1 [J.Cao,T.Zhu,R.Ma,Z.Guo,Y.Zhang,and H.Li,“Asoftwarebased remote attestation scheme for internetof thingsdevices,”IEEE Transactions on Dependable and Secure Computing,vol.20,no.2,pp.1422–1434,2022] generates and transmits a large amount of checksum data in the checksum challenge stage, resulting in large bandwidth consumption. The ESDRA method in reference 2 [B. Kuang, A. Fu, S. Yu, G. Yang, M. Su, and Y. Zhang, “Esdra: An efficient and secure distributed remote attestation scheme for iotswarms,” IEEE Internet of Things Journal, vol. 6, no. 5, pp. 8372–8383, 2019] and the method in reference 3 [B. Kuang, A. Fu, Y. Gao, Y. Zhang, J. Zhou, and R. H. Deng, “Fesa: Automatic federated swarm attestation on dynamic large-scale iot devices,” IEEE Transactions on Dependable and Secure Computing, 2022] have been improved by optimizing the overhead of the proving node, but due to the reliance on communication with neighboring nodes, it brings additional bandwidth overhead.In the NABSA method proposed in Reference 4 [H. Oguma, A. Yoshioka, M. Nishikawa, R. Shigetomi, A. Otsuka, and H. Imai, "New attestation based security architecture for invehicle communication," in IEEE GLOBECOM 2008-2008 IEEE Global Telecommunications Conference. IEEE, 2008, pp. 1–6.], each pair of ECUs needs to communicate with each other, which also leads to significant bandwidth overhead. Reference 5 [F. DP¨ullen, and S.Katzenbeisser, "Ensuring the safe and secure operation of electronic control units inroad vehicles," in 2019 IEEE Security and Privacy Workshops (SPW). IEEE, 2019, pp. 126131] The ESSO method proposed by the user can minimize the bandwidth overhead on a single node, but it cannot achieve node identity authentication. Reference 6 [J. Van Bulck, JT and F.Piessens, "Vulcan: Efficient component authentication and software isolation for automotive control networks," in Proceedings of the 33rd Annual Computer Security Applications Conference, 2017, pp. 225–237] Although the VulCAN method proposed by

[11] has a lower bandwidth requirement for a single node than the present application, its bandwidth consumption rises rapidly as the number of nodes increases, making it unsuitable for large-scale applications. In addition, communication delay is mainly caused by data transmission on slow channels and is closely related to bandwidth overhead. In a practical environment, a typical in-vehicle network is considered, which includes a traditional CAN bus with a bandwidth of 128 kbps and an automotive Ethernet with a bandwidth in the range of 100-1000 Mbps. Given that the bandwidth of automotive Ethernet is much higher than that of the CAN bus, its communication cost is negligible compared to that of the CAN bus. In this context, the communication delay on the CAN bus is mainly concerned. In the present application, the single communication delay of a single node can be calculated by the formula (11+75) / 128 kbps·1000=0.67 ms. For a vehicle with n ECUs (located in 10 different domains), the overall communication delay will be 0.67ms + 0.1n ms. This is because the collective proof mechanism allows all nodes to perform verification tasks in parallel, and the deviation in startup time is only 0.1ms, so it is relatively small. And because of the use of the collective proof mechanism, this application supports parallel execution, thereby significantly reducing communication delays, especially in an environment using the CAN bus, where the delay increases more slowly as the number of nodes increases. This enables the application to provide more efficient communication performance in practical applications.

[0103] Table 1 Bandwidth overhead comparison

[0104] method <![CDATA[ECU i (bits)]]> Total bandwidth cost (bits) Communication delay (milliseconds) Reference 1SRA 1233 1233n 9.63n Reference 2ESDRA 360 360n 2.81n Reference 3FESA 568 568n 4.44n Document 4NABSA 240 <![CDATA[392n 2 -280n+128]]> <![CDATA[3.06n 2 -2.19n+1]]> Reference 5ESSO 131 131n 1.02n Reference 6 VulCAN 248 248n 1.94n This application 470 86n+384 0.67+0.1n

[0105] This application has obvious advantages in terms of computational overhead, as shown in Table 2. Due to the use of a collective attestation mechanism, the entire domain is considered as a whole during the verification process, rather than verifying each ECU node one by one, which significantly reduces the computational overhead, and the computing power of the sub-controller and the vehicle gateway is far more advanced than that of the ECU. In addition, in this application, the main computational overhead is an HMAC operation of the ECU. For a single attestation node, it can be expressed as 11.70n ms. The method SRA in reference 1 [J.Cao, T.Zhu, R.Ma, Z.Guo, Y.Zhang, and H.Li, "A softwarebased remote attestation scheme for internet of things devices," IEEE Transactions on Dependable and Secure Computing, vol.20, no.2, pp.1422–1434, 2022] needs to generate a series of HMACs during the verification and challenge phase of the attestation node response, resulting in a large computational overhead. The ESDRA and FESA schemes in reference 2 [B. Kuang, A. Fu, S. Yu, G. Yang, M. Su, and Y. Zhang, “Esdra: An efficient and secure distributed remote attestationscheme for iot swarms,” IEEE Internet of Things Journal, vol. 6, no. 5, pp. 8372–8383, 2019] and reference 3 [B. Kuang, A. Fu, Y. Gao, Y. Zhang, J. Zhou, and R. H. Deng, “Fesa: Automatic federated swarm attestation on dynamic large-scale iot devices,” IEEE Transactions on Dependable and Secure Computing, 2022] managed to reduce the communication overhead of the proving node, but the additional overhead caused by the neighboring nodes increased.In the method NABSA in reference 4 [H.Oguma, A.Yoshioka, M.Nishikawa, R.Shigetomi, A.Otsuka, and H.Imai, "New attestation based security architecture for invehicle communication," inIEEE GLOBECOM 2008-2008IEEE Global Telecommunications Conference.IEEE, 2008, pp.1], each pair of ECUs needs to communicate with each other, resulting in a computational overhead of O(n2). In reference 5 [F. D. andS.Katzenbeisser, "Ensuring the safe and secure operation of electronic controlunits in road vehicles," in 2019 IEEE Security and Privacy Workshops (SPW). IEEE, 2019, pp. 126131] In the user's scheme ESSO, each message needs to calculate a hash value and two HMACs (one for the sender and one for the receiver). In reference 6 [J. Van Bulck, JT and F.Piessens, "Vulcan: Efficient component authentication and software isolation for automotive control networks," in Proceedings of the 33rd Annual Computer Security Applications Conference, 2017, pp. 225–237] In VulCAN, each message needs to be encrypted and decrypted, and two HMACs need to be calculated. This application is more efficient in terms of ECU computing cost, can achieve lower computing overhead, and adapt to resource-constrained vehicle network environments.

[0106] Table 2 Comparison of calculation costs

[0107]

[0108]

[0109] It is worth noting that the terms "first" and "second" in the present invention are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0110] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by reviewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality of components or steps.

[0111] The above contents are further detailed descriptions of the present invention in combination with specific preferred embodiments, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. For ordinary technicians in the technical field to which the present invention belongs, several simple deductions or substitutions can be made without departing from the concept of the present invention, which should be regarded as falling within the protection scope of the present invention.

Claims

1. A cluster remote attestation method suitable for in-vehicle networks, characterized in that: include: In passive attestation mode: the cloud server actively triggers the passive authentication process and sends a request message to the corresponding sub-controller through the gateway; The sub-controller notifies the corresponding ECU to cooperate in completing identity authentication in response to the request message, generates a first response message and notifies the cloud server through the gateway; the cloud server performs hash verification based on the first response message, and if the verification fails, notifies the sub-controller through the gateway to shut down the corresponding ECU; In active attestation mode: the cloud server sends a request message to the gateway, and the gateway generates a subscription message and sends it to the corresponding sub-controller; If the sub-controller successfully subscribes to the ECU, it sends a confirmation message to the cloud server, and then responds to the request message to notify the corresponding ECU to cooperate in completing identity authentication, generates a second response message and notifies the cloud server through the gateway; The cloud server performs hash verification based on the second response message. If the authentication fails, the cloud server notifies the sub-controller through the gateway to shut down the corresponding ECU. In the offline certification mode: the gateway generates a request message and sends it to the corresponding sub-controller, and the sub-controller responds to the request message to notify the corresponding ECU to cooperate in completing the identity authentication, and generates a third response message to notify the gateway; The gateway verifies the ECU according to the third response message, and if the verification fails, notifies the sub-controller to shut down the corresponding ECU.

2. The cluster remote attestation method applicable to the in-vehicle network according to claim 1, characterized in that: The cloud server actively triggers the passive authentication process and sends a request message to the sub-controller through the gateway, including: a1, the cloud server actively triggers the passive authentication process for the predetermined domain or predetermined ECU, and sends a CRA request message to the vehicle gateway through a secure channel; a2. After receiving the CRA request message, the gateway generates a SOME / IP METHOD message and sends a RA message to the sub-controller of the relevant domain.

3. The cluster remote attestation method applicable to the in-vehicle network according to claim 2, characterized in that: The sub-controller notifies the ECU to cooperate in completing the identity authentication in response to the request message, generates a response message and notifies the cloud server through the gateway, including: a3, the sub-controller that receives the RA message generates a timestamp T and a RA CAN RTR frame; a4, the sub-controller that receives the RA message distributes the RA CAN RTR frame to the predetermined ECUs in each bus; a5, the ECU that receives the RA CAN RTR frame generates a time stamp T i and the RA CAN data frame of the hash value of its own ID; a6, the ECU that receives the RA CAN RTR frame sends the RA CAN data frame in a5 to the sub-controller; a7, the sub-controller that receives the RA CAN data frame collects the RA CAN data frames of all ECUs; calculates the preset key of each ECU to authenticate each ECU, thereby generating a RA SOME / IP METHOD response message; a8, all RA SOME / IP METHOD response messages are sent to the gateway; a9, the gateway collects all RA SOME / IP METHOD response messages, extracts the payloads therefrom and aggregates them into a first CRA response message; a10, the gateway sends the first CRA response message to the cloud server.

4. The cluster remote attestation method applicable to the in-vehicle network according to claim 3, characterized in that: The cloud server performs hash authentication according to the first response message, and if the authentication fails, notifies the sub-controller through the gateway to shut down the corresponding ECU, including: a11, the cloud server verifies the hash value in the received first CRA response message; a12, if the hash verification fails, the cloud server sends a verification failure message to the gateway, indicating the index of the failed domain; a13, the gateway locates the ECU that failed verification based on the index, and sends the ID of the ECU that failed verification to the sub-controller; a14, the sub-controller shuts down the failed ECU.

5. The cluster remote attestation method applicable to the in-vehicle network according to claim 1, characterized in that: The cloud server sends a request message to the gateway, and the gateway generates a subscription message and sends it to the sub-controller, including: b1, the cloud server sends a CRA request message to the vehicle gateway through a secure channel for a predetermined domain or predetermined ECU; b2. After receiving the CRA request message, the gateway generates and sends a RA SOME / IP EVENT SUBSCRIPTION event subscription message to the sub-controller of the relevant domain.

6. The cluster remote attestation method applicable to the in-vehicle network according to claim 5, characterized in that: If the sub-controller successfully subscribes to the ECU, it sends a confirmation message to the cloud server, and then responds to the request message to notify the ECU to cooperate in completing the identity authentication, generates a response message and notifies the cloud server through the gateway, including: b3, if the sub-controller successfully subscribes to the predetermined ECU, it sends an ACK confirmation message to the gateway; b4, the sub-controller generates a timestamp T and a RA CAN RTR frame; b5, the sub-controller distributes the RA CAN RTR frame to the predetermined ECUs in each bus; b6, the ECU that receives the RA CAN RTR frame generates a time stamp T i and the RA CAN data frame of the hash value of its own ID; b7, the ECU that receives the RA CAN RTR frame sends the RA CAN data frame in b6 to the sub-controller; b8, the sub-controller that receives the RA CAN data frame collects the RA CAN data frames of all ECUs; calculates the preset key of each ECU to authenticate each ECU, thereby generating a RA SOME / IP EV ENT response message; b9, the sub-controller that receives the RA CAN data frame sends all RA SOME / IP EVENT response messages to the gateway.

7. The cluster remote attestation method applicable to the in-vehicle network according to claim 6, characterized in that: The cloud server performs hash authentication according to the response message, and if the authentication fails, notifies the sub-diabolo device to shut down the corresponding ECU through the gateway, including: b10, the gateway collects all RA SOME / IP EVENT response messages, extracts payloads therefrom and aggregates them into a second CRA response message; b11, the gateway sends the second CRA response message to the cloud server; b12, the cloud server verifies the hash value in the received second CRA response message; b13, if the hash verification fails, the cloud server sends a verification failure message to the gateway, indicating the index of the failed domain; b14, the gateway locates the ECU that failed verification based on the index, and sends the ID of the ECU that failed verification to the sub-controller; b15, the sub-controller shuts down the failed ECU.

8. The cluster remote attestation method applicable to the in-vehicle network according to claim 1, characterized in that: The gateway generates a request message and sends it to the corresponding sub-controller, and the sub-controller responds to the request message to notify the corresponding ECU to cooperate in completing identity authentication, and generates a third response message to notify the gateway, including: c1, the gateway sends a RA SOME / IP METHODSUBSCRIPTION message to the sub-controller for a predetermined domain or a predetermined ECU; c2, after receiving the RA SOME / IP METHOD SUBSCRIPTION message, the sub-controller generates a timestamp and a RA CAN RTR frame; c3, the sub-controller distributes the RA CAN RTR frame to the predetermined ECUs in each bus; c4, the ECU that receives the RA CAN RTR frame generates a message carrying a timestamp T i and the RA CAN data frame of the hash value of its own ID; c5, the ECU that receives the RA CAN RTR frame sends the RA CAN data frame in c4 to the sub-controller; c6, the sub-controller that receives the RA CAN data frame collects the RA CAN data frames of all ECUs; calculates the preset key of each ECU to authenticate each ECU, thereby generating a RA SOME / IP EVENT response message; c7, the sub-controller that receives the RA CAN data frame sends all RA SOME / IP EVENT response messages to the gateway.

9. The cluster remote attestation method applicable to the in-vehicle network according to claim 8, characterized in that: The gateway verifies the ECU according to the third response message, and if the verification fails, notifies the sub-controller to shut down the corresponding ECU, including: c8, the gateway collects all RA SOME / IP EVENT response messages, extracts payloads from them and aggregates them into a third CRA response message, verifies the hash value in the received third CRA response message, and if the verification fails, locates the ECU that failed the verification based on the index of the failure domain of the failed verification, and sends the ID of the ECU that failed the verification to the sub-controller, thereby shutting down the failed ECU.

10. A cluster remote attestation system suitable for in-vehicle networks, characterized in that: include: In passive attestation mode: the cloud server actively triggers the passive authentication process and sends a request message to the corresponding sub-controller through the gateway; The sub-controller notifies the corresponding ECU to cooperate in completing identity authentication in response to the request message, generates a first response message and notifies the cloud server through the gateway; the cloud server performs hash verification based on the first response message, and if the verification fails, notifies the sub-controller through the gateway to shut down the corresponding ECU; In active attestation mode: the cloud server sends a request message to the gateway, and the gateway generates a subscription message and sends it to the corresponding sub-controller; If the sub-controller successfully subscribes to the ECU, it sends a confirmation message to the cloud server, and then responds to the request message to notify the corresponding ECU to cooperate in completing identity authentication, generates a second response message and notifies the cloud server through the gateway; The cloud server performs hash verification based on the second response message. If the authentication fails, the cloud server notifies the sub-controller through the gateway to shut down the corresponding ECU. In the offline certification mode: the gateway generates a request message and sends it to the corresponding sub-controller, and the sub-controller responds to the request message to notify the corresponding ECU to cooperate in completing the identity authentication, and generates a third response message to notify the gateway; The gateway verifies the ECU according to the third response message, and if the verification fails, notifies the sub-controller to shut down the corresponding ECU.

Images