1. A system for verifying software on a remote computing device (104, 105, 106), optionally an electronic control unit, the system comprising:

one or more processors (606); and

a memory device (608) having one or more computer-readable instructions that, when executed by the one or more processors (606), cause the system to:

obtaining a real copy of software of the remote computing device;

sending a verification request comprising a random data string to the remote computing device (104, 105, 106);

receiving a remote check value from the remote computing device (104, 105, 106), wherein the remote check value is generated by the remote computing device (104, 105, 106) based on the random data string and software on the remote computing device (104, 105, 106);

calculating a local check value based on a real copy of software used by the remote computing device (104, 105, 106) and the random data string; and

determining whether the remote computing device (104, 105, 106) has authentic software based on a comparison of the received remote check value and the local check value.

2. The system of claim 1, wherein the remote verification value is generated by the remote computing device (104, 105, 106) using the random data string as an encryption key, additional input, or a combination thereof for a cryptographic checksum calculation used to produce the remote verification value; and is

Wherein the calculating the local check value comprises:

calculating the local check value using the random data string as an encryption key for a cryptographic checksum calculation that generates the local check value.

3. The system of claim 1, wherein the random data string is a unique value of the authentication request.

4. The system of claim 1, wherein the operations further comprise: obtaining user data comprising a device identifier from the remote computing device (104, 105, 106), wherein the remote check value is optionally generated based on a combination of software of the remote computing device, the random data string, and user data from the remote computing device (104, 105, 106), and wherein the operations optionally comprise: the local check value (106) is calculated based on a combination of the software copy of the remote computing device (104, 105, 106), the random data string, and a copy of the user data obtained from the remote computing device (104, 105, 106) or a separate system that obtained the user data.

5. The system of claim 2, wherein the cryptographic calculation comprises a digital signature calculation, a block cipher-based message authentication code calculation, or a hash-based message authentication code calculation using a cryptographic hash function or a block cipher and one or more of a cryptographic key, a nonce, and static data.

6. The system of claim 1, wherein software is validated in response to the remote computing device (104, 105, 106) transitioning from a sleep state to a fully functional state and at least one of a system event or a period of time during which validation does not exceed a predetermined threshold, or in response to an external signal corresponding to a user input.

7. The system of claim 1, wherein the operations further comprise: initiate recovery of the remote computing device (104, 105, 106) in response to determining that the remote computing device (104, 105, 106) does not have authentic software due to a difference between the remote check value and the local check value.

8. The system of claim 1, wherein the operations further comprise: initiating recovery of a second remote computing device (104, 105, 106) that is part of a system that includes the remote computing device (104, 105, 106) without real software.

9. The system of claim 1, wherein the operations further comprise: in response to determining that the remote computing device (104, 105, 106) does not have real software based on a comparison difference between the remote check value and the local check value, sending a command to cause the remote computing device (104, 105, 106) to enter a defined error response state.

10. The system of claim 1, wherein the remote computing device (104, 105, 106) includes a storage device (614) that stores a real copy of the software, wherein available space of the storage device (614) not used for the real copy of the software is filled with random data values up to a predetermined threshold amount or a predetermined capacity of the storage device (614).

11. The system of claim 1, the operations further comprising: storing metadata indicating a time period during which the remote computing device (104, 105, 106) calculated the remote check value, the time period being based on one or more performance attributes of the remote computing device (104, 105, 106).

12. A computer-implemented method for verifying software of a remote computing device (104, 105, 106), optionally an electronic control unit, the method comprising:

obtaining a real copy of software of the remote computing device (104, 105, 106);

sending a verification request comprising a random data string to the remote computing device (104, 105, 106);

receiving a remote check value from the remote computing device (104, 105, 106), wherein the remote check value is generated by the remote computing device (104, 105, 106) based on the random data string and software on the remote computing device (104, 105, 106);

calculating a local check value based on a real copy of software used by the remote computing device (104, 105, 106) and the random data string;

determining whether the remote computing device (104, 105, 106) has authentic software based on a comparison of the received remote check value and the local check value; and

optionally, user data comprising a device identifier is obtained from the remote computing device (104, 105, 106).

13. The method of claim 12, further comprising: in response to determining that the remote computing device does not have real software due to the difference between the remote check value and the local check value, initiating recovery of the remote computing device (104, 105, 106), and the method optionally comprises: in response to determining that the remote computing device (104, 105, 106) does not have real software based on the comparison difference of the remote check value and the local check value, sending a command to cause the remote computing device (104, 105, 106) to enter a defined error response state.

14. The method of claim 12, wherein the remote verification value is generated by the remote computing device (104, 105, 106) using the random data string as a cryptographic key, additional input, or a combination thereof for a cryptographic checksum calculation used to produce the remote verification value; and is

Wherein the calculating the local check value comprises:

calculating the local check value using the random data string as a cryptographic key for a cryptographic checksum calculation that generates the local check value.

15. The method of claim 12, wherein the remote verification value is generated based on a combination of software of the remote computing device (104, 105, 106), the random data string, and user data from the remote computing device (104, 105, 106), and wherein the random data string is optionally a unique value of the authentication request.

Background

A computing device may execute software retrieved from a number of sources. To ensure that the computing device operates reliably and securely, the computing device may incorporate techniques to ensure that the authentic authorized software is executed without executing software that has been replaced, modified, or otherwise altered, for example, due to device failure, accident, unauthorized user, or the like. In some instances, a computing device may implement techniques to access authorized data files without accessing unauthorized data files for configuring the system to operate in a particular manner. Traditionally, methods of securing computing devices have included secure boot or use of a Trusted Platform Module (TPM). By secure boot, the executable software is signed with an encrypted digital signature, which the microprocessor verifies before loading the software to be executed. Keyed hash functions, such as hash-based message authentication codes or "HMACs," may also be used as secure boot methods to secure computing devices. An unauthorized user or attacker does not have the key to create the signature or HMAC checksum and therefore cannot alter the software and have the signature/checksum also match the modified code. Accordingly, the microprocessor will not load software with an invalid signature, thereby protecting the integrity of the system. With respect to TPM-based techniques for securing computing devices, a TPM is a secondary chip that verifies ("certifies") executable code and static data being executed by a main CPU. In some techniques, the TPM may release keys or other data that enable full operation of the host CPU only after the code is verified.

In some instances, secure boot and TPM technologies may serve as a computing platform equipped with a microprocessor implementing a secure boot or TPM chip. Many computer platforms use standard microprocessors that do not have secure boot capability nor TPM. These systems cannot verify that their software has been altered before entering an operational state, and therefore execute unauthorized software, which may compromise the security, safety, and/or reliability of the computer system. Examples of these computing platforms include legacy computerized devices, computerized consumer devices, many internet of things ("IoT") devices, and specialized computerized devices, such as electronic control units ("ECUs") for controlling vehicle operations. For example, it is impossible to assume that the vehicle as a whole is in a known good safety state due to the failure to verify the software and data in all safety critical ECUs in the vehicle.

Moreover, in many, if not most, cases, computer platforms and devices equipped with secure boots and TPM's rarely perform power-on resets (invoke secure boots). For example, some ECUs in a vehicle enter a sleep mode when they are off, and only wake up from sleep when the vehicle ignition is on. Such ECUs are rarely powered down and therefore they cannot regularly perform a safe start. In such ECUs, there is a risk that the ECU software is modified without being detected by an unauthorized user.

Disclosure of Invention

