Validating software residing on a remote computing device

Abstract

To provide a system and method including a processor capable of executing computer-readable instructions including operations including obtaining an authentic copy of software of a remote computing device and transmitting a verification request including a random data string to the remote computing device.SOLUTION: The method includes receiving, from a remote computing device, a remote check value generated by the remote computing device based on a random data string and software on the remote computing device, computing a local check value based on an authentic copy of the 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 check value and the local check value.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to verifying software residing on a remote computing device. [Background technology]

[0002] A computing device may execute software obtained from any number of sources. For reliable, secure, and protected operation of a computing device, the computing device may incorporate techniques to ensure the execution of authentic, authorized software rather than software that has been replaced, modified, or otherwise altered, for example, by equipment malfunction, accident, unauthorized user, etc. In some examples, a computing device may implement techniques to access authorized data files used to configure the system to operate in a particular manner rather than unauthorized data files. Traditional methods for protecting computing devices include the use of secure boot or a trusted platform module (“TPM”). In secure boot, executable software is signed with a cryptographic digital signature, which the microprocessor verifies before loading the software to be executed. Keyed hash functions, such as hash-based message authentication codes or “HMAC,” may also be used as a secure boot method to protect a computing device. Because unauthorized users or attackers do not have the key to create the signature or HMAC checksum, unauthorized users cannot modify the software and can still match the signature / checksum to modified code. Thus, the microprocessor will not load software with an invalid signature, i.e., the integrity of the system is protected. With respect to TPM-based technologies for securing computing devices, the TPM may be an auxiliary chip that verifies ("certifies") the executable code and static data being executed by the main CPU. In some technologies, only if the code is verified will the TPM release keys or other data, allowing full operation of the main CPU.

[0003] In some examples, secure boot and TPM technologies function on computing platforms equipped with microprocessors that implement secure boot or TPM chips. However, many computer platforms use standard microprocessors without secure boot capabilities and without TPMs. Because these systems cannot verify whether software has been modified before entering an operational state, unauthorized software may be executed, potentially compromising the security, safety, and / or reliability of the computer system. Examples of these computing platforms include, among others, most older computerized devices, computerized consumer devices, many Internet of Things ("IoT") devices, and specialized computerized devices such as electronic control units ("ECUs") used to control the operation of vehicles. As an example, without the ability to verify the software and data of all safety-critical ECUs within a vehicle, it is impossible to assume that the entire vehicle is in a known good safety state.

[0004] Furthermore, in many, if not most, computer platforms and devices with Secure Boot or with a TPM may rarely perform a power-on reset (which invokes Secure Boot). For example, some ECUs in vehicles may go into a sleep mode when the vehicle is turned off and may be powered on by the vehicle ignition. These ECUs only wake up from sleep when the power is turned on. Therefore, these ECUs are typically never powered off and therefore do not undergo a periodic secure boot. In these types of ECUs, there is a risk that the ECU software can be modified by an unauthorized user without detection. Summary of the Invention

[0005] Systems, methods, and devices for verifying software residing on a remote computing device are disclosed herein. In various implementations, a system for verifying software on a remote computing device is provided. The system includes one or more processors and a memory device, and the memory device includes one or more computer-readable instructions that, when executed by the one or more processors, cause the system to perform operations. The operations include obtaining an authentic copy of the software for the remote computing device, sending a verification request to the remote computing device including a random data string, receiving from the remote computing device a remote check value generated by the remote computing device based on the random data string and the software of the remote computing device, calculating a local check value based on the authentic copy of the 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 check value and the local check value.

[0006] The remote check value may be generated by the remote computing device by using the random data string as an encryption key, an additional input, or a combination thereof for a cryptographic checksum operation that generates 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 operation that generates the local check value.

[0007] The random data string may be unique to the verification request.

[0008] The operations may further include obtaining user data including the device identifier from the remote computing device.

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

[0010] The operations may include calculating a local check value based on a combination of a copy of the software on the remote computing device, a random data string, and a copy of the user data obtained from the remote computing device or another system that obtained the user data.

[0011] The cryptographic operation may include a digital signature operation, a block cipher-based message authentication code operation, or a hash-based message authentication code operation using a cryptographic hash function or block cipher and one or more of a cryptographic key, a nonce, and static data.

[0012] The software may be verified in response to the remote computing system transitioning from a sleep state to a fully functional state.

[0013] The software may be validated in response to a system event, or a period of time without validation exceeding a predetermined threshold, or an external signal corresponding to a user input.

[0014] The remote computing device may be an electronic control unit.

[0015] The operations may include initiating recovery of the remote computing device in response to determining that the remote computing device does not have authentic software due to a discrepancy between the remote check value and the local check value.

[0016] The actions can include initiating recovery of a second remote computing device that is part of a system that includes the remote computing device that does not have the authentic software.

[0017] The operations may include sending a command to place the remote computing device in a predetermined error response state in response to a determination that the remote computing device does not have authentic software based on a difference between the remote check value and the local check value in the comparison.

[0018] The remote computing device can include a storage device that stores a true copy of the software, and available space on the storage device that is not used by the true copy of the software is filled with random data values ​​up to a predetermined threshold amount or a predetermined capacity of the storage device.

[0019] The operations further include storing metadata indicating a time period for calculation of a remote check value for the remote computing device, the time period being based on one or more performance attributes of the remote computing device.

[0020] According to a further embodiment, a system for verifying software is provided. The system includes one or more processors and a memory device, the memory device including one or more computer-readable instructions that, when executed by the one or more processors, cause the system to perform operations. The operations include receiving a verification request from a secure computing device including a random data string, generating a first check value based on the random data string and the software in response to the verification request, and transmitting the first check value to the secure computing device so that the secure computing device compares the first check value with a second check value generated using the random data string and an authentic copy of the software.

[0021] The remote check value may be generated by the remote computing device by using the random data string as an encryption key, an additional input, or a combination thereof for a cryptographic checksum operation that generates 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 operation that generates the local check value.

[0022] The operations may include transmitting user data including a 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 a second check value using the random data string, the authentic copy of the software, and the user data.

[0023] The memory device may store software and any available space on the memory device not used by the software may be filled with random data values ​​up to a predetermined threshold amount or a predetermined capacity of the memory device.

[0024] The operations can include storing metadata in the secure computing device indicating a time period for calculation of a remote check value for the system, the time period being based on one or more performance attributes of the system.

[0025] According to yet a further embodiment, a computer-implemented method for verifying software is provided, the method including obtaining an authentic copy of software for a remote computing device, sending a verification request to the remote computing device including a random data string, receiving from the remote computing device a remote check value generated by the remote computing device based on the random data string and the software of the remote computing device, calculating a local check value based on the authentic copy of the 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 check value and the local check value.

[0026] The remote computing device may be an electronic control unit.

[0027] The method may include initiating recovery of the remote computing device in response to determining that the remote computing device does not have authentic software due to a discrepancy between the remote check value and the local check value.

