A cluster remote attestation method and system suitable for in-vehicle networks

Abstract

The application provides a cluster remote proof method and system suitable for an in-vehicle network, and proposes three authentication modes including passive proof, active proof and offline proof for the security challenge in the heterogeneous network environment where the vehicle-mounted Ethernet and CAN bus coexist. The authentication mechanism of the application realizes remote identity authentication and firmware integrity verification of various ECUs in the vehicle-mounted network through flexible authentication strategies, effectively prevents malicious nodes or firmware tampering, and ensures the security and reliability of the vehicle-mounted network. Whether in normal networking, real-time data exchange or network disconnection extreme scenarios, the integrity and trustworthiness of the ECU can be guaranteed, thereby providing an efficient and reliable security protection scheme for the vehicle-mounted network environment.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of authentication, and particularly relates to a cluster remote attestation method and system suitable for an in-vehicle network. BACKGROUND

[0002] With the rapid development of intelligent automobile technology, electronic control units (ECUs) play an increasingly important role in modern vehicles. ECUs are not only responsible for basic sensing and control functions of vehicles, but also undertake the task of transmitting information in in-vehicle networks (IVNs). However, due to security vulnerabilities in the design of in-vehicle networks, 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 IVN buses, thereby threatening the safety of vehicles and even endangering the lives of 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 IVNs.

[0003] Remote attestation (RA) is a technology for verifying the integrity of devices, usually consisting of a verifier node and a prover node. The verifier node is responsible for verifying the integrity of the prover node. The verifier node usually has strong computing and storage capabilities, while the prover node is vulnerable to attacks due to resource constraints. Collective remote attestation reduces communication overhead by introducing an aggregator, which is responsible for collecting and forwarding evidence from all prover nodes, thereby improving authentication efficiency.

[0004] In the field of Internet of Things (IoT), remote attestation technology has been widely applied for detecting infected nodes. There have been some studies on collective RA schemes, which have proposed methods such as formalizing analysis of collective RA models, designing 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 delay observation mechanisms to prevent proxy attacks. However, these schemes still have certain problems, such as the inability to implement device identity authentication and the inability to resist physical attacks. To enhance security, research has proposed a secure asynchronous remote attestation scheme based on asynchronous communication, and through multi-to-one authentication and distributed attestation to reduce the risk of single-point failure. Although these methods can effectively improve security, many collective authentication schemes still require certain hardware support from devices (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, Remote Attestation (RA) techniques are also crucial in IVN. Although some IVN authentication schemes have been proposed, such as authentication key-based node authentication, decentralized attestation schemes, and firmware integrity verification using hash functions and challenge-response mechanisms, these schemes still face problems such as high computational and communication overhead, lack of consideration for actual IVN network topology, lack of cross-domain support, and lack of node identity authentication. In addition, many existing schemes assume that the vehicle gateway is connected to a single CAN bus, but modern vehicles usually have multiple buses and transmit data to the vehicle gateway through automotive Ethernet, making 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, vehicle connectivity to 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 popularity of Firmware Over-The-Air (FOTA) technology, firmware updates for IVN nodes have become more frequent, supporting new features or fixing security vulnerabilities. However, since FOTA is conducted through public wireless networks, and In-Vehicle Network (IVN) lacks effective security guarantees, ECU nodes face significant security risks. Therefore, for resource-constrained IVN nodes, a lightweight remote attestation scheme is needed to verify the integrity of ECU firmware to improve overall security.

[0007] In addition, with the development of automotive Electrical / Electronic (E / E) architecture from distributed to domain-centralized, traditional IVN authentication schemes have become difficult to adapt to the needs of modern vehicles. Traditional schemes are usually based on decentralized architecture, with the vehicle gateway directly connected to the ECU through the CAN bus, but in modern vehicles, ECUs communicate with sub-controllers through the CAN bus, and sub-controllers are connected to the vehicle gateway through automotive Ethernet. Therefore, existing authentication schemes are difficult to provide effective security protection for actual vehicles. To solve this problem, a new collective remote attestation method is proposed, which can ensure the integrity of IVN nodes and achieve ECU identity authentication through pre-key correction, providing more practical identity verification 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] Delay observation mechanism: This mechanism is introduced to address the challenges of software-based remote attestation in wireless networks. It allows the verifier node to select observation nodes based on distance and reputation, which helps to effectively monitor network delays.