In embodiments, the present disclosure provides a system for verifying software on a remote computing device. The system includes one or more processors and a memory device whose one or more computer-readable instructions, when executed by the one or more processors, cause the system to perform some operations. These operations include: obtaining a true Copy (authetic Copy) of software of the remote computing device; sending a verification request including a random data string to a remote computing device; receiving a remote check value from a remote computing device, wherein the remote check value is generated by the remote computing device based on the random data string and software on the remote computing device; calculating a local check value based on a real copy of software for the remote computing device and the random data string; and determining whether the remote computing device has Authentic Software (Authentic Software) based on a comparison of the received remote verification value and the local verification value.

The remote check value may be generated by the remote computing device using the random data string as an encryption key, an additional input, or a combination thereof for a cryptographic checksum calculation used to produce the remote check value, and calculating the local check value may include calculating the local check value using the random data string as an encryption key for a cryptographic checksum calculation used to produce the local check value.

The random data string may be the unique value of the authentication request.

The operations may further include: user data including a device identifier is obtained from a remote computing device.

The remote check value may be generated based on a combination of software of the remote computing device, the random data string, and user data from the remote computing device.

The operations may include: the local check value is calculated based on a combination of a copy of the software of the remote computing device, the random data string, and a copy of the user data obtained from the remote computing device or a separate system that obtained the user data.

The cryptographic calculation may include a digital signature calculation, a block cipher-based message authentication code calculation, or a hash-based message authentication code calculation using a cryptographic hash function or block cipher and one or more of a cryptographic key, a random number (Nonce), and static data.

The software may be verified in response to the remote computing system transitioning from the hibernate state to the fully functional state.

The software may be verified in response to a system event or verification for a period of time not exceeding a predetermined threshold or in response to an external signal corresponding to a user input.

The remote computing device may be an electronic control unit.

The operations may include: in response to determining that the remote computing device does not have authentic software due to the difference between the remote check value and the local check value, initiating recovery of the remote computing device.

The operations may include: initiating recovery of a second remote computing device, the second remote computing device being part of a system that includes a remote computing device without real software.

The operations may include: in response to determining that the remote computing device does not have authentic software based on the comparative difference between the remote check value and the local check value, a command is sent to cause the remote computing device to enter a defined error response state.

The remote computing device may include a storage device to store a real copy of the software, wherein available space of the storage device not used for the real copy of the software is filled with random data values up to a predetermined threshold amount or a predetermined capacity of the storage device.

The operations further comprise: metadata is stored indicating a time period during which the remote computing device calculated the remote check value, the time period being based on one or more performance attributes of the remote computing device.

According to other embodiments, the present disclosure provides a system for verifying software. The system includes one or more processors and a memory device whose one or more computer-readable instructions, when executed by the one or more processors, cause the system to perform some operations. The operations include: receiving, from a secure computing device, an authentication request comprising a random data string; generating a first check value based on the random data string and the software in response to the authentication request; and transmitting the first check value to the secure computing device, whereby the secure computing device compares the first check value to a second check value generated using the random data string and the true copy of the software.

The remote check value may be generated by the remote computing device using the random data string as an encryption key, an additional input, or a combination thereof for a cryptographic checksum calculation used to produce the remote check value, and calculating the local check value may include calculating the local check value using the random data string as an encryption key for a cryptographic checksum calculation used to produce the local check value.

The operations may include: the method may further include transmitting user data including the device identifier to the secure computing device, and generating the first check value may include generating the first check value based on the random data string, the software, and the user data, and the secure computing device may generate the second check value using the random data string, the authentic copy of the software, and the user data.

The storage device may store the software and the available space of the storage device not used for the software may be filled with random data values up to a predetermined threshold amount or a predetermined capacity of the storage device.

The operations may include: metadata is stored in the secure computing device indicating a period of time for which the system calculated the remote check value, the period of time being based on one or more performance attributes of the system.

According to yet further embodiments, the present disclosure provides a computer-implemented method for verifying software. The method comprises the following steps: obtaining a real copy of software of a remote computing device; sending a verification request including a random data string to a remote computing device; receiving a remote check value from a remote computing device, wherein the remote check value is generated by the remote computing device based on the random data string and software on the remote computing device; calculating a local check value based on a real copy of software for the remote computing device and the random data string; and determining whether the remote computing device has authentic software based on a comparison of the received remote verification value and the local verification value.

The remote computing device may be an electronic control unit.

The method may include: in response to determining that the remote computing device does not have authentic software due to the difference between the remote check value and the local check value, initiating recovery of the remote computing device.

The method may include: in response to determining that the remote computing device does not have authentic software based on the comparative difference between the remote check value and the local check value, a command is sent to cause the remote computing device to enter a defined error response state.

The remote check value may be generated by the remote computing device using the random data string as a cryptographic key, an additional input, or a combination thereof for a cryptographic checksum calculation for producing the remote check value, and calculating the local check value may include calculating the local check value using the random data string as a cryptographic key for a cryptographic checksum calculation for producing the local check value.

The remote check value is generated based on a combination of software of the remote computing device, the random data string, and user data from the remote computing device.

The random data string may be the only data string of the authentication request.

The operations may include: user data including a device identifier is obtained from a remote computing device.

According to still further embodiments, the present disclosure provides a method for verifying software. The method comprises the following steps: generating, by the remote computing device, a remote check value based on the data string and the software of the remote computing device; outputting the remote check value and the data string from the remote computing device to the secure data store; obtaining, by a secure computing device, a true copy of software of a remote computing device; obtaining a data string and a remote check value from a secure data store; calculating a local check value based on a real copy of software for the remote computing device and the data string; and determining whether the remote computing device has authentic software based on a comparison of the obtained remote verification value and the local verification value.

Generating the remote verification value may include calculating the remote verification value based on a predetermined time interval.

According to still further embodiments, the present disclosure provides a system for verifying existing software on a remote computing device. The system includes one or more processors and a memory device whose one or more computer-readable instructions, when executed by the one or more processors, cause the system to perform some operations. The operations include: obtaining a true copy of software of the remote computing device, wherein the true copy is the most recently known authorized software provided to the remote computing device; sending a verification request including a random data string to a remote computing device; receiving a remote check value from a remote computing device, wherein the remote check value is generated by the remote computing device based on the random data string and existing software on the remote computing device; calculating a local check value based on the real copy of the software and the random data string; and determining whether the existing software is authentic based on a comparison of the received remote check value and the local check value.

The remote computing device may include a storage device that stores existing software, and the available space on the storage device that is not used for the existing software contains random data values up to a predetermined threshold amount or a predetermined capacity of the storage device.

According to still further embodiments, the present disclosure provides a computer-implemented method for verifying existing software on a remote computing device. The method comprises the following steps: obtaining a true copy of software of the remote computing device, wherein the true copy is the most recently known authorized software provided to the remote computing device; sending a verification request including a random data string to a remote computing device; receiving a remote check value from a remote computing device, wherein the remote check value is generated by the remote computing device based on the random data string and existing software; calculating a local check value based on the real copy and the random data string; and determining whether the existing software is authentic based on a comparison of the received remote check value and the local check value.

Available space in the storage device of the remote computing device that does not store existing software contains random data values up to a predetermined threshold amount or a predetermined capacity of the storage device.

The real copy may be obtained during an initialization phase of the remote computing device and stored in a trusted software repository for access during subsequent authentication.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate examples of the many features of the disclosed subject matter. The drawings and description together serve to explain the principles of the various techniques described herein.

FIG. 1 is a block diagram of an example system for verifying software resident on a remote computing device according to an example embodiment described herein;