[0028] The method may include sending a command to place the remote computing device in a predetermined error response state in response to a determination that the remote computing device does not have authentic software based on a difference between the remote check value and the local check value in the comparison.

[0029] The remote check value may be generated by the remote computing device by using the random data string as a cryptographic key, an additional input, or a combination thereof for a cryptographic checksum operation that generates 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 operation that generates the local check value.

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

[0031] The random data string may be unique to the verification request.

[0032] The actions may include obtaining user data including a device identifier from the remote computing device.

[0033] According to yet a further embodiment, a method for verifying software is provided, the method comprising: generating, by the remote computing device, a remote check value based on the remote check value; outputting the remote check value and the data string from the remote computing device to a secure data repository; obtaining, by the secure computing device, an authentic copy of the software for the remote computing device; obtaining the data string and the remote check value from the secure data repository; calculating a local check value based on the authentic copy of the software and the data string for the remote computing device; and determining whether the remote computing device has authentic software based on a comparison of the obtained remote check value and the local check value.

[0034] Generating the remote check value may include calculating the remote check value based on a predetermined time interval.

[0035] According to yet a further embodiment of the present disclosure, there is provided a system for verifying existing software on a remote computing device. The system includes one or more processors and a memory device, the memory device including one or more computer-readable instructions that, when executed by the one or more processors, cause the system to perform operations. The operations include obtaining an authentic copy of software for the remote computing device, the software being the last known authorized software provided to the remote computing device, sending a verification request to the remote computing device including a random data string, receiving from the remote computing device a remote check value generated by the remote computing device based on the random data string and the existing software on the remote computing device, calculating a local check value based on the authentic 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.

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

[0037] According to yet a further embodiment, a computer-implemented method for verifying existing software on a remote computing device is provided, the method including obtaining an authentic copy of software for the remote computing device that is the last known authorized software provided to the remote computing device, sending a verification request to the remote computing device that includes a random data string, receiving from the remote computing device a remote check value that is generated by the remote computing device based on the random data string and the existing software, calculating a local check value based on the authentic 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.

[0038] Available space on a storage device of a remote computing device that stores existing software is filled with random data values ​​up to a predetermined threshold amount or a predetermined capacity of the storage device.

[0039] An authentic copy may be obtained during the initialization phase of a remote computing device and stored in a trusted software repository for later access for verification. can. [Brief explanation of the drawings]

[0040] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate numerous examples of the features of the disclosed subject matter and, together with the specification, serve to explain the principles of the various technologies described herein. [Figure 1] FIG. 1 is a block diagram of an example system for verifying software residing on a remote computing device according to example embodiments described herein. [Figure 2]FIG. 2 is a process flow diagram of an exemplary method for verifying software residing on a remote computing device with a secure computing device according to example embodiments described herein. [Figure 3] FIG. 1 is a process flow diagram of an example method for a remote computing device to enable verification of software present on the remote computing device according to example embodiments described herein. [Figure 4] FIG. 1 is a block diagram of an example device including an electronic control unit having software verified by a secure computing device according to example embodiments described herein. [Figure 5] FIG. 1 is a process flow diagram of an example method for a remote computing device to enable verification of software present on the remote computing device according to example embodiments described herein. [Figure 6] FIG. 1 is a block diagram of an example computing system capable of hosting systems and methods according to example embodiments described herein. DETAILED DESCRIPTION OF THE INVENTION

[0041] Reference will now be made in detail to various implementations of the technology described herein, some examples of which are illustrated in the accompanying drawings. Where convenient, the same reference numerals will be used throughout the drawings to refer to the same or like parts.

[0042] The techniques, methods, and devices described herein can verify software stored within any suitable computing device, such as an embedded computing device, among others. For example, the techniques and devices described herein include a secure computing device that performs remote verification of software and static data residing on a remote computing device. Thus, in various embodiments, the secure computing device acts as a controller or manager of the verification process and interacts with a computing device that is typically not co-located with the secure computing device and is generally referred to herein as the remote computing device. The secure computing device implements the techniques described herein to ensure that the remote computing device is running valid or authentic software and associated data, rather than software and data that has, for example, been modified or tampered with (maliciously or accidentally) or is out of date (e.g., an older software release that has been replaced). For many existing computerized devices that are deployed remotely (e.g., IoT devices, computerized medical equipment, ECUs in vehicles, etc.), a secure computing device cannot simply request that the remote computing device perform a checksum or hash of the program space of the remote computing device and transmit that check value (e.g., checksum) back to the secure computing device for comparison with a local known good value stored on the secure computing device, because an unauthorized user or the like could modify software residing on the remote computing device to prevent unauthorized users or software from tampering with the remote computing device.

[0004] This is because it would cause the remote computing device to supply or recalculate a previously verified check value that was present on the remote computing device. Furthermore, in existing computerized devices, there is typically no secure communication channel between the remote computing device and the secure computing device attempting to verify or validate the software of the remote device. Thus, in such cases, data transmitted between the remote computing device and the secure computing device cannot be presumed to be authentic, for example, because the data (e.g., check value, checksum, etc.) may have originated from somewhere other than the remote computing device being verified or validated.

[0043] The techniques described herein verify software stored on a remote computing device with a separate secure computing device. For example, rather than maintaining a check value for the remote computing device's software and data, such as a hash-based message authentication code ("HMAC") value, various implementations of the techniques described herein include using the secure computing device to store an authentic and valid copy of the remote computing device's software, and optionally static data. In some such implementations, to verify the software and static data on the remote computing device, the secure computing device can send a verification request to the remote computing device, which can include a unique value such as a random data string or a current time value in microseconds (e.g., a nonce). Then, in response to the request, the remote computing device can use the supplied random data string or value to perform a check value calculation (e.g., an HMAC calculation or a block cipher-based MAC such as CMAC, among others) on its software and static data, or can create a digital signature of its software and static data.

[0044] In some embodiments, when a remote computing device receives a verification request that includes a unique value such as a nonce, the remote computing device uses the received nonce directly as a key, or in combination with a key available to the remote computing device, for an HMAC or cryptographically-based MAC calculation (the "check value") on its own software and static data.

[0045] In various embodiments, the remote computing device sends the check value it computed back to the secure computing device that sent the request, which can use the same nonce and shared key (if used) to compute a check value (e.g., an HMAC result) for the verified copy of the remote computing device's software and static data residing on the secure computing device.

[0046] 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 can be considered verified and correct, because if any software code or static data of the remote computing device differs from the verified copy stored on the secure computing device, the calculation of the check value performed by the remote device will necessarily yield a different check value, given that the same nonce and / or key is used for the calculation by both systems. In some embodiments, a check value as used herein is a cryptographically calculated value based on any suitable cryptographic technique. In some examples, the check value is It may be determined using any suitable cryptographic technique, such as SHA-256, among others, and may prevent unauthorized users from calculating the same value without verifying software. Using a unique nonce for each verification request may make it impossible for unauthorized users to regenerate or reuse old check values.