[0010] Remote attestation request phase: In this phase, the verifier node informs the prover node to perform remote attestation. It also selects an observation node to monitor network delays. The prover node fills its memory with a specified seed to prevent memory duplication attacks, ensuring that malicious code cannot hide in RAM.

[0011] Data backup and integrity: To ensure the integrity of the prover node’s data during the authentication process, the scheme includes a mechanism for backing up and encrypting the data before transmission to the verifier node. This data will be restored after the authentication is complete.

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

[0013] The above-mentioned scheme for remote attestation (RA) of in-vehicle networks (IVN) has the following drawbacks:

[0014] 1. Over-reliance on computing and communication resources, which makes them difficult to run effectively in resource-constrained ECU nodes (Electronic Control Units). For example, although RSA signature-based authentication schemes have high security in traditional computing environments, they require a large amount of computing resources and memory during execution, which is a huge burden for low-power devices such as low-end ECUs in vehicle networks, so existing security solutions often cannot meet the needs of low-power, 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 contains multiple independent bus systems and is connected to multiple domain controllers through vehicle Ethernet. This multi-level, multi-protocol network environment requires authentication mechanisms to have higher flexibility and adaptability.

[0016] 3. Although it can provide some 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. Lack of strong identity verification can allow malicious devices to pretend to be legitimate ECUs to enter the network, and the absence 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 of neighboring nodes. This participation increases the complexity of system implementation, especially when the number of nodes is large or the network environment is unstable. Since these schemes often rely on collaboration and information sharing between nodes, any single node failure or malicious behavior can cause the collective proof process to be interrupted or fail. SUMMARY

[0018] To solve the above problems in the prior art, the present application provides a cluster remote proof method and system suitable for in-vehicle networks. The technical problems to be solved by the present application are solved by the following technical solutions:

[0019] A cluster remote proof method suitable for in-vehicle networks includes:

[0020] In passive proof 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 to notify the corresponding ECU to cooperate to complete identity authentication, generates a first response message and notifies the cloud server through the gateway; the cloud server performs hash verification according to the first response message, and if the verification fails, it notifies the sub-controller to close the corresponding ECU through the gateway;

[0021] In the active proof mode: the cloud server sends a request message to the gateway, the gateway generates a subscription message and sends it to the corresponding sub-controller; the sub-controller sends an acknowledgement message to the cloud server if the subscription ECU is successful, and then responds to the request message to notify the corresponding ECU to complete the identity authentication, generates a second response message and notifies the cloud server through the gateway; the cloud server performs hash verification according to the second response message, and if the authentication fails, the cloud server notifies the sub-controller to close the corresponding ECU through the gateway.

[0022] In the 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 to notify the corresponding ECU to complete 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, the gateway notifies the sub-controller to close the corresponding ECU.

[0023] A cluster remote proof system suitable for in-vehicle networks includes:

[0024] In the passive proof mode: the cloud server initiates a passive authentication process, and sends a request message to the corresponding sub-controller through the gateway; the sub-controller responds to the request message to notify the corresponding ECU to complete the identity authentication, generates a first response message and notifies the cloud server through the gateway; the cloud server performs hash verification according to the first response message, and if the verification fails, the cloud server notifies the sub-controller to close the corresponding ECU through the gateway;

[0025] In the active proof mode: the cloud server sends a request message to the gateway, the gateway generates a subscription message and sends it to the corresponding sub-controller; the sub-controller sends an acknowledgement message to the cloud server if the subscription ECU is successful, and then responds to the request message to notify the corresponding ECU to complete the identity authentication, generates a second response message and notifies the cloud server through the gateway; the cloud server performs hash verification according to the second response message, and if the authentication fails, the cloud server notifies the sub-controller to close the corresponding ECU through the gateway;

[0026] In the 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 to notify the corresponding ECU to complete 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, the gateway notifies the sub-controller to close the corresponding ECU.

[0027] Beneficial effects:

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

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

[0030] 3. Based on the pre-set authentication key, the application proposes an efficient identity authentication scheme, enabling ECU nodes to complete identity verification without increasing additional computational burden. This scheme effectively reduces the computational overhead of the system, especially suitable for resource-constrained in-vehicle network environments, ensuring the efficiency and reliability of identity authentication.

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

[0032] The application will be further described in detail below in conjunction with the accompanying drawings and examples. BRIEF DESCRIPTION OF DRAWINGS