FIG. 2 is a process flow diagram of an example method for using a secure computing device to authenticate software residing on a remote computing device in accordance with the example embodiments described herein;

FIG. 3 is a process flow diagram of an example method for a remote computing device to enable verification of software resident on the remote computing device in accordance with the example embodiments described herein;

FIG. 4 is a block diagram of an example device with an electronic control unit having software verified by a secure computing device, according to an example embodiment described herein;

FIG. 5 is a process flow diagram of an example method for a remote computing device to enable validation of software resident on the remote computing device according to an example embodiment described herein; and

FIG. 6 is a block diagram of an example of a computing system that may host systems and methods according to example embodiments described herein.

Detailed Description

Various embodiments of the present technology will now be described in detail with reference to the accompanying drawings. For purposes of clarity, the same reference numbers will be used in the drawings to identify the same or similar elements.

The techniques, methods, and devices of the present invention may validate software stored in any suitable computing device, such as an embedded computing device. For example, the techniques and apparatus of the present invention include a secure computing device that performs remote verification of software and static data residing in a remote computing device. Thus, in embodiments, the secure computing device acts as a controller or manager of the authentication process and interacts with a computing device (broadly referred to herein as a remote computing device) that is typically not co-located therewith. The secure computing device may implement the techniques of this disclosure to ensure that the remote computing device is executing valid or authorized software and related data, without executing software and data that has been altered or tampered with (malicious or unexpected) or is out of date (e.g., an old software version that has been replaced). For many remotely deployed existing computerized devices (e.g., IoT devices, computerized medical devices, ECUs in vehicles, etc.), the secure computing device cannot simply request that the remote computing device perform a checksum or hash value of the remote computing device program space and send that checksum value (e.g., checksum) back to the secure computing device to be compared to a locally known valid value stored at the secure computing device, as an unauthorized user or the like may alter software resident in the remote computing device to supply or recalculate a previously validated checksum value already in the remote computing device, after which the unauthorized user or software may damage the remote device. Additionally, with existing computerized devices, it is often the case that there is no secure communication channel between the remote computing device and the secure computing device attempting to validate or verify the software of the remote device. Accordingly, in this case, the authenticity of the data sent between the remote computing device and the secure computing device cannot be presumed, as, for example, the data (e.g., checksum, etc.) may come from a location other than the remote computing device being pinged or authenticated.

The techniques of the present invention utilize a separate secure computing device to authenticate software stored on a remote computing device. For example, in addition to retaining a check value (such as a hash-based message authentication code ("HMAC") value) for the software and data of the remote computing device, embodiments of the present technology include using the secure computing device to store a true valid copy of the software and optionally static data of the remote computing device. In some such embodiments, to authenticate software and static data on a remote computing device, the secure computing device may send an authentication request to the remote computing device, which may include a unique value, such as a random data string or a time of day value in microseconds (e.g., a random number), or the like. Then, in response to the request, the remote computing device may perform a check value calculation on its software and static data using the supplied random data string or value (e.g., HMAC calculation or a packet-cipher-based MAC, such as a CMAC), and may also create a digital signature of its software and static data.

In some embodiments, when the remote computing device receives an authentication request that includes a unique value, such as a random number, the remote computing device may use the received random number directly as a key or in combination with a key available to the remote computing device to perform an HMAC calculation or a cryptographic-based MAC calculation ("check value") on its software and static data.

In embodiments, the remote computing device sends its calculated check value back to the requesting secure computing device. The secure computing device may use the same random number and shared key (if used) to calculate a check value (e.g., HMAC result) for the validated copy of the remote computing device's software and static data residing on the secure computing device.

If the check value received by the secure computing device from the remote computing device matches a check value generated locally on the secure computing device, the software and static data of the remote computing device may be considered verified and correct because, assuming the same random number and/or key is used in the calculations of the two systems, the check value calculation done by the remote device will necessarily result in a different check value if there is any software code or static data in the remote computing device that is different from the verified copy stored in the secure computing device. In certain embodiments, as used herein, a check value is a cryptographic calculation value based on any suitable cryptographic technique. In some instances, determining the check value using any suitable cryptographic technique, such as SHA-256, may prevent unauthorized users from calculating the same value without validating the software. The use of a random number (a unique value for each authentication request) can ensure that an unauthorized user cannot replay or reuse an earlier check value.

The techniques and apparatus of the present invention include various practical applications and technical improvements over conventional systems. For example, the secure computing device may periodically request authentication of the software of the remote computing device. Thus, the remote computing device may be authenticated when the remote computing device wakes up from a hibernation state or at any other time. The techniques of the present invention can validate and ensure that authorized software is executed in a system that experiences little or no power-on reset, such as an industrial control system. Additionally, the techniques of this disclosure may enable a remote computing device to verify its software with little or no interference to its normal operation by scheduling the verification to occur during periods of inactivity when the remote computing device has sufficient available resources (such as CPU resources).

In some embodiments, the techniques and apparatus of the present invention do not require the remote computing device to have a dedicated security device or perform heavy processing that affects performance but does not affect the cost of the remote computing device. As described herein, the data transmitted over the communication channel between the secure computing device and the remote computing device is minimal (e.g., an authentication request including a random number and a response including a check value), which advantageously reduces the utilization of the communication bandwidth and enables communication via equipment and infrastructure of limited bandwidth and performance limited channels, such as a control area network "CAN" bus or a local internet "LIN" bus. In some examples, the communication channel between the secure computing device and the remote computing device may be a WiFi communication channel, a bluetooth communication channel, a 5G communication channel, or an ethernet communication channel, among others. In some embodiments, the communication channel may be a system bus within a device housing having two or more different printed circuit boards or modules. In certain examples, the communication channel may be included within any suitable internet of things (IoT) system for healthcare applications, industrial control systems, and the like. For example, a system module may have a secure microprocessor that can perform secure boot, but other system modules may not have a secure microprocessor. A module equipped with a secure microprocessor may periodically use the techniques of the present invention to verify software in other modules that do not have a secure microprocessor. In some instances, the external system may periodically verify the software of the module equipped with the secure microprocessor.

In some embodiments, a single secure computing device may authenticate multiple remote computing devices comprising a complex system. For example, a vehicle may be equipped with a novel dedicated gateway ECU having the secure computing device functionality described herein, and the gateway ECU may authenticate some or all of the other ECUs in the vehicle, up to 50 or more in number. In some instances, the authentication techniques described herein may be controlled and prompted by a central secure computing device that may communicate with one or more remote computing devices over any distance and over any network. For example, a secure computing device located at a central data center may communicate with a remote computing device deployed anywhere in the world over the internet or any suitable network. Additionally, in certain embodiments, if the secure computing device detects a failure or problem in the remote computing device, the secure computing device may initiate a recovery process or the like in the remote computing device; or the secure computing device may place the entire complex system, such as a vehicle containing the problem remote computing device (e.g., ECU), in a secure state.

The present technology relates not only to data manipulation, but also to an improved software verification system that is capable of determining whether a remote device is executing authentic software, or whether an unauthorized user has modified the software of the remote device. Additionally, the techniques of the present invention employ a novel way of verifying software executed by a remote device based on the generation of a remote check value by the remote device and a local check value by a secure computing device.