[0047] The techniques and devices described herein include various practical applications and technical enhancements over conventional systems. For example, a secure computing device can periodically request verification of a remote computing device's software. Thus, the remote computing device can be verified when the remote computing device wakes up from a sleep state or at any other time. The techniques herein can verify and ensure the execution of authentic software, particularly in systems where power-on resets may be rare, such as industrial control systems. Furthermore, the techniques herein can enable a remote computing device to verify its software with little or no disruption to its normal operation by scheduling the verification to occur during periods of inactivity when sufficient resources, such as CPU resources, are available on the remote computing device.

[0048] In some embodiments, the techniques and devices described herein do not require the remote computing device to have special security equipment or to perform cumbersome processing that affects performance, and do not affect the cost of the remote computing device. As described herein, data transmitted over a communication channel between the secure computing device and the remote computing device is minimal (e.g., a verification request including a nonce and a response including a check value), which advantageously reduces communication bandwidth usage and enables communication over bandwidth-limited equipment and infrastructure and performance-limited channels, such as a Controller Area Network (“CAN”) bus or a Local Interconnect Network (“LIN”) bus, among others. 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 enclosure with two or more different printed circuit boards or modules. In some examples, the communication channel may be included within any suitable Internet of Things (IoT) system for healthcare applications, industrial control systems, etc. For example, one module in a system may have a secure microprocessor capable of performing a secure boot, while other modules in the system may not have a secure microprocessor. The module with the secure microprocessor can periodically use the techniques described herein to verify the software of other modules that do not have a secure microprocessor. In some examples, an external system can periodically verify the software of modules with secure microprocessors.

[0049] In some embodiments, a single secure computing device can verify numerous remote computing devices that make up a complex system. For example, a vehicle can be equipped with a novel, specialized gateway ECU that has the functionality of the secure computing device described herein, and this gateway ECU can verify some or all of the other ECUs in the vehicle, which may be 50 or more. In some examples, the verification techniques described herein can be controlled and driven from a central secure computing device that can communicate with remote computing devices over any distance and over any network. For example, a central device A secure computing device located at a data center can communicate with remote computing devices deployed anywhere in the world via the Internet or any suitable network. Furthermore, in some implementations, if the secure computing device detects a fault or problem in a remote computing device, the secure computing device can initiate recovery actions or the like in the remote computing device, or the secure computing device can place an entire complex system, such as a vehicle, that includes a problematic remote computing device (e.g., an ECU) into a safe state.

[0050] The technology herein is not simply related to data manipulation, but to an improved software verification system that allows for determining whether a remote device is running authentic software or whether an unauthorized user has modified the software on the remote device. Additionally, the technology described herein employs 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 the generation of a local check value by the secure computing device.

[0051] 1 is a block diagram of an exemplary system for verifying software residing on a remote computing device. System 100 can include one or more secure computing devices 102 and one or more remote computing devices 104, 105, and 106. In some examples, secure computing device 102 can 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 one module of a system including multiple intelligent modules connected by a backplane or the like. In some embodiments, secure computing device 102 can be part of, or a subsystem of, one or more of a vehicle, a watercraft (e.g., a boat), an aircraft, a spacecraft, a medical device, a robot, a drone, a wireless or wired communication module, and an IoT device. In some embodiments, secure computing device 102 can be, or can be part of, a specialized on-board unit that primarily performs the functions of a secure computing device as described herein. Remote computing devices 104, 105, and 106 may, in some examples, represent any number of remote computing devices, such as on-board units (“OBUs”) or ECUs of a vehicle, a watercraft, an aircraft, a spacecraft, a robot, a drone, a medical device, or an IoT device. For example, in a vehicle embodiment, remote computing devices 104, 105, and 106 may include any number of ECUs that store software and / or data that can be verified by secure computing device 102.For example, 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), etc. In some transportation-related embodiments, remote computing devices 104, 105, and 106 may be or correspond to, among other things, a traffic control device (e.g., a traffic signal, a traffic light, or an electronic traffic sign), a digital sign, a pedestrian warning system, a motorcycle sensor, a bicycle sensor, or a roadside unit (RSU) of an electronic sign.

[0052] In various implementations, the secure computing device 102 may be a remote computer. The computing engine 107 may include a computation engine 107 that can verify the software of the remote computing devices 104, 105, 106, for example, to determine whether the software in the remote computing devices is authentic, up-to-date, and / or unaltered from its original form. In some embodiments, the computation engine 107 may be a hardware security module (“HSM”) (not shown), or may or may not include an HSM. An HSM can enhance the security of the techniques herein, allowing the secure computing device 102 and the remote computing device 104 to perform secure computations with greater security against threats from unauthorized users, etc. In some implementations, the computation engine 107 may be capable of, or be designed to perform, secure computations itself, without requiring an on-board HSM.

[0053] In various implementations, different HSM versions may be used in the compute engines 107. For example, the HSM may include an internal HSM installed as a plug-in card in one or more of the compute engines. In such implementations, the internal HSM may be installed as a Peripheral Component Interconnect (PCI) HSM or PCI Express (PCIe) HSM in one or more of the compute engines. Also, for example, the HSM in the compute engines 107 may include an external HSM separate from the compute engines in their own enclosure, a network-attached HSM, or a network-attached HSM. In some embodiments, the HSM may be built into or integrated into the cryptographic processor of the microprocessor. In some examples, the microprocessor may perform a secure boot such that software executed by the microprocessor is verified with a firmware program capable of calculating cryptographic checksums or verifying digital signatures. In some embodiments, an external hardware module may implement the HSM functionality.

[0054] In some embodiments, the secure computing device 102 and the remote computing devices 104, 105, and 106 can communicate over any suitable digital channel 108, such as a CAN bus or a LIN bus, among others. In some examples, the digital channel 108 may be secure or insecure. For example, the secure computing device 102 and the remote computing devices 104, 105, and 106 can communicate over an insecure digital channel when software executed by or included on each of the remote computing devices 104, 105, and 106 is verified. Verification by the secure computing device 102 of software residing on the remote computing devices 104, 105, and 106 is described in more detail below in connection with FIGS. 2 and 3. In some examples, a trusted software repository 110 can provide authentic software to the remote computing devices 104, 105, and 106 and / or the secure computing device 102 over the digital channel 108. For example, trusted software repository 110 may store authentic software that is supposed to be stored on and executed by each of remote computing devices 104, 105, and 106. As previously mentioned, if remote computing devices 104, 105, and 106 are different from one another (e.g., device 104 is a PCM, device 105 is a TCM, and device 106 is an EBCM), trusted software repository 110 may store copies of authentic software and associated static data (e.g., configuration files) for each of these three devices 104-106, e.g., three different software programs, images, etc.

[0055] Those skilled in the art will appreciate that the components and implementation details shown in FIG. 1 are examples presented for brevity and clarity of explanation. This example is not intended to be limiting, and many variations are possible; other components, processes, implementation details, and variations can be used without departing from the principles of the technology described herein. For example, system 100 can include any suitable number of secure computing devices 102 and remote computing devices 104, and secure computing device 102 and remote computing device 104 can communicate over any number of digital channels 108. In some examples, secure computing device 102 can be located any suitable distance from remote computing devices 104, 105, and 106, and thus digital channel 108 may include a global communications network. For example, secure computing device 102 need not be located in close proximity to remote computing devices 104, 105, and 106.