[0033] Figure 1 is a flowchart of a cluster remote attestation method for in-vehicle networks provided by the application;

[0034] Figure 2 is a process diagram of passive attestation provided by the application;

[0035] Figure 3 is a process diagram of active attestation provided by the application;

[0036] Figure 4 is a process diagram of offline attestation provided by the application. DETAILED DESCRIPTION

[0037] The application will be further described in detail below in conjunction with the accompanying drawings and examples.

[0038] To solve the problems in the prior art, the cluster remote attestation mechanism suitable for a vehicle-mounted heterogeneous network is provided, three authentication modes including passive attestation, active attestation and offline attestation are provided for the security challenge in the heterogeneous network environment where the vehicle-mounted Ethernet and CAN bus coexist. The mechanism realizes remote identity authentication and firmware integrity verification of various ECUs (Electronic Control Unit) in the vehicle-mounted network through flexible authentication strategies, effectively prevents malicious nodes or firmware tampering, and ensures the security and reliability of the vehicle-mounted network. Whether in normal networking, real-time data exchange or network disconnection extreme scenarios, the integrity and trustworthiness of the ECUs can be ensured, thereby providing an efficient and reliable security protection scheme for the vehicle-mounted network environment.

[0039] As shown in Figure 1 , the application provides a cluster remote attestation method suitable for in-vehicle network, which comprises:

[0040] In the 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 responds to the request message to inform the corresponding ECU to cooperate to complete identity authentication, generates a first response message and notifies the cloud server through the gateway; the cloud server performs hash verification according to the first response message, and if the verification fails, the cloud server notifies the sub-controller to close the corresponding ECU through the gateway;

[0041] The passive attestation of the application is triggered by the cloud server, as shown in Figure 2 . 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 requests, the ECU sends the CAN data frame of the attestation to the domain controller, the domain controller aggregates the attestation frame into a SOME / IP response data packet and sends it to the gateway, and the gateway then aggregates these data packets into a message and sends it to the cloud server.

[0042] Referring to Figure 2 , the attestation process of the application in the passive attestation mode is as follows:

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

[0044] a2, after the gateway receives the CRA request message, a SOME / IP METHOD message is generated, and an RA message is sent to the sub-controller of the related domain.

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

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

[0047] a5, the ECUs receiving the RA CAN RTR frame generate a RA CAN data frame carrying a timestamp T i and a hash value of its own ID HMAC i = HMAC ak (ID ECU || firmware) , the data payload of the RA CAN data frame is set to T i || HMAC i ; HMAC i represents a message authentication code, HMAC ak represents a hash operation on a message, ID ECU represents the ID of the predetermined ECU, firmware represents the device firmware, and || represents a message connector;

[0048] a6, the ECUs receiving the RA CAN RTR frame send the RA CAN data frame in a5 to the sub-controller;

[0049] a7, the sub-controller receiving 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 authentication of the ECU k fails, the ECU will be regarded as untrusted, and will be replaced with an untrusted label to inform the gateway that the ECU is untrusted. Then, the untrusted ECU will be reported and closed.

[0052] wherein, represents a reply message of the sub-controller, represents the ID of the sub-controller.

[0053] represents the ID of ECU1, represents the ID of ECU2, represents the firmware of ECU1, represents the firmware of ECU2.

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

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

[0056]

[0057] wherein, denotes the gateway ID, T j denotes the timestamp, denotes the hash operation on the reply message to the sub-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 message of verification failure to the gateway, indicating the index of the failure domain;

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

[0062] a14, the sub-controller closes the ECU of failure.

[0063] Next, the above process is illustrated by a specific example. Assume that there are three ECUs in domain A, which are ECU1, ECU2 and ECU3. Assume that ECU1 is a spoofed ECU, ECU2 is a compromised ECU, and ECU3 is a legitimate ECU. At this time, passive proof is carried out to find out all the illegal ECUs. In a1, domain A is requested to prove. 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 pre-key authentication. According to the untrusted label in a7, the gateway will receive the notification in a9. Subsequently, the cloud server will verify the mismatch of domain A in a11, and notify the gateway in a12. Then, the compromised ECU2 will be located and closed in a13 and a14.