FIG. 1 is a block diagram of an example system for verifying software resident on a remote computing device. The system 100 may include one or more secure computing devices 102 and one or more remote computing devices 104, 105, and 106. In some instances, the secure computing device 102 may be any suitable computing device, such as a management or gateway electronic control unit, a desktop device, a laptop device, a wearable device, a server, or a system module containing many smart modules connected via a backplane or the like. In certain embodiments, the security computing device 102 may be a vehicle, watercraft (e.g., a ship), aircraft, spacecraft, medical device, robot, drone, wireless or wired communication module, and IoT device. In certain embodiments, the secure computing device 102 may be, or be part of, a dedicated onboard unit that primarily performs the functions of the secure computing device described herein. In certain examples, the remote computing devices 104, 105, and 106 may correspond to any number of remote computing devices, such as onboard units ("OBUs") or ECUs of vehicles, watercraft, aircraft, spacecraft, robots, drones, medical devices, or IoT devices. For example, in vehicle embodiments, the remote computing devices 104, 105, and 106 may include any number of ECUs that store software and/or data that may be verified by the secure computing device 102. For example, the remote computing devices 104, 105, and 106 may be various ECUs such as an Engine Control Module (ECM), a Powertrain Control Module (PCM), a Transmission Control Module (TCM), a brake control module (BCM or EBCM), a Central Control Module (CCM), a Central Timing Module (CTM), a General Electronic Module (GEM), a Body Control Module (BCM), a Suspension Control Module (SCM), and the like. In certain traffic-related embodiments, the remote computing devices 104, 105, and 106 may be or correspond to roadside units (RSUs) of traffic control devices (e.g., traffic signals, traffic lights, or electronic traffic signs), digital billboards, pedestrian warning systems, motorcycle sensors, bicycle sensors, or electronic signs, etc.

In various embodiments, the secure computing device 102 may include one or more compute engines 107 that may validate the software of the remote computing devices 104, 105, 106; for example, it may be determined whether the software in the remote computing device is authentic, up to date, and/or has not altered its original form. In some embodiments, compute engine 107 may or may not be or include a hardware security module ("HSM") (not shown in the figures). The HSM may enhance the security of the present technology and enable the secure computing device 102 and the remote computing device 104 to perform secure computations with greater security against threats from unauthorized users and the like. In some embodiments, the compute engine 107 may or may be designed to perform secure computations on its own without the need for an embedded HSM.

In various embodiments, different versions of HSM may be used in compute engine 107. For example, the HSM may comprise an embedded HSM installed as a plug-in card within one or more of the compute engines. In such example embodiments, the embedded HSM may be installed in the one or more compute engines as a Peripheral Component Interconnect (PCI) HSM or a PCI Express (PCIe) HSM. Also, for example, the HSMs in compute engine 107 may comprise network-attached or network-connected external HSMs that are separate from the compute engines in their own chassis. In some embodiments, the HSM may be embedded or integrated into a cryptographic processor of a microprocessor. In some instances, the microprocessor may perform a secure boot to verify software executed by the microprocessor using a firmware program capable of computing a cryptographic checksum or verifying a digital signature. In some embodiments, the external hardware module may implement HSM functionality.

In certain embodiments, the secure computing device 102 and the remote computing devices 104, 105, and 106 may communicate over any suitable digital channel 108, such as a CAN bus or a LIN bus. In some examples, digital channel 108 may be a secure or unsecure digital channel. For example, the secure computing device 102 and the remote computing devices 104, 105, and 106 may communicate over an unsecure digital channel when verifying software executed by or contained in each of the remote computing devices 104, 105, and 106. The authentication of software residing on remote computing devices 104, 105, and 106 via secure computing device 102 is detailed below in conjunction with fig. 2 and 3. In some instances, the trusted software store 110 may provide the authentic software to the remote computing devices 104, 105, and 106 and/or the secure computing device 102 via the digital channel 108. For example, the trusted software store 110 may store the actual software that should be stored in each remote computing device 104, 105, and 106 and executed by each remote computing device 104, 105, and 106. As described above, if the remote computing devices 104, 105, and 106 are different from each other (e.g., if device 104 is PCM, device 105 is TCM, and device 106 is EBCM), the trusted software store 110 stores a real software copy and associated static data (e.g., configuration files) for each of the three devices 104 and 106; for example, it stores three different software programs, images, etc.

It will be appreciated by those of ordinary skill in the art that the components and implementation details shown in FIG. 1 are examples presented for simplicity and clarity of explanation. Other components, processes, implementation details and variations may be used without departing from the technical principles of the invention, as this example is not intended to be limiting, and many variations are possible. For example, the system 100 may include any suitable number of secure computing devices 102 and remote computing devices 104, and the secure computing devices 102 and remote computing devices 104 may communicate via any number of digital channels 108. In some instances, the secure computing device 102 may be located at any suitable distance from the remote computing devices 104, 105, and 106 such that the digital channel 108 may include a global communication network. For example, the secure computing device 102 may not be in close proximity to the remote computing devices 104, 105, and 106.

FIG. 2 is a process flow diagram of an example method for verifying software resident on a remote computing device. The method 200 may be implemented using any suitable computing device, such as the secure computing device 102 in fig. 1 and the secure computing device 408 in fig. 4.

At block 202, the secure computing device may obtain a true copy of software stored (or supposed to be stored) within and/or executed by the remote computing device. In some embodiments, the secure computing device may obtain a true copy of the software via any suitable network connection, the internet, or the like. In some instances, the secure computing device may obtain a true copy of the software from the remote computing device during an initialization period (e.g., at the time of manufacture and/or initial provisioning of the remote computing device, such as during manufacture of an automobile that already has multiple OBUs). For example, software may be stored or installed on the secure computing device and the remote computing device during an initialization period. In some cases, the secure computing device and the remote computing device may not have access to the remote network during the initialization period and/or may not have reached any external network connection during the initialization period. In this case, the secure computing device and the remote computing device may be selected from devices such as universal serial bus ("USB") devices, CD-ROMs, Bluetooth enabled devices, and the like^TMThe device or any other suitable computer readable medium that obtains the actual software.

In some embodiments, the secure computing device may also or alternatively obtain the real software of the remote device from a storage device (e.g., a storage device implementing the trusted software repository 110) that is accessible locally or over a network such as a CAN or PCI bus. The storage device may be downloaded or programmed during an initialization period, such as a manufacturing period. The storage device may be updated occasionally to contain the latest real software on the remote device. In some instances, software to be installed on the remote computing device is cryptographically signed (or checked based on a message authentication code) to enable the secure computing device to determine whether the software is the most up-to-date authentic software. In some embodiments, a copy of the software may be stored in trusted storage and/or protected by a digital signature or cryptographic checksum to protect the software from undetected modifications.

In some embodiments, the secure computing device may obtain any number of software copies of any number of remote computing devices, such as electronic control units. Generally, secure computing devices need to verify or evaluate a true copy of the remote device's software. Accordingly, the secure computing device may not be able to obtain software from the remote device because the software on the remote computing device may have been intentionally or unintentionally altered or replaced so that it is no longer authentic. And the secure computing device should download, store, program, or otherwise obtain the actual software from the trusted device. For example, the secure computing device may obtain software from a secure repository or the like during manufacture of the secure computing device, and may periodically receive updates via secure communications from a trusted source (e.g., via secure over-the-air updates from the trusted software repository 110). In some such instances, the secure computing device may access a trusted repository containing digital signatures or Message Authentication Codes (MACs) for individual software components or collections of components, such that unauthorized users or unauthorized software cannot replace or alter the software without detection.