[0056] 2 is a process flow diagram of an exemplary method for verifying software residing on a remote computing device. Method 200 can be implemented on any suitable computing device, such as secure computing device 102 of FIG. 1 and secure computing device 408 of FIG. 4.

[0057] In block 202, the secure computing device may obtain an authentic copy of software stored (or assumed to be stored) in and / or executed (or assumed to be executed) by the remote computing device. In some embodiments, the secure computing device may obtain the authentic copy of the software via any suitable network connection, such as the Internet. In some examples, the secure computing device may obtain the authentic copy of the software from the remote computing device during an initialization period, such as when the remote computing device is manufactured and / or initially provided, such as during the manufacture of an automobile having multiple OBUs. For example, the software may be stored or installed on both the secure computing device and the remote computing device during the initialization period. In some cases, the secure computing device and the remote computing device may not have access to a remote network during the initialization period, and / or may not have an external network connection during the initialization period. In such cases, the secure computing device and the remote computing device may obtain the authentic software from any suitable computer-readable medium, such as a Universal Serial Bus (“USB”) device, a CD-ROM, a Bluetooth-enabled device, etc.

[0058] Additionally or alternatively, in some embodiments, the secure computing device may obtain authentic software for the remote device from, among other things, a storage device (e.g., a storage device implementing trusted software repository 110) that may be locally accessible or accessible over a network such as a CAN or PCI bus. The storage device may be downloaded or programmed during an initialization period, such as during manufacturing. The storage device may be updated from time to time to include the latest authentic software on the remote device. In some examples, software installed on the remote computing device is cryptographically signed to enable the secure computing device to determine whether the software is the latest authentic software. (or verified based on a message authentication code). 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 prevent the software from being modified undetected.

[0059] In some embodiments, a secure computing device can obtain any number of copies of software for any number of remote computing devices, such as electronic control units, among others. Generally, a secure computing device requires authentic copies of software for remote devices to be verified or evaluated. Therefore, a secure computing device need not obtain software from remote devices, because the software on the remote computing device may have been intentionally or unintentionally altered or replaced and may no longer be authentic. Rather, a secure computing device should download or store authentic software from a trusted device, be programmed with authentic software from a trusted device, or otherwise obtain authentic software from a trusted device. For example, a secure computing device may obtain software from a secure repository, etc., at the time of manufacture of the secure computing device, and may periodically receive updates via secure communications from a trusted source, such as by secure over-the-air updates from trusted software repository 110. In some such examples, a secure computing device may have access to a trusted repository that contains digital signatures or message authentication codes (MACs) for individual software components or entire collections of components, so that unauthorized users or unauthorized software cannot replace or modify the software without detection.

[0060] 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 various components or subsystems of a vehicle or roadside unit, etc. As discussed above in connection with FIG. 1 , vehicles having ECUs include automobiles, watercraft (e.g., boats), aircraft, spacecraft, drones, etc. In some embodiments, the electronic control unit may reside in a roadside unit (RSU), such as a traffic control device (e.g., a traffic signal, traffic light, or electronic traffic sign), a digital sign, a pedestrian warning system, a motorcycle sensor, a bicycle sensor, or an electronic sign, among others. Additionally, the remote computing device may be or be included in many non-vehicle-related devices, such as a medical device, a robot, a wireless or wired communication module, or an IoT device, among others.

[0061] In some examples, a remote device (e.g., an electronic control unit or a roadside unit) may communicate with the secure computing device via a CAN bus, a LIN bus, an Ethernet, a network connection, or a Bluetooth connection, among others. In various implementations, the secure computing device may verify software from or within any number of remote computing devices, as discussed in further detail below in connection with blocks 204-212.

[0062] In block 204, the secure computing device may send a verification request to the remote computing device that includes a random data string. Random data, as referred to herein, is unique for each verification request and may include any time-varying data that contains sufficient entropy to prevent unauthorized users from pre-calculating or otherwise determining the value of the random data. In the verification request, the remote computing device may indicate that the secure computing device should provide information that the remote computing device will use to verify or validate the authenticity of software currently stored on and / or executed by the remote computing device. In some implementations, a random data string, which may also be referred to as a nonce, may be used as a digital encryption key for cryptographic checksum calculations or as a variable in a digital signature in the verification process.

[0063] In various implementations, the secure computing device may periodically send a verification request for a particular remote device at any suitable static or random time interval. For example, the secure computing device may send a verification request to the remote computing device at a static time daily, monthly, or yearly, among other times. In some other examples, the secure computing device may select a random time interval to send the verification request based on a random time within a predetermined number of hours, days, or months, among other events. For example, the secure computing device may send a verification request to the remote computing device at a randomly selected time within a day, or at a selected random time within several hours within a day.

[0064] In some embodiments, the secure computing device may verify the software of the remote computing device when the period since the last verification (or initialization) exceeds a predetermined threshold or in response to an external signal corresponding to user input. For example, the secure computing device may verify the software of the remote computing device after an appropriate predetermined number of seconds, minutes, hours, days, months, years, etc. has passed without verification, such as 12 hours, 30 days, 6 months, or 1 year. In some embodiments, verification of the software of the remote computing device may be performed in response to a system event, such as when the remote computing device transitions from a sleep state to a fully functional state, among other things. For example, the secure computing device may receive or otherwise detect an indication from the remote computing device or another system that the remote computing device has transitioned from any appropriate sleep state, partial power state, etc. to a fully powered and functional state. The secure computing device may respond to an indication of a change in the power state of the remote computing device by sending a verification request to the remote computing device. In various embodiments, a change in the power state of the remote computing device or a system including the remote computing device may trigger the sending of a verification request to the remote computing device. For example, when a remote computing device transitions from a low power state to a high power state, a power change notification may be generated and transmitted to the secure computing device, which may initiate verification of software present on the remote computing device. In some examples, the secure computing device may respond to a power state change notification caused by, for example, the starting of a vehicle, which changes the power of one or more of the on-board OBU remote computing devices.The secure computing device may also implement a delay between detecting a change in power state and requesting verification of the remote computing device.

[0065] In block 206, the secure computing device may receive, obtain, or detect a remote check value from a remote computing device, where the remote computing device, in various embodiments, The remote check value may be created and provided in response to a verification request in SEQ ID NO: 04. In various implementations, the remote computing device may calculate, compute, or generate the remote check value using or based on a random data string and software on the remote computing device. In some examples, the remote check value may be generated using the random data string as a cryptographic key for a cryptographic operation performed on software stored within the remote computing device. In various examples, the random data string may be in the form of a digital key, a block cipher-based message authentication code, or a nonce for any suitable HMAC encryption algorithm. In some embodiments, the random data string may be appended to or otherwise combined with the software prior to signing the software, thereby generating a unique digital signature. In some examples where a fixed key is used, the random data string (e.g., a nonce) causes each calculation to produce a different result, thus ensuring freshness and preventing replay of old calculations by unauthorized devices or software. In some embodiments, the remote check value may be generated with a hash function rather than a cryptographic key. For example, the remote check value may be generated by hashing a nonce value and the software.