[0064] In the active proof mode: the cloud server sends a request message to the gateway, 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 an acknowledgement message to the cloud server, and in response to the request message, it notifies the corresponding ECU to cooperate to complete identity authentication, generates a second response message and notifies the cloud server through the gateway; the cloud server performs hash verification according to the second response message, and if the authentication fails, it notifies the sub-controller through the gateway to close the corresponding ECU; ​

[0065] Active attestation is similar to passive process, the main difference is that active attestation uses the EVENT class in SOME / IP protocol. Therefore, the cloud server can periodically verify the ECUs through the notification operation of SOME / IP protocol without sending verification requests. In this mode, the domain controller acts as a client and subscribes to the ECUs as servers. The ECUs actively send messages to the domain controller in the form of event notification, as shown in Figure 3 The attestation process of the present application in active attestation 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 a predetermined ECU;

[0067] b2, after the gateway receives the CRA request message, it generates and sends a RA SOME / IP EVENT SUBSCRIPTION event subscription message to the sub-controller of the related 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 receiving the RA CAN RTR frame generates a RA CAN data frame carrying a timestamp T i and its own ID HMAC 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 receiving the RA CAN RTR frame sends the RA CAN data frame in b6 to the sub-controller;

[0073] b8, the sub-controller receiving 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, denoted as:

[0074]

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

[0076] b10, the gateway collects all the RA SOME / IP EVENT response messages, extracts the payloads therefrom and aggregates them into a second CRA response message, denoted 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 message of verification failure to the gateway, indicating the index of the failed domain;

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

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

[0083] In the 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 to inform the corresponding ECU to cooperate to complete identity authentication, generates a third response message to inform the gateway; the gateway verifies the ECU according to the third response message, and if the verification fails, the sub-controller is informed to shut down the corresponding ECU.

[0084] The offline proof is designed for the case where the vehicle is disconnected from the cloud server. For example, when the vehicle is passing through the desert or forest, the network cannot be connected, in which case remote proof must be performed through the vehicle gateway, and the detailed protocol is as shown in Figure 4 The proof process of the present application in the offline proof mode is as follows:

[0085] c1, the gateway sends a RA SOME / IP METHOD SUBSCRIPTION 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 RA CAN RTR frame;

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

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

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

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

[0091]

[0092] If the authentication of a certain ECU fails, the ECU will be regarded as untrusted, and will be replaced by a flag to inform the gateway that the ECU is untrusted. Then, the untrusted ECU will be reported and closed.

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

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

[0095] The vehicle ECU unit can reflect the running state of the vehicle, and the application can upload the running state of the vehicle to the cloud for storage to support event analysis when an accident occurs. Through tracking and analysis of the running state of the vehicle, investigators after an accident can restore the process of the accident, thereby providing a basis for accident responsibility tracking and safety protection.

[0096] In a second aspect, the application provides a cluster remote attestation system suitable for in-vehicle networks, comprising:

[0097] In the passive proof 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 to notify the corresponding ECU to cooperate to complete identity authentication, generates a first response message and notifies the cloud server through the gateway; the cloud server performs hash verification according to the first response message, and if the verification fails, notifies the sub-controller to close the corresponding ECU through the gateway;

[0098] In the 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 sub-controller successfully subscribes to the ECU, it sends an acknowledgement message to the cloud server, and then responds to the request message to notify the corresponding ECU to cooperate to complete identity authentication, generates a second response message and notifies the cloud server through the gateway; the cloud server performs hash verification according to the second response message, and if the authentication fails, notifies the sub-controller to close the corresponding ECU through the gateway;

[0099] In the offline proof 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 to complete identity authentication, generates a third response message and notifies the gateway; the gateway verifies the ECU according to the third response message, and if the verification fails, notifies the sub-controller to close the corresponding ECU.

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

[0101] The present application uses an Arduino series development board similar to the actual node computing power in the vehicle network to perform comprehensive performance testing, verifies the execution efficiency of the proposed protocol in different hardware environments, and ensures that the protocol can still provide good performance on real vehicle devices, meeting the requirements of performance and response speed in actual applications. Formal security verification tool Tamarin is used for comprehensive attack testing, simulating various common security threats and attack scenarios (such as replay attacks, tampering attacks, etc.), verifying that the proposed protocol can effectively resist these attacks in actual applications, and ensuring the security and reliability of network communication.

