Digital shadow for remote attestation of vehicle software

Abstract

Systems and methods for performing vehicle software attestation. A system includes a main electronic control unit (ECU) and a verifier system included in a vehicle. The main ECU receives a digital shadow request generated by the verifier system and generates a digital shadow. The digital shadow is based on a unique one-way identifier of a program memory space of the main ECU and a unique one-way identifier of a program memory space of each of a plurality of other ECUs included in the vehicle. The main ECU transmits the digital shadow to the verifier system. The verifier system receives a digital shadow from the main ECU as a first digital shadow, receives a second digital shadow from a digital twin representing software installed in each of the main ECU and the plurality of other ECUs, and determines whether the first digital shadow matches the second digital shadow.

Description

Background Art

[0001] Vehicles include a large number of electronic control units (ECUs). Each ECU may execute software or firmware (collectively referred to herein as "software"), and the software may be updated over time, including via Flash Over the Air (FOTA) updates. Software attestation generally refers to a trust-building mechanism that allows a system (the verifier) ​​to check the integrity of the program memory contents of another system (the prover) against modification, such as modification by malicious code or modification of code that affects regulatory compliance. Summary of the invention

[0002] It is often difficult for a party with a legitimate need to know to be confident that the correct software is installed in each electronic control unit (ECU) of a vehicle. This is particularly difficult for regulators and other third parties who do not have physical or reliable and secure network access to the vehicle or do not have a complete software definition of the vehicle's internals, which vehicle and software manufacturers may not want to provide. In addition, such third parties may need to inspect many vehicles and therefore many modules. For example, there are approximately 1.4 billion cars in the world, and each car may have 50 or even possibly 100 ECUs.

[0003] Therefore, to address these and other technical issues, the examples, aspects, and features described herein use digital twins and digital shadows for vehicle software certification. Digital twins are based on the idea that digital information structures about physical systems can be created as independent entities. This digital information is a "twin" of the information embedded in the physical system itself and is linked to the physical system throughout the life cycle of the system so that modifications to the physical system are also applied to the digital twin. Using digital twins, each original equipment manufacturer (OEM) maintains a digital copy of the digital twin-enabled software installed in one or more ECUs of one or more vehicles to provide the ability to monitor operations, maintenance requirements, and current status as the vehicle goes through its life cycle from manufacturing.

[0004] As used herein, a Digital Shadow (DS) is a cryptographically unique one-way identifier of a vehicle software image. When the software installed on the ECU present in the vehicle and the digital twin, respectively, matches, the same value of the Digital Shadow is obtained from the ECU present in the vehicle and from the digital twin. Since the Digital Shadow is encrypted and is a one-way identifier, the Digital Shadow can be shared with untrusted institutions and over untrusted networks without leaking sensitive information about the ECU (full software definition), the adversary cannot determine the Digital Shadow fingerprint without the software, and the adversary cannot determine the software based on the knowledge of the Digital Shadow or the algorithm.

[0005] For example, an example provides a system for performing vehicle software certification. The system includes a main electronic control unit (ECU) included in the vehicle and a verifier system. The verifier system is configured to generate a digital shadow request and transmit the digital shadow request to the address of the vehicle through a communication network. The main ECU is configured to receive the digital shadow request and generate a unique unidirectional identifier of the program memory space of the main ECU. The main ECU is also configured to receive a unique unidirectional identifier of the program memory space of each of the multiple other ECUs included in the vehicle, generate a digital shadow based on the unique unidirectional identifier of the program memory space of the main ECU and the unique unidirectional identifier of the program memory space of each of the multiple other ECUs, and transmit the digital shadow as a response to the digital shadow request to the verifier system. The verifier system is also configured to receive a digital shadow from the main ECU as a first digital shadow, receive a second digital shadow from a digital twin representing the software installed in each of the main ECU and the multiple other ECUs, determine whether the first digital shadow matches the second digital shadow, and in response to the first digital shadow matching the second digital shadow, set the vehicle to pass the software certification.

[0006] Another example provides a method for performing vehicle software attestation. The method includes: receiving a digital shadow request from a verifier system at a main electronic control unit (ECU) included in the vehicle, and generating a unique one-way identifier of a program memory space of the main ECU using the main ECU. The method also includes receiving a unique one-way identifier of a program memory space of each of a plurality of other ECUs included in the vehicle at the main ECU, and generating a digital shadow using the main ECU based on the unique one-way identifier of the program memory space of the main ECU and the unique one-way identifier of the program memory space of each of the plurality of other ECUs. The method also includes transmitting the digital shadow to the verifier system as a response to the digital shadow request by the main ECU via a communication network.

[0007] Yet another example provides a non-transitory computer-readable medium storing instructions executable by an electronic processor to perform a set of functions. The set of functions includes receiving a digital shadow request from a verifier system, and in response to receiving the digital shadow request, performing the following operations: (i) generating a unique one-way identifier of a program memory space of a master electronic control unit (ECU) included in a vehicle, (ii) receiving a unique one-way identifier of a program memory space of each of a plurality of other ECUs included in the vehicle, (iii) generating a digital shadow based on the unique one-way identifier of the program memory space of the master ECU and the unique one-way identifier of the program memory space of each of the plurality of other ECUs, and (iv) transmitting the digital shadow to the verifier system as a response to the digital shadow request over a communication network.

[0008] Other aspects, features, and embodiments will become apparent by consideration of the detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The accompanying drawings, together with the detailed description below, are incorporated into and form a part of the specification and are used to further illustrate embodiments and conceptual aspects including the claimed subject matter and to explain various principles and advantages of various aspects and embodiments, wherein like reference numerals refer to the same or functionally similar elements in various views.

[0010] Figure 1 is a block diagram of a proof system according to some aspects.

[0011] Figure 2 Schematically illustrates some aspects of Figure 1 The certification system includes the primary vehicle telematics processor.

[0012] Figure 3 Schematically illustrates some aspects of Figure 1 The digital twin included in the proof system.

[0013] Figure 4 is according to some aspects, for including Figure 1 Flowchart of an example method for requesting and verifying a digital shadow of a host vehicle telematics processor and a digital twin in an attestation system.

[0014] Figure 5 According to some aspects, Figure 4 A sequence diagram of the example method.

[0015] Figure 6 Schematically illustrates an example Merkle tree according to some aspects.

[0016] Fig. 7A and Figure 7B Schematically illustrates an architecture of a vehicle electronic control unit represented as a node in an example Merkle tree according to some aspects.

[0017] Figure 8 is a flow chart of an example method of creating a digital shadow in accordance with some aspects.

[0018] Those skilled in the art will appreciate that the elements in the figures are shown for simplicity and clarity and are not necessarily drawn to scale. For example, the sizes of some elements in the figures may be exaggerated relative to other elements to help improve understanding of the embodiments and aspects.