As previously mentioned, in various vehicle-related embodiments, each remote computing device may be an electronic control unit that stores and executes software that manages different components or subsystems within the vehicle, roadside units, and the like. As described above with respect to fig. 1, vehicles having an ECU include automobiles, watercraft (e.g., watercraft), aircraft, spacecraft, drones, and the like. In certain embodiments, the electronic control unit may reside in a roadside unit (RSU), such as a traffic control device (e.g., a traffic signal, a traffic light, or an electronic traffic sign), a digital billboard, a pedestrian warning system, a motorcycle sensor, a bicycle sensor, or an electronic sign, among others. Further, the remote computing device is or is included in many non-vehicle related devices, such as medical devices, robotics, wireless or wired communication modules, or IoT devices, and the like.

In some examples, the remote device (e.g., an electronic control unit or roadside unit) may be via a CAN bus, a LIN bus, an ethernet, a network connection, or Bluetooth^TMConnection, etc. to communicate with the secure computing device. In embodiments, the secure computing device may verify the software from or in any number of remote computing devices, as described in detail below with respect to block 204 and 212.

At block 204, the secure computing device may send a verification request including a random data string to the remote computing device. As referred to herein, random data may include any time-varying data that is unique to each authentication request and includes sufficient entropy to prevent unauthorized users from pre-computing or otherwise determining a random data value. In some embodiments, the verification request may indicate that the remote computing device is to provide information that the secure computing device uses to validate or verify the authenticity of software currently stored in and/or executed by the remote computing device. In certain implementations, a random data string (which may also be referred to as a random number) may be used as a digital cryptographic key for cryptographic checksum calculations or as a variable in a digital signature during an authentication process.

In embodiments, the secure computing device may send authentication requests for a particular remote device at any suitable static time interval or periodically at random time intervals. For example, the secure computing device may send the authentication request to the remote computing device at a fixed time of day, month, or year. In some other instances, the secure computing device may select a random time interval to send the authentication request at a random time based on an event within a predetermined number of hours, days, or months, etc. For example, the secure computing device may send the authentication request to the remote computing device at any randomly selected time during the day or at a randomly selected time during the hours of the day.

In some embodiments, the secure computing device may authenticate the software of the remote computing device when a period since a last authentication (or since initialization) exceeds a predetermined threshold, or in response to an external signal corresponding to a user input. For example, the secure computing device may authenticate the software of the remote computing device after an appropriate predetermined number of seconds, minutes, hours, days, months, years, etc. have not been authenticated (e.g., 12 hours, 30 days, 6 months, or 1 year). In some embodiments, software that authenticates a remote computing device may be executed in response to a system event, such as each time the remote computing device transitions from a hibernation state to a fully functional state, or the like. For example, the secure computing device may receive or otherwise detect, from the remote computing device or from other systems, an indication that the remote computing device has transitioned from any suitable sleep state, partial power state, or the like to a full power and full functionality state. The secure computing device may respond to the indication of the change in power state of the remote computing device by transmitting an authentication request to the remote computing device. In embodiments, any change in the power state of the remote computing device or the system in which the remote computing device resides may trigger the transmission of an authentication request to the remote computing device. For example, a transition of the remote computing device from any low power state to a high power state may result in a power change indication being generated and transmitted to the secure computing device, which may initiate verification of software resident on the remote computing device. In certain instances, the secure computing device may respond to an indication of a power state change due to a starting vehicle or the like, where the starting vehicle changes power to its embedded OBU remote computing device or devices. The secure computing device may also implement a delay between detecting the change in power state and requesting authentication of the remote computing device.

At block 206, the secure computing device may receive, obtain, or detect a remote verification value from a remote computing device, which may create and provide the remote verification value in response to the authentication request of block 204 in various embodiments. In various embodiments, the remote computing device may use or be based on the random data string and software on the remote computing device to calculate, or generate the remote check value. In some instances, the remote check value may be generated using a random data string that is used as an encryption key for cryptographic calculations running on software stored within the remote computing device. In various examples, the random data string may take the form of a digital key, a block cipher-based message authentication code, or a random number of any suitable HMAC encryption algorithm. In some embodiments, a random data string may be attached to or otherwise combined with the software in some manner prior to signing the software, which enables the generation of a unique digital signature. In some instances where a fixed key is used, a random data string (e.g., a random number) forces each calculation to produce a different result, thereby ensuring freshness, which prevents unauthorized devices or software from replaying earlier calculations. In some embodiments, a hash function may be utilized to generate the remote check value without the encryption key. For example, the remote check value may be generated by performing a hashing algorithm on the random number value and software.

In some embodiments, the remote check value is computed, calculated or generated using software stored in the remote computing device that includes static or read-only information, etc., in combination with software on the device and the random data string. For example, the remote check value may be generated by an HMAC function applied to static information (such as a binary executable, a directory, etc.) on the remote device, but with one of the static files used as a key. In some embodiments, the remote computing device may identify and exclude any dynamic information, such as temporary files, user input data, sensor data, variables, and the like. For example, the remote computing device may maintain a list of files corresponding to static information and a separate list of files corresponding to dynamic information, which may be modified or changed over time. The remote check value may be generated based on an HMAC function applied only to the static information file without regard to the dynamic information file. In some embodiments, the HMAC or CMAC function may generate a remote check value based on static information from the list in combination with other random numbers or digital signatures, etc. For example, a hash function may generate a remote check value based on a combination of a password with a fixed key and a random number and software into plaintext. In some embodiments, other suitable cryptographic checksum calculation techniques may be used to generate the remote check value.

At block 208, the secure computing device may generate or calculate a local check value based on or using the true copy of the software in the remote computing device (from block 202) and the random data string. In some embodiments, the secure computing device generates the local check value by using the same algorithm or technique that the remote computing device used to generate the remote check value and by using the random data string in the same manner as the remote computing device. In contrast, the secure computing device uses a true copy of the software to generate the local check value, while the remote computing device uses an internal copy of the software to generate the remote check value. Under this condition, if the internal copy of the software of the remote computing device is the same as the true copy of the software, then the remote verification value will be the same as the local verification value; otherwise, the two values will be different.

In some embodiments, the local check value may be calculated or generated by using a random data string as an encryption key for an encryption calculation running on a true copy of the software. In such embodiments, the random data string is applied, combined, or used with software residing in the remote computing device using the same techniques as the random data string is applied, combined, or used with software residing in the remote computing device; and the same cryptographic calculation is used by both the secure computing device and the remote computing device. In various examples, the cryptographic calculation may include a hash-based message authentication code using a cryptographic hash function, a random Nonce used as a cryptographic key, and so forth. In some instances, the random data string may be used as a digital key for validating the software using any suitable cryptographic-based MAC algorithm. In some instances, cryptographic calculations without cryptographic keys may be performed using a hash function applied to the random number and software.

At block 210, the secure computing device may determine or verify whether the remote computing device is executing authentic software based on a comparison of the remote verification value and the local verification value. For example, in embodiments, if the software residing on the remote computing device is authentic, e.g., has not been altered and is identical to the known authentic copy of the software acquired by the secure computing device at block 202, the remote check value will be the same value as the local check value. If the remote verification value is the same value as the local verification value, the secure computing device may determine that the remote computing device is actually executing authentic software and that the secure computing device need not perform additional operations, but in some embodiments it may maintain a satisfactory verification record. Similarly, if the software resident on the remote computing device has been modified, altered, or otherwise different from the known authentic software acquired by the secure computing device at block 202, the remote verification value will be a different value than the local verification value. For example, if unauthorized or unintentional modifications are made to software residing on the remote computing device, the remote verification value will be different from the local verification value generated by the secure computing device. If the remote verification value is different from the local verification value (which indicates that the remote computing device is not using authentic software), the security computing device may take additional action, such as alerting the operator, disabling or partially disabling the remote computing device, modifying or restoring software in the remote computing device, or otherwise resolving the problem.

