System, method, and computer program product for generating vehicle identification information

Abstract

The present disclosure provides systems, methods, and computer program products for generating vehicle identification information. According to an embodiment, a system may include: a storage store storing computer executable commands; and at least one processor communicatively connected to the storage, the at least one processor may be configured to execute a command to: determine whether all of the plurality of control units within the vehicle have been safely started; and generating identification information of the vehicle on the basis of the plurality of control units that have been normally started safely, in response to a determination that all of the plurality of control units have been normally started safely.

Description

Technical Field

[0001] Systems, methods, and computer program products integrated with exemplary embodiments of the present disclosure relate to vehicle systems, and more particularly, to generating identification information of vehicle systems. Background Art

[0002] Modern vehicles are capable of performing a wide range of complex functions, such as the generation of telemetry data, the sending and receiving of data via the Internet, and the like. In order for the vehicle to perform the above functions, the vehicle is essentially connected to an upstream server.

[0003] In the related art, in order for a server to identify a specific vehicle from among multiple vehicles communicating with the server, a vehicle identification number (VIN) may be used. VIN may refer to a code having multiple characters (e.g., numbers, alphabetic characters, combinations thereof, and the like) that function as a unique identifier for a specific vehicle. VIN is sometimes assigned to a vehicle during the manufacture of the above-mentioned vehicle, and may identify and specify the main components, technical standards, manufacturers, and the like of the vehicle.

[0004] However, the above method of using VIN to identify a specific vehicle may have at least the following disadvantages: VIN is sometimes associated with only a portion of the components (e.g., the main components) of the vehicle, but not with important components of the vehicle, so such a configuration may present privacy and security issues.

[0005] Furthermore, various VINs are sometimes implemented based on various competing standards, resulting in various VINs having various formats. Thus, sometimes a particular server is not configured to read a VIN of a particular format, sometimes misinterprets a VIN having a different format and specifies the wrong vehicle, and due to the existence of similar situations, the server may have problems identifying a particular vehicle. With globalization, vehicles can be moved between countries more frequently (using VINs of various standards), so the above problems have become more prevalent.

[0006] Furthermore, the use of VINs sometimes does not comply with privacy laws such as the General Data Protection Regulation (GDPR) that permit identifiers to be permanent and cannot be reset. Summary of the invention

[0007] The exemplary embodiment of the present disclosure automatically generates identification information of the vehicle system based on multiple control units that have normally performed a secure boot. Therefore, the exemplary embodiment of the present disclosure improves privacy and security, standardizes the identification information format, and reduces the risk of non-compliance with privacy laws.

[0008] According to an embodiment, a system is provided. The system may include: a memory storage storing computer executable commands; and at least one processor connected to the memory storage in a communicable manner, and the at least one processor may be configured to execute commands to perform the following processing: determining whether all multiple control units in a vehicle have been safely started normally; and in response to the determination that all multiple control units have been safely started normally, generating vehicle identification information based on multiple control units that have been safely started normally.

[0009] According to an embodiment, the identification information may specify a plurality of cryptographic signatures associated with a plurality of control units that have normally performed secure booting, and the plurality of cryptographic signatures may be unique.

[0010] According to an embodiment, at least one processor may be configured to execute commands to perform the following processing: in response to a determination that not all of the multiple control units have performed safety startup normally, restarting a failed control unit that has not performed safety startup normally; determining whether the failed control unit has restarted normally; and in response to a determination that the failed control unit has not restarted normally, disabling one or more non-essential functions of the vehicle.

[0011] According to an embodiment, the multiple control units may include a central control unit and one or more secondary control units, the central control unit may include a storage memory and at least one processor, the at least one processor may be configured to execute commands to determine whether the multiple control units have all performed a safe boot normally through the following processing: performing a safe boot; determining whether the safe boot is successful; in response to the determination that the safe boot is successful, sending a request related to the status of one or more secondary control units to the more than one secondary control units; receiving the status of one or more secondary control units from the more than one secondary control units; and determining whether the more than one secondary control units have performed a safe boot normally based on the status.

[0012] According to an embodiment, at least one processor may be configured to execute a command to send a first failure notification to one or more secondary control units in response to a failure of secure boot, and the one or more secondary control units may be configured to select a control unit from a plurality of control units different from the central control unit as a new central control unit in response to receipt of the first failure notification.

[0013] According to an embodiment, the status of one or more secondary control units may be cryptographically signed by the corresponding one or more secondary control units using an encryption key.

[0014] According to an embodiment, the plurality of control units may include an electronic control unit (ECU: Electronic Control Unit).

[0015] According to an embodiment, the identification information may include a software bill of material (SBOM: Software Bill of Material).

[0016] According to an embodiment, at least one processor may be configured to execute a command to send the identification information to the server via an Elliptic Curve Integrated Encryption Scheme (ECIES).

[0017] According to an embodiment, a method is provided, which may include: determining whether all of the plurality of control units in a vehicle have been safely started normally; and in response to the determination that all of the plurality of control units have been safely started normally, generating identification information of the vehicle based on the plurality of control units that have been safely started normally.

[0018] According to an embodiment, the identification information may specify a plurality of cryptographic signatures associated with a plurality of control units that have normally performed secure booting, and the plurality of cryptographic signatures may be unique.

[0019] According to an embodiment, the method may also include: in response to a determination that not all of the multiple control units have performed safety startup normally, restarting a failed control unit that has not performed safety startup normally; determining whether the failed control unit has restarted normally; and in response to a determination that the failed control unit has not restarted normally, disabling one or more non-essential functions of the vehicle.

[0020] According to an embodiment, the multiple control units may include a central control unit and one or more secondary control units, and the determination of whether the multiple control units in the vehicle have all performed safety startup normally may include: performing safety startup through the central control unit; determining whether the safety startup is successful through the central control unit; in response to the determination that the safety startup is successful, sending a request related to the status of one or more secondary control units to one or more secondary control units through the central control unit; receiving the status of one or more secondary control units from one or more secondary control units through the central control unit; and determining whether the safety startup of one or more secondary control units has been performed normally based on the status through the central control unit.

[0021] According to an embodiment, the method may also include: in response to a failure of secure startup, sending a first failure notification to one or more secondary control units through the central control unit; and in response to receiving the first failure notification, selecting a control unit from multiple control units different from the central control unit as a new central control unit through the more than one secondary control unit.

[0022] According to an embodiment, the status of one or more secondary control units may be cryptographically signed by the corresponding one or more secondary control units using an encryption key.