[0019] Apparatus and method components are represented by conventional symbols in the drawings where appropriate, and only those specific details relevant to understanding embodiments and aspects of the claimed subject matter are shown so as not to obscure the disclosure with details that would be readily apparent to one of ordinary skill in the art having the benefit of the description herein. DETAILED DESCRIPTION

[0020] Before explaining any embodiment, aspect, example and feature in detail, it should be understood that the embodiment, aspect, example and feature are not limited in their application to the construction and arrangement details of the components set forth in the following description or shown in the accompanying drawings. Other embodiments, aspects, examples and features are possible and can be practiced or implemented in various ways.

[0021] It should also be noted that multiple hardware- and software-based devices and multiple different structural components can be used to implement embodiments, aspects, examples, and features. In addition, it should be understood that embodiments, aspects, examples, and features may include hardware, software, and electronic components or modules, which, for the purpose of discussion, may be shown and described as if most components are implemented only in hardware. However, a person of ordinary skill in the art will recognize, based on a reading of this detailed description, that in at least one example, the electronic-based aspects described herein may be implemented in software (e.g., stored on a non-transitory computer-readable medium) that can be executed by one or more processors. Therefore, it should be noted that in various cases, multiple hardware- and software-based devices, as well as multiple different structural components, may be utilized. For example, the "control unit" and "controller" described in the specification may include one or more electronic processors, one or more physical memory modules including a non-transitory computer-readable medium, one or more input / output interfaces, and various connections (e.g., a system bus) connecting components.

[0022] For ease of description, some or all of the example systems presented herein are described with a single example of each of their components. Some examples may not describe or illustrate all components of the system. Other examples may include more or less of each of the described components, may combine some components, or may include additional or alternative components.

[0023] As described above, it is difficult for third parties (e.g., parties independent of the vehicle manufacturer, software provider, and vehicle owner or user) to verify the software image on the vehicle. As the amount of software installed on the vehicle and the ease with which such software can be updated (e.g., via Flash Over the Air (FOTA) updates) increases, the difficulty of software certification increases. Similarly, vehicle manufacturers and software providers may not be open to sharing complete software with third parties (such as, for example, vehicle owners and government regulators). Furthermore, communicating with the vehicle over an unreliable or untrusted communication network adds an additional layer of trust requirements.

[0024] Therefore, aspects described herein use digital twins and digital shadows to perform remote software attestation. A digital twin, which may be maintained by a vehicle manufacturer or other party (such as, for example, a vehicle or vehicle equipment original equipment manufacturer (OEM), a software provider, etc.), is a digital copy of the software contained in each ECU of each vehicle. A digital shadow is a cryptographically unique one-way identifier of a software image. As described in more detail below, a third party (e.g., a regulator) may communicate with both the vehicle and the vehicle's digital twin (using private / public key encryption or other secure communication methods) to request a digital shadow. In some aspects, a vehicle and an associated digital twin generate a digital shadow by representing the vehicle ECU as a node within a tree (such as, for example, a Merkle tree). A Merkle tree allows for efficient and secure verification of the contents of a data structure, and in particular, a Merkle tree is a tree in which each leaf node represents a cryptographic hash of a block of data, and each node (parent node) that is not a leaf node is labeled with a cryptographic hash of the label of its child node. For example, for each node of a Merkle tree representing an ECU within a vehicle architecture representing the ECU, a cryptographically unique one-way identifier (such as, for example, a message authentication code (MAC), a checksum, an error detection code, a hash, a keyed hash, etc.) of the memory space of the ECU represented by each leaf node is generated using a unique device key associated with the represented ECU, and the generated node identifier is transmitted to each parent node of the leaf node. Each parent node concatenates the node identifier received from each child node with a similar identifier determined for the ECU represented by the parent node to create a node identifier for the parent node using the unique device key of the ECU represented by the parent node. The node identifier calculated by the top node in the tree (a node without a parent node) represents a digital shadow of the vehicle software image and is transmitted to a third party (e.g., a regulator). The third party compares the digital shadow received from the vehicle with the digital shadow received from the digital twin to determine whether the vehicle passes the software certification, and the digital twin generates the digital shadow using the same vehicle architecture Merkle tree.

[0025] For example, Figure 1 is a block diagram of a certification system 100 according to some aspects. Figure 1As shown, the proof system 100 includes a verifier system 110, a main electronic control unit (ECU) 120 included in a vehicle 125, a vehicle management system 130, and a digital twin 140. The verifier system 110, the main ECU 120, the vehicle management system 130, and the digital twin 140 can communicate through one or more communication networks 150. The one or more communication networks 150 include one or more wireless connections, wired connections, or a combination of both. The one or more communication networks 150 can be implemented using a wide area network and one or more local area networks and combinations or derivatives thereof, such as the Internet (including public and private IP networks), long-term evolution (LTE) networks, 4G networks, 5G networks, and local area networks such as Bluetooth. TM network or Wi-Fi network. It should be understood that in some aspects, Figure 1 The components shown may communicate using the same communication network 150 or different communication networks 150. For example, in some aspects, the verifier system 110 and the vehicle management system 130 may communicate via a communication network that is different from the communication network used by the verifier system 110 to communicate with the master ECU 120, the digital twin 140, or both. It should also be understood that the components included in the attestation system 100 may communicate via one or more intermediate devices, such as, for example, routers, gateways, firewalls, etc. (not shown). In addition, in some aspects, one or more pairs of components included in the attestation system 100 may communicate via dedicated wired or wireless connections.

[0026] The verifier system 110 is associated with an entity (eg, a regulator) that wishes to verify a software image of a vehicle 125. The verifier system 110 includes one or more computing devices, such as, for example, one or more servers.

[0027] The master ECU 120 is the designated point of contact for the verifier system 110 within the vehicle 125. In some aspects, the master ECU 120 is configured to provide functionality in addition to communicating with the verifier system 110. For example, in some aspects, the master ECU 120 is a telematics ECU included in the vehicle. Figure 1 As shown, the vehicle 125 includes one or more additional ECUs (collectively referred to herein as "other ECUs 155" or individually as "ECU 155"). The main ECU 120 can communicate with the other ECUs 155 via one or more wired or wireless communication channels or connections, such as, for example, a bus (e.g., a controller area network (CAN) bus) included in the vehicle 125.

[0028] The vehicle management system 130 includes one or more computing devices, such as, for example, one or more servers. The vehicle management system is associated with an entity, such as, for example, a vehicle manufacturer, OEM, software provider, etc., and stores or has access to identification information of the vehicle 125, such as, for example, a vehicle identification number (VIN) and an identifier (such as, for example, a communication address of the main ECU 120 or another component of the vehicle 125), which allows remote communication with the vehicle 125 via one or more communication networks 150.