[0066] In some embodiments, the remote check value is calculated, computed, or generated using software, including static or read-only information stored on the remote computing device, in combination with a random data string and software on the device. For example, the remote check value can be generated by an HMAC function applied to static information on the remote device, such as binary executable files, files, and directories, where one of the static files is used as a key. In some embodiments, the remote computing device can identify and exclude dynamic information, such as temporary files, user-input data, sensor data, variables, and the like. For example, the remote computing device can maintain a list of files corresponding to static information and another list of files corresponding to dynamic information that may be modified or change over time. The remote check value can be generated based on an HMAC function applied only to static information files, while ignoring dynamic information files. In some embodiments, an HMAC or CMAC function can generate the remote check value based on, among other things, static information from a list in combination with a nonce or digital signature. For example, a hash function can generate the remote check value based on a nonce combined with a cipher with a fixed key and software as plaintext. In some embodiments, other suitable cryptographic checksum calculation techniques can be used to generate the remote check value.

[0067] In block 208, the secure computing device may generate or calculate a local check value based on or using the authentic copy of the software and the random data string at the remote computing device (from block 202). 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 it is used at the remote computing device. In contrast, the secure computing device uses an authentic copy of the software to generate the local check value, while the remote computing device uses its own internal copy of the software to generate the remote check value. Under these conditions, if the remote computing device's internal copy of the software is the same as the authentic copy of the software, the remote check value will be the same as the local check value. otherwise, the two values ​​are different.

[0068] In some implementations, the local check value may be calculated or generated by using a random data string as an encryption key for an encryption operation performed on an authentic copy of the software. In such implementations, the random data string is applied, combined, or used with the software residing on the secure computing device using the same techniques for applying, combining, or using the random data string and the software residing on the remote computing device, and the same encryption operation is used by both the secure computing device and the remote computing device. In various examples, the encryption operation may include, among other things, a hash-based message authentication code using a cryptographic hash function and a random nonce used as the encryption key. In some examples, the random data string may be used as a digital key used to verify the software using any suitable cryptographic-based MAC algorithm. In some examples, a hash function applied to the nonce value and the software may be used for encryption operations without an encryption key.

[0069] In block 210, the secure computing device can determine or verify whether the remote computing device is running authentic software based on a comparison of the remote check value and the local check value. For example, in various implementations, if the software residing on the remote computing device is authentic, e.g., unaltered and identical to the known authentic copy of the software obtained by the secure computing device in block 202, the remote check value and the local check value will be the same. If the remote check value and the local check value are the same, the secure computing device can determine that the remote computing device is indeed running authentic software, and thus the secure computing device need not take any further action, although in some implementations may keep a record of satisfactory verification. Similarly, if the software residing on the remote computing device has been altered, tampered with, or otherwise not identical to the known authentic software obtained by the secure computing device in block 202, the remote check value and the local check value will be different. For example, if the software residing on the remote computing device has been subject to unauthorized or unintended modification, the remote check value will differ from the local check value generated by the secure computing device. If the remote check value and the local check value differ (signaling that the remote computing device is not using authentic software), the secure computing device may take additional action, such as alerting an operator, disabling or partially disabling the remote computing device, correcting or recovering the software on the remote computing device, or otherwise addressing the problem.

[0070] As one example of an additional action, in block 212, the secure computing device may modify the operation of the remote computing device in response to determining or detecting a difference between the remote check value and the local check value, e.g., from the comparison of block 210. For example, the secure computing device may disable (e.g., turn off) or partially disable (e.g., command to enter safe mode, etc.) the remote computing device. Additionally, the local secure computing device may generate an alert, etc. In some additional or alternative embodiments, In this way, the secure computing device can modify the operation of an entire system incorporating the remote computing device, such as modifying the operation of a vehicle that includes an ECU with inauthentic software.

[0071] 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 examples, recovery of the remote computing device may include loading or writing known authentic software to the remote computing device to replace the inauthentic software detected in block 210. Additionally or alternatively, in various vehicle embodiments, recovery of the remote computing device may include sending an instruction by the secure computing device to the vehicle's ECU to enter a safe state or a predetermined error response state, such as a "limp home" mode that reduces the vehicle's top speed.

[0072] In some examples, the secure computing device can modify the operation of another remote computing device, or multiple other remote computing devices that form or are part of the same system (e.g., in the same vehicle), in response to detecting a difference between the remote check value and the local check value (i.e., detecting inauthentic software) in a single remote computing device of the overall system. For example, the secure computing device can initiate recovery of each electronic control unit in the vehicle (or one specific other ECU, or a specific collection of all ECUs) in response to detecting inauthentic software (which may have been dangerously corrupted, unauthorized modified, maliciously hacked, etc.) in any one electronic control unit. In some embodiments, the secure computing device can request or command the remote computing device to enter a safe state or mode in response to detecting a difference between the remote check value and the local check value. In some examples, the safe state can include modifying or disabling the operation of a system or subsystem that includes or is controlled by the remote computing device. For example, safety conditions may include, among other things, preventing the arm of a welding robot from rotating, directing an autonomous vehicle to the side of the road, or limiting the set of speeds and features available to the vehicle.

[0073] The process flow diagram of FIG. 2 is not intended to imply that the operations of method 200 must be performed in any particular order, nor is it intended to imply that all operations of method 200 must be included in all cases. Furthermore, method 200 may include any suitable number of additional operations. For example, method 200 may further include obtaining user data from the remote computing device, where the user data includes a device identifier, a device name, etc. In some examples, the device identifier may include a hardware-specific value, such as a microprocessor's electronic serial number. In some embodiments, method 200 may include generating a remote check value based on a combination of the remote computing device's software, a random data string, and user data from the remote computing device. In some embodiments, method 200 may include calculating a local check value based on a combination of the remote computing device's copy of the software, the random data string, and a copy of the user data obtained from the remote computing device or from a computer capable of accepting and providing user input to both the remote computing device and the secure computing device. can.

[0074] 3 is a process flow diagram of an exemplary method for a remote computing device to enable verification of software present on the remote computing device. Method 300 can be performed on any suitable computing device, such as remote computing device 104 of FIG. 1 or a vehicle gateway, among others.

[0075] 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 some embodiments, the remote computing device may receive a copy of the software that is also stored locally on or within the secure computing device during the initialization process described above in connection with block 202 of FIG. 2 . For example, the remote computing device may receive the copy of the software over any suitable network connection. In some embodiments, the remote computing device may receive the copy of the software to any suitable computer-readable medium, such as a Universal Serial Bus (“USB”) device, a CD-ROM, or the like. In some embodiments, the remote computing device may receive the copy of the stored software from a trusted software repository accessible to the remote computing device and the secure computing device. In some examples, the remote computing device and the secure computing device may obtain the copy of the stored software at different times and locations. For example, the remote computing device may obtain the software at the time of manufacture, while the secure computing device may obtain the software at a later time.