[0023] According to an embodiment, the plurality of control units may include an electronic control unit (ECU).

[0024] According to an embodiment, the identification information may include a software bill of materials (SBOM).

[0025] According to an embodiment, at least one processor may be configured to execute commands to send the identification information to the server via Elliptic Curve Integrated Cryptography Scheme (ECIES).

[0026] According to an embodiment, a computer program product is provided. The computer program product may record a command, the command being executable by at least one processor of a system, the command causing the at least one processor to perform a method, the method comprising: determining whether all of a plurality of control units in a vehicle have been safely started normally; and in response to the determination that all of the plurality of control units have been safely started normally, generating identification information of the vehicle based on the plurality of control units that have been safely started normally.

[0027] According to an embodiment, the identification information may specify a plurality of cryptographic signatures associated with a plurality of control units that have normally performed secure booting, and the plurality of cryptographic signatures may be unique.

[0028] Additional aspects are described in part in the description that follows and in part are obvious from the description, or may be achieved by practice of the presented embodiments of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Hereinafter, features, advantages, and significance of preferred embodiments of the present disclosure will be described with reference to the accompanying drawings, in which like reference numerals represent like elements.

[0030] Figure 1 A block diagram showing an exemplary system configuration for generating vehicle identification information according to one or more embodiments.

[0031] Figure 2 A block diagram showing a first exemplary component of a vehicle identification information generation (VIG) system according to one or more embodiments.

[0032] Figure 3 A block diagram illustrating second exemplary components of a vehicle identification information generation (VIG) system according to one or more embodiments.

[0033] Figure 4 A flowchart illustrating an exemplary method of generating vehicle identification information according to one or more embodiments.

[0034] Figure 5 A flow chart illustrating an exemplary method of verifying and generating identification information of a vehicle in accordance with one or more embodiments.

[0035] Figure 6 A flowchart is provided showing an exemplary method for determining whether all of a plurality of control units in a vehicle have been safely started normally in accordance with one or more embodiments.

[0036] Figure 7 A flow chart illustrating an exemplary secure boot process according to one or more embodiments.

[0037] Figure 8 A flow chart illustrating an exemplary method of restarting a failed control unit according to one or more embodiments. DETAILED DESCRIPTION

[0038] The following detailed description of exemplary embodiments is made with reference to the accompanying drawings. The same reference numbers in different drawings may identify the same or identical elements.

[0039] The above disclosure provides examples and illustrations, but is not intended to be exhaustive, nor is it intended to limit the implementation scheme to the exact form disclosed. Modifications and deformations can be obtained in view of the above disclosure, or according to the implementation scheme. Moreover, one or more features or constituent elements of one embodiment can be embedded in another embodiment (or one or more features of another embodiment), or can be combined therewith. Moreover, it is understood that in the description of the actions provided below, one or more actions can be omitted, one or more actions can be added, one or more actions can be performed (at least partially) simultaneously, and the order of one or more actions can be switched.

[0040] It is apparent that the systems and / or methods described in this specification may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement the system and / or method is not limited to the implementation scheme. Therefore, the actions and behaviors of the system and / or method are recorded in this specification without reference to specific software code. It is understood that software and hardware can be designed to implement the system and / or method based on the description of this specification.

[0041] Even if a particular combination of features is disclosed in this specification, this combination is not intended to limit the disclosure of possible implementations. In fact, many of the features can be combined in ways that are not specifically disclosed in this specification.

[0042] Unless otherwise expressly stated, the elements, behaviors or commands used in this specification should not be interpreted as important or necessary. In addition, the articles "a" and "an" used in this specification are intended to include more than one item and can be used interchangeably with "more than one". In the case of only one item, a term such as "one" or the same term is used. In addition, the terms "has", "have", "having", "include", "including" or similar terms used in this specification are meant to be open-ended terms. Moreover, unless otherwise expressly stated, phrases such as "based on..." mean "based at least in part on...". Moreover, expressions such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0043] The system, method, apparatus, and the like provided in the exemplary embodiment of the present disclosure automatically generate identification information of a vehicle system (ie, a vehicle) based on a plurality of control units that have normally performed safety booting.

[0044] According to an embodiment, the system can determine whether all of the multiple control units in the vehicle have been safely started normally, and can generate vehicle identification information based on the determination. For example, based on the determination that all of the multiple control units have been safely started normally, the system can generate vehicle identification information based on the multiple control units that have been safely started normally.

[0045] Finally, the exemplary embodiment of the present disclosure automatically generates identification information of a vehicle system based on a plurality of control units that have normally performed a safety boot, thereby improving privacy and security, standardizing the identification information format, and reducing the risk of non-compliance with privacy laws.

[0046] It is assumed that the features, advantages, and significance of the exemplary embodiments described above in this specification are only part of the present disclosure, are not intended to be exhaustive, and are not intended to limit the scope of the present disclosure.

[0047] Hereinafter, further descriptions are provided on the features, components, configurations, operations, and implementations of the system for generating vehicle identification information of the present disclosure according to one or more embodiments.

[0048] Exemplary system architecture

[0049] Figure 1 A block diagram of an exemplary system configuration 100 for generating vehicle identification information according to one or more embodiments is shown. Figure 1 As shown, the system configuration 100 may include a server 110 and a vehicle identification information generation (VIG) system 120 .

[0050] The server 110 may include a cloud server, a hybrid cloud server, a server cluster, and the like. The server 110 may be remote from the VIG system 120 and may be connected to the VIG system 120 in a communicable manner.

[0051] The VIG system 120 may include a system, platform, module, or similar element that may be configured to perform one or more actions or behaviors to generate identification information of the vehicle. According to an embodiment, the VIG system 120 may be equipped in a vehicle.

[0052] Below, refer to Figures 4 to 8 Exemplary operations that may be performed by the VIG system 120 to generate vehicle identification information are described below. Figure 2 and Figure 3 Several exemplary components that may be included in VIG system 120 are described for one or more embodiments.

[0053] Figure 2A block diagram showing exemplary components of a VIG system 200 according to one or more embodiments. The VIG system 200 may be used with Figure 1 Therefore, unless otherwise expressly stated, features associated with the VIG system 120 and the VIG system 200 can be applied in the same manner to each other.