[0029] As described above, the digital twin 140 is a digital copy of the software contained in one or more ECUs (e.g., the main ECU 155 and each of the one or more other ECUs 155) in the vehicle 125. In some aspects, the digital twin 140 is included as part of the vehicle management system 130, or can be associated with the same entity associated with the vehicle management system 130. For example, the digital twin 140 can be maintained by an OEM, which allows the OEM to monitor the operation, maintenance needs, and current status of the vehicle 125 as the vehicle goes through its life cycle from manufacturing.

[0030] It should be understood that although Figure 1 The illustrated attestation system 100 includes a single vehicle management system, a single vehicle 125 and associated master ECU 120, and a single digital twin 140, but the attestation system 100 may include multiple vehicle management systems 130 and multiple digital twins 140, which allows the verifier system 110 to verify the software images of multiple vehicles (e.g., by communicating with the master ECU 120 included in each of the multiple vehicles). Figure 1 The configuration shown is for illustration only and should not be considered limiting. Additionally, in some aspects, the attestation system 100 includes multiple verifier systems 110 as described herein, such as, for example, when there are multiple entities verifying the same or different software installed in one or more vehicles 125 .

[0031] As described above, the verifier system 110 includes one or more computing devices, such as, for example, one or more servers. Figure 1 As shown, in some aspects, the verifier system 110 includes an electronic processor 160, a memory 170, and an input / output (I / O) interface 180. It should be understood that the verifier system 110 may include other components (not shown), including, for example, power management components, protection components, human-machine interface (HMI) components. Similarly, in some aspects, the verifier system 110 may include multiple processors, memory modules, interfaces, or combinations thereof.

[0032] Electronic processor 160, which may include, for example, a programmable electronic microprocessor, microcontroller or similar electronic data processing device, is communicatively coupled to memory 170 and I / O interface 180. Electronic processor 160 cooperates with memory 170 and I / O interface 180 and is configured to implement the methods described herein, among other things.

[0033] The memory 170 may be composed of one or more non-transitory computer-readable media and include at least a program storage area and a data storage area. The program storage area and the data storage area may include a combination of different types of memory, such as read-only memory ("ROM"), random access memory ("RAM"), flash memory or other suitable memory devices.

[0034] The electronic processor 160 sends and receives information (e.g., from the memory 170, the I / O interface 180, or a combination thereof) and processes the information by executing one or more software instructions or modules, which can be stored in the memory 170 or another non-transitory computer-readable medium. The software may include firmware, one or more applications, program data, filters, rules, one or more program modules, and other executable instructions. The electronic processor 160 is configured to retrieve from the memory 170 and execute software for performing software certification as described herein, etc. For example, Figure 1 As shown, in some aspects, the memory 170 stores, among other things, a certification program 185 that, when executed by the electronic processor 160, operates as described herein to perform remote software certification of the vehicle 125. Figure 1 As shown, in some aspects, the memory 170 (or a separate memory module accessible by the electronic processor 160) also stores a verifier private key 190 and a vehicle management public key 195. As described in more detail below, the keys 190 and 195 allow the verifier system 110 to communicate securely with other components of the certification system 100 using public key encryption. It should be understood that one or more components of the certification system 100 can establish and use other forms of secure communication, and the use of public key encryption should not be considered limiting. For example, in some aspects, one or more components of the certification system 100 can communicate using symmetric keys. The establishment and exchange of keys in public key encryption systems are known and are not described herein for the sake of brevity. Therefore, with respect to the methods described herein, it should be assumed that key pairs have been established and distributed accordingly for use within the certification system 100. In addition, it should be understood that the use of public key encryption or other mechanisms for secure communication between components of the system 100 is optional. For example, in some aspects, one or more components of system 100 may communicate using public key encryption, digital signatures, or both, and may rely on security features of communication network 150, transmitted data, etc. to provide data security.

[0035] The I / O interface 180 transmits and receives information from devices external to the verifier system 110 (e.g., via one or more communication networks 150). In some aspects, the I / O interface 180 includes one or more transmitters, receivers, or transceivers for wirelessly communicating with external devices. Similarly, in some aspects, the I / O interface 180 includes one or more ports for receiving a cable, such as, for example, an Ethernet cable or other type of cable that allows the verifier system 110 to communicate with an external device via a wired connection. It should be understood that the I / O interface 180 can communicate with one or more external devices via one or more wired connections, wireless connections, or a combination thereof.

[0036] The vehicle management system 130 may include similar components as those shown for the verifier system 110. For example, although not shown in Figure 1 , but the vehicle management system 130 may include one or more electronic processors, one or more memory modules, and one or more I / O interfaces, as described above with respect to the verifier system 110. In contrast to the verifier system 110, the memory included in the vehicle management system 130 may store a vehicle management private key and a verifier public key, as described above, which allows the vehicle management system 130 to securely communicate with external devices and systems, such as, for example, the verifier system 110. As described above, the memory included in the vehicle management system 130 may store an identifier of the vehicle 125 (such as, for example, a VIN), and an associated identifier of the master ECU 120 (such as, for example, an address). In some aspects, the vehicle management system 130 may store additional information about the vehicle 125, one or more ECUs included in the vehicle 125, an associated digital twin 140, or a combination thereof. For example, in some aspects, the vehicle management system 130 may store an identifier of a digital twin 140 associated with the vehicle 125, which the vehicle management system 130 may provide to the verifier system 110 to identify what digital twin 140 the verifier system 110 should use to perform software attestation of the vehicle 125.

[0037] The master ECU 120 may also include components similar to those of the verifier system 110. For example, Figure 2 As shown, in some aspects, the master ECU 120 includes an electronic processor 200, a memory 205, and an I / O interface 210, which may function similarly to the electronic processor 160, the memory 170, and the I / O interface 180 described above with respect to the verifier system 110. As described with respect to the verifier system 110, the schematic illustration of the components included in the master ECU 120 is provided as one example configuration, and the master ECU 120 may include additional components.

[0038] like Figure 2As shown, the memory 205 included in the master ECU 120 stores a digital shadow program 215 that, when executed by the electronic processor 200, operates as described herein to generate a digital shadow, such as, for example, in response to receiving a request from the verifier system 110. Figure 2 As shown, in some aspects, the memory 205 (or a separate memory module accessible by the electronic processor 200) also stores a verifier public key 220 and a device key 225. As described in more detail below, the verifier public key 220 allows the master ECU 120 to authenticate data received from the verifier system 110, such as, for example, by using a digital signature. The device key 225 is unique to the master ECU 120 and, as described below, is used by the master ECU 120 to create a digital shadow, and the digital twin of the master ECU 120 uses the same unique device key 225 to similarly create a digital shadow.