[0076] In some embodiments, the remote computing device may be configured to have a certain amount of storage and / or memory for storing a copy of the received software, along with an additional 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 examples, the available storage of the remote computing device may store a random data value. In some examples, the random data value may be shared with or transmitted to the secure computing device so that the secure computing device can calculate a local copy of the check value. A cryptographic checksum may then be calculated for the entire available storage, including the stored program software and the random data that fills the remaining available space. This technique may prevent a remote computing device from storing both malware and a copy of legitimate software in memory and using the legitimate copy of the software to calculate the correct response or cryptographic checksum value in response to a verification request, but then executing other stored, unauthorized software.

[0077] At block 304, the remote computing device may receive a verification request from the secure computing device, the verification request including the random data string. In some embodiments, the remote computing device may cause the secure computing device to generate and send the verification request to the remote computing device. For example, the remote computing device may receive notification that the remote computing device has transitioned from a sleep state to a fully functional state. A notification may be sent to the secure computing device. In some embodiments, the remote computing device may generate an indication when the remote computing device transitions from any suitable sleep state, partial power state, etc. to a fully powered and functional state. As described above in connection with FIG. 2 , the secure computing device may respond to the indication of a change in the power state of the remote computing device by sending a verification request to the remote computing device. In some embodiments, a change in the power state of the remote computing device may trigger the generation and transmission of an indicator to the secure computing device. For example, a transition from a low power state to a high power state in the remote computing device may result in the generation and transmission of an indication to the secure computing device to initiate verification of software residing on the remote computing device. In some embodiments, the remote computing device may receive the verification request at any suitable random period, static period, etc.

[0078] In some embodiments, the verification request may indicate a period of time within which the remote value should be calculated or generated, as described in further detail below in connection with block 306. In some examples, the period of time is determined based on the number of instructions the processor of the remote computing device can execute per second or any other suitable time frame. For example, the verification request may indicate that the remote computing device has a period of 5 seconds, 10 seconds, or any other suitable amount of time within which to generate or calculate the remote check value. In some examples, the remote computing device may be configured to perform the software check or verification immediately upon receiving the verification request. The secure computing device may have a local time estimate of the time it will take the remote computing device to perform the software check and send the remote check value to the secure computing device. If the remote device performs the software check too quickly or too slowly, the secure computing device may determine that the remote computing device may be running unauthorized software. In some embodiments, the secure computing device may store metadata indicating a period of time for the remote computing device to calculate the remote check value, the period of time being based on one or more performance attributes of the remote computing device. Performance attributes may include processor speed, memory read / write speed, etc. This technique can prevent a remote computing device from compressing stored legitimate software in order to store non-genuine software. In some instances, the duration of the validation request can prevent a remote computing device from decompressing the legitimate software to yield a correct remote check value.

[0079] In block 306, the remote computing device may calculate, compute, or generate a remote check value based on a random data string used as an encryption key for the encryption operation of the software, or based on a nonce value and a hash function applied to the software without an encryption key. In some embodiments, the remote check value is generated based on static or read-only information stored on the remote computing device. For example, the remote check value may be generated by an HMAC function applied to static information, such as binary executable files, files, directories, etc. In some embodiments, the remote computing device may identify and filter out dynamic information, such as temporary files, user-entered data, etc. For example, the remote computing device may store a list of files corresponding to static information and another list of files corresponding to dynamic information that may change. The remote check value may be generated based on a hash function applied to a list of static information while ignoring dynamic information from the calculation of the cryptographic checksum function. For example, the remote computing device may identify a set of static executable files and generate the remote check value based, in particular, on the application of any suitable HMAC function to binary representations 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 read-only software, file size of read-only files, etc. 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 a nonce, or to the nonce and a digital signature. In some embodiments, the remote computing device may generate the remote check value by applying a cryptographic checksum to both the software and a stored random data value stored in storage or memory of the remote computing device. For example, the remote computing device may include a storage device that stores an authentic copy of the software and the random data value, where the available storage capacity of the storage device is below a predetermined threshold. For example, available space on a storage device not used for authentic copies of software can be filled with random data values ​​up to a predetermined threshold amount or capacity of the storage device. In some embodiments, the predetermined threshold may be 5 MB, 10 MB, etc. In some examples, the remote computing device can generate and store random data values ​​until the available storage space in the storage device falls below the predetermined threshold. This approach can prevent the remote computing device from storing non-genuine software.

[0080] At block 308, the remote computing device may transmit the remote check value to the secure computing device. For example, the remote computing device may transmit the remote check value to the secure computing device via any suitable CAN bus, LIN bus, network connection, Bluetooth connection, computer-readable medium, etc.

[0081] In some embodiments, the full functionality of the software is not available on the remote computing device until the software on the remote computing device is verified by the secure computing device. In some examples, the remote computing device may receive permission for full operation of the software once correct verification of the software is confirmed. For example, additional functionality within the software may be allowed to execute after verification of the software stored on the remote computing device.

[0082] It should be understood that FIG. 3 is an example implementation of the techniques described herein, and that system 300 may include fewer or additional components and devices in further implementations. For example, method 300 may include calculating or generating, by the remote computing device, a hash of a nonce value and a static code stored on the remote computing device. The hash of the nonce or the nonce itself may, in some examples, be used as an encryption key to encrypt a known plaintext message. In some embodiments, the remote computing device may send the encrypted plaintext message to the secure computing device. If the secure computing device is unable to decrypt the encrypted plaintext message or the ciphertext, the method continues with the remote computing device. This may include determining that software stored on the computing device has been modified to include non-authentic software or instructions.

[0083] In some embodiments, the nonce value in the verification request includes a complete unique time based on a date (or the number of seconds since a predetermined year, etc.). In some examples, the nonce value may not be transmitted from the secure computing device to the remote computing device. For example, the method may include the secure computing device issuing a command to the remote computing device to provide a check value, and the remote computing device may return the check value and the time / date of processing the verification request by the remote computing device. In some examples, the secure computing device may verify that the time / date is within an expected range and is not a repetition of an older 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 the check value along with the date / time to a log file or any other suitable location in a 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 on any suitable external computing device or external storage device, and may include check values ​​calculated by the remote computing device at predetermined time intervals, such as every 5 seconds, 1 minute, or 5 minutes, among others. In some examples, the remaining available space on the storage device of the remote computing device may be filled with random data values ​​to prevent the storage of a pre-computed check value. In some examples, a counter value may be initialized and incremented as a non-transmitted nonce value if a clock is unavailable.

[0084] 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 example embodiments described herein.

[0085] In some embodiments, vehicle 400 may include electronic control units (“ECUs”) 402, 404, 406, which may be remote computing devices that may be combined with secure computing device 408, secure ECUs, or any suitable device. In some embodiments, secure computing device 408 may include copies of software stored in each ECU 402, 404, and 406. The copies of 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 calculate, compute, or generate a respective unique remote check value in response to a validation request and transmit the respective remote check value to secure computing device 408 via digital channels 408, 410, and 412. The secure computing device 408 can then verify, based on the random data string or nonce, that the static software stored in each ECU 402, 404, and 406 has not been altered, based on the process described above in connection with Figures 3 and 4.