[0054] like Figure 2 As shown, the VIG system 200 may include a plurality of control units, namely, control unit A, control unit B, control unit C, and control unit D. According to an embodiment, the control units may be connected to each other in a communicative manner. According to an embodiment, one of the plurality of control units may be configured as a central control unit (e.g., control unit A) that functions in a manner that performs a function for generating identification information of the vehicle. According to an embodiment, the plurality of control units may include an electronic control unit (ECU) that controls one or more electrical systems in the vehicle. For example, the plurality of control units may include an engine control unit, a brake control unit, a general electronic unit, an advanced driver assistance system, and the like.

[0055] It is understood that the VIG system 200 may include more than one embodiment without departing from the scope of the present disclosure. Figure 2 The control units shown may be more or fewer control units, and / or may be configured with Figure 2 The control units shown are different.

[0056] Figure 3 A block diagram showing exemplary components of a VIG system 300 according to one or more embodiments. The VIG system 300 may be used with Figure 1 VIG system 120 and Figure 2 Therefore, unless otherwise expressly stated, features associated with the VIG system 120 , the VIG system 200 , and the VIG system 300 may be applied in the same manner.

[0057] like Figure 3 As shown, the VIG system 300 may include at least one communication interface 310, at least one processor 320, at least one input / output component 330, and at least one storage 340. According to an embodiment, at least one communication interface 310, at least one processor 320, at least one input / output component 330, and at least one storage 340 may be equipped in each of the control units (e.g., control unit A, control unit B, control unit C, and control unit D) of the VIG system.

[0058] It is understood that the VIG system 300 may include more than one embodiment without departing from the scope of the present disclosure. Figure 3 The components shown may be more or less than the components shown, and / or may be configured as Figure 3 The components shown are different.

[0059] The communication interface 310 may include at least one transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, a bus, etc.) that enables the components of the VIG system 300 to communicate with each other via a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection, and / or to communicate with one or more components located outside the VIG system 300.

[0060] For example, the communication interface 310 may connect the processor 320 to the storage 340, thereby enabling them to communicate with each other and perform actions with each other when performing one or more actions. As another example, the communication interface 310 may connect the VIG system 300 (or one or more components included in the VIG system 300) to the server 110, thereby enabling them to communicate with each other and perform actions with each other.

[0061] According to one or more embodiments, the communication interface 310 may include one or more application programming interfaces (APIs) that enable the VIG system 300 (or one or more components included in the VIG system 300) to communicate with one or more software applications (e.g., software applications deployed in the server 110, etc.).

[0062] The input / output component 330 may include at least one component that enables the VIG system 300 to receive information and / or provide output information. It is understood that in some embodiments, the input / output component 330 may include at least one input component (e.g., a touch screen display, buttons, switches, microphones, sensors, etc.) and at least one output component (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.), each of which may be separated from each other.

[0063] The storage 340 may include one or more storage media (or computer program products) suitable for internally storing data, information and / or computer executable commands. According to an embodiment, the storage 340 may include at least one storage storage such as a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) for storing information and / or commands for use by the processor 320. Further or alternatively, the storage 340 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid-state hard disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cassette, a magnetic tape, and / or another type of non-transitory computer-readable medium, and include a corresponding drive.

[0064] According to an embodiment, the storage 340 may be configured to store information such as raw data, metadata, or similar data obtained from the server 110. In addition or alternatively, the storage 340 may be configured to store one or more information associated with one or more actions performed by the processor 320. For example, the storage 340 may store information that determines the historical actions performed by the processor 320 to generate the identification information, one or more results of the actions performed by the processor 320, or similar items. In addition, the storage 340 may store data or information required when generating the identification information.

[0065] In some implementations, the storage 340 may include multiple storage media, and the storage 340 may be configured to store duplicates or copies of at least a portion of the information in multiple storage media to provide redundancy and back up information or establish related data. In addition, the storage 340 may also store computer-readable commands or computer-executable commands, which, when executed by one or more processors (e.g., processor 320), cause one or more processors to perform one or more actions / movements described in this specification.

[0066] The processor 320 may include at least one processor that can be programmed or configured to perform the functions or actions described in this specification. For example, the processor 320 may be configured to execute computer executable instructions stored in at least one storage medium or storage storage (e.g., storage 340, etc.), thereby performing one or more behaviors or one or more actions described in this specification.

[0067] According to an embodiment, the processor 320 may be configured to receive one or more signals and / or one or more user inputs that determine one or more commands to perform one or more actions (e.g., via the communication interface 310, the input / output component 330, etc.). Moreover, the processor 320 may be implemented by hardware, firmware, or a combination of hardware and software. For example, the processor 320 may include a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), and / or at least one of another type of processing or computing components.

[0068] According to an embodiment, the processor 320 may be configured to collect, extract and / or receive one or more information (in the form of signals or data, etc.) from the server 110 and process the one or more received information, thereby generating identification information.

[0069] Below, refer to Figures 4 to 8 A description of several exemplary actions that may be performed by processor 320 is provided.

[0070] Exemplary actions for generating vehicle identification information in the present disclosure

[0071] Below, refer to Figures 4 to 8 Several exemplary actions that may be performed by the VIG system of the present disclosure are described.

[0072] Figure 4A flowchart of an exemplary method 400 for generating identification information of a vehicle representing one or more embodiments. One or more actions in method 400 may be performed by at least one processor of the VIG system (e.g., processor 320). According to an embodiment, the VIG system may be equipped in a vehicle and may have multiple control units for controlling an electrical system in the vehicle. According to an embodiment, the multiple control units may include a central control unit and one or more secondary control units (i.e., control units among multiple control units other than the central control unit), whereby one or more actions in method 400 may be performed by the central control unit. According to an embodiment, one or more actions in method 400 may be performed during the starting process of the vehicle. According to an embodiment, the multiple control units may include an electronic control unit (ECU).

[0073] like Figure 4 As shown, in action S410, at least one processor may be configured to determine whether all of the multiple control units in the vehicle have normally performed a safe start. It is understandable that during the vehicle startup process, the multiple control units in the vehicle are respectively configured to perform a safe start process, and the at least one processor may be configured to determine whether all of the multiple control units have successfully performed the process. Figure 6 and Figure 7 The description related to the secure boot process and the determination of whether all the multiple control units have normally performed the secure boot is described. Next, the method proceeds to action S420.

[0074] In action S420, at least one processor may be configured to generate identification information of the vehicle based on the multiple control units that have normally performed a safe start in response to a determination that all of the multiple control units have normally performed a safe start during action S410. According to an embodiment, the identification information may specify multiple cryptographic signatures associated with the multiple control units that have normally performed a safe start, where the multiple cryptographic signatures are unique.