[0039] like Figure 2 As shown, the memory 205 also includes a program memory space 230 for storing software executable by the electronic processor 200. The software stored in the program memory space 230 represents the software that the verifier system 110 wants to verify. It should be understood that Figure 2 The components included in the memory 205 shown in FIG. 1 may be distributed in a plurality of memory modules of the main ECU 120 and are not limited to being stored in the same module.

[0040] Although not shown, one or more other ECUs 155 included in the vehicle 125 include similar components as the master ECU 120, including the digital shadow program 215 (or version thereof), a unique device key, and program memory space to store software that the verifier system 110 wishes to verify. As described in more detail below, these other ECUs 155 included in the vehicle 125 communicate (directly or indirectly) with the master ECU 120, rather than directly with the verifier system 110, wherein the master ECU 120 is configured with a complete digital shadow of the vehicle 125, which the master ECU 120 transmits to the verifier system 110.

[0041] Figure 3 Schematically illustrated is a digital twin 140 included in the attestation system 100 according to some aspects. Like the master ECU 120, the digital twin 140 includes an electronic processor 300, a memory 305, and an I / O interface 310, the functions of which may be similar to the electronic processor 200, the memory 205, and the I / O interface 210 described above with respect to the master ECU 120. As described with respect to the master ECU 120, the schematic illustration of the components included in the digital twin 140 is provided as one example configuration, and the digital twin 140 may include additional components, and Figure 3The components of the digital twin 140 shown can be distributed across multiple computing devices. For example, in some aspects, the digital twin 140 is maintained as part of one or more database systems, where a device (electronic processor) separate from the digital twin 140, such as, for example, the vehicle management system 130, can access the database system to generate a digital shadow as described herein. Therefore, the digital twin 140 can be implemented using multiple computing devices.

[0042] like Figure 3 As shown, a memory 305 included in the digital twin 140 stores a digital shadow program 215 that, when executed by the electronic processor 300, operates as described herein to generate a digital shadow, such as, for example, in response to receiving a request from the verifier system 110. In some aspects, the digital shadow program 215 executed by the digital twin 140 is the same as the digital shadow program 215 executed by the master ECU 120. However, the digital shadow program 215 executed by the digital twin 140 may also be different from the digital shadow program 215 executed by the master ECU 120 to account for the fact that the digital twin 140 digitally represents software for multiple ECUs included in the vehicle 125, and therefore the digital shadow may be constructed in a manner different from the master ECU 120, which communicates with other ECUs in the vehicle 125 to generate the digital shadow. However, even if the digital shadow programs 215 executed by the digital twin 140 and the main ECU 120 are different, when the software installed on the vehicle 125 matches the software maintained in the digital twin 140, the resulting digital shadows created by each program 215 should match.

[0043] like Figure 3 As shown, in some aspects, the memory 305 (or a separate memory module accessible by the electronic processor 300) also stores the verifier public key 220 and the device key 225, and includes a program memory space 330. As previously described, the verifier public key 220 allows the digital twin 140 to authenticate data received from the verifier system 110, such as, for example, by using a digital signature. Also as previously described, the device key 225 is unique to the master ECU 120 and is used by the digital twin 140 to create a digital shadow as described below. The program memory space 330 stores software that should be installed in the program memory space 230 of the master ECU 120, and similar to how the master ECU 120 creates a digital shadow of the program memory space 230, the digital twin 140 creates a digital shadow of the program memory space 330. When the program memory space 230 and the program memory space 330 store the same software, the created digital shadows match.

[0044] like Figure 3As shown, since the digital twin 140 represents software installed on multiple ECUs (not just the main ECU 120) of the vehicle 125, the digital twin 140 also includes program memory spaces (collectively referred to as program memory spaces 340 or individually referred to as program memory spaces 340) of one or more other ECUs 155 included in the vehicle 125, wherein each program memory space 340 stores software that should be installed in the corresponding other ECU 155 of the vehicle. Similarly, the digital twin 140 stores a unique device key (collectively referred to as a unique device key 345 or individually referred to as a unique device key 345) for each such other ECU 155. It should be understood that Figure 3 The components shown included in memory 305 can be distributed among multiple memory modules of the digital twin 140 and are not limited to being stored in the same module or even on the same device.

[0045] Figure 4 is a flow chart of an example method 400 for requesting and verifying a digital shadow from a master ECU 120 and a digital twin 140 included in an attestation system 100, according to some aspects. The method 400 is described herein as being performed by the verifier system 110, and specifically, by the electronic processor 160 executing the attestation program 185.

[0046] like Figure 4 As shown, in some aspects, the method 400 includes the verifier system 110 issuing an address request to the vehicle management system 130 (at block 405 ). Figure 5 The sequence diagram in and Algorithm 1 set forth below (where, as an example, OEM represents the vehicle management system 130 and the regulator represents the verifier system 110) provide further details about the method 400, and in particular the address request. Figure 5 As shown, the verifier system 110 may request an address by generating (via the electronic processor 160 executing the certification program 185) an address request. In some aspects, the address request includes an identifier of the vehicle 125 (such as, for example, the VIN of the vehicle 125) and a random number. The verifier system 110 uses the verifier private key 190 (REG PRI ) signs the address request (to create a signed address request) and uses the public key 195 (OEM PUB ) encrypts the signed address request (concatenated with the identifier and random number in plain text) (to create an encrypted address request). The verifier system 110 transmits the encrypted address request to the vehicle management system 130 via the communication network 150.

[0047] The vehicle management system 130 receives the encrypted address request (by executing a certification program executed by an electronic processor of the vehicle management system 130) and uses a private key (OEM PRI ) decrypts the encrypted address request and passes the public key (REG PUB ) to verify the signed address request. The vehicle management system 130 can verify the signed address request by using the public key (REG PUB ) decrypts the signed address request to verify the signed address request to reveal the vehicle identifier and the random number, which the vehicle management system 130 can compare with the plaintext version also included in the address request. As described in more detail below, the vehicle management system 130 uses the random number obtained from the decrypted address request to authenticate itself to the verifier system 110 by sending the revealed random number back to the verifier system 110 in an address response.

[0048] In response to the address request for verification of the signature, the vehicle management system 130 determines, based on the stored data, an identifier (address, ADR) of the master ECU 120 installed in the vehicle 125 identified by the identifier included in the address request. VIN ), and generates an address response. Figure 5 As shown, in some aspects, the address response includes an identifier of the master ECU 120 and the random number included in the address request. As described above, the vehicle management system 130 can return the random number in the address response to prove to the verifier system 110 that the vehicle management system 130 is able to reveal the provided random number and is therefore an authorized vehicle management system 130 (with access to the private key associated with the vehicle management public key 195).