[0086] Those skilled in the art will appreciate that the components and implementation details shown in Figure 4 are examples presented for simplicity and clarity of explanation. This example is not intended to be limiting, and since many variations are possible, other components, processes, implementation details, and variations may be used without departing from the principles of the technology described herein. It can be used.

[0087] 5 is a process flow diagram of an exemplary method for a remote computing device to enable verification of software present on the remote computing device. Method 500 can be performed on any suitable computing device, such as remote computing device 104 of FIG. 1 or a vehicle gateway, among others.

[0088] At block 502, the remote computing device may calculate, compute, or generate a remote check value based on the data string and software stored on the remote computing device. The data string may be, among other things, any suitable random value, timestamp, or incrementing counter. In some embodiments, the remote check value is generated based on static or read-only information stored on 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 file, a file, or a directory, as described above in connection with block 306 of FIG. 3. In some embodiments, the remote check value may be generated based on a hash function applied to a list of static information while ignoring dynamic information from the calculation of the cryptographic checksum function. 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 check value may include calculating the remote check value based on a predetermined time interval, such as any number of seconds, minutes, hours, or days, among other things.

[0089] At block 504, the remote computing device may output the remote check value and data string from the remote computing device to a secure data repository. For example, the remote computing device may transmit the remote check value to the secure data repository via any suitable CAN bus, LIN bus, network connection, Bluetooth connection, computer-readable medium, etc. In some embodiments, the secure data repository may be any suitable storage device, log file, computing device, server, etc. that can receive and store the remote check value and data string from the remote computing device.

[0090] In some embodiments, the remote computing device can periodically verify the software when the secure computing device is unavailable or offline. For example, the remote computing device can verify the software stored on the remote computing device without receiving a verification request or command including a nonce value from the secure computing device. In some examples, the secure computing device can asynchronously communicate with a secure data repository to access a remote check value and verify the software of the remote computing device.

[0091] 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 the initialization process described above in connection with block 202 of FIG. 2. In some embodiments, the secure computing device may obtain a copy of the stored software that is also provided to the remote computing device. In some examples, the remote computing device and the secure computing device can obtain copies of the stored software at different times and locations.

[0092] The secure computing device may obtain the data string and the remote check value from the secure data repository at block 508. For example, the secure computing device may access the secure data repository using any suitable digital communication channel to obtain the data string and the remote check value calculated by the remote computing device.

[0093] At block 510, the secure computing device may generate or calculate a local check value based on or using the authentic copy of the software at 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 it is used at the remote computing device. In some examples, the secure computing device generates the local check value using an authentic copy of the software, while the remote computing device generates the remote check value using its own internal copy of the software. Under these conditions, if the remote computing device's internal copy of the software is the same as the authentic copy of the software, the remote check value will be the same as the local check value; otherwise, the two values ​​will differ. In some examples, a hash function applied to the data string and software can be used for cryptographic operations without a cryptographic key.

[0094] At block 512, the secure computing device can determine or verify whether the remote computing device is running authentic software based on a comparison of the remote check value and the local check value. For example, in various implementations, if the software residing on the remote computing device is authentic, e.g., unaltered and identical to the known authentic copy of the software obtained by secure computing at block 506, the remote check value and the local check value will be the same. If the remote check value and the local check value are the same, the secure computing device can determine that the remote computing device is indeed running authentic software, and thus the secure computing device need not take any further action, although in some implementations may keep a record of satisfactory verification. Similarly, if the software residing on the remote computing device has been altered, modified, or otherwise not identical to the known authentic software obtained by secure computing at block 506, the remote check value and the local check value will be different.

[0095] It should be understood that FIG. 5 is an example implementation of the techniques described herein, and that method 500 may include fewer or additional blocks in further implementations.

[0096] 6 is a block diagram of an example computing environment 600 including a computing system 602 that can be used to implement systems and methods in accordance with implementations of the present technology. Other components and / or arrangements can also be used. 1-5, such as secure computing device 102 or remote computing device 104 of FIG. 1, among others. In some implementations, a series of computing systems similar to computing system 600 can each be customized with dedicated hardware and / or programmed as a specialized server to implement one of the components of FIGS. 1-5 that can communicate with each other over network 504.

[0097] 6 , computing system 600 includes several components, such as a central processing unit (CPU) 606, memory 608, input / output (I / O) device 610, hardware security module (HSM) 612, and non-volatile storage device 614. System 600 can be implemented in various ways. For example, an implementation as an integrated platform (server, workstation, personal computer, laptop, etc.) can include CPU 606, memory 608, non-volatile storage 614, and I / O device 610. In such a configuration, components 606, 608, 614, and 610 can connect and communicate via a local data bus and can access data repository 616 (e.g., implemented as a separate database system) via an external I / O connection. I / O component 610 can be connected to external devices via a direct communication link (e.g., a wired or local Wi-Fi connection), a network such as a local area network (LAN) or a wide area network (WAN such as a cellular network or the Internet), and / or other suitable connection. System 600 may be standalone or may be a subsystem of a larger system.

[0098] CPU 606 may be one or more known processors or processing devices, such as, for example, the Core® line of microprocessors manufactured by Intel® Corporation of Santa Clara, California, a secure microprocessor including an HSM such as the NXP i.MX8, or the Athlon® line of microprocessors manufactured by AMD® Corporation of Sunnyvale, California. Memory 608 may be one or more high-speed storage devices configured to store instructions and information executed or used by CPU 606 to perform certain functions, methods, and processes related to the implementation of the present technology. Storage 614 may be volatile or non-volatile, magnetic, semiconductor, tape, optical, or other types of storage devices or computer-readable media, including devices such as CDs and DVDs intended for long-term storage, as well as solid-state devices.

[0099] In the illustrated implementation, memory 608 includes one or more programs or applications 618 that, when loaded from storage 614 and executed by CPU 606, perform various operations, procedures, processes, or methods in accordance with the present technology. Alternatively, CPU 606 can execute one or more programs located remotely from system 600. For example, system 600 can access via network 604 one or more remote programs that, when executed, perform functions and processes associated with implementing the present technology.

[0100] In one implementation, memory 608 may include programs 618 for performing the particular functions and operations described herein with respect to secure computing device 102 and / or remote computing device 104. In some implementations, memory 608 may also include other programs or applications that implement other methods and processes that provide ancillary functionality to the present technology. In some 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 CPU 606 to execute instructions in accordance with the techniques described herein.

[0101] Memory 608 may also be configured with other programs (not shown) unrelated to the present technology and / or an operating system (not shown) that performs certain functions well known in the art when executed by CPU 606. By way of example, the operating system may be Microsoft Windows®, Unix®, Linux®, Apple Computer® operating systems, or other operating systems. The choice of operating system and the use of an operating system are also not critical to the present technology.