As some example of additional actions, at block 212, the secure computing device may modify operation of the remote computing device in response to determining or detecting a difference between the remote verification value and the local verification value; for example, according to the comparison of block 210. For example, the secure computing device may disable the remote computing device (e.g., turn it off) or partially disable the remote computing device (e.g., command it to enter a secure mode, etc.). Further, the local secure computing device may generate an alert, or the like. In certain additional or alternative embodiments, the security computing device may modify operation of the entire system containing the remote computing device, such as modifying operation of a passenger vehicle containing an ECU with non-authentic software.

In some embodiments, the secure computing device may initiate recovery of the remote computing device in response to detecting a difference between the remote check value and the local check value. In some instances, the recovery of the remote computing device may include loading or flushing known authentic software into the remote computing device to replace the non-authentic software detected at block 210. In various vehicle embodiments, the recovery of the remote computing device may also or alternatively include the secure computing device sending an instruction to the ECU of the vehicle to enter a safe state or a defined false response state, such as "Limp Home" that reduces the maximum speed of the vehicle.

In some instances, the secure computing device may modify operation of another remote computing device or a plurality of other remote computing devices forming or being part of the same system (e.g., in the same vehicle) in response to detecting a difference between the remote verification value and the local verification value in a single remote computing device in the overall system (i.e., detecting non-authentic software). For example, the secure computing device may initiate recovery of each electronic control unit (or a particular other ECU or a particular subset of all ECUs) in the vehicle in response to detecting non-authentic software (which may have dangerous accidental damage, unauthorized modification, malicious hacking, etc.) in any single electronic control unit. In some embodiments, the secure computing device may request or command the remote computing device to enter a secure state or secure mode in response to detecting a difference between the remote check value and the local check value. In some instances, the secure state may include modifying or disabling operation of a system or subsystem that includes or is controlled by the remote computing device. For example, the safe state may include preventing the robotic arms of the welding robot from turning, directing the autonomous vehicle to one side of the road, or limiting the speed and functionality available to a group of vehicles, etc.

The process flow diagram in fig. 2 is not intended to specify that the operations of method 200 are to be performed in any particular order, or that all of the operations of method 200 are to be included in each case. Additionally, method 200 may include any suitable number of additional operations. For example, method 200 may also include obtaining user data from a remote computing device, where the user data includes a device identifier, a device name, and the like. In some instances, the device identifier may comprise a hardware specific value, such as an electronic serial number of a microprocessor or the like. In certain embodiments, the method 200 may include generating a remote check value based on a combination of software of the remote computing device, the random data string, and user data from the remote computing device. In some embodiments, the method 200 may include calculating the local check value based on a combination of a copy of the software of the remote computing device, a random data string, and a copy of the user data obtained from the remote computing device or from a device capable of accepting user input and providing it to the remote computing device and the secure computing device.

FIG. 3 is a process flow diagram of an example method for a remote computing device to enable verification of software resident on the remote computing device. The method 300 can be performed using any suitable computing device, such as the remote computing device 104 or the vehicle gateway in fig. 1.

At block 302, the remote computing device may obtain a copy of the stored software that is also provided to the secure computing device. In certain embodiments, during the initialization process described above with respect to block 202 in fig. 2, the remote computing device may receive a copy of the software that is also stored locally or internally to the secure computing device. For example, the remote computing device may receive the copy of the software via any suitable network connection. In some embodiments, the remote computing device may receive a copy of the software to any suitable computer-readable medium, such as a universal serial bus ("USB") device, CD-ROM, or the like. In some embodiments, the remote computing device may receive a copy of the stored software from a trusted software repository accessible to the remote computing device and the secure computing device. In some instances, the remote computing device and the secure computing device may obtain copies of the stored software at different times and locations. For example, the remote computing device may acquire the software during manufacturing, while the secure computing device may acquire the software at a later time.

In some embodiments, the remote computing device may be configured with a certain amount of storage and/or memory to store a copy of the received software and in addition a predetermined amount of available storage and/or memory. For example, the predetermined amount of available storage and/or memory may be 10 megabytes, 100 megabytes, or any other suitable value. In some instances, the available storage of the remote computing device may store random data values. In some instances, the random data value may be shared or otherwise communicated to the secure computing device to enable the secure computing device to compute a local copy of its check value. The cryptographic checksum may then be calculated over the total available storage, including stored program software and random data that fills the remaining available space. This technique can prevent a remote computing device from storing a copy of malware and genuine software in its memory, and using the copy of genuine software to compute a correct answer or cryptographic checksum value for a verification request, and then executing other unauthorized stored software.

At block 304, the remote computing device may receive a verification request from the secure computing device that includes a random data string. In some embodiments, the remote computing device may cause the secure computing device to generate and transmit an authentication request to the remote computing device. For example, the remote computing device may transmit an indication to the secure computing device that the remote computing device has transitioned from the hibernation state to the fully-functional state. In some embodiments, the remote computing device may generate an indication when the remote computing device has transitioned from any suitable sleep state, partial power state, etc. to a full power and full functionality state. As described above with respect to fig. 2, the secure computing device may respond to the indication of the change in power state of the remote computing device by transmitting an authentication request to the remote computing device. In some embodiments, any change in power state of the remote computing device may trigger generation and communication of an indicator to the secure computing device. For example, transitioning from any low power state to a high power state within the remote computing device may result in generating an indication to initiate verification of software residing on the remote computing device and communicating the indication to the secure computing device. In some embodiments, the remote computing device may receive the authentication request at any suitable random period, static period, or the like.

In some embodiments, as detailed below with respect to block 306, the validation request may indicate a period of time during which the remote value is to be calculated or generated. In some instances, the period is determined based on the number of instructions executable by the processor of the remote computing device per second or any other suitable timeframe. For example, the validation request may indicate that the remote computing device has a period of 5 seconds, 10 seconds, or any other suitable amount of time to generate or calculate the remote verification value. In some instances, the remote computing device may be configured to perform software verification or authentication immediately upon receiving the authentication request. The secure computing device may have a local time estimate of the time required for the remote computing device to perform the software check and transmit the remote check value to the secure computing device. If the remote device performs a software check too quickly or too slowly, the secure computing device may determine that the remote computing device may be executing unauthorized software. In some embodiments, the secure computing device may store metadata indicating a period of time for which the remote computing device calculated the remote verification value, wherein the period of time is based on one or more performance attributes of the remote computing device. The performance attributes may include processor speed, memory read/write speed, and the like. Such techniques can prevent a remote computing device from compressing stored genuine software for storage of unauthorized software. In some instances, the period of the validation request can prevent the remote computing device from decompressing the genuine software to provide the correct remote check value.