[0049] The vehicle management system 130 uses a private key (OEM PRI ) signs the created address response (to create a signed address response) and uses the public key (REG PUB ) encrypts the signed address response (to create an encrypted address response). The vehicle management system 130 then transmits the encrypted address response to the verifier system 110 via the communication network 150.

[0050] Verifier system 110 receives the encrypted address response and uses verifier private key 190 (REG PRI ) decrypts the encrypted address response and passes the vehicle management public key 195 (OEM PUB ) to verify the signed address response. As described above, the verifier system 110 can verify the signed address response by using the vehicle management public key 195 (OEM PUB) decrypts the signed address response and confirms that the random number returned in the address response is the random number originally sent by the verifier system 110 to verify the signed address response.

[0051] It should be appreciated that the address request described above may be an optional part of the method 400. For example, in some aspects, the verifier system 110 may have access to the address of the vehicle 125 (e.g., the master ECU 120), and may not need to request the address from the vehicle management system. Furthermore, even in the case where the address of the vehicle 125 is maintained external to the verifier system 110, the verifier system 110 may access or request the address in a variety of ways, and in particular, the aspects described herein are not limited to use with the address request described herein.

[0052] Back to Figure 4 In response to receiving (and optionally verifying) the requested vehicle address (at block 405), the verifier system 110 issues a digital shadow request to the vehicle 125 (at block 410) using the information received in the address response from the vehicle management system 130. Similarly, Figure 5 The sequence diagram in provides further details about the digital shadow commands. Specifically, Figure 5 As shown, to create a digital shadow request, the verifier system 110 generates a random seed (at block 465) and includes the random seed in the digital shadow request. The digital shadow request also includes a random seed using the verifier private key 190 (REG PRI ) signed random seed (to create a signed digital shadow request), and transmit the signed digital shadow request to the address of the vehicle 125 (the address ADR of the master ECU 120) VIN ), such as, for example, transmitted to the master ECU 120 via the communication network 150. Also, as described above, the use of a digital signature is optional.

[0053] like Figure 4 As shown, in response to receiving a digital shadow (DS VEH ) In response to the digital shadow request (at block 415), the verifier system 110 issues another (second) digital shadow request to the digital twin 140 (at block 420). Figure 5 The sequence diagram in provides further details about the digital shadow commands issued to the digital twin 140. Figure 5 As shown, to create a second digital shadow request for the digital twin 140, the verifier system 110 includes the previously generated random seed and the verifier private key 190 (REG PRI) signed seed (to create a signed second digital shadow request), and transmit the signed second digital shadow request to the digital twin 140. In some aspects, rather than requesting the digital shadows serially (waiting until a digital shadow is successfully received from the vehicle 125), the verifier system 110 may request the digital shadows in parallel or at least in an overlapping manner. However, in the case where the vehicle 125 may not be able to access the communication network 150 to communicate with the verifier system 110, waiting until a digital shadow is received from the vehicle 125 can avoid making a request to the digital twin 140.

[0054] like Figure 5 As shown, in response to receiving a digital shadow (DS DT )(Second Digital Shadow)(At block 425), the verifier system 110 determines the first digital shadow (DS VEH ) is the same as the second digital shadow (DS DT ) matches (at block 430). In response to the first digital shadow matching the second digital shadow (at block 430), the verifier system 110 sets (records, marks, etc.) the vehicle 125 as being software certified (at block 435). Alternatively, in response to the first digital shadow not matching the second digital shadow (at block 430), the verifier system 110 sets the vehicle 125 as being software uncertified (at block 440).

[0055] Algorithm 1: Remote Attestation Using Digital Shadow

[0056]

[0057] As described above, the Digital Shadow is a cryptographically unique one-way identifier of the vehicle software image. When the software installed on the ECU present in the vehicle and the digital twin, respectively, matches, the same value of the Digital Shadow is obtained from the ECU present in the vehicle and from the digital twin. Since the Digital Shadow is encrypted and is a one-way identifier, the Digital Shadow can be shared with untrusted organizations and over untrusted networks without leaking sensitive information about the ECU (full software definition), the adversary cannot determine the Digital Shadow fingerprint without the software, and the adversary cannot determine the software based on knowledge of the Digital Shadow or the algorithm.

[0058] In some aspects, the main ECU 120 and the digital twin 140 create digital shadows of their respective memory spaces using, for example, message authentication codes (MACs), checksums, error detection codes, hashes, keyed hashes, etc. of the program memory space, where the resulting identifier is encrypted using the unique device key 225. In some aspects, the main ECU 120 and the digital twin 140 each create a single digital shadow that represents not only the program memory spaces 230, 330 of the main ECU 120 and the digital twin 140, respectively, but also the program memories of one or more other ECUs 155 included in the vehicle 125. In some aspects, the main ECU 120 and the digital twin 140 use Merkle trees to create digital shadows representing the software spaces of multiple ECUs. As described above, Merkle trees allow for efficient and secure verification of the contents of data structures, and specifically, as Figure 6 As shown, it is a tree 600 in which each leaf node (collectively, “leaf nodes” 605 and individually, “leaf node 605”) represents a cryptographic hash of a block of data, and each node that is not a leaf node (parent nodes, collectively, “parent nodes 610” and individually, “parent node 610”) is labeled with the cryptographic hash of the data and the labels of its children, such as, for example, by concatenating the hashes.

[0059] For example, for each node of a Merkle tree representing an ECU within a vehicle architecture of the ECU, a cryptographically unique one-way identifier of the memory space of the ECU represented by each leaf node is generated using a unique device key associated with the represented ECU, and the generated node identifier is transmitted to each parent node of the leaf node. Each parent node concatenates the node identifier received from each child node with a similar identifier determined for the ECU represented by the parent node to create a node identifier for the parent node using the unique device key of the ECU represented by the parent node. The node identifier created by the top node in the tree (a node without a parent node) represents a digital shadow of the vehicle software image and is transmitted to the verifier system 110.

[0060] Fig. 7A and Figure 7B According to some aspects, the architecture of a vehicle ECU is schematically illustrated represented as a node in a Merkle tree 700A and 700B, respectively. Fig. 7A An example Merkle tree 700A is shown for organizing vehicle ECUs in a domain-based vehicle architecture, where vehicle gateway 1 (VG1) and vehicle gateway 2 (VG2) redundantly control the same domain controller (DC) (denoted as DC1, DC2, DC3, and DC4). Fig. 7A As shown, each domain controller (DC1, DC2, DC3 and DC4) controls a different group of vehicle ECUs.

[0061] Using the example Merkle tree 700A, creating a hash would be specified by the following generalized equation:

[0062] HkD xx =hash(ECU xx )

[0063] hD x = hash(DC x |hEx1|…|hExe d )

[0064] DC x has e d children