[0102] The present application has obvious advantages in communication overhead and delay as shown in Table 1. Specifically, compared with other related methods, the present application can effectively reduce the 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 in a single time can be represented 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, “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] generates and transmits a large amount of checksum data in the checksum challenge stage, resulting in large bandwidth consumption. The ESDRA method in document 2 [B. Kuang, A. Fu, S. Yu, G. Yang, M. Su, and Y. Zhang, “Esdra: An efficient and secure distributed remote attestation scheme for IoT swarms,” IEEE Internet of Things Journal, vol. 6, no. 5, pp. 8372-8383, 2019] and the method in document 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 improved the overhead of the proof node by optimizing, but due to the dependence on the communication of neighbor nodes, additional bandwidth overhead is brought.The NABSA method proposed in document 4 [H. Oguma, A. Yoshioka, M. Nishikawa, R. Shigetomi, A. Otsuka, and H. Imai, “New attestation based security architecture for in-vehicle communication,” in IEEE GLOBECOM 2008 - 2008 IEEE Global Telecommunications Conference. IEEE, 2008, pp. 1-6.] requires each pair of ECUs to communicate with each other, which also leads to significant bandwidth overhead. The ESSO method proposed in document 5 [F. D. P¨ullen, and S. Katzenbeisser, “Ensuring the safe and secure operation of electronic control units in road vehicles,” in 2019 IEEE Security and Privacy Workshops (SPW). IEEE, 2019, pp. 126131] can minimize the bandwidth overhead on a single node, but cannot achieve node identity authentication. Document 6 [J. Van Bulck, J. T. The VulCAN method proposed in [A. Kolesnikov, V. Russell, 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] is lower than the present application in terms of bandwidth requirement of a single node, but its bandwidth consumption will quickly rise with the number of nodes and become unsuitable for large-scale applications. In addition, the communication delay is mainly caused by data transmission of the slow channel and is closely related to the bandwidth overhead. In a practical environment, a typical vehicle network is considered, which contains 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 the automotive Ethernet is much higher than that of the CAN bus, its communication cost can be negligible compared to the CAN bus. In this context, the focus is mainly on the communication delay on the CAN bus. 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 containing n ECUs (located in 10 different domains), the overall communication delay will be 0.67 ms+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.1 ms, so it is relatively small. And because of the collective proof mechanism, the present application supports parallel execution, thereby significantly reducing the communication delay, especially in an environment using the CAN bus, as the number of nodes increases, the delay grows relatively flat. This enables the present application to provide more efficient communication performance in practical applications.

[0103] Table 1 Bandwidth overhead comparison

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

[0105] The present application has obvious advantages in terms of computational overhead, as shown in Table 2. Due to the adoption of the collective attestation mechanism, the entire domain is treated 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 vehicle gateway is far superior to that of the ECU. In addition, in the present application, the main computational overhead is one HMAC operation of the ECU. For a single attestation of a node, it can be expressed as 11.70n ms. The method SRA of 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] requires a series of HMACs to be generated during the attestation node response in the checksum challenge phase, resulting in a large computational overhead. The ESDRA scheme of document 2 [B. Kuang, A. Fu, S. Yu, G. Yang, M. Su, and Y. Zhang, “Esdra: An efficient and secure distributed remote attestation scheme for IoT swarms,” IEEE Internet of Things Journal, vol. 6, no. 5, pp. 8372-8383, 2019] and the FESA document 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 attestation nodes, but the additional overhead caused by the neighbor nodes increased.In the method NABSA of document 4 [H. Oguma, A. Yoshioka, M. Nishikawa, R. Shigetomi, A. Otsuka, and H. Imai, "New attestation based security architecture for in-vehicle communication," in IEEE GLOBECOM 2008 - 2008 IEEE 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 the scheme ESSO of document 5 [F. Kargl, M. Ratschiller, and S. Katzenbeisser, "Ensuring the safe and secure operation of electronic control units in road vehicles," in 2019 IEEE Security and Privacy Workshops (SPW). IEEE, 2019, pp. 126-131] a hash value and two HMACs (one for the sender and one for the receiver) need to be computed for each message. While in the method VulCAN of document 6 [J. Van Bulck, J. T. D. and S. Katzenbeisser, "Ensuring the safe and secure operation of electronic control units in road vehicles," in 2019 IEEE Security and Privacy Workshops (SPW). IEEE, 2019, pp. 126-131] a hash value and two HMACs (one for the sender and one for the receiver) need to be computed for each message. While in the method VulCAN of document 6 [J. Van Bulck, J. T. 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] each message needs to be encrypted and decrypted and two HMACs need to be computed. The present application is more efficient in terms of ECU computational cost, enabling a lower computational overhead, suitable for resource-constrained in-vehicle network environments.

[0106] Table 2 Computational cost comparison

[0107]

[0108]

[0109] It is to be noted that the terms "first", "second", and the like in the description do not necessarily connote any actual physical or chronological order, quantity, or importance. Rather, they are merely used to distinguish one element from another. In the description, "a plurality" means two or more, unless expressly specified otherwise.

[0110] Although the present application has been described in connection with various embodiments thereof, it will be understood that other modifications will be apparent to those of ordinary skill in the art and can be made without departing from the spirit and scope of the application, which are indicated by the following claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude a plurality.

[0111] The above description is further to specific preferred embodiments of the present application and is not to be construed in any way as limiting the present application. It is to be understood by those skilled in the art that a number of further modifications and / or improvements can be made hereto without departing from the scope of the present application.

Claims

1. A cluster remote attestation method suitable for in-vehicle networks, characterized by, Comprise: In passive proof mode: the cloud server initiates 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 to inform the corresponding ECU to complete the identity authentication, generates a first response message and notifies the cloud server through the gateway; the cloud server performs hash verification according to the first response message, and if the verification fails, the cloud server notifies the sub-controller to close the corresponding ECU through the gateway; 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 sub-controller subscribes to the ECU successfully, it sends a confirmation message to the cloud server, and then responds to the request message to inform the corresponding ECU to complete the identity authentication, generates a second response message and notifies the cloud server through the gateway; The cloud server performs hash verification according to the second response message, and if the authentication fails, the cloud server notifies the sub-controller to close the corresponding ECU through the gateway; In offline proof 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 inform the corresponding ECU to complete the identity authentication, generates a third response message and notifies the gateway; The gateway verifies the ECU according to the third response message, and if the verification fails, the gateway notifies the sub-controller to close the corresponding ECU; The cloud server initiates the passive authentication process and sends a request message to the sub-controller through the gateway, comprising: a1, the cloud server initiates the passive authentication process for the predetermined domain or the predetermined ECU, and sends a CRA request message to the vehicle gateway through a secure channel; a2, after the gateway receives the CRA request message, it generates a SOME / IP METHOD message and sends an RA message to the sub-controller of the related domain; The cloud server sends a request message to the gateway, and the gateway generates a subscription message and sends it to the sub-controller, comprising: b1, the cloud server sends a CRA request message to the vehicle gateway through a secure channel; b2, after the gateway receives the CRA request message, it generates and sends an RA SOME / IP EVENT SUBSCRIPTION event subscription message to the sub-controller of the related domain.

2. The cluster remote attestation method applicable to in-vehicle networks according to claim 1, characterized in that, The sub-controller responds to the request message to inform the ECU to complete the identity authentication, generates a response message and notifies the cloud server through the gateway, comprising: a3, the sub-controller that receives the RA message generates a timestamp and the RA CAN RTR frame; a4, the sub-controller receiving the RA message distributes the RA CAN RTR frame to the predetermined ECU in each bus; a5, the ECU that received the RACAN RTR frame generates a RACAN data frame carrying the timestamp and the hash value of its own ID; a6, the ECU receiving the RA CAN RTR frame sends the RA CAN data frame in a5 to the sub-controller; a7, the sub-controller receiving the RA CAN data frame collects the RA CAN data frame of all ECUs; calculates the preset key of each ECU to perform identity authentication on each ECU, thereby generating an 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 payload therefrom and aggregates them into a first CRA response message; a10, the gateway sends the first CRA response message to the cloud server.

3. The cluster remote attestation method applicable to in-vehicle networks according to claim 2, characterized in that, The cloud server performs hash authentication according to the first response message, and if the authentication fails, the gateway is notified to close 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 message of verification failure to the gateway, indicating the index of the failed domain; a13, the gateway locates the ECU that fails verification based on the index, and sends the ID of the ECU that fails verification to the sub-controller; a14, the sub-controller closes the failed ECU.

4. The cluster remote attestation method applicable to in-vehicle networks of claim 1, wherein, The sub-controller sends a confirmation message to the cloud server if the ECU subscription is successful, and then responds to the request message to notify the ECU to cooperate to complete identity authentication, generate a response message and notify the cloud server through the gateway including: b3, the sub-controller sends an ACK confirmation message to the gateway if the subscription of the predetermined ECU is successful; b4, the sub-controller generates a time stamp and a RACAN RTR frame; b5, the sub-controller distributes the RA CAN RTR frame to the predetermined ECU in each bus; b6, the ECU that received the RACAN RTR frame generates a RACAN data frame carrying a timestamp and a hash value of its own ID; b7, the ECU receiving the RA CAN RTR frame sends the RA CAN data frame in b6 to the sub-controller; b8, the sub-controller receiving the RA CAN data frame collects the RA CAN data frame of all ECUs; calculates the preset key of each ECU to perform identity authentication on each ECU, thereby generating a RA SOME / IP EVENT response message; b9, the sub-controller receiving the RA CAN data frame sends all RA SOME / IP EVENT response messages to the gateway.

5. The cluster remote attestation method applicable to in-vehicle networks according to claim 4, characterized in that, The cloud server performs hash authentication according to the response message, and if the authentication fails, the gateway is notified to close the corresponding ECU including: b10, the gateway collects all RA SOME / IP EVENT response messages, extracts the payload 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 message of verification failure to the gateway, indicating the index of the failed domain; b14, the gateway locates the ECU that fails verification based on the index, and sends the ID of the ECU that fails verification to the sub-controller; b15, the sub-controller closes the failed ECU.

6. The cluster remote attestation method applicable to in-vehicle networks of claim 1, wherein, 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 to complete identity authentication, and generates a third response message to notify the gateway including: c1, the gateway sends a RA SOME / IP METHOD SUBSCRIPTION message to the sub-controller for a predetermined domain or a predetermined ECU; c2, after the sub-controller receives the RA SOME / IP METHOD SUBSCRIPTION message, a timestamp and a RA CAN RTR frame are generated; c3, the sub-controller distributes the RA CAN RTR frame to the predetermined ECUs in the bus; c4, the ECU that received the RACAN RTR frame generates a RACAN data frame carrying a timestamp and a hash value of its own ID; c5, the ECU receiving the RA CAN RTR frame sends the RA CAN data frame in c4 to the sub-controller; c6, the sub-controller receiving 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 receiving the RA CAN data frame sends all the RA SOME / IP EVENT response messages to the gateway.

7. The cluster remote attestation method applicable to in-vehicle networks according to claim 6, characterized in that, The gateway verifies the ECU according to the third response message, and if the verification fails, the sub-controller is notified to close the corresponding ECU, including: c8, the gateway collects all the RA SOME / IP EVENT response messages, extracts the payload therefrom and aggregates the payload into a third CRA response message, verifies the hash value in the received third CRA response message, if the verification fails, the ECU that fails to verify is located based on the index of the failure field of the verification failure, and the ID of the ECU that fails to verify is sent to the sub-controller, thereby closing the failed ECU.

8. A cluster remote attestation system suitable for use in an in-vehicle network, characterized by, including: In the passive proof 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 to notify the corresponding ECU to cooperate to complete the identity authentication, generates a first response message and notifies the cloud server through the gateway; the cloud server performs hash verification according to the first response message, and if the verification fails, the sub-controller is notified to close the corresponding ECU through the gateway; In the 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 sub-controller successfully subscribes to the ECU, it sends an acknowledgement message to the cloud server, and then responds to the request message to notify the corresponding ECU to cooperate to complete the identity authentication, generates a second response message and notifies the cloud server through the gateway; The cloud server performs hash verification according to the second response message, and if the authentication fails, the sub-controller is notified to close the corresponding ECU through the gateway; In the offline proof 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 to complete the identity authentication, generates a third response message and notifies the gateway; The gateway verifies the ECU according to the third response message, and if the verification fails, the sub-controller is notified to close the corresponding ECU; 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 a predetermined domain or a predetermined ECU, and sends a CRA request message to the vehicle gateway through a secure channel; a2, after the gateway receives the CRA request message, generates a SOME / IP METHOD message, and sends an RA message to the sub-controller of the related domain; 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 a predetermined ECU; b2, after the gateway receives the CRA request message, generates and sends an RA SOME / IP EVENT SUBSCRIPTION event subscription message to the sub-controller of the related domain.

Images