[0075] According to an embodiment, each of the control units (e.g., ECUs) may have a set of public encryption keys and private encryption keys embedded by the manufacturer during its manufacture. The key may be embedded in a hardware security module (HSM) in the SOC (System On Chips) of the control unit, which only allows the control unit to use the key to provide an encryption signature, preventing any third-party attacker from using the key. Moreover, the sets of keys (and corresponding signatures) are unique, with the result that no two control units can provide the same encryption signature, regardless of whether the control units are manufactured by the same manufacturer, manufactured in the same batch, have the same model, and are similar. According to an embodiment, the encryption signatures of more than one secondary control unit may be received by the central control unit as part of the determination of whether all of the multiple control units have performed a secure boot normally.

[0076] According to an embodiment, the identification information may include a software bill of materials (SBOM) specifying a plurality of cryptographic signatures associated with a plurality of control units that have normally performed secure booting.

[0077] It will be appreciated that the cryptographic signatures are each specific to a particular control unit and therefore the identification information (specifying a combination of such specific signatures) is also specific, with the result that the identification information can be used to identify a specific vehicle having a specific control unit corresponding to a specific signature within the identification information. Furthermore, the identification information only specifies a combination of specific signatures, so that the format associated with the identification information of a vehicle can be standardized regardless of location.

[0078] When action S420 is performed, method 400 may end or terminate. Alternatively, method 400 may return to action S410, with the result that at least one processor may be configured to repeatedly perform the determination (in action S410) that all of the plurality of control units have normally performed the safety start and the generation of the vehicle identification information (in action S420) for at least a specified amount of time.

[0079] Therefore, the system of the present disclosure can generate the identification information of the vehicle based on a plurality of control units that have normally performed safety startup.

[0080] Exemplary actions of verifying and generating vehicle identification information in the present disclosure

[0081] Figure 5A flowchart of an exemplary method 500 for verifying and generating vehicle identification information according to one or more embodiments. One or more actions of method 500 may be part of actions S410 and / or S420 in method 400 and may be performed by at least one processor (eg, processor 320) of the VIG system.

[0082] like Figure 5 As shown, in action S510, at least one processor may be configured to determine whether all of the multiple control units in the vehicle have normally performed a safe start. It is understandable that during the vehicle startup process, the multiple control units in the vehicle are respectively configured to perform a safe start process, and the at least one processor may be configured to determine whether all of the multiple control units have successfully performed the process. Figure 6 and Figure 7 Description is given of the secure boot process and the determination of whether all of the plurality of control units have normally performed secure boot.

[0083] Therefore, based on the determination that all the multiple control units in the vehicle have performed the safety startup normally, at least one processor can determine that all the multiple control units in the vehicle are valid, and proceed to action S520. On the other hand, based on the determination that not all the multiple control units in the vehicle have performed the safety startup normally (i.e., one or more of the multiple control units in the vehicle have failed in the safety startup process), at least one processor can determine that one or more of the multiple control units in the vehicle is sometimes not valid, and proceed to action S540.

[0084] In action S520, at least one processor may be configured to generate identification information of the vehicle based on the plurality of control units that have normally performed a secure boot. According to an embodiment, similar to action S420 in method 400, the identification information may specify a plurality of cryptographic signatures associated with the plurality of control units that have normally performed a secure boot. Then, the method proceeds to action S530.

[0085] In action S530, at least one processor may be configured to send identification information to a server. According to an embodiment, the server may refer to a server located outside the vehicle that communicates with the vehicle to perform a variety of functions. According to an embodiment, the server may receive and store the identification information, and may use the identification information to identify the vehicle. Specifically, the identification information specifies a combination of unique signatures associated with a specific control unit in a specific vehicle, so the server can identify the specific vehicle based on whether the vehicle includes a combination of control units associated with the combination of unique signatures specified in the identification information. Moreover, the identification information only specifies a combination of unique signatures, so the format related to the vehicle's identification information can be standardized regardless of the location.

[0086] According to an embodiment, at least one processor may be configured to send the identification information to the server via an elliptic curve integrated encryption scheme (ECIES). According to an embodiment, the identification information may be sent via ECIES using the vehicle VIN as a salt for generating a key. It is understood that by using the VIN as a salt and using ECIES to encrypt and send data, it is possible to block or prohibit the key or vehicle from the server if necessary.

[0087] According to an embodiment, the server may store information related to the vehicle, such as the owner of the vehicle, software and hardware in the vehicle, and the like, which may be identified by the identification information.

[0088] In action S540, at least one processor may be configured to restart the failed control unit. According to an embodiment, the failed control unit may refer to a control unit that does not normally perform a safe boot. Figure 8 The description related to the restart of the failed control unit is recorded. Next, the method proceeds to action S550.

[0089] In action S550, at least one processor may be configured to determine whether the failed control unit is restarted normally. According to an embodiment, at least one processor may be configured to: send a request related to the status of the failed control unit to the failed control unit, receive the status of the failed control unit from the failed control unit, determine whether the failed control unit is restarted normally based on the status, and thereby determine whether the failed control unit is restarted normally, similarly to actions S630, S640, and S650 in method 600 described below.

[0090] It can be understood that, in the case where there are multiple failed control units, actions S540 and S550 can be performed on all failed control units.

[0091] Therefore, based on the determination that the failed control unit has been restarted normally, the at least one processor can determine that all of the multiple control units in the vehicle are valid, and proceed to action S520. On the other hand, based on the determination that the failed control unit has not been restarted normally (i.e., the failed control unit has failed in the restart process), the at least one processor can determine that one or more of the multiple control units in the vehicle are not valid, and proceed to action S560.

[0092] In action S560, at least one processor may be configured to disable one or more non-essential functions of the vehicle. According to an embodiment, non-essential functions of the vehicle may refer to functions of the vehicle that are not directly associated with the movement of the vehicle. For example, non-essential functions may include online payment, weather forecast, video playback, and similar items provided via the vehicle's in-vehicle infotainment (IVI) system. According to an embodiment, at least one processor may be configured to enable all safety-critical CAN (Controller Area Network) signals to be sent and received within the vehicle, and to prevent one or more non-safety-critical CAN signals from being sent and received within the vehicle, thereby disabling one or more non-essential functions of the vehicle.