[0065] hV1=hash(VG1|hDC1|…|hDC4)

[0066] hV2=hash(VG2|hDC1|…|hDC4)

[0067] ECU master 120verifies hV1=hV2

[0068] DS=hash(h(ECU master)|hV1)

[0069] As shown in the generalized equation above, since VG1 and VG2 redundantly control the same DC, they should generate the same hash value provided to the master ECU 120. Therefore, the master ECU 120 can verify that the hashes received from VG1 and VG2 match, and in response to the hashes matching, the master ECU 120 can use one of the hashes (e.g., the hash from VG1) to create a final hash (digital shadow).

[0070] Figure 7B An example Merkle tree 700B is shown for organizing vehicle ECUs in a domain-based vehicle architecture, where VG1 and VG2 independently control different DCs for redundancy. Using the example Merkle tree 700B, creating a hash will be specified by the following generalized equation:

[0071] HkD xx =hash(ECU xx )

[0072] hD x =hash(DCx|hEx1|…|hExe d )

[0073] DC x has e d children.

[0074] hV1=hash(VG1|hDC1|hDC2)

[0075] hV2=hash(VG2|hDC3|hDC3)

[0076] DS=hash(h(ECU Master)|hV1|hV2)

[0077] It should be understood that Fig. 7A and 7B The vehicle architecture and associated Merkle tree shown represent example architectures and trees, and other architecture and tree configurations are possible.

[0078] Using a Merkle tree as described above to represent the architecture of the ECUs included in the vehicle 125 allows the master ECU 120 and the associated digital twin 140 to generate a digital shadow for transmission to the verifier system 110 that represents the software images of multiple ECUs included in the vehicle 125 . Figure 8 is a flow chart of an example method 800 for creating a digital shadow. Algorithms 2 and 3 set forth below provide further details regarding method 800, and in particular, the generation of a digital shadow by an ECU. For the sake of brevity, method 800 is described herein as being performed by a master ECU 120, and in particular, by an electronic processor 200 executing a digital shadow program 215. However, it should be understood that when the software image of the ECU matches the corresponding software image of the ECU maintained in the digital twin 140, a similar method 800 may be executed via the digital twin 140 (via the electronic processor 300 executing the digital shadow program 215) to create a digital shadow that matches the digital shadow created via the master ECU 120.

[0079] like Figure 8 As shown, the method 800 includes receiving a digital shadow request from the verifier system 110 via the master ECU 120 at block 805 (as described above with reference to Figure 4 The above reference Figure 4 and 5 In some aspects, the digital shadow request includes a seed generated by the verifier system 110 and a private key 190 (REG PRI ) to sign (encrypt) the generated seed.

[0080] like Figure 8As shown, in some aspects, in response to receiving the digital shadow request, the master ECU 120 verifies that the vehicle 125 is in a predetermined state before processing the digital shadow request (at block 810). The predetermined state can be a "safe" state, where processing power can be used to create a digital shadow when a communication network (or a specific state of a communication network) is available, when a software update is not in progress, when the vehicle 125 is operating in a specific operating mode, when the vehicle is experiencing or not experiencing a specific operating event, or a combination thereof.

[0081] After optionally confirming that the vehicle 125 is in a predetermined state (at block 810), the master ECU 120 may verify the signature of the digital shadow request (at block 815). As described above, in some aspects, the digital shadow request includes a seed generated by the verifier system 110 and a signature signed with the verifier private key 190 (REG PRI ) encrypted with the generated seed. Therefore, the master ECU 120 can PUB ) decrypts the encrypted seed to verify the received digital shadow request. When the encrypted seed matches the unencrypted seed included in the request, the master ECU 120 verifies that the digital shadow request was generated by the verifier system 110 (and not an impostor). When the encrypted seed does not match the unencrypted seed, the master ECU 120 can reject the digital shadow request, such as by ignoring the request. In some aspects, the master ECU 120 can also alert the verifier system 110, the vehicle management system 130, or both, of the rejected request. As described above, the use of digital signatures is optional.

[0082] In response to optionally validating the digital shadow request (at block 815), the master ECU 120 sends the seed included in the digital shadow request to each slave ECU (or other device) as represented in the applicable Merkle tree (at block 820). The master ECU 120 may select a seed based on the applicable Merkle tree (e.g., identified by a unique identifier or other mechanism for identifying and communicating with the slave ECUs) and the total number of such child nodes (Num child ) to maintain a list of sub-ECUs, which allows the main ECU 120 to identify how many sub-ECUs the main ECU 120 must send seeds to and how many sub-ECUs should provide responses to the seeds that the main ECU 120 needs to build the requested digital shadow for the vehicle 125.

[0083] The master ECU 120 also generates a unique one-way identifier, such as, for example, a message authentication code (MAC), for the program memory space 230 of the master ECU 120 (at block 825). To prevent the master ECU 120 (or a different one) from submitting a previously generated digital shadow to the verifier system 110 in response to a received request, the master ECU 120 generates a MAC for the program memory space 230 based on a seed included in the digital shadow request. Specifically, the master ECU 120 generates a MAC for the program memory space 230 by starting at the seed (the location within the program memory space 230 indicated by the seed) and moving to the end of the program memory space 230 (Number 100) before restarting at the beginning (1) of the program memory space 230. mem ). In some aspects, as the master ECU 120 steps through the program memory space 230 starting from the seed, the master ECU 120 concatenates the data stored at each location of the program memory space 230 to generate a new, rearranged version of the program memory space 230, and then generates a MAC of the rearranged program memory space 230. Thus, the seed allows the verifier system 110 to ensure that the master ECU 120 generates a digital shadow of the current software image, rather than simply resubmitting a previously generated digital shadow (because the previously generated digital shadow may have been generated using a different seed and therefore does not match the digital shadow provided via the digital twin 140). Again, it should be understood that the use of a seed is optional. In the event that the digital shadow request does not include a seed, the master ECU 120 may transmit other data to each sub-ECU to trigger the generation of a unique unidirectional identifier for the program memory space of each sub-ECU, such as, for example, an identifier request. Therefore, the use of random seeds described herein should not be considered limiting. In addition, although the aspects described herein continuously rearrange the memory space, other patterns, such as pseudo-random patterns, may also be used. For example, in some aspects, the ECU memory space can be rearranged by starting at a position corresponding to the received seed and then skipping a predetermined number of memory locations (wherein multiple cycles through the memory are performed until all memory locations have been processed). Similarly, when rearranging the memory space, the received seed can be used to set a predetermined number of memory locations to be skipped (from a static or dynamic starting position). In addition, it should be understood that in some aspects, only a subset of the memory locations are used to generate the digital shadow, which can reduce computational requirements on the ECU. However, generating the digital shadow based on the entire memory space can identify software modifications that might otherwise be missed when only a portion of the memory space is processed.