At block 306, the remote computing device may compute, calculate, or generate a remote check value based on a random data string used as an encryption key for cryptographic calculations of the software or based on a hash function applied to the random number value and the software without using the encryption key. In some embodiments, the remote check value is generated based on static information or read-only information stored in the remote computing device. For example, the remote check value may be generated by an HMAC function applied to static information (such as a binary executable, a directory, etc.). In some embodiments, the remote computing device may identify and exclude any dynamic information, such as temporary files, user input data, and the like. For example, the remote computing device may maintain a list of files corresponding to static information and a separate list of files corresponding to dynamic information, which may be modified. The remote check value may be generated based on a hash function applied to the list of static information while ignoring the dynamic information from the cryptographic checksum function calculation. For example, the remote computing device may identify a set of static executable files and create a generated remote check value based on applying any suitable HMAC functionality or the like to the binary representation of the static executable files. In some embodiments, the remote computing device may identify static metadata corresponding to software stored on the remote computing device. For example, the static metadata may include installation time of the read-only software, file size of the read-only file, and the like. In some embodiments, the remote computing device may generate the remote check value by applying any suitable cryptographic checksum function to the static metadata and the random number or the random number and the digital signature. In some embodiments, the remote computing device may generate the remote verification value by applying a cryptographic verification sum to both the stored software and the stored random data value in the storage or memory of the remote computing device. For example, the remote computing device may include a storage device that stores a true copy of the software and the random data value, the storage device having an available storage capacity below a predetermined threshold. For example, the available space in the storage device not used for a true copy of the software may be filled with random data values up to a predetermined threshold amount or a predetermined capacity of the storage device. In some embodiments, the predetermined threshold may be 5MB, 10MB, etc. In some instances, the remote computing device may generate and store random data values until the available storage space in the storage device is below a predetermined threshold. Such techniques can prevent the remote computing device from storing unauthorized software.

At block 308, the remote computing device may transmit the remote verification value to the secure computing device. For example, the remote computing device may be via any suitable CAN bus, LIN bus, network connection, Bluetooth^TMThe connection, computer readable medium, etc. communicates the remote verification value to the secure computing device.

In some embodiments, all features of the software are not available on the remote computing device until the software of the remote computing device is authenticated by the secure computing device. In some instances, the remote computing device may receive a license for the full operation of the software upon confirmation that the software was properly verified. For example, after software stored on a remote computing device is verified, additional features within the software may be enabled for execution.

It should be understood that fig. 3 is an exemplary embodiment of the present technology and that in additional embodiments, system 300 may include fewer or additional components and devices. For example, the method 300 may include calculating or generating, by the remote computing device, a hash of the nonce value and the static code stored on the remote computing device. In some instances, a hash of the random number or the random number itself may be used as an encryption key to encrypt a known plaintext message. In some embodiments, the remote computing device may send the encrypted clear text message to the secure computing device. If the secure computing device is unable to decrypt the encrypted plaintext message or ciphertext, the method may include determining that software stored in the remote computing device has been modified to include unauthorized software or instructions.

In some embodiments, the random value in the authentication request includes a complete unique time based on the date (or seconds since a predetermined year, etc.). In some instances, the random value may not be transmitted from the secure computing device to the remote computing device. For example, the method may include issuing, by the secure computing device, a command to the remote computing device to provide a verification value, and the remote computing device may then respond with the verification value and the time/date at which the authentication request was processed by the remote computing device. In some instances, the secure computing device may confirm that the time/date is within an expected range without repeating the old value. In some embodiments, the remote computing device may not be prompted to provide the check value. For example, the remote computing device may periodically output check values with date/time in a log file or any other suitable location in the storage device. The check value stored in the log file may be verified by the secure computing device at any suitable time. In some embodiments, the log file may be stored in any suitable external computing device or external storage device, and the log file may include check values calculated by the remote computing device at predetermined time intervals (such as 5 seconds, 1 minute, or 5 minutes, etc.). In some instances, any remaining available space in the storage device of the remote computing device may be filled with random data values in case a pre-computed check value is stored. In some examples, if the clock is not available, the count value may be initialized and incremented to a non-transmitted random number.

FIG. 4 is a block diagram of an example vehicle with an electronic control unit having software verified by a secure computing device, according to an example embodiment described herein.

In certain embodiments, the vehicle 400 may include electronic control units ("ECUs") 402, 404, 406, which are remote computing devices that may be coupled to a secure computing device 408, a secure ECU, or any suitable device. In certain embodiments, the secure computing device 408 may include a copy of the software stored on each ECU 402, 404, and 406. The copy of the software may include read-only files and other static information stored in each ECU 402, 404, and 406. In some examples, each ECU 402, 404, 406 may compute, calculate, or generate a separate unique remote check value in response to an authentication request and transmit the separate remote check value to the secure computing device 408 via the digital channels 410 and 412. Then, based on the processing described above with respect to fig. 3 and 4, the secure computing device 408 may verify whether the static software stored on each ECU 402, 404, and 406 has not been modified based on a random data string or random number.

It will be appreciated by those of ordinary skill in the art that the components and implementation details shown in FIG. 4 are examples presented for simplicity and clarity of explanation. Other components, processes, implementation details and variations may be used without departing from the technical principles of the invention, as this example is not intended to be limiting, and many variations are possible.

FIG. 5 is a process flow diagram of an example method for a remote computing device to enable verification of software resident on the remote computing device. The method 500 may be performed using any suitable computing device, such as the remote computing device 104 or the vehicle gateway in fig. 1.

At block 502, the remote computing device may compute, calculate, or generate a remote check value based on the data string and software stored on the remote computing device. The data string may be any suitable random value, timestamp, or incremental count, etc. In some embodiments, the remote check value is generated based on static information or read-only information stored in the remote computing device. For example, as described above with respect to block 306 in fig. 3, the remote check value may be generated by an HMAC function applied to static information (such as a binary executable, a directory, etc.). In some embodiments, the remote check value may be generated based on a hash function applied to the list of static information while ignoring the dynamic information from the cryptographic checksum function calculation. In some embodiments, the remote computing device may generate the remote check value by applying any suitable cryptographic checksum function to the static metadata and the data string. In some examples, generating the remote verification value may include computing the remote verification value based on a predetermined time interval (e.g., any number of seconds, minutes, hours, or days).

At block 504, the remote computing device may output the remote check value and the data string from the remote computing device to the secure data store. For example, the remote computing device may be via any suitable CAN bus, LIN bus, network connection, Bluetooth^TMThe connection, computer readable medium, etc. communicates the remote verification value to the secure data store. In certain embodiments, the secure database may be any suitable storage device, log file, computing device, server, etc. that may receive and store remote check values and data strings from a remote computing device.

In some embodiments, the remote computing device may periodically verify the software when the secure computing device is unavailable or offline. For example, the remote computing device may authenticate software stored on the remote computing device without receiving an authentication request or command with a random value from the secure computing device. In some instances, the secure computing device may communicate asynchronously with the secure data store to access the remote check values and to authenticate the software of the remote computing device.

At block 506, the secure computing device may obtain a copy of the stored software that is also provided to the remote computing device. In some embodiments, the secure computing device may receive a copy of the software during an initialization process as described above with respect to block 202 in fig. 2. In some embodiments, the secure computing device may receive a copy of the stored software from a trusted software repository accessible to the secure computing device and the remote computing device. In some instances, the remote computing device and the secure computing device may obtain copies of the stored software at different times and locations.

At block 508, the secure computing device may retrieve the data string and the remote check value from the secure data store. For example, the secure computing device may access the secure data store using any suitable digital communication channel to retrieve the data string and remote check value computed by the remote computing device.

At block 510, the secure computing device may generate or calculate a local check value based on or using the real copy of the software in the remote computing device (from block 508) and the data string. In some embodiments, the secure computing device generates the local check value by using the same algorithm or technique that the remote computing device used to generate the remote check value and by using the data string in the same manner as the remote computing device. In some instances, the secure computing device uses a true copy of the software to generate the local check value, while the remote computing device uses an internal copy of the software to generate the remote check value. Under this condition, if the internal copy of the software of the remote computing device is the same as the true copy of the software, then the remote verification value will be the same as the local verification value; otherwise, the two values will be different. In some instances, cryptographic calculations without cryptographic keys may be performed using a hash function applied to the data string and the software.

At block 512, the secure computing device may determine or verify whether the remote computing device is executing authentic software based on the comparison of the remote check value and the local check value. For example, in embodiments, if the software residing on the remote computing device is authentic, e.g., has not been altered and is identical to the known authentic copy of the software obtained by the secure computing device at block 506, the remote check value will be the same value as the local check value. If the remote verification value is the same value as the local verification value, the secure computing device may determine that the remote computing device is actually executing authentic software and that the secure computing device need not perform additional operations, but in some embodiments it may maintain a satisfactory verification record. Similarly, if the software resident on the remote computing device has been modified, altered, or otherwise different from the known authentic software acquired by the secure computing device at block 506, the remote verification value will be a different value than the local verification value.

It should be understood that fig. 5 is an exemplary embodiment of the present technology and that method 500 may include fewer or additional blocks in additional embodiments.

FIG. 6 is an exemplary block diagram of a computing environment 600 including a computing system 602 that can be used to implement systems and methods in accordance with embodiments of the present technology. Other components and/or arrangements may also be used. In certain embodiments, computing system 602 may be used to implement, at least in part, various components of fig. 1-5, such as secure computing device 102 or remote computing device 104 of fig. 1, or the like. In certain embodiments, a series of computing systems similar to computing system 600 may each be customized with dedicated hardware and/or programmed as a dedicated server to implement one of the components in fig. 1-5, which may communicate with each other via network 504.

In the example shown in fig. 6, computing system 600 includes several components, such as a Central Processing Unit (CPU)606, a memory 608, input/output (I/O) devices 610, a Hardware Security Module (HSM)612, and a non-volatile storage device 614. System 600 may be implemented in a variety of ways. For example, an embodiment that is an integrated platform (such as a server, workstation, personal computer, laptop, etc.) may include a CPU606, memory 608, non-volatile storage 614, and I/O devices 610. In such a configuration, the components 606, 608, 614, and 610 may be connected and communicate through a local data bus, and may access the data store 616 (e.g., implemented as a separate database system) via an external I/O connection. I/O component 610 may connect to external devices through a direct communication link (e.g., a hardwired or local Wi-Fi connection), through a network such as a Local Area Network (LAN) or a wide area network (WAN, such as a cellular telephone network or the internet), and/or through other suitable connections. The system 600 may be a stand-alone system or may be a subsystem of a large system.

CPU606 may be one or more known processors or processing devices, such as the Intel available from Santa Clara, Calif^TMCore of company^TMSerial microprocessors, secure microprocessors including HSM (e.g., NXP i.MX8), or Senivir AMD from California^TMAthlon, Inc^TMA series of microprocessors. Memory 608 may be one or more flash memory devices configured to store instructions and information that are executed or used by CPU606 to perform certain functions, methods and processes associated with embodiments of the present technology. Storage 614 may be a volatile or non-volatile, magnetic, semiconductor, tape, optical or other type of storage device or computer readable medium, including for example CDs and DVDsAnd solid state devices intended for long term storage.

In the illustrated embodiment, the memory 608 contains one or more programs or applications 618 loaded from the storage device 614 that, when executed by the CPU606, perform various operations, programs, processes, or methods in accordance with the present techniques. Alternatively, the CPU606 may execute one or more programs located remotely from the system 600. For example, system 600 may access one or more remote programs via network 604 that, when executed, perform functions and processes associated with embodiments of the present technology.

In a certain embodiment, the memory 608 may include a program 618 for performing the specialized functions and operations described herein for the secure computing device 102 and/or the remote computing device 104. In some embodiments, memory 608 may also include other programs or applications that implement other methods and processes for providing ancillary functionality to the present technology. In certain examples, memory 608 may include any suitable non-transitory computer-readable medium. For example, a non-transitory computer-readable medium may include computer-executable instructions that direct the CPU606 to execute instructions in accordance with the techniques of this disclosure.

The memory 608 may also be configured with other programs (not shown) not relevant to the present technique and/or an operating system (not shown) that performs several functions known in the art when executed by the CPU 606. For example, the operating system may be Microsoft Windows^TM、Unix^TM、Linux^TM、Apple Computers^TMAn operating system or other operating system. Selecting an operating system, or even using an operating system, is not a necessary technical feature of the present technology.

HSM 612 may be a device with its own processor that securely generates and stores digital security assets and/or securely performs various cryptographic and sensitive computations. The HSM 612 protects digital security assets (such as encryption keys) and other sensitive data from possible access by an attacker. In some embodiments, HSM 612 may be a card or board that attaches directly to computing system 600. The HSM 612 may also be integrated into a single chip microprocessor.

The I/O devices 610 may include one or more input/output devices that allow the system 600 to receive and/or transmit data. For example, the I/O devices 610 may include one or more input devices, such as a keyboard, touch screen, mouse, etc., that allow data to be input from a user. In addition, the I/O devices 610 may include one or more output devices, such as a display screen, CRT monitor, LCD monitor, plasma display, printer, speaker device, etc., that allow data to be output or presented to a user. The I/O devices 610 may also include one or more digital and/or analog communication input/output devices that allow the computing system 600 to communicate digitally, for example, with other machines and devices. Other configurations and/or numbers of input and/or output devices may be incorporated into the I/O device 610. In some examples, the I/O device 610 may be implemented on a single chip microprocessor.

In the illustrated embodiment, the system 600 is connected to a network 604 (such as the internet, a private network, a virtual private network, a cellular or other network, or a combination of such networks), which network 604 may in turn be connected to various systems and computing machines, such as servers, personal computers, laptop computers, client devices, and the like. In general, system 600 may input data from and output data to external machines and devices via network 604.

In the example embodiment shown in FIG. 6, the data store or data source 616 is a separate database, file system, or dedicated memory external to the system 600. In other embodiments, the data source 616 may be hosted by the system 600. In various embodiments, the data source 616 may manage and store data for implementing systems and methods in accordance with the present techniques. For example, the data source 616 may be managed by the HSM 612 or the CPU606 and store data structures containing software and/or metadata, etc. for each remote computing device 104 that is authenticated by the system 100.

Data source 616 may include one or more databases, file systems, or other storage volumes that store information and that may be accessed and/or managed by system 600. By way of example, the database 616 may be Oracle^TMDatabase, Sybase^TMDatabases or other relational databases. However, in accordance with the present techniqueThe systems and methods of (1) are not limited to a single data structure or database, nor even to the use of a database or data structure. In some examples, data source 616 may include a file system or flat file, or the like.

Those of ordinary skill in the art will recognize that the components and implementation details of the system of FIG. 6 are examples presented for simplicity and clarity of explanation. Other components and implementation details may be used.

Although the above examples use specific instances of computerized devices such as OBUs, ECUs and RSUs, for clarity of explanation, the present techniques are not limited to those specific instances. Embodiments in accordance with the present technology can be used with a variety of computerized devices, such as medical devices (e.g., dialysis machines, infusion pumps, etc.), robots, drones, autonomous vehicles, wireless communication modules (e.g., embedded universal integrated circuit cards (euiccs)), and the like.

Other embodiments of the present technology will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed technology. Various modifications of the illustrative embodiments, as well as other embodiments of the subject matter, which are apparent to persons skilled in the art to which the subject matter pertains are deemed to lie within the scope of the subject matter disclosed.