[0093] According to an embodiment, at least one processor may be configured to disable one or more non-essential functions of the vehicle associated with the failed control unit. According to an embodiment, at least one processor may be configured to disable all non-essential functions of the vehicle regardless of which function is associated with the failed control unit.

[0094] It is understood that when one or more non-essential functions of a vehicle are disabled, the only way to enable the function is to have a trusted / verified entity such as a seller, dealer, manufacturer, or similar entity of the vehicle enable the function. Such a process prevents malicious hardware and / or software from being installed to put the vehicle at risk. In particular, for example, in the case where a user of the vehicle installs credit card information into the vehicle's IVI system in order to make an online payment, when untrusted / invalidated hardware and / or software is detected in the vehicle (i.e., by determining that not all of the multiple control units have been safely booted normally, and the failed control units cannot be restarted), the function for making online payments should be disabled. Moreover, in order to improve security and prevent any third party from easily putting the vehicle at risk, the enablement of the function should be limited to trusted / verified entities.

[0095] It is also understood that when untrusted / invalid hardware and / or software is detected in the vehicle, some or all of the non-essential functions of the vehicle should be disabled, but the essential functions of the vehicle, such as the movement and operation of the vehicle, should not be disabled. Thus, the vehicle can at least act in a manner that transports the user to a trusted / verified entity, and in addition, any undesirable accidents that may occur due to completely disabling all functions of the vehicle can be prevented.

[0096] According to an embodiment, when one or more non-essential functions of the vehicle are disabled, a lock notification may be provided to the user. According to an embodiment, the lock notification may indicate to the user that one or more non-essential functions of the vehicle are disabled (locked); and in order to enable the function, the user should go to a trusted / verified entity. According to an embodiment, the lock notification may be in the form of an LED light.

[0097] When action S530 or S560 is performed, method 500 may end or terminate.

[0098] Alternatively, when action S530 is performed, method 500 may return to action S510, with the result that at least one processor may be configured to repeatedly perform, at least for a specified amount of time, the determination of whether multiple control units have all performed a safe start normally (in action S510), the generation of vehicle identification information (in action S520), the sending of identification information (in action S530), the restarting of a failed control unit (in action S540), the determination of whether a failed control unit has restarted normally (in action S550), and the invalidation associated with one or more non-essential functions of the vehicle (in action S560).

[0099] For example, when action S530 (sending identification information) is performed and method 500 ends, the user may drive the vehicle to a certain location and stop the vehicle. Then, the next time the user starts the vehicle, the vehicle starts the startup process, and method 500 may be started again. Assuming that the hardware of the vehicle (i.e., the hardware associated with the control unit and the control unit itself in the vehicle) has not changed, actions S510, S520, and S530 may be performed again, and the identification information of the vehicle remains the same.

[0100] On the other hand, in the event that the hardware of the vehicle is appropriately changed by a trusted / verified entity, the next time the user starts the vehicle and performs actions S510 and S520, the resulting identification information is different from the previous identification information (i.e., the signature shown in the new identification information specifies the new hardware, not the previous hardware). Therefore, at least one processor may send the new identification information to the server during action S530, as a result of which the server may update the identification information of the vehicle stored on the server. According to an embodiment, the server may store both the new identification information and the old identification information of the vehicle to maintain a record of the vehicle.

[0101] Through this process, the identification information of the vehicle can be changed, thereby reducing the risk of violating privacy laws that allow for identifiers that are permanent and cannot be reset.

[0102] It is also understood that in order for a trusted / verified entity to appropriately modify the vehicle's hardware (after which the control units all perform a safe boot normally), a diagnostic tool may be used to place the vehicle in a diagnostic mode. In this mode, the vehicle's hardware and / or software may be modified so that the new hardware and / or software does not fail during a safe boot.

[0103] It is also understandable that, in the event that a third-party attacker installs malicious hardware and / or software in the vehicle, the next time the user starts the vehicle, the control unit associated with the malicious hardware and / or software may fail in the safe startup process, and actions S540, S550, and S560 may be performed.

[0104] Through this process, the identification information of the vehicle can function not only as an identifier of the vehicle, but also as a verification tool for verifying whether the vehicle is in danger and it is dangerous to fully operate, thereby improving the safety of the vehicle. In addition, the identification information only specifies the combination of components (i.e., control units) of the vehicle, and does not specify the specific configuration of the components, so privacy can be maintained.

[0105] Exemplary operation of determining whether all of the plurality of control units in the vehicle have been safely started normally in the present disclosure

[0106] Figure 6 A flowchart of an exemplary method 600 for determining whether all of a plurality of control units in a vehicle have performed a safe start normally, representing one or more embodiments. One or more actions of method 600 may be part of action S510 in method 500, and may be performed by at least one processor of the VIG system (e.g., processor 320). In particular, similar to the description provided in association with methods 400 and 500, the plurality of control units may include a central control unit and one or more secondary control units, where one or more actions of method 600 may be performed by the central control unit. Moreover, during the vehicle startup process, the plurality of control units in the vehicle (i.e., the central control unit and one or more secondary control units) are respectively configured to perform a safe start process.

[0107] like Figure 6 As shown, in action S610, at least one processor (ie, the processor of the central control unit) may be configured to perform a secure boot. Figure 7 The description related to the secure boot process is recorded. Next, the method enters action S620.

[0108] In action S620, at least one processor may be configured to determine whether the secure boot is successful. Therefore, based on the determination that the secure boot process is successful, at least one processor may determine that the central control unit of the plurality of control units has performed the secure boot normally, and enter action S630. On the other hand, based on the determination that the secure boot process is not successful, at least one processor may determine that the central control unit of the plurality of control units has not performed the secure boot normally, and enter action S660.

[0109] In action S630, at least one processor may be configured to send a request related to the status of the one or more secondary control units to the one or more secondary control units. According to an embodiment, the status of the one or more secondary control units may indicate whether the one or more secondary control units are normally safely started.

[0110] For example, when the vehicle has control unit A, control unit B, control unit C, and control unit D, and control unit A functions as a central control unit, control unit A, control unit B, control unit C, and control unit D may be configured to perform a safety boot process, respectively. In this regard, when control unit A normally performs a safety boot during actions S610 and S620, control unit A may be configured to send requests related to the status of control unit B, control unit C, and control unit D to control unit B, control unit C, and control unit D, respectively. Next, the method proceeds to action S640.

[0111] In action S640, at least one processor may be configured to receive statuses of at least one secondary control unit from at least one secondary control unit. According to an embodiment, the statuses of at least one secondary control unit may indicate whether at least one secondary control unit has normally performed a safety boot.