[0084] As shown in Algorithm 2 described below, in some embodiments, a unique one-way identifier (MACECU ) includes a unique device key 225 based on the master ECU 120 (ECU KEY ). As also shown in Algorithm 2 and described above, the master ECU 120 generates not only a unique identifier for its own program memory space 230, but also a digital shadow representing the software image of multiple ECUs included in the vehicle 125. Creating this "global" digital shadow for the vehicle 125 reduces the number of communications required between the master ECU 120 and the verifier system 110, which may be difficult given the availability of communication networks, given the mobility of the vehicle 125 and the fact that communications may only occur when the vehicle 125 is operating. Therefore, in creating an identifier (MAC) for the program memory space 230, ECU ), the master ECU 120 determines whether it has received each sub-ECU (sub-ECU i ) of the corresponding program memory space (e.g., MAC i ).

[0085] When a sub-ECU that receives a seed (or other type of identifier request) from the main ECU 120 has one or more sub-ECUs (according to an applicable Merkel tree), similar to the main ECU 120, the sub-ECU generates a unique unidirectional identifier (e.g., MAC) for its corresponding program memory space (e.g., by rearranging the program memory space according to the seed received from the main ECU 120 and generating a MAC of the rearranged program memory space using the sub-ECU's unique device key), and also forwards the received seed (or other form of identifier request) to each sub-node ECU, and waits for a response from the sub-node ECU similar to the main ECU 120.

[0086] Alternatively, when a child ECU receives a seed (or other type of identifier request) from a parent node ECU (e.g., master ECU 120 or a different ECU) and the receiving child ECU does not have any child nodes (Num child=0), the child ECU is considered a leaf node in the Merkel tree and uses its unique device key to generate a unique unidirectional identifier (e.g., MAC) for its program memory space, similar to the master ECU 120 described above for block 830. However, since the leaf node ECU does not have any child nodes, in this case, the child ECU does not forward a seed or similar identifier request to any additional ECU, nor does it wait for an identifier from any child ECU. Instead, the leaf node ECU generates a unique unidirectional identifier (e.g., a MAC based on the ECU's device key) and returns the generated identifier to each parent node ECU. Further details on an example of generating a unique unidirectional identifier at a leaf node are given in Algorithm 3 below.

[0087] return Figure 8 In response to receiving the identifier of the memory space of each corresponding sub-ECU (at block 830), the master ECU 120 generates a digital shadow (DS VEH ) in response to the digital shadow request received from the verifier system 110 (at block 835), and generates a digital shadow (DS VEH ) is sent to the verifier system 110, such as via the communication network 150 (at block 840). In some aspects, the master ECU 120 passes the MAC (MAC ECU ) (as generated using the device key 225) and the generated MAC (MAC 1 …MAC NumChild ) (as generated using the unique device key of the sub-ECU) to generate a digital shadow, and to generate a MAC (MAC) of the resulting concatenation based on the unique device key 225 of the master ECU 120. Node ), the MAC (because the master ECU 120 has no parent node) is transmitted to the verifier system 110. Figure 5 As shown, in some aspects, before sending the digital shadow to the verifier system 110, the master ECU 120 uses the verifier public key 220 (REG PUB ) encrypts the generated digital shadow, which protects the transmitted digital shadow because only the verifier system 110 (storing the verifier private key 190 (REG PRI )) can decrypt the transmission and receive the generated digital shadow.

[0088] Algorithm 2: Constructing the parent node MAC

[0089]

[0090] Algorithm 3: Constructing Leaf Mode MAC

[0091]

[0092] As mentioned above about Figure 4 As described, the verifier system 110 receives digital shadows (generated similarly to the method 800 described above) from both the master ECU 120 and the digital twin 140, and compares the digital shadows (at block 430). As described above, in some aspects, the digital shadows transmitted by the master ECU 120, the digital twin 140, or both may be encrypted with the verifier public key 220 prior to transmission to the verifier system 110. Thus, in some aspects, in order to compare the received digital shadows, the verifier system 110 may decrypt one or both digital shadows with the verifier private key 190.

[0093] When the digital shadow received from the master ECU 120 matches the digital shadow received from the digital twin 140, the verifier system 110 can confirm that the vehicle 125 has the software maintained in the currently installed digital twin 140, and can therefore ensure that the vehicle 125 has the appropriate software installed and does not include outdated software, malware, non-compliant software, etc. In some aspects, in response to determining that the received digital shadow does not match, the verifier system 110 can record the problem, and in some aspects, can take additional actions, such as, for example, pushing a software update to the vehicle 125 directly or via another system or device (e.g., the vehicle management system 130). Alternatively or additionally, the additional actions may include generating a notification (paper, electronic, or both) to be sent to the vehicle owner, the vehicle management system 130, denying the vehicle 125 access to a resource, or a combination thereof. For example, in response to determining that the received digital shadow does not match, the vehicle 125 may be denied access to a section of highway or other road, denied access to external services or functions (such as, for example, navigation signals or vehicle-to-vehicle communications), denied access to one or more on-board vehicle services or functions (such as, for example, shutting down one or more services or functions provided by one or more ECUs included in the vehicle 125), or a combination thereof.

[0094] Thus, among other things, the examples described herein provide vehicle software attestation. Compared to the use of sentinels, local clocks, or other software checking solutions (which may be easily bypassed or not scalable given processing power and communication requirements), the methods and systems described herein provide efficient and effective remote software attestation over unreliable networks and in the face of low trust requirements. Thus, the methods and systems described herein provide a technical advancement over current attestation strategies.

[0095] In the foregoing description, specific examples, aspects and features have been described. However, it will be appreciated by those skilled in the art that various modifications and variations may be made without departing from the scope of the invention as set forth in the appended claims. Therefore, the description and drawings are to be regarded as illustrative rather than restrictive, and all such modifications are intended to be included within the scope of the present teachings.

[0096] In this document, relative terms such as first and second, top and bottom, etc. are used only to distinguish one entity or action from another entity or action, and do not necessarily require or imply any actual such relationship or order between such entities or actions. The terms "include", "comprising", "having", "having", "containing", "covering", "include", "containing" or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes, has, contains, or contains a list of elements includes not only those elements, but may also include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element beginning with "includes...", "having...", "including...", or "containing..." does not, without more limitations, exclude the presence of additional identical elements in the process, method, article, or apparatus that includes, has, contains, or contains the element. The terms "a" and "an" are defined as one or more unless otherwise expressly stated herein. The terms "substantially," "essentially," "about," "approximately," or any other versions thereof, are defined as approximating what one of ordinary skill in the art understands, and in one non-limiting embodiment, within 10%, in another embodiment within 5%, in another embodiment within 1%, and in another embodiment within 0.5%. The term "coupled," as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. A device or structure that is "configured" in a particular way is configured in at least that way, but may also be configured in ways that are not listed.

[0097] Various features, aspects, advantages and embodiments are set forth in the following claims.

Claims

1. A system for performing vehicle software certification, the system include: The main electronic control unit (ECU) included in the vehicle; as well as The validator system is configured to: Generate a digital shadow request, and Transmitting the digital shadow request to the vehicle’s address via the communication network, The main ECU is configured as: Receive digital shadow requests, Generates a unique unidirectional identifier for the main ECU's program memory space, receiving a unique unidirectional identifier of a program memory space of each of a plurality of other ECUs included in the vehicle, generating a digital shadow based on a unique unidirectional identifier of a program memory space of the master ECU and a unique unidirectional identifier of a program memory space of each of the plurality of other ECUs, and The digital shadow is transmitted as a response to the digital shadow request to the verifier system, the verifier system being further configured to: Receive the digital shadow from the master ECU as the first digital shadow, receiving a second digital shadow from a digital twin representing software installed in the master ECU and each of the plurality of other ECUs, determining whether the first digital shadow matches the second digital shadow, and In response to the first digital shadow matching the second digital shadow, the vehicle is configured to be software certified.

2. The system of claim 1, wherein the verifier system is further configured to obtain the address of the vehicle by: generating an address request, the address request including an identifier of the vehicle, Sign the address request with the private key associated with the validator system to create a signed address request, encrypting the signed address request with a public key associated with the vehicle management system to create an encrypted address request, and Transmit the encrypted address request to the vehicle management system.

3. The system of claim 2, wherein the vehicle management system is configured to: Receive encrypted address requests, decrypt the encrypted address request with the private key associated with the vehicle management system to obtain the signed address request, Verify the signed address request via the public key associated with the verifier system, and In response to a request to verify a signed address, the following operations are performed: determining an address of a vehicle identified by an identifier included in the address request, generating an address response, the address response including an address of the vehicle, Sign the address response with the private key associated with the vehicle management system to produce a signed address response, encrypting the signed address response with a public key associated with the validator system to create an encrypted address response, and Transmit the encrypted address response to the validator system.

4. The system of claim 3, wherein the verifier system is further configured to: Receive the encrypted address response, decrypt the encrypted address response with the private key associated with the validator system to obtain the signed address response, Verifying the signed address response via the public key associated with the vehicle management system, and In response to verifying the signed address response, a first digital shadow is generated using the address included in the address response.

5. The system of claim 1, wherein the verifier system is further configured to generate a random seed and include the random seed in the digital shadow request. 6 . The system of claim 5 , wherein the master ECU is configured to generate a unique unidirectional identifier for the program memory space of the master ECU based on a random seed.

7. The system of claim 6, wherein the master ECU is configured to generate a unique one-way identifier for the program memory space of the master ECU based on a random seed by: generating a message authentication code for the program memory space of the master ECU starting from the random seed until the end of the program memory space of the master ECU and then starting from the beginning of the program memory space.

8. The system of claim 1 , wherein the verifier system is further configured to sign the digital shadow request with a private key of the verifier system to create a signed digital shadow request, and wherein the master ECU is configured to verify the signed digital shadow request using a public key of the verifier system.

9. The system of claim 1, wherein the master ECU is further configured to verify that the vehicle is in a predetermined mode in response to receiving the digital shadow request.

10. The system of claim 1 , wherein the master ECU is further configured to request a unique unidirectional identifier from each of the plurality of other ECUs by transmitting a random seed included in the digital shadow request to each of the sub-ECUs of the master ECU as represented in a tree structure of the vehicle architecture. The system of claim 10 , wherein the tree structure comprises a Merkel tree.

12. The system of claim 10, wherein the master ECU is configured to generate the first digital shadow by generating a message authentication code that is a concatenation of a unique one-way identifier received from each sub-ECU and a unique one-way identifier of a program memory space of the master ECU.

13. The system of claim 10, wherein the unique one-way identifier of the program memory space of the master ECU comprises a message authentication code of the program memory space of the master ECU based on a unique device key of the master ECU.

14. The system of claim 1, wherein the verifier system is further configured to generate a second digital shadow request and transmit the second digital shadow request to the digital twin, wherein the digital twin transmits the second digital shadow to the verifier system as a response to the second digital shadow request.

15. The system of claim 14, wherein the verifier system generates and transmits the second digital shadow request in response to receiving the first digital shadow from the master ECU.

16. A method for performing vehicle software certification, the method include: receiving, at a main electronic control unit (ECU) included in a vehicle, a digital shadow request from a verifier system; Generate a unique one-way identifier for the program memory space of the main ECU using the main ECU, receiving, at the master ECU, a unique unidirectional identifier of a program memory space of each of a plurality of other ECUs included in the vehicle; generating, using the master ECU, a digital shadow based on a unique one-way identifier of a program memory space of the master ECU and a unique one-way identifier of a program memory space of each of a plurality of other ECUs; as well as The digital shadow is transmitted to the verifier system as a response to the digital shadow request via the communication network using the master ECU.

17. The method according to claim 16, further comprising: include: At the verifier system, receiving the digital shadow from the master ECU as a first digital shadow; receiving, at a verifier system, a second digital shadow from a digital twin representing software installed in the master ECU and each of the plurality of other ECUs; Determining, using the verifier system, whether the first digital shadow matches the second digital shadow; as well as In response to the first digital shadow matching the second digital shadow, the vehicle is configured to be software certified.

18. The method of claim 16, wherein generating the unique one-way identifier of the program memory space of the master ECU comprises rearranging the program memory space of the master ECU based on a seed included in the digital shadow request and generating the unique one-way identifier of the rearranged program space of the master ECU.

19. A non-transitory computer readable medium storing instructions executable by an electronic processor to perform a set of functions, the set of functions include: receiving a digital shadow request from a verifier system; as well as In response to receiving a digital shadow request, the following operations are performed: Generates a unique unidirectional identifier for the program memory space of a main electronic control unit (ECU) included in the vehicle, receiving a unique unidirectional identifier of a program memory space of each of a plurality of other ECUs included in the vehicle, generating a digital shadow based on a unique unidirectional identifier of a program memory space of the master ECU and a unique unidirectional identifier of a program memory space of each of the plurality of other ECUs, and The digital shadow is transmitted to the verifier system as a response to the digital shadow request over the communication network.

20. The non-transitory computer-readable medium of claim 19, wherein generating a unique one-way identifier for the program memory space of the master ECU comprises rearranging the program memory space of the master ECU based on a seed included in the digital shadow request, and generating a unique one-way identifier for the rearranged program space of the master ECU.

Images