System and method for verifying vehicle hardware and computer program product

Abstract

A system and method of verifying vehicle hardware and a computer program product are provided. According to an exemplary embodiment, the system can include a storage memory storing computer executable instructions, and at least one processor communicatively coupled to the storage memory, the at least one processor can be configured to execute the instructions to perform the following actions: receive a cryptographic signature from target hardware and receive an authentication request; verify the authentication request based on the cryptographic signature; in response to a success of the verification of the authentication request, obtain an authentication parameter of the target hardware from the target hardware; instruct the target hardware to perform a proof of work (PoW); verify a result obtained by the target hardware performing the PoW based on the obtained authentication parameter of the target hardware; and in response to a success of the verification of the result obtained by performing the PoW, designate the target hardware as authenticated.

Description

Technical Field

[0001] Exemplary embodiments of this disclosure relate to vehicle systems, and more particularly, to systems and methods for verifying vehicle hardware, as well as computer program products. Background Technology

[0002] Modern vehicles are capable of performing a wide range of complex functions, such as generating telemetry data, sending and receiving data via the Internet, providing driver assistance actions, and similar functions. These functions can be activated and executed by hardware components installed within the vehicle.

[0003] Recently, vehicle hardware has been developed and manufactured to be expandable in a plug-and-play manner, resulting in hardware that can be quickly set up and operational without requiring extensive manual intervention. This improvement enhances the user experience in a simple and effective way, expanding the availability of vehicle functionality and computing power.

[0004] Relatedly, the aforementioned improvements in vehicle hardware provide leeway for the further exploitation and implementation of counterfeit and untrusted hardware (hardware capable of falsely reporting its own ability to perform specific actions) in vehicles. Examples of such hardware include USB (Universal Serial Bus) drives that falsely report storage space, counterfeit USB cables that can damage connected devices, fake modular CPUs (Central Processing Units), and similar hardware. Such hardware could significantly increase the risk to the safety and security of the vehicle's driver. Summary of the Invention

[0005] Exemplary implementations matching this disclosure enable hardware in a vehicle to be authenticated and verified in an accurate and efficient manner based on the actual results and synchronization cycles of proof-of-work performed by the hardware, thereby improving security against counterfeit and untrusted hardware.

[0006] According to an exemplary embodiment, a system is provided. The system may include: a storage device storing computer-executable instructions; and at least one processor communicatively connected to the storage device, the at least one processor being configured to execute the instructions to perform the following actions: receiving a cryptographic signature from target hardware and receiving an authentication request; verifying the authentication request based on the cryptographic signature; obtaining authentication parameters of the target hardware from the target hardware in response to successful verification of the authentication request; instructing the target hardware to perform proof-of-work (PoW); verifying the result obtained by performing PoW through the target hardware based on the obtained authentication parameters of the target hardware; and designating the target hardware as authenticated in response to successful verification of the result obtained by performing PoW.

[0007] According to an exemplary implementation, the obtained authentication parameters may include at least one of CPU speed, CPU frequency, and power consumption level.

[0008] According to an exemplary implementation, at least one processor may also be configured to execute instructions to perform the following actions: broadcasting the authentication capability; detecting a broadcast termination condition; and terminating the broadcast of the authentication capability in response to detecting the broadcast termination condition.

[0009] According to an exemplary implementation, the broadcast termination condition may include the vehicle not moving and the time since the start of the primary hardware being less than a threshold.

[0010] According to an exemplary implementation, at least one processor may also be configured to execute instructions to perform the following actions: establish a communication schedule with the target hardware based on the authentication parameters obtained from the target hardware and the authentication parameters of the first-level hardware; determine the amount of time during which the target hardware fails to communicate according to the communication schedule; and, in response to determining that the amount of time during which the target hardware fails to communicate according to the communication schedule exceeds a threshold, designate the target hardware as unauthenticated.

[0011] According to an exemplary implementation, the target hardware may be designated as authenticated in the authentication map along with the timestamp of the latest communication from the target hardware.

[0012] According to an exemplary implementation, the target hardware may include an electronic control unit (ECU).

[0013] According to an exemplary implementation, a method is provided. The method may include: receiving a cryptographic signature from target hardware and receiving an authentication request; verifying the authentication request based on the cryptographic signature; obtaining authentication parameters of the target hardware from the target hardware in response to successful verification of the authentication request; instructing the target hardware to perform proof-of-work (PoW); verifying the result obtained by performing PoW through the target hardware based on the obtained authentication parameters; and designating the target hardware as authenticated in response to successful verification of the result obtained by performing PoW.

[0014] According to an exemplary implementation, the obtained authentication parameters may include at least one of CPU speed, CPU frequency, and power consumption level.

[0015] According to an exemplary implementation, the method may further include: broadcasting the authentication capability; detecting a broadcast termination condition; and terminating the broadcast of the authentication capability in response to detecting the broadcast termination condition.

[0016] According to an exemplary implementation, the broadcast termination condition may include the vehicle not moving and the time since the start of the primary hardware being less than a threshold.

[0017] According to an exemplary implementation, the method may further include: establishing a communication schedule with the target hardware based on the authentication parameters obtained from the target hardware and the authentication parameters of the first-level hardware; determining the amount of time during which the target hardware fails to communicate according to the communication schedule; and, in response to determining that the amount of time during which the target hardware fails to communicate according to the communication schedule exceeds a threshold, designating the target hardware as unauthenticated.

[0018] According to an exemplary implementation, the target hardware may be designated as authenticated in the authentication map along with the timestamp of the latest communication from the target hardware.

[0019] According to an exemplary implementation, the target hardware may include an electronic control unit (ECU).