[0112] According to an embodiment, in the case where one or more secondary control units have performed a secure boot normally, the one or more secondary control units may be configured to send a status indicating that the one or more secondary control units have performed a secure boot normally to the central control unit. According to an embodiment, the one or more secondary control units may cryptographically sign the status using an encryption key, with the result that the status may function as proof that the one or more secondary control units have performed a secure boot normally. For example, when encryption key B is embedded in control unit B during the manufacture of control unit B, and control unit B has performed a secure boot normally, control unit B may cryptographically sign the status using encryption key B, and then send the signed status indicating that control unit B has performed a secure boot normally to control unit A.

[0113] According to an embodiment, in the case that one or more secondary control units do not normally perform safety boot, the one or more secondary control units may be configured to send a status indicating that one or more secondary control units do not normally perform safety boot to the central control unit. For example, in the case that control unit C does not normally perform safety boot, control unit C may send a status indicating that control unit C does not normally perform safety boot to control unit A. Then, the method proceeds to action S650.

[0114] In action S650, at least one processor may be configured to determine whether all secondary control units (i.e., all control units in the vehicle other than the central control unit) have been safely started normally based on the received condition. Therefore, based on the determination that all secondary control units have been safely started normally, at least one processor may determine that all of the multiple control units in the vehicle have been safely started normally. On the other hand, based on the determination that not all secondary control units have been safely started normally, at least one processor may determine that not all of the multiple control units in the vehicle have been safely started normally.

[0115] In action S660, at least one processor may be configured to send a first failure notification to one or more secondary control units. According to an embodiment, the first failure notification may indicate that the central control unit did not perform a safe start normally. According to an embodiment, the one or more secondary control units may be configured to select a control unit from a plurality of control units in a vehicle different from the central control unit as a new central control unit in response to receiving the first failure notification. According to an embodiment, the one or more secondary control units may be configured to select a new central control unit among the one or more secondary control units based on voting.

[0116] It will be appreciated that the control unit may store a list of preferred control units in its manufacture respectively. The list of preferred control units may specify a priority as to which control unit should be the central control unit. The list of preferred control units may be predetermined by the manufacturer of the control unit as required based on the use of the control unit, the type of vehicle and the like. For example, an ADAS (Advanced Driver Assistance Systems) has a high computing power, and therefore an ECU designed for use in a battery electric vehicle may specify an Advanced Driver Assistance System (ADAS) ECU as the first preferred control unit.

[0117] It will be appreciated that, depending on the implementation, the initial control unit (eg, control unit A) may also be selected as the central control unit by more than one secondary control unit based on voting.

[0118] When a new central control unit is selected, method 600 may be started again for the new central control unit, where the previous central control unit is now considered a secondary control unit. For example, in the case where control unit A does not perform a safe boot normally, and control unit D is selected as the new central control unit, method 600 may be started again for control unit D as the central control unit and control units A, control unit B, and control unit C as secondary control units. It is also understood that in the case where the new central control unit also does not perform a safe boot normally during action S610, action S660 may be further performed again to select a new central control unit. For example, in the case where control unit D also does not perform a safe boot normally, action S660 may be performed, where control unit B or control unit C may be further selected as the new central control unit.

[0119] It is understandable that, in the case that the new central control unit has normally performed a security boot when being selected, the new central control unit may skip actions S610 and S620.

[0120] Exemplary secure boot process in the present disclosure

[0121] Figure 7 A flow chart illustrating an exemplary secure boot process according to one or more embodiments.

[0122] like Figure 7 As shown, the secure boot process can be separated into four software execution permission levels / stages, namely, exception level (EL: Exception Level) 3 related to the boot firmware, exception level 2 related to the hypervisor, exception level 1 related to the operating system (OS: Operating System), and exception level 0 related to the application.

[0123] The secure boot process can be started at EL3, at which time the power is turned on and the boot ROM starts. Next, the boot ROM can be configured to run (launch) the boot firmware. When the boot firmware is run, the boot ROM can be configured to determine whether the boot firmware has been adjusted by comparing the boot firmware with a memory image previously verified for the boot firmware. The memory image previously verified for the boot firmware can represent the most recently verified composition of the boot firmware (for example, the composition of the boot firmware in manufacturing). It is understandable that the memory image previously verified for the boot firmware can be stored in the memory of the corresponding control unit. It is also understandable that in the case where the boot firmware has been updated before, the updated boot firmware can also be stored in the memory and can be used for comparison.

[0124] The boot firmware may also be configured to determine whether the associated hardware being executed is true by cryptographically querying the associated hardware. It is understandable that, similar to the control unit (e.g., ECU), each hardware in the vehicle may also have a set of public encryption keys and private encryption keys embedded by the manufacturer during the manufacture of the hardware to specify that the hardware is true. Therefore, the boot firmware can cryptographically query the associated hardware based on the key embedded in the associated hardware to confirm whether the associated hardware is true. When the boot ROM confirms that the boot firmware has not been adjusted, and the boot firmware confirms that the associated hardware is true, the boot ROM may be configured to sign the hash of the boot firmware to confirm that the boot firmware has been properly started.

[0125] The boot firmware can then be configured to run the hypervisor at EL2 and determine whether the hypervisor has been conditioned by comparing the hypervisor to a memory image previously verified for the hypervisor, similar to the boot firmware. When the boot firmware determines that the hypervisor is not conditioned, the boot firmware can be configured to sign a hash of the hypervisor to confirm that the hypervisor has been properly launched.

[0126] The hypervisor can then be configured to run the OS at EL1 and determine whether the OS has been conditioned by comparing the OS to a memory image previously verified for the OS, similar to the boot firmware. When the hypervisor determines that the OS is not conditioned, the hypervisor can be configured to sign a hash of the OS to confirm that the OS has been properly booted.

[0127] The OS can then be configured to run the application at EL0 and determine whether the application has been conditioned by comparing the application to a memory image previously verified for the application, similar to the boot firmware. When the OS determines that the application is not conditioned, the OS can be configured to sign a hash of the application to confirm that the application has been properly launched.

[0128] Thus, each level in the boot process can sequentially verify the level above, thus providing a chain level of trust via cryptographic signatures. Thus, when the application is properly launched and all hashes of EL3, EL2, EL1, and EL0 are signed, the control unit is normally securely booted. Furthermore, when the control unit is normally securely booted, all constituent elements (hardware, software, and the like) associated with the control unit can be listed to generate an SBOM, where the hash of the SBOM can be cryptographically signed and stored in the memory of the control unit. It is understood that in the case where the hardware and / or software associated with the control unit is appropriately changed by a trusted / verified entity and a new hash of the SBOM is generated, the new hash of the SBOM can be cryptographically signed and stored in the memory of the control unit together with the previous hash of the SBOM to maintain a record of the constituent elements of the control unit.

[0129] At this point, when the control unit receives a request related to the status, the control unit can then send a signed hash of the SBOM to indicate that the control unit has normally performed a secure boot. It can be understood that the above-mentioned cryptographic signature is provided using an encryption key embedded in the corresponding control unit.

[0130] It is understood that in the case where any level is not properly initiated, the boot process may sometimes stop and may not provide a signature. Therefore, the control unit does not normally perform a secure boot. In this regard, when the control unit receives a request related to the condition, then the control unit may send a notification to indicate that the control unit did not normally perform a secure boot.

[0131] In view of the above, according to an embodiment, the generated identification information of the vehicle may include a signed hash of the SBOM that specifies signed hashes of a plurality of SBOMs received from a plurality of control units.

[0132] Depending on the implementation, the secure boot process may be completed in less than 460 milliseconds or 520 milliseconds.

[0133] Exemplary actions for restarting a failed control unit in the present disclosure

[0134] Figure 8A flowchart of an exemplary method 800 for restarting a failed control unit according to one or more embodiments is shown. One or more actions of method 800 may be part of action S540 in method 500 and may be performed by at least one processor (e.g., processor 320) of the VIG system. In particular, similar to the description provided in association with methods 400 and 500, the plurality of control units may include a central control unit and one or more secondary control units, where one or more actions of method 800 may be performed by the central control unit. Furthermore, the failed control unit may refer to a control unit among the plurality of control units that did not perform a safe startup normally.

[0135] like Figure 8 As shown, in action S810, at least one processor (i.e., a processor of a central control unit) may be configured to send a second failure notification to a server. According to an embodiment, the second failure notification may identify the failed control unit and indicate that the failed control unit did not perform a secure boot normally. According to an embodiment, the server may be configured to send data for restarting the failed control unit in response to receipt of the second failure notification. According to an embodiment, the data for restarting the failed control unit may include a wireless (OTA: Over-The-Air) patch that resets the failed control unit to restore it to the factory settings.

[0136] It is understood that the vehicle may have a primary communication path for internal communication within the vehicle and a secondary communication path for external communication outside the vehicle. Therefore, it is understood that the second failure notification may be sent to the server via the secondary communication path. Next, the method proceeds to action S820.

[0137] In action S820, at least one processor may be configured to receive data for restarting the failed control unit from the server. Next, the method proceeds to action S830.

[0138] In action S830, at least one processor may be configured to use the received data to restart the failed control unit. According to an embodiment, at least one processor may be configured to: execute a patch to reset the failed control unit to restore to factory settings, and then request the failed control unit to perform a secure boot process again.

[0139] Various options for implementation

[0140] The above disclosure provides examples and illustrations, but is not intended to be exhaustive, nor is it intended to limit the implementation scheme to the exact form disclosed. Modifications and variations may be obtained in view of the above disclosure, or according to the practice of the implementation scheme.

[0141] Some embodiments may involve systems, methods and / or computer-readable media that integrate any possible level of technical detail. Moreover, one or more of the above-mentioned constituent elements may be implemented as commands stored in a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or medium(s)) having computer-readable program commands in order to cause the processor to perform an action.

[0142] A computer-readable storage medium may be a tangible device that can hold and store commands used by a command execution device. The computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above, but is not limited to these. A non-exhaustive list of more specific examples of computer-readable storage media includes the following, namely, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM (Erasable Programmable ReadOnly Memory) or flash memory), static random access memories (SRAM), portable compact disc read-only memories (CD-ROM), digital versatile discs (DVD), memory sticks, floppy disks, punched cards with commands recorded or mechanically encoded devices such as raised structures in grooves, and any suitable combination of the above. The computer-readable storage medium used in this specification should not be interpreted as a temporary signal itself such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (for example, a light pulse passing through a fiber optic cable), or an electrical signal sent through a wire.

[0143] The computer-readable program commands recorded in this specification can be downloaded from a computer-readable storage medium to a respective computing / processing device, or can be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can have copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program commands from the network and transmits the computer-readable program commands to be stored in a computer-readable storage medium in the respective computing / processing device.

[0144] The computer readable program code / commands for performing actions may be assembler commands, instruction-set-architecture (ISA) commands, machine commands, machine dependent instructions, microcode, firmware commands, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++ or similar programming languages, and procedural programming languages ​​such as "C" programming language or similar programming languages. The computer readable program commands may be executed entirely on the user's computer, or may be executed partially on the user's computer, or may be executed as a stand-alone software package, or may be executed partially on the user's computer and partially on a remote computer, or may be executed entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to thereby connect to the Internet). In some embodiments, in order to perform a scheme or action, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), can use state information of computer-readable program commands to individualize the electronic circuit, thereby executing the computer-readable program commands.

[0145] The computer-readable program commands may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device in order to generate a machine, and as a result, the commands executed by the processor of the computer or other programmable data processing device generate components that implement the functions / behaviors specified in the functional blocks or functional blocks (multiple) of the flowchart and / or block diagram. The computer-readable program commands may also be stored in a computer-readable storage medium, which may instruct a computer, a programmable data processing device, and / or other devices to function in a specific manner, and as a result, the computer-readable storage medium having the commands stored therein has an article of manufacture, which includes commands for implementing the scheme of the functions / behaviors specified in the functional blocks or functional blocks (multiple) of the flowchart and / or block diagram.

[0146] Computer-readable program commands may also be loaded onto a computer, other programmable data processing apparatus, or other device, and a series of action steps may be performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, as a result of which the commands executed on the computer, other programmable apparatus, or other device implement the functions / behaviors specified in the functional box or functional box(es) in the flowchart and / or block diagram.

[0147] The flowcharts and block diagrams in the figure illustrate the architecture, functions and actions of possible implementation schemes of the systems, methods and computer-readable media of various embodiments. In this regard, each functional block in the flowchart or block diagram may represent a part of a microservice module, segment or command having one or more executable commands to implement the specified logical function. The method, computer system and computer-readable medium may include additional functional blocks, fewer functional blocks, different functional blocks or functional blocks of different configurations compared to those depicted in the figure. In a partially replaced implementation scheme, the functions recorded in the functional blocks may be generated independently of the order recorded in the figure. For example, two functional blocks shown in succession may actually be executed simultaneously or substantially simultaneously, or the functional blocks may be executed in reverse order according to the associated functions. It should be noted that each functional block of the block diagram and / or flowchart, and the combination of functional blocks of the block diagram and / or flowchart can be implemented by a dedicated hardware-based system, wherein the system performs a specified function or behavior, or executes a combination of dedicated hardware and computer commands.

[0148] It is apparent that the systems and / or methods described in this specification may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement the system and / or method is not limited to the implementation scheme. Therefore, it is understood that the actions and behaviors of the system and / or method are not described in this specification with reference to specific software code, and the software and hardware may be designed to implement the system and / or method based on the description of this specification.

[0149] It will be appreciated that many modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the claims, the present disclosure may be practiced in other ways than those specifically described in this specification.

Claims

1. A system for generating vehicle identification information, comprising: a storage memory storing computer executable instructions; and at least one processor, communicatively connected to the storage device, The at least one processor is configured to execute the command to perform the following processing: Determining whether all of the plurality of control units in the vehicle have been safely started normally; and In response to a determination that all of the plurality of control units have normally performed safety activation, identification information of the vehicle is generated based on the plurality of control units that have normally performed safety activation.

2. The system for generating vehicle identification information according to claim 1, wherein: The identification information specifies a plurality of encrypted signatures associated with the plurality of control units that have normally performed secure booting, and each of the plurality of encrypted signatures is unique.

3. The system for generating vehicle identification information according to claim 1 or 2, wherein: The at least one processor is configured to execute the command to perform the following processing: In response to a determination that not all of the plurality of control units have normally performed safety booting, restarting a failed control unit that has not normally performed safety booting; Determining whether the failed control unit is restarted normally; as well as In response to a determination that the failed control unit did not normally restart, one or more non-essential functions of the vehicle are disabled.

4. The system for generating vehicle identification information according to any one of claims 1 to 3, wherein: The plurality of control units include a central control unit and one or more secondary control units. The central control unit comprises the storage memory and the at least one processor. The at least one processor is configured to execute the command to determine whether all of the plurality of control units are normally securely started by: Perform a safe boot; Determining whether the secure boot is successful; In response to a determination that the secure boot is successful, sending a request related to a status of the one or more secondary control units to the one or more secondary control units; receiving the status of the one or more secondary control units from the one or more secondary control units; and Based on the situation, it is determined whether the one or more secondary control units have been safely started normally.

5. The system for generating vehicle identification information according to claim 4, wherein: The at least one processor is configured to execute the command to send a first failure notification to the one or more secondary control units in response to a failure of the secure boot, The one or more secondary control units are configured to select a control unit from the plurality of control units different from the central control unit as a new central control unit in response to receipt of the first failure notification.

6. The system for generating vehicle identification information according to claim 4 or 5, wherein: The status of the one or more secondary control units is cryptographically signed by the corresponding one or more secondary control units using an encryption key.

7. The system for generating vehicle identification information according to any one of claims 1 to 6, wherein: The plurality of control units include an electronic control unit ECU.

8. The system for generating vehicle identification information according to any one of claims 1 to 7, wherein: The identification information includes a software bill of materials SBOM.

9. The system for generating vehicle identification information according to any one of claims 1 to 8, wherein: The at least one processor is configured to execute the command to send the identification information to a server via an elliptic curve integrated encryption scheme ECIES.

10. A method for generating vehicle identification information, comprising: Determine whether all the multiple control units in the vehicle have been safely started normally; as well as In response to a determination that all of the plurality of control units have normally performed safety activation, identification information of the vehicle is generated based on the plurality of control units that have normally performed safety activation.

11. The method for generating vehicle identification information according to claim 10, wherein: The identification information specifies a plurality of encrypted signatures associated with the plurality of control units that have normally performed secure booting, and each of the plurality of encrypted signatures is unique.

12. The method for generating vehicle identification information according to claim 10 or 11, further comprising: In response to a determination that not all of the plurality of control units have normally performed safety booting, restarting a failed control unit that has not normally performed safety booting; Determining whether the failed control unit is restarted normally; as well as In response to a determination that the failed control unit did not normally restart, one or more non-essential functions of the vehicle are disabled.

13. The method for generating vehicle identification information according to any one of claims 10 to 12, wherein: The plurality of control units include a central control unit and one or more secondary control units. The determination of whether all of the plurality of control units in the vehicle have been safely started normally includes: Performing a safe start-up via the central control unit; Determining whether the secure boot is successful by the central control unit; In response to a determination that the secure boot is successful, sending, by the central control unit, a request related to the status of the one or more secondary control units to the one or more secondary control units; receiving, by the central control unit, the conditions of the one or more secondary control units from the one or more secondary control units; and The central control unit determines whether the one or more secondary control units have been safely started normally based on the situation.

14. The method for generating vehicle identification information according to claim 13, further comprising: In response to a failure of the secure boot, sending a first failure notification to the one or more secondary control units through the central control unit; as well as In response to receiving the first failure notification, a control unit is selected by the one or more secondary control units from the plurality of control units different from the central control unit as a new central control unit.

15. The method for generating vehicle identification information according to claim 13 or 14, wherein: The status of the one or more secondary control units is cryptographically signed by the corresponding one or more secondary control units using an encryption key.

16. The method for generating vehicle identification information according to any one of claims 10 to 15, wherein: The plurality of control units include an electronic control unit ECU.

17. The method for generating vehicle identification information according to any one of claims 10 to 16, wherein: The identification information includes a software bill of materials SBOM.

18. The method for generating vehicle identification information according to any one of claims 10 to 17, wherein: At least one processor is configured to execute commands to send the identification information to a server via an elliptic curve integrated encryption scheme ECIES.

19. A computer program product having recorded thereon commands, wherein the commands are executable by at least one processor, and the commands cause the at least one processor to perform a method. The method comprises: Determine whether all the multiple control units in the vehicle have been safely started normally; as well as In response to a determination that all of the plurality of control units have normally performed safety activation, identification information of the vehicle is generated based on the plurality of control units that have normally performed safety activation.

20. The computer program product of claim 19, wherein: The identification information specifies a plurality of encrypted signatures associated with the plurality of control units that have normally performed secure booting, and each of the plurality of encrypted signatures is unique.

Images