[0102] The 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 operations. The HSM 612 protects digital security assets such as encryption keys and other sensitive data from access by potential attackers. In some implementations, the HSM 612 may be a plug-in card or board that installs directly into the computing system 600. It is also possible to integrate the HSM 612 into a single-chip microprocessor.

[0103] The I / O device(s) 610 may comprise one or more input / output devices that enable the system 600 to receive and / or transmit data. For example, the I / O device(s) 610 may include one or more input devices that enable the input of data from a user, such as a keyboard, touch screen, mouse, etc. Additionally, the I / O device(s) 610 may include one or more output devices that enable the output or presentation of data to a user, such as a display screen, CRT monitor, LCD monitor, plasma display, printer, speaker device, etc. Additionally, the I / O device(s) 610 may include one or more digital and / or analog communication input / output devices that enable the computing system 600 to digitally communicate with, for example, other machines and devices. Other configurations and / or numbers of input and / or output devices are possible in the I / O device(s) 610. In some examples, the I / O device(s) 610 may be implemented on a single-chip microprocessor.

[0104] In the illustrated implementation, system 600 is connected to a network 604 (such as the Internet, a private network, a virtual private network, a cellular network, or other networks, or a combination thereof), which in turn may be connected to various systems and computing machines, such as servers, personal computers, laptop computers, client devices, etc. In general, system 600 can input data from and output data to external machines and devices via network 604.

[0105] 6, the data repository or data source 616 is a standalone database or file system, or dedicated memory external to the system 600. In other implementations, the data source 616 may be hosted by the system 600. In various implementations, the data source 616 may manage and store data used to implement the systems and methods according to the present technology. For example, the data source 616 may be managed by the HSM 612 or the CPU 606 and store data structures containing software and / or metadata for each remote computing device 104 validated by the system 100. .

[0106] Data source 616 may comprise one or more databases, file systems, or other memory banks that store information and are accessed and / or managed via system 600. By way of example, database 616 may be an Oracle® database, a Sybase® database, or other relational database. However, systems and methods according to the present technology are not limited to distinct data structures or databases, or even to the use of databases or data structures. In some examples, data source 616 may include, among other things, a file system or a flat file.

[0107] Those skilled in the art will appreciate that the system components and implementation details in Figure 6 are examples presented for simplicity and clarity of explanation, and other components and implementation details can be used.

[0108] Although the above examples use specific examples of computerized devices such as an OBU, an ECU, and an RSU for clarity of explanation, the technology is not limited to those specific examples. Various implementations of the technology can be used with and for a wide variety of computerized devices such as medical equipment (e.g., dialysis machines, infusion pumps, etc.), robots, drones, autonomous vehicles, wireless communication modules (e.g., embedded universal integrated circuit cards (eUICCs)), among others.

[0109] Other implementations of the present technology will be apparent to those skilled in the art from consideration of the specification and practice of the technology disclosed herein. Various modifications of the illustrated embodiments, as well as other embodiments of the present technology that are apparent to those skilled in the art to which the disclosed subject matter pertains, are deemed to be within the scope of the disclosed subject matter.

Claims

1. A system for verifying software on a remote computing device (104; 105; 106), optionally on an electronic control unit, comprising: one or more processors (606); a memory device (608) containing one or more computer-readable instructions; It is equipped with The one or more computer-readable instructions, when executed by the one or more processors (606), obtaining a true copy of the software on the remote computing device; sending a verification request to said remote computing device (104; 105; 106) including a random data string; receiving from the remote computing device (104; 105; 106) a remote check value generated by the remote computing device (104; 105; 106) based on the random data string and the software on the remote computing device (104; 105; 106); calculating a local check value based on the authentic copy of the software for 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 with the local check value; A system that causes the system to perform an operation including:

2. the remote check value is generated by the remote computing device (104; 105; 106) using the random data string as a cryptographic key, an additional input, or a combination thereof, for a cryptographic checksum operation that generates the remote check value; Calculating the local check value comprises: calculating the local check value using the random data string as a cryptographic key for the cryptographic checksum operation that generates the local check value; The system of claim 1 , comprising:

3. The system of claim 1 , wherein the random data string is unique to the verification request.

4. 2. The system of claim 1, wherein the operations further include obtaining user data including a device identifier from the remote computing device (104; 105; 106), and the remote check value is optionally generated based on a combination of the software of the remote computing device, the random data string, and the user data from the remote computing device (104; 105; 106), and the operations optionally include calculating the local check value based on a combination of the copy of the software 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 another system that obtained the user data.

5. The encryption operation may be a digital signature operation, a block cipher-based operation, or a cryptographic hash function or block cipher operation using one or more of the cryptographic key, a nonce, and static data.

3. The system of claim 2, further comprising a hash-based message authentication code operation.

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

7. 2. The system of claim 1, wherein the operations further include initiating recovery of the remote computing device (104; 105; 106) in response to a determination 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. 2. The system of claim 1, wherein the actions further include 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) that does not have authentic software.

9. 2. The system of claim 1, wherein the operations further include, in response to a determination that the remote computing device (104; 105; 106) does not have authentic software based on a difference between the remote check value and the local check value in the comparison, sending a command to place the remote computing device (104; 105; 106) in a predetermined error response state.

10. 2. The system of claim 1, wherein the remote computing device includes a storage device that stores the authentic copy of the software, and available space on the storage device that is not used by the authentic copy of the software is filled with random data values ​​up to a predetermined threshold amount or a predetermined capacity of the storage device.

11. 2. The system of claim 1, wherein the operations further include storing metadata indicating a time period for calculation of the remote check value for the remote computing device (104; 105; 106), 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, comprising: Obtaining a true copy of the software on the remote computing device (104; 105; 106); sending a verification request to said remote computing device (104; 105; 106) including a random data string; receiving from the remote computing device (104; 105; 106) a remote check value generated by the remote computing device (104; 105; 106) based on the random data string and the software of the remote computing device (104; 105; 106); a local check based on the authentic copy of the software for the remote computing device (104; 105; 106) and the random data string; calculating a value of determining whether the remote computing device (104; 105; 106) has authentic software based on a comparison of the received remote check value with the local check value; Including, Obtaining user data including a device identifier from said remote computing device (104; 105; 106). Optionally,

13. Initiating recovery of the remote computing device (104; 105; 106) in response to determining that the remote computing device does not have authentic software due to a discrepancy between the remote check value and the local check value. further comprising and in response to determining that the remote computing device (104; 105; 106) does not have authentic software based on a difference between the remote check value and the local check value in the comparison, sending a command to place the remote computing device (104; 105; 106) in a predetermined error response state.

13. The method of claim 12, optionally comprising:

14. the remote check value is generated by the remote computing device (104; 105; 106) using the random data string as a cryptographic key, an additional input, or a combination thereof, for a cryptographic checksum operation that generates the remote check value; Calculating the local check value comprises: calculating the local check value using the random data string as a cryptographic key for the cryptographic checksum operation that generates the local check value; 13. The method of claim 12, comprising:

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

Images