[0020] According to an exemplary embodiment, a non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium may record instructions executable by at least one processor to cause at least one processor to perform a method, the method comprising: receiving a cryptographic signature from target hardware and receiving an authentication request; verifying the authentication request based on the cryptographic signature; obtaining authentication parameters of the target hardware from the target hardware in response to successful verification of the authentication request; instructing the target hardware to perform proof-of-work (PoW); verifying the result obtained by performing PoW through the target hardware based on the obtained authentication parameters; and designating the target hardware as authenticated in response to successful verification of the result obtained by performing PoW.

[0021] According to an exemplary implementation, the obtained authentication parameters may include at least one of CPU speed, CPU frequency, and power consumption level.

[0022] According to an exemplary implementation, the method may further include: broadcasting the authentication capability; detecting a broadcast termination condition; and terminating the broadcast of the authentication capability in response to detecting the broadcast termination condition.

[0023] According to an exemplary implementation, the broadcast termination condition may include the vehicle not moving and the time since the start of the primary hardware being less than a threshold.

[0024] According to an exemplary implementation, the method may further include: establishing a communication schedule with the target hardware based on the authentication parameters obtained from the target hardware and the authentication parameters of the first-level hardware; determining the amount of time during which the target hardware fails to communicate according to the communication schedule; and, in response to determining that the amount of time during which the target hardware fails to communicate according to the communication schedule exceeds a threshold, designating the target hardware as unauthenticated.

[0025] According to an exemplary implementation, the target hardware may be designated as authenticated in the authentication map along with the timestamp of the latest communication from the target hardware.

[0026] Further solutions will be partially described in the following description and will become partially apparent from the description, or may be implemented by practicing the embodiments presented in this disclosure. Attached Figure Description

[0027] Hereinafter, the functions, advantages and importance of the preferred embodiments of the present disclosure will be described with reference to the accompanying drawings, in which the same reference numerals denote the same elements.

[0028] Figure 1 This is a block diagram illustrating an exemplary system configuration for verifying vehicle hardware, representing one or more exemplary implementations.

[0029] Figure 2 This is a flowchart illustrating an exemplary method for verifying vehicle hardware according to one or more exemplary embodiments.

[0030] Figure 3 This is a flowchart illustrating an exemplary method for verifying vehicle hardware according to one or more exemplary embodiments.

[0031] Figure 4A This is a diagram illustrating a sequence of processes for verifying vehicle hardware using one or more exemplary implementations.

[0032] Figure 4B This is a diagram illustrating a sequence of processes for verifying vehicle hardware using one or more exemplary implementations.

[0033] Figure 5 This is a block diagram illustrating exemplary constituent elements in a system with one or more exemplary embodiments. Detailed Implementation

[0034] The following detailed description of preferred embodiments will be made with reference to the accompanying drawings. The above disclosure provides examples and descriptions, but is not intended to be exhaustive, nor is it intended to limit the implementation to the exact forms disclosed. Modifications and variations can be made in light of the above disclosure, or modifications and variations can be obtained according to the implementation of the embodiments. Furthermore, one or more functions or components of one embodiment can be incorporated into or combined with another embodiment (or one or more functions of another embodiment). Moreover, it is understood that in the flowcharts and descriptions of the actions provided below, one or more actions may be omitted, one or more actions may be added, one or more actions may be performed simultaneously (at least partially), and the order of one or more actions may be interchanged.

[0035] Even if a specific combination of functions is listed in the claims and / or disclosed in this specification, such combination is not intended to limit the disclosure of possible implementations. In fact, many functions can be combined in ways not specifically listed in the claims and / or not disclosed in this specification. Each dependent claim listed below may be directly dependent on only one claim, but the disclosure of possible implementations includes each dependent claim combined with all other claims in the set of claims.

[0036] Unless otherwise explicitly stated, the elements, actions, or instructions used in this specification should not be construed as essential or necessary. Furthermore, when used in this specification, the articles “a” and “an” are intended to include more than one item and may be used interchangeably with “more than one.” Where only one item is intended, the term “one” or similar terms are used. Additionally, when used in this specification, the terms “has,” “have,” “having,” “include,” “including,” or similar terms are intended as open-ended expressions. Moreover, unless otherwise explicitly stated, the phrase “based on…” is intended to mean “at least partially based on….” Furthermore, expressions such as “[A] and / or [B],” “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.

[0037] Regarding expressions such as "at least one processor," when configured to perform the implementation of multiple actions, the execution of multiple instructions, etc., such expressions should be understood as each of a single processor performing the implementation of multiple actions, etc., or each of a plurality of processors performing at least a portion (however, not necessarily all) of the implementation of multiple actions, etc.

[0038] Throughout this specification, references to "one embodiment," "implementation," "non-limiting preferred embodiment," or the same terms mean that a particular function, structure, or feature described in connection with the illustrated embodiment is included in at least one embodiment of the solution. Therefore, the phrases "in one embodiment," "in an embodiment," "in a non-limiting preferred embodiment," and the same terms throughout this specification may all refer to the same embodiment, but not necessarily the same embodiment.

[0039] Furthermore, the functions, advantages, and features described in this disclosure can be combined in any suitable manner in more than one exemplary embodiment. Those skilled in the art, based on the description herein, will recognize that this disclosure can be implemented in more than one manner without specific functions or advantages associated with particular embodiments. In other instances, further functions and advantages may be recognized in specific embodiments, though not always present in all embodiments of this disclosure.

[0040] Furthermore, the terms "vehicle" and "vehicle system" used in this specification refer to any suitable type of vehicle capable of implementing the exemplary embodiments of this disclosure. For example, "vehicle" can mean a powered vehicle such as a passenger car, truck, bus, motorcycle, or any other suitable type of automobile powered by an engine, motor, or other mechanical component. Alternatively or further, without departing from the scope of this disclosure, "vehicle" used in this specification can mean a bicycle, skateboard, or any other suitable type of unpowered vehicle.

[0041] As explained above, improvements in vehicle hardware can create hardware capable of falsifying data and false reports to perform specific actions, which could significantly increase the risk to the safety and security of the vehicle's driver.

[0042] In related technologies, to verify the authenticity of hardware components, drivers may need to manually inspect and verify the hardware, for example, by checking the serial number, using separate verification tools, or similar operations. However, such methods can be inefficient and sometimes unreliable when it comes to accurately verifying hardware.

[0043] Therefore, a system is needed that can verify the hardware in a vehicle in an efficient and accurate manner.

[0044] It can be assumed that the functions, advantages, and importance of the exemplary embodiments described in this specification are only a part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure. The following provides further descriptions related to the functions, constituent elements, configurations, operations, and implementation schemes of the exemplary embodiments of this disclosure.

[0045] Figure 1 This is a block diagram illustrating an exemplary system configuration 100 for verifying vehicle hardware, representing one or more exemplary implementations. (See diagram for example.) Figure 1 As shown, the system configuration 100 may include primary hardware 110 and target hardware 120.

[0046] Level 1 hardware 110 may include components of hardware that have been verified as genuine and are installed in the vehicle. Level 1 hardware can be verified, for example, via verification tools / software and the like. Here, Level 1 hardware 110 can function as an authentication point for authenticating and verifying other hardware in the vehicle. Relatedly, according to an exemplary embodiment, Level 1 hardware 110 may include a device, system, platform, module, or the like that can be configured to perform one or more actions or operations to verify vehicle hardware. According to an exemplary embodiment, Level 1 hardware may include an Electronic Control Unit (ECU), wherein the ECU may include a System-on-Chip (SoC).

[0047] Relatedly, Level 1 hardware 110 can be configured to collect requests from other components regarding their status, condition, and capabilities. These requests may comply with specific standards such as the ISO 17990-3 software entitlement schema. Furthermore, Level 1 hardware 110 can utilize one or more hardware-based security technologies when performing one or more actions described in this specification within a secure enclave for execution. These hardware-based security technologies may include, for example, ARM Trustzone, AMD Secure Encrypted Virtualization (SEV), Intel Software Guard Extensions (SGX), and similar technologies. Moreover, Level 1 hardware can utilize one or more encryption key storage methods when performing one or more actions described in this specification. These encryption key storage methods may, for example, be tamper-proof and non-cloneable electronic fuses (e-fuse). Furthermore, Level 1 hardware 110 may include and implement a Trusted Execution Environment (TEE).

[0048] Exemplary actions that can be performed by the Level 1 hardware 110, which verifies the vehicle hardware, will be referred to Figure 2 Figure 4 is illustrated below. Furthermore, some exemplary components that may be included in the primary hardware 110 of one or more exemplary embodiments will be referred to... Figure 5 The following is a record of this.

[0049] Target hardware 120 may include unverified components of vehicle-mounted hardware that are the target of verification / certification performed by primary hardware 110. According to an exemplary embodiment, the target hardware may include an electronic control unit (ECU), which may include a system-on-a-chip (SoC). Target hardware 120 may be communicatively connected to primary hardware 110 via one or more interfaces such as a serial port, USB port, PCI (Peripheral Component Interconnect) Express, Ethernet, and similar interfaces. Furthermore, target hardware 120 may include and implement a Trusted Execution Environment (TEE).

[0050] The following is for reference Figure 2 Figure 4 illustrates some exemplary actions that can be performed by the first-level hardware of this disclosure.

[0051] Figure 2 The flowchart illustrates an exemplary method 200 for verifying vehicle hardware, representing one or more exemplary implementations. One or more actions in method 200 may be performed by at least one processor (e.g., processor 512) of the primary hardware.

[0052] like Figure 2 As shown, in action S210, at least one processor can be configured to receive an authentication request. The authentication request can be received from the target hardware requesting Level 1 hardware to authenticate / verify the target hardware. Furthermore, the authentication request may contain a cryptographic signature.

[0053] According to an exemplary implementation, authentication requests can be received via more than one interface of the Level 1 hardware. In particular, the Level 1 hardware may include and implement a Trusted Execution Environment (TEE), whereby the TEE can be configured to control more than one interface of the Level 1 hardware (e.g., serial port, USB port, PCI High Speed, Ethernet, etc.), listen for and wait for the receipt of authentication requests.

[0054] According to an exemplary implementation, an authentication request can be sent from the target hardware in response to receiving authentication capability from the primary hardware. Specifically, the primary hardware can be configured to broadcast the authentication capability to all hardware in the vehicle. The authentication capability can be broadcast periodically (e.g., once per second) until a broadcast termination condition is detected. In response to detecting the broadcast termination condition, the primary hardware can be configured to terminate the broadcast of the authentication capability.

[0055] According to an exemplary implementation, authentication capabilities may include signals, messages, and similar content indicating that the Level 1 hardware can be used for authentication (verification), as well as any associated communication information, such as one or more interfaces through which the Level 1 hardware can communicate (e.g., serial port, USB port, PCI high-speed, Ethernet, etc.). Furthermore, broadcast termination conditions may include, for example, the vehicle not moving, the time since the Level 1 hardware started being less than a threshold (e.g., less than 300 seconds since the Level 1 hardware started (ignition started), and similar conditions. Therefore, when one of the above broadcast termination conditions is met, the Level 1 hardware can terminate the broadcast of the authentication capability.

[0056] Considering the above, the target hardware can be configured to send an authentication request to the primary hardware in response to receiving an authentication capability broadcast from the primary hardware. According to an exemplary implementation, the target hardware can be configured to send an authentication request to the primary hardware in response to receiving multiple authentication capabilities broadcast from the primary hardware. For example, the target hardware can be configured to send an authentication request to the primary hardware after receiving three broadcast authentication capabilities.

[0057] According to an exemplary implementation, the authentication request can be received at the beginning of a key exchange method such as Diffie-Hellman key exchange. Furthermore, the authentication request can include a data packet that has been cryptographically signed using an encryption key.

[0058] According to an exemplary implementation, in response to receiving an authentication request, the Level 1 hardware can establish a secure connection with the target hardware. Then, the method proceeds to action S220.

[0059] In action S220, at least one processor can be configured to verify the authentication request based on a cryptographic signature.

[0060] Here, as described above, the authentication request may include a data packet that has been cryptographically signed using a cryptographic key. Therefore, at least one processor can be configured to verify the authentication request by verifying the chain of trust of the cryptographic key used to sign the cryptographic signature of the authentication request.

[0061] Relatedly, in the encryption key (e.g., based on the use of a specific method) Figure 1When the encrypted key stored using the aforementioned encryption key storage method is properly linked to the root of a trust encryption key via a chain, at least one processor can determine that the encryption key used to sign the encrypted signature of the authentication request comes from a trusted manufacturer, and the verification can be successful. Conversely, if the encryption key is not properly linked to the root of a trust encryption key via a chain, at least one processor can determine that the encryption key used to sign the encrypted signature of the authentication request does not come from a trusted manufacturer, and the verification can fail.

[0062] Therefore, in response to the successful verification of the authentication request, at least one processor can determine that the next stage of verification can begin to check whether the target hardware is genuine, and then the method proceeds to action S230. On the other hand, in response to the failure of the authentication request verification, at least one processor can determine that the target hardware is not genuine, and then the method proceeds to action S270.

[0063] In action S230, at least one processor may be configured to acquire authentication parameters of the target hardware. Authentication parameters may include parameters for verification of Proof of Work (PoW) performed by the target hardware (hereinafter referred to as actions S240 and S250). According to an exemplary embodiment, authentication parameters may also include parameters for clock cycle synchronization between the primary hardware and the target hardware (hereinafter referred to as action S235). According to an exemplary embodiment, authentication parameters may include at least one of CPU speed, CPU frequency, and power level.

[0064] According to an exemplary implementation, at least one processor can be configured to send a request to receive authentication parameters of the target hardware to the target hardware, receive the authentication parameters of the target hardware from the target hardware, and thereby obtain the authentication parameters of the target hardware. Then, the method proceeds to action S240.

[0065] In action S240, at least one processor can be configured to instruct the target hardware to perform Proof-of-Work (PoW). Here, PoW can refer to a form of cryptographic authentication whereby a target entity (i.e., the target hardware) authenticates to another entity (i.e., the first-level hardware) that it has performed a specific computational job. Relatedly, PoW can include PoW execution items associated with peripheral devices of the target hardware.

[0066] According to an exemplary implementation, at least one processor may be configured to determine (i.e., design, generate, select, etc.) PoW, send a request to target hardware to perform the determined PoW to the target hardware, receive the result obtained by performing PoW through the target hardware from the target hardware, thereby instructing the target hardware to perform PoW.

[0067] PoW can be determined using any method and in any manner as needed. According to an exemplary implementation, PoW can be determined in the normal world context outside the TEE of the first-level hardware.

[0068] According to an exemplary implementation, PoW can be encrypted using the public key of the target hardware's TEE, wherein the public key is signed by the primary hardware and sent to the target hardware via a secure channel to the TEE. The method then proceeds to action S250.

[0069] In action S250, at least one processor may be configured to verify the result obtained by performing PoW through the target hardware. The result obtained by performing PoW through the target hardware may be verified based on the authentication parameters acquired by the target hardware (i.e., the authentication parameters acquired during action S230).

[0070] For example, during action S230, authentication parameters can be acquired, where the target hardware reports its CPU speed (authentication parameter) as 5.5 GHz. Then, during action S240, the first-level hardware can instruct the target hardware to perform Proof-of-Work (PoW) to authenticate the target hardware's true / actual CPU speed. Relatedly, during action S240, the target hardware can send the PoW result indicating its true / actual CPU speed is 2.1 GHz. Therefore, during action S250, the first-level hardware can verify this result and recognize that the target hardware's true / actual CPU speed is lower than the reported CPU speed.

[0071] It is understood here that the methods and specifications for verifying the results obtained from PoW can be arbitrary, based on specific authentication parameters, and can be specified by the user (e.g., the manufacturing industry). For example, verification can be successful if the obtained authentication parameters meet or fall within a specific amount of error relative to the results obtained from PoW (e.g., verification can be successful if the results obtained from PoW indicate that the true / actual CPU speed of the target hardware is 5.5 GHz (the reported CPU speed)). In another example, verification can be successful if the obtained authentication parameters are lower than the results obtained from PoW (i.e., the results are reported at least at a minimum level, e.g., verification is successful if the results obtained from PoW indicate that the true / actual CPU speed of the target hardware is at least 5.5 GHz (the reported CPU speed)).

[0072] Relatedly, in response to the successful verification of the result obtained from performing PoW, at least one processor can determine that the target hardware is genuine, and then the method proceeds to action S260. On the other hand, in response to the failure of the verification of the result obtained from performing PoW, at least one processor can determine that the target hardware is not genuine, and then the method proceeds to action S270.

[0073] In action S260, at least one processor can be configured to designate the target hardware as authenticated. The target hardware can be designated as authenticated in an authentication mapping. According to an exemplary implementation, the target hardware can be designated as authenticated in the authentication mapping along with the timestamp of the latest communication from the target hardware.

[0074] In particular, the Level 1 hardware can store a mapping representing all hardware in vehicles that have been certified within the TEE. Therefore, in response to the successful verification of the results obtained from the PoW operation, the Level 1 hardware can update the mapping in a manner that designates the target hardware as already certified (genuine).

[0075] According to an exemplary implementation, the authentication map may also include the results of PoW and the inherent identification information of the target hardware (e.g., a globally unique identifier (GUID)).

[0076] The above description is provided with reference to the “mapping diagram”, but it is understood that this disclosure is not limited thereto, and the “mapping diagram” can be any form such as a list or a similar form.

[0077] In action S270, at least one processor can be configured to designate the target hardware as uncertified. The target hardware can be designated as uncertified in the certification mapping.

[0078] Considering the above, at least one processor can be configured to enable all hardware in a certified vehicle to perform their respective functions and actions.

[0079] For example, Level 1 hardware can enable the operating system (OS) of the (certified and verified) target hardware to communicate with it via a low-latency communication channel. Here, Level 1 hardware can then directly address the target hardware's memory address space by sending commands prefixed with a GUID representing the target hardware. This allows Level 1 hardware to expand its control area. Level 1 hardware can then designate sufficiently robust components of certified hardware (i.e., the certified and verified target hardware) as Level 2 hardware and share sufficient information with them according to a synchronization schedule. As a result, in the event of a failure of Level 1 hardware, Level 2 hardware can maintain control and function as Level 1 hardware.

[0080] When actions S260 and / or S270 are performed, method 200 may end or terminate. Alternatively, method 200 may return to action S210, resulting in at least one processor being configured to repeatedly perform (in action S210) receiving authentication requests, (in action S220) verifying authentication requests, (in action S230) acquiring authentication parameters, (in action S240) indicating target hardware, (in action S250) verifying results, (in action S260) specifying target hardware, and / or (in action S270) specifying target hardware for at least a predetermined amount of time. For example, at least one processor can continuously (or periodically) receive authentication requests from other hardware in the vehicle (i.e., the second target hardware), and then restart the reception of authentication requests (in action S210), the verification of authentication requests (in action S220), the acquisition of authentication parameters (in action S230), the indication of target hardware (in action S240), the verification of results (in action S250), the designation of target hardware (in action S260), and / or the designation of target hardware (in action S270).

[0081] Considering the above, the process enables the hardware in the vehicle to be authenticated and verified in an accurate and effective manner based on the actual results of PoW performed through the hardware, thereby improving security against counterfeit and untrusted hardware.

[0082] Figure 3 The flowchart illustrates an exemplary method 300 for verifying vehicle hardware, representing one or more exemplary implementations. One or more actions in method 300 may be performed by at least one processor (e.g., processor 512) of the primary hardware.

[0083] like Figure 3 As shown, method 300 can be used with... Figure 2 The method described above is the same as 200, except that action S235 is added between action S230 and action S240, and action S280 is added after action S260. Therefore, for clarity, the descriptions related to method 200 are omitted in this specification.

[0084] In action S235, at least one processor can be configured to establish a communication schedule with the target hardware.

[0085] The communication schedule can include a timeline in which the primary hardware and the target hardware can communicate with each other. According to an exemplary implementation, the communication schedule can determine a specified synchronization period (e.g., a clock synchronization period) for the periodic loop of times when the primary hardware and the target hardware can communicate with each other (synchronously).

[0086] Therefore, according to the exemplary implementation, the primary hardware can communicate with the target hardware according to a communication schedule. Specifically, the primary hardware can communicate with the target hardware according to the communication schedule both before the target hardware is designated as authenticated (e.g., during action S240) and after the target hardware is designated as authenticated (after action S260). For example, after the target hardware is designated as authenticated during action S260, the primary hardware can continue to communicate with the target hardware according to a communication schedule from the normal world operating system, where services can be synchronized using a common synchronization point (an incremented signed counter message) according to the communication schedule.

[0087] The communication schedule can be established based on the authentication parameters obtained by the target hardware and the authentication parameters of the first-level hardware. In particular, according to an exemplary implementation, at least one processor can be configured to determine the communication schedule based on the authentication parameters obtained by the target hardware and the authentication parameters of the first-level hardware, and send the determined communication schedule to the target hardware, thereby establishing a communication schedule with the target hardware.

[0088] For example, as described above for action S230, the authentication parameters may include parameters for clock cycle synchronization between the primary hardware and the target hardware, and may include at least one of CPU speed, CPU frequency, and power consumption level. Accordingly, the primary hardware may (e.g., via TEE) check its own CPU speed, CPU frequency, and power consumption level, check the target hardware's CPU speed, CPU frequency, and power consumption level (the authentication parameters acquired during action S230), and identify any overlapping time slots related to instruction execution in the target hardware's CPU to determine a communication schedule. Then, the determined communication schedule can be sent to the target hardware accordingly. It is understood that, if the target hardware's CPU is a real-time core, the above can be implemented using a shared communication mechanism per x number of instructions. Such a real-time core can be verified to execute time synchronization protocols such as Autosar PRS TimeSync Protocol.

[0089] It is understandable that different CPUs (i.e., within a SoC) may operate at different frequencies and clock speeds, but there should be a common synchronization point between different SoCs (i.e., Tier 1 hardware and target hardware). Therefore, further certification and verification can be performed periodically based on the parameters mentioned above.

[0090] Relatedly, as mentioned above, the primary hardware can communicate with the target hardware according to the communication schedule (synchronization cycle) after the target hardware is designated as authenticated during action S260.

[0091] Here, in action S280, at least one processor can be configured to determine the amount of time during which the target hardware fails to communicate according to the communication schedule, and to determine whether the determined amount of time is greater than a threshold.

[0092] Relatedly, in response to the determination that the amount of time is not more than a threshold, the Level 1 hardware can determine that the target hardware is still trustworthy and continuously check and track the amount of time the target hardware has not communicated according to the communication schedule. On the other hand, in response to the determination that the amount of time is more than a threshold, the Level 1 hardware can determine that the target hardware is no longer trustworthy, and the method enters action S270, designating the target hardware as unauthenticated.

[0093] For example, if the target hardware misses three synchronization cycles, the Level 1 hardware can determine that the target hardware is no longer trustworthy.

[0094] Considering the above, the process enables certified / verified hardware in the vehicle to be continuously checked and verified based on a synchronization cycle, thereby further improving security against counterfeit and untrusted hardware.

[0095] Furthermore, as described above for method 200, the primary hardware can designate a component of sufficiently robust, certified hardware (i.e., the certified and verified target hardware) as secondary hardware and share sufficient information with the secondary hardware according to a synchronization schedule. As a result, in the event of a failure of the primary hardware, the secondary hardware can maintain control and function as the primary hardware. Here, the secondary hardware can maintain a known state of the memory via a hash map and send the hash value of the hash map to the primary hardware at common synchronization points. Alternatively, the primary hardware can verify the resulting hash map. Thus, the primary hardware recognizes that the secondary hardware is still valid and synchronized.

[0096] Figure 4A and Figure 4B This describes a sequence of processes for verifying vehicle hardware, illustrating one or more exemplary implementations. For example... Figure 4A and Figure 4B As shown, the process sequence may include a first-stage ECU 410 and a target ECU 420. The first-stage ECU 410 and the target ECU 420 can be configured with a specific... Figure 1 The aforementioned first-level hardware 110 and target hardware 120 are identical. Furthermore, Figure 4A and Figure 4B One or more actions may include reference Figure 2 and Figure 3 And performed one or more of the above actions or a part of the above actions.

[0097] In step 1, the first-level ECU 410 can broadcast the authentication capability that can be received by the target ECU 420. Here, the target ECU 420 can then count the amount of time that the target ECU 420 receives the authentication capability, and in the same manner as described above for action S210, when the count exceeds the threshold in steps 2 to 3, an authentication request is sent to the first-level ECU 410.

[0098] In step 4, the first-level ECU 410 can verify the received authentication request in the same manner as described above for action S220.

[0099] In steps 5 to 6, in response to the successful verification of the received authentication request, the first-level ECU 410 can send a request to receive authentication parameters to the target ECU 420, and can receive authentication parameters from the target ECU 420 in the same manner as described above for action S230.

[0100] In steps 7 to 8, the first-level ECU 410 can determine the communication schedule and send the communication schedule to the target ECU 420 in the same manner as described above for action S235.

[0101] In steps 9 to 10, the first-level ECU 410 can determine the PoW and send the PoW to the target ECU 420. Here, the target ECU 420 can then perform the PoW in steps 11 to 12 in the same manner as described above for action S240 and send the result of performing the PoW to the first-level ECU 410.

[0102] In step 13, the first-level ECU 410 can verify the results obtained from the PoW operation in the same manner as described above for action S250.

[0103] In step 14, in response to the successful verification of the result obtained by performing PoW, the first-level ECU 410 can designate the target ECU 420 as certified in the certification mapping in the same manner as described above for action S260.

[0104] In step 15, the first-level ECU 410 can track the amount of time that the target ECU 420 has not communicated according to the communication schedule in the same manner as described above for action S280.

[0105] In step 16, in response to the determination that the amount of time is greater than the threshold, the first-level ECU 410 can determine that the target ECU 420 is no longer trustworthy, and designate the target ECU 420 as uncertified in the authentication mapping in the same manner as described above for action S270.

[0106] Figure 5 This is a block diagram illustrating exemplary components in a system 500 with one or more exemplary implementations. System 500 can be... Figure 1 The first-level hardware 110 corresponds to this, so it is possible that, unless otherwise specified, the functions associated with the first-level hardware 110 and the system 500 can be applied in the same way.

[0107] like Figure 5 As shown, system 510 may include at least one bus 511, at least one processor 512, at least one memory 513, at least one storage component 514, at least one input component 515, at least one output component 516, and at least one communication interface 517.

[0108] It can be assumed that, without departing from the scope of this disclosure, system 510 may include more than Figure 5 The contents shown may have more or fewer constituent elements. For example, in one embodiment, system 510 may include multiple storage constituent elements 514, input constituent elements 515 and output constituent elements 516 may be implemented as transceiver constituent elements, and memory 513 and storage constituent elements 514 may be implemented as storage memory, and may have similar contents.

[0109] Bus 511 can be configured to facilitate or enable communication between the components of system 510. Specifically, bus 511 can connect the components in a manner that enables them to communicate with each other, providing components related to the data transmission and flow of control signals between the components. Bus 511 may include one or more of the following buses that can be implemented in system 510 to enable real-time (or near-real-time) communication and cooperation between the components within system 510: internal bus, address bus, data bus, control bus, Controller Area Network (CAN) bus, Ethernet bus, Peripheral Component Interconnect Express (PCIe) bus, and any other suitable type of bus.

[0110] Processor 512 can be implemented by hardware, firmware, or a combination of hardware and software, and can be configured to perform real-time (or near-real-time) data processing and control of system 510. Processor 512 may include one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), Neural Processing Unit (NPU), Tensor Processing Unit (TPU), Accelerated Processing Unit (APU), microprocessor, microcontroller, Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), Application-Specific Integrated Circuit (ASIC), and / or another type of processing or computing component that can be implemented in system 510. In some implementations, processor 512 may be programmed to perform more than one action described in this specification. Furthermore, processor 512 may include multiple processing units, each dedicated to performing a specific action.

[0111] Memory 513 may include one or more media that store temporary data, runtime variables, program instructions, and buffers required for the operation of system 510. Memory 513 may include one or more of the following types of memory that can be implemented in system 510 to store information and / or instructions for use by processor 512: flash memory, read-only memory (ROM), random-access memory (RAM), dynamic or static storage devices (e.g., flash memory, magnetic storage, and / or optical storage), or any other suitable type of memory.

[0112] Storage component 514 can be configured to store non-volatile data such as firmware, configuration settings, calibration data, information, and / or software associated with the operation and use of system 510. For example, storage component 514 may include hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid-state drives), compact optical disks (CDs), digital versatile optical disks (DVDs), floppy disks, cassette tapes, magnetic tapes, and / or another type of non-transitory computer-readable media, and includes corresponding drives.

[0113] According to an exemplary embodiment, storage component 514 can be configured to store computer-readable or computer-executable instructions that implement one or more actions of system 510. Storage component 514 can provide the stored information to memory 513 for execution by processor 512.

[0114] Input element 515 may include one or more input elements (e.g., a touchscreen display, keyboard, keypad, mouse, button, switch, and / or microphone) that enable system 510 to receive information via user input. Output element 516 may include one or more output elements (e.g., a display, speaker, navigation device, one or more light-emitting diodes (LEDs)). According to an exemplary embodiment, input element 515 and / or output element 516 may be optional and may be removed from system 510.

[0115] At least one communication interface 517 may include a transceiver (e.g., a transceiver and / or a separate receiver and transmitter) that enables the system 510 to communicate with other components (e.g., ECU, user equipment, etc.) via a wired connection, a wireless connection, or a combination of wired and wireless connections. For example, the communication interface 517 may include a Controller Area Network (CAN) bus interface, an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, or a similar interface.

[0116] According to one or more embodiments, the communication interface 517 may include at least one input / output (I / O) interface, at least one network interface, at least one storage interface, or a similar interface that enables components 512 to 516 to communicate with other components. Furthermore, the communication interface 517 may include at least one application programming interface (API) that enables system 510 (or one or more components included in system 510) to communicate with one or more software applications (e.g., software applications deployed in an ECU).

[0117] Computer-executable instructions (e.g., software instructions, etc.) may be read into memory 513 and / or storage component 514 via communication interface 517 from another computer-readable medium or from another device (e.g., a remote server, external storage, etc.). When executed, the computer-executable instructions stored in memory 513 and / or storage component 514 may cause processor 512 to execute one or more processes described in this specification. Further or alternatively, hard-wired circuitry may be used instead of software instructions, or hard-wired circuitry may be used in combination with software instructions, to execute one or more processes described in this specification. Therefore, the implementation schemes described in this specification are not limited to any specific combination of hardware circuitry and software.

[0118] It can be assumed that the functions, advantages, and importance of the exemplary embodiments described above in this specification are only a part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure. The following provides further explanation of the functions, constituent elements, configuration, operation, and implementation of the exemplary embodiments of this disclosure, as well as the associated technical advantages and importance.

[0119] It is understood that the specific order or hierarchy of function blocks in the process / flowcharts disclosed in this specification are examples of exemplary methods. It is understood that the specific order or hierarchy of function blocks in the process / flowcharts can be reconfigured based on design preferences. Furthermore, some function blocks can be combined or omitted. The appended method claims present the elements of various function blocks in a sample order and are not intended to limit the user to the specific order or hierarchy presented.

[0120] Some implementations may relate to systems, methods, and / or computer-readable media at any possible level of technical detail. Furthermore, as described above, one or more of the aforementioned components may be implemented as instructions 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 media(s)) having computer-readable program instructions therein to cause the processor (or processor(s)) to perform actions.

[0121] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium can 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 thereto. A non-exhaustive list of more specific examples related to computer-readable storage media includes portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile optical disc (DVD), memory sticks, floppy disks, punched cards containing instructions, or mechanically encoded devices such as raised structures in slots, and any suitable combination of the above. The computer-readable storage medium used in this specification should not be construed as a temporary signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through an optical fiber), or an electrical signal transmitted through a wire.

[0122] The computer-readable program instructions described in this specification can be downloaded from a computer-readable storage medium to various computing / processing devices, or downloaded via a network such as the Internet, local area network, wide area network, and / or wireless network to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. Network adapter cards or network interfaces within each computing / processing device receive the computer-readable program instructions from the network and transmit them to the computer-readable storage medium within the respective computing / processing device.

[0123] Computer-readable program code / instructions that perform actions can be any of the following: assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages. These programming languages ​​include object-oriented programming languages ​​such as Smalltalk, C++, or similar languages, as well as procedural programming languages ​​such as "C" or similar languages. Computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can 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 can connect to an external computer (e.g., via the internet using an internet service provider). In some implementations, for example, to perform a scheme or action, electronic circuits including programmable logic circuits, field-programmable gate arrays (FPGAs) or programmable logic arrays (PLAs) can use state information of computer-readable program instructions to personalize the electronic circuits, thereby executing computer-readable program instructions.

[0124] To generate a machine, the computer-readable program instructions can be provided to a processor of a SoC, a general-purpose computer, a special-purpose computer, or other programmable data processing device, resulting in the instructions, which, when executed by the processor of the computer or other programmable data processing device, create components that implement the functions / behaviors specified in the function blocks or function blocks(multiple) of the flowchart and / or block diagram. The computer-readable program instructions can also be stored in a computer-readable storage medium that instructs a computer, programmable data processing device, and / or other device to function in a particular manner, resulting in a computer-readable storage medium internally storing the instructions comprising an article of manufacture that includes instructions for implementing the functions / behaviors specified in the function blocks or function blocks(multiple) of the flowchart and / or block diagram.

[0125] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or another device and perform a series of action steps on the computer, other programmable apparatus or other device to generate a computer-implemented process, the result of which is that the instructions executed on the computer, other programmable apparatus or other device implement the functions / behaviors specified in the function blocks or function blocks(multiple) of the flowchart and / or block diagram.

[0126] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and action of possible implementations of systems, methods, and computer-readable media in various embodiments. Relatedly, each functional block in a flowchart or block diagram may represent a module, segment, or portion of instructions having one or more executable instructions that implement the specified logical function. Compared to what is depicted in the figures, methods, computer systems, and computer-readable media may include further functional blocks, fewer functional blocks, different functional blocks, or functional blocks with different configurations. In some alternative implementations, the functions described in the functional blocks may occur independently of the order described in the figures. For example, two functional blocks shown consecutively may actually be executed simultaneously or substantially simultaneously, or, depending on the related functions, the functional blocks may sometimes be executed in reverse order. It should also be noted that the functional blocks of the block diagrams and / or flowcharts, as well as combinations of functional blocks in the block diagrams and / or flowcharts, can be implemented by a system based on dedicated hardware, wherein the dedicated hardware-based system performs the specified function or behavior or executes a combination of dedicated hardware and computer instructions.

[0127] It is evident that the systems and / or methods described in this specification can be implemented in various forms, including 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 a limitation on the implementation. Therefore, the actions and behaviors of the system and / or method are described in this specification without reference to specific software code, and it is understood that software and hardware can be designed to implement the system and / or method based on the description in this specification.

[0128] Computer program products including the computer programs described above can also be stored on storage media or distributed via communication lines.

Claims

1. A system for verifying vehicle hardware, comprising: Storage memory, which stores computer-executable instructions; and At least one processor is communicatively connected to the storage device. The at least one processor is configured to execute the instructions to perform the following actions: Receive the cryptographic signature and authentication request from the target hardware; The authentication request is verified based on the encrypted signature. In response to the successful verification of the authentication request, the authentication parameters of the target hardware are obtained from the target hardware; Instruct the target hardware to perform Proof-of-Work (PoW); Based on the authentication parameters obtained from the target hardware, the result obtained by performing the PoW through the target hardware is verified. as well as In response to the successful verification of the result obtained from the PoW, the target hardware is designated as certified.

2. The system according to claim 1, wherein, The obtained authentication parameters include at least one of CPU speed, CPU frequency, and power consumption level.

3. The system according to claim 1 or 2, wherein, The at least one processor is also configured to execute the instructions to perform the following actions: Broadcast the authentication capability; Detect the broadcast termination conditions; and In response to the detection of the broadcast termination condition, the broadcast of the authentication capability is terminated.

4. The system according to claim 3, wherein, The broadcast termination conditions include the vehicle not moving and the time since the primary hardware was started being less than a threshold.

5. The system according to any one of claims 1 to 4, wherein, The at least one processor is also configured to execute the instructions to perform the following actions: Based on the obtained authentication parameters of the target hardware and the authentication parameters of the first-level hardware, a communication schedule with the target hardware is established. Determine the amount of time during which the target hardware did not communicate according to the communication schedule; as well as In response to the determination that the amount of time during which the target hardware failed to communicate according to the communication schedule exceeded a threshold, the target hardware was designated as unauthenticated.

6. The system according to any one of claims 1 to 5, wherein, The target hardware, along with the timestamp of the latest communication from the target hardware, is designated as authenticated in the authentication map.

7. The system according to any one of claims 1 to 6, wherein, The target hardware includes an electronic control unit (ECU).

8. A method for verifying vehicle hardware, comprising: Receive the cryptographic signature and authentication request from the target hardware; The authentication request is verified based on the encrypted signature. In response to the successful verification of the authentication request, the authentication parameters of the target hardware are obtained from the target hardware; Instruct the target hardware to perform Proof-of-Work (PoW); Based on the authentication parameters obtained from the target hardware, the result obtained by performing the PoW through the target hardware is verified. as well as In response to the successful verification of the result obtained from the PoW, the target hardware is designated as certified.

9. The method according to claim 8, wherein, The obtained authentication parameters include at least one of CPU speed, CPU frequency, and power consumption level.

10. The method according to claim 8 or 9, wherein, The method further includes: Broadcast the authentication capability; Detect the broadcast termination conditions; and In response to the detection of the broadcast termination condition, the broadcast of the authentication capability is terminated.

11. The method according to claim 10, wherein, The broadcast termination conditions include the vehicle not moving and the time since the primary hardware was started being less than a threshold.

12. The method according to any one of claims 8 to 11, wherein, The method further includes: Based on the obtained authentication parameters of the target hardware and the authentication parameters of the first-level hardware, a communication schedule with the target hardware is established. Determine the amount of time during which the target hardware did not communicate according to the communication schedule; and In response to the determination that the amount of time during which the target hardware failed to communicate according to the communication schedule exceeded a threshold, the target hardware was designated as unauthenticated.

13. The method according to any one of claims 8 to 12, wherein, The target hardware, along with the timestamp of the latest communication from the target hardware, is designated as authenticated in the authentication map.

14. The method according to any one of claims 8 to 13, wherein, The target hardware includes an electronic control unit (ECU).

15. A computer program product comprising a computer program that causes at least one processor to perform a method, wherein, The method includes: Receive the cryptographic signature and authentication request from the target hardware; The authentication request is verified based on the encrypted signature. In response to the successful verification of the authentication request, the authentication parameters of the target hardware are obtained from the target hardware; Instruct the target hardware to perform Proof-of-Work (PoW); Based on the authentication parameters obtained from the target hardware, the result obtained by performing the PoW through the target hardware is verified; and In response to the successful verification of the result obtained from the PoW, the target hardware is designated as certified.

16. The computer program product according to claim 15, wherein, The obtained authentication parameters include at least one of CPU speed, CPU frequency, and power consumption level.

17. The computer program product according to claim 15 or 16, wherein, The method further includes: Broadcast the authentication capability; Detect the broadcast termination conditions; and In response to the detection of the broadcast termination condition, the broadcast of the authentication capability is terminated.

18. The computer program product according to claim 17, wherein, The broadcast termination conditions include the vehicle not moving and the time since the primary hardware was started being less than a threshold.

19. The computer program product according to any one of claims 15 to 18, wherein, The method further includes: Based on the obtained authentication parameters of the target hardware and the authentication parameters of the first-level hardware, a communication schedule with the target hardware is established. Determine the amount of time during which the target hardware did not communicate according to the communication schedule; and In response to the determination that the amount of time during which the target hardware failed to communicate according to the communication schedule exceeded a threshold, the target hardware was designated as unauthenticated.

20. The computer program product according to any one of claims 15 to 19, wherein, The target hardware, along with the timestamp of the latest communication from the target hardware, is designated as authenticated in the authentication map.

Images