Remote Attestation for Resource-Constrained Devices

Abstract

Ensuring integrity and security of software packages in resource-constrained systems. A method for remote attestation of a resource-constrained system includes obtaining a segment of system data in an authentication device in response to an authentication request, determining the integrity of the system data by identifying whether a root hash consisting of integrity hashes of the segment matches a reference hash, and providing a report according to the integrity.

Description

[Technical Field]

[0001] The subject matter described herein relates generally to systems and methods for remote attestation, and more particularly to using homomorphic hashing to facilitate remote attestation of software on resource-constrained devices. [Background technology]

[0002] Traditionally, vehicle security required vehicle owners to manually lock the doors and / or start the vehicle using a physical key. As technology advances, vehicle systems have evolved into more complex systems that not only include additional functionality but also face additional / different risks. For example, many modern vehicles are equipped with electronic systems capable of collecting data about the vehicle's operation, communicating with remote systems, and receiving / providing electronic control. However, with increasing functionality and connectivity to external networks, the computing systems within the vehicle that provide these advanced functions become vulnerable to attack by malicious actors. For example, malicious actors may attempt to access vehicle systems in order to modify the vehicle's operation or steal sensitive information. Summary of the Invention [Problem to be solved by the invention]

[0003] In particular, various computing systems within a vehicle may contain numerous programs working together to provide the aforementioned functions. To protect these programs, the system may perform remote attestation at the request of a trusted service provider. This arrangement requires the system to collect the data being attested before calculating a comparison value. Therefore, if the data size is larger than the working memory (e.g., buffer, cache), the system cannot efficiently perform the calculation. Furthermore, using remote attestation in a trusted execution environment (TEE) or with other privileged programs with limited memory space can encounter similar issues, such as the inability to calculate a hash value for the data due to its size. The same resource constraints can further limit parallel remote attestation requests, as available memory can be rapidly consumed by a single process. Therefore, ensuring integrity and software package security within resource-constrained systems presents unique challenges that can affect the security of the entire system. [Means for solving the problem]

[0004] Exemplary systems and methods relating to remote attestation for resource-constrained devices are disclosed. As previously discussed, malicious attacks on a vehicle's computing systems can pose significant problems. While some attacks merely reveal sensitive information, other attacks can cause problems with the functionality of various vehicle systems. Furthermore, because various systems are implemented for specific purposes, these systems may have limited resources (e.g., memory) to perform tasks, especially tasks secondary to the system's primary purpose. As such, implementing actual integrity checks and security routines on these devices can pose unique challenges.

[0005] Thus, in one approach, the system of the present invention functions to secure computing systems within devices such as vehicles by using staged hashing (also referred to herein as homomorphic hashing), thereby avoiding the problems that arise when attempting to process all system data at once. For example, the system of the present invention, in various arrangements, periodically performs an authentication process to verify system data, including program code / instructions and associated program data. The system may be prompted to perform authentication pursuant to an authentication request from a remote entity (e.g., a trusted authentication system associated with the OEM) or according to a defined schedule. In either case, the system monitors for authentication requests and proceeds to verify system data upon receipt.

[0006] In particular, a system can pass an authentication request to a trusted program executing within a trusted execution environment (TEE), for example. The system then retrieves a segment of system data, either a predefined size or a dynamically determined size. In the case of a dynamically determined size, the system can determine the size according to the range of memory available within the TEE or another metric. In either approach, the system does not verify the entire system data at once, but instead processes segments of the system data to accommodate the system's limited resources. Furthermore, in one or more configurations, despite operating under limited resources, the system does not affect the normal execution of other programs when performing authentication, and operates in coordination with the execution of other tasks to achieve authentication. In this manner, the trusted program receives the system data as segments and separately generates integrity hashes for the segments. The integrity hash is a digest representing the contents of the segment. Therefore, if the value of a segment is altered, the resulting integrity hash will differ from the hash generated from the original contents.

[0007] The system then further processes the multiple integrity hashes into a single root hash using a homomorphic hash function. The homomorphic hash function effectively combines the integrity hashes into a single hash while aggregating the representations of the segments. As a result, the root hash represents the current state of the system data and whether any changes have been made since the original, trusted version of the system data. Thus, in at least one arrangement, the system can compare the root hash to a reference hash stored in secure storage on the authentication or verification device. The reference hash is a root hash of the previously verified original contents of the system data. Thus, if the root hash and the reference hash match, the system can verify the integrity of the system data. If not, the integrity of the system data is compromised.

[0008] Whichever result the system identifies, the system proceeds to generate a report regarding the authentication. The report may include different information depending on the result. For example, if the system identifies that integrity has been compromised, the report may include an integrity hash along with an indication of the negative result. In a further example, the report may include attribute information about each segment, such as the size of each segment, the memory address range of the segment, and a timestamp for when each integrity hash was generated. Otherwise, the system generates a report indicating that the system data is valid.

[0009] The remote entity authenticating the system receives the report and verifies whether the report indicates that the authentication was successful and the system data is valid and uncorrupted, or whether the report indicates that the authentication failed. If the authentication failed, the remote entity, in at least one arrangement, performs additional functions to verify the results. For example, the remote entity can verify individual segments of the system data to facilitate tracing the cause of the authentication failure. To achieve this, the remote entity hashes a verified version of the original contents of the system data. That is, the remote entity stores a copy of the system data that is known to be valid. The remote entity can then hash segments of the system data stored on the remote entity according to the segment's dynamic or predefined size to generate segment hashes. The segment hashes correspond to the integrity hash generated by the authentication device. In this way, the remote entity compares the segment hashes with the integrity hash provided in the report. This comparison allows the remote entity to identify which segments have been modified.

[0010] The remote entity can then use information about the segments to perform further forensic investigation to identify the cause of the modification (e.g., a specific malicious attack) and can also provide mitigation instructions to the authentication device. The remote entity communicates the mitigation instructions to the authentication device in a report, acknowledgment, or other communication to cause the authentication device to undertake one or more mitigation actions. Mitigation actions may include restoring system data to a known valid state, disabling at least a portion of the authentication device to prevent further malicious modification, or other actions intended to thwart malicious attacks against the authentication device. In this manner, this approach can improve the security of resource-limited devices by ensuring the ability to perform authentication and identify malicious modification of system data when it occurs.

[0011] In one embodiment, a security system is disclosed. The security system includes one or more processors and a memory communicatively coupled to the one or more processors. The memory stores a control module including instructions that, when executed by the one or more processors, cause the one or more processors to retrieve a segment of system data in an authentication device in response to an authentication request. The control module includes instructions for determining the integrity of the system data by identifying whether a root hash consisting of integrity hashes of the segments matches a reference hash. The control module includes instructions for providing a report in response to the integrity.

[0012] In one embodiment, a non-transitory computer-readable medium is disclosed. The computer-readable medium stores instructions that, when executed by one or more processors, cause the one or more processors to perform the disclosed functions. The instructions include instructions for obtaining a segment of system data in an authentication device in response to an authentication request. The instructions include instructions for determining the integrity of the system data by identifying whether a root hash consisting of integrity hashes of the segment matches a reference hash. The instructions include instructions for providing a report depending on the integrity.

[0013] In one embodiment, a method is disclosed. The method includes obtaining a segment of system data in an authentication device in response to an authentication request. The method includes determining the integrity of the system data by identifying whether a root hash consisting of integrity hashes of the segment matches a reference hash. The method includes providing a report in response to the integrity. [Brief explanation of the drawings]

[0014] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various systems, methods, and other embodiments of the present disclosure. It will be understood that the boundaries of elements shown in the figures (e.g., boxes, groups of boxes, or other shapes) represent one embodiment of the boundaries. In some embodiments, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some embodiments, an element shown as an internal component of another element may be implemented as an external component, or vice versa. Additionally, elements may not be drawn to scale.

[0015] [Figure 1] FIG. 1 illustrates one embodiment of a vehicle configuration in which exemplary systems and methods may be implemented. [Figure 2]FIG. 2 illustrates one embodiment of a security system related to using staged hashing to support remote attestation in resource-constrained environments. [Figure 3] FIG. 3 is a flow chart illustrating one embodiment of a method for performing authentication in a resource-constrained device. [Figure 4] FIG. 4 shows a system flow diagram of the functions performed by the individual entities involved in remote attestation. [Figure 5] Figure 5 shows a diagram of the Trusted Execution Environment (TEE) and the associated functions that run there. [Figure 6] FIG. 6 is a flow chart illustrating one embodiment of a method for requesting authentication and verifying the results of remote authentication. [Figure 7] FIG. 7 is a flow chart illustrating a method for performing remote attestation by a remote device. [Figure 8] FIG. 8 is a diagram illustrating an example of remote attestation. DETAILED DESCRIPTION OF THE INVENTION

[0016] Systems, methods, and other embodiments related to remote attestation of resource-constrained devices are disclosed. As previously discussed, malicious attacks on a vehicle's computing systems can pose significant problems. While some attacks simply reveal sensitive information, other attacks can cause problems with the functionality of various vehicle systems. Furthermore, because various systems are implemented for specific purposes, these systems may have limited resources (e.g., memory) to perform tasks, especially tasks secondary to the system's primary purpose. As such, implementing security routines in these devices can present unique challenges.

[0017] Thus, in one approach, the system of the present invention functions to secure computing systems within a vehicle by using staged hashing (also referred to herein as homomorphic hashing), thereby avoiding the problems that arise when attempting to process all system data at once. For example, the system of the present invention periodically performs an authentication process to verify system data, including program code and associated program data. The system may be prompted to perform authentication pursuant to an authentication request from a remote entity (e.g., a trusted authentication system associated with the OEM) or according to a defined schedule. In either case, the system monitors for authentication requests and proceeds to verify system data upon receipt.

[0018] In particular, the system can pass an authentication request to a trusted program executing within a trusted execution environment (TEE), for example. The system then retrieves segments of system data, either of a predefined size or a dynamically determined size. In the case of a dynamically determined size, the system can determine the size according to the range of memory available within the TEE, system memory load, network load, CPU load, or another metric. In either approach, the system does not verify the entire system data at once; instead, it processes segments of the system data to accommodate the system's limited resources. In this way, the trusted program receives the system data as segments and individually generates integrity hashes for the segments. The integrity hash is a digest representing the contents of the segment. Therefore, if the value of a segment is changed, the resulting integrity hash will differ from the hash generated from the original content.

[0019] The system then further processes the multiple integrity hashes into a single root hash using a homomorphic hash function. The homomorphic hash function effectively combines the integrity hashes into a single hash while aggregating the representations of the segments. As a result, the root hash represents the current state of the system data and whether any changes have been made since the original, trusted version of the system data. Thus, in at least one arrangement, the system can compare the root hash to a reference hash stored in secure storage on the authentication device. The reference hash is the root hash of the original contents of the system data. Thus, if the root hash and the reference hash match, the system can verify the integrity of the system data. If not, the integrity of the system data is compromised.

[0020] Whichever result the system identifies, it proceeds to generate a report on the authentication. The report may include different information depending on the result. For example, if the system identifies that integrity has been compromised, the report may include an integrity hash along with an indication of the negative result. The report may also include other security-related information, such as system events, inspection records, authentication and access logs. Otherwise, the system generates a report indicating that the system data is valid.

[0021] The remote entity authenticating the system receives the report and verifies whether the report indicates that the authentication was successful and the system data is valid and uncorrupted, or whether the report indicates that the authentication failed. If the authentication failed, the remote entity, in at least one arrangement, performs additional functions to verify the results. For example, the remote entity can verify individual segments of the system data to facilitate tracing the cause of the authentication failure. To achieve this, the remote entity hashes a verified version of the original contents of the system data. That is, the remote entity stores a copy of the system data that is known to be valid. The remote entity can then hash segments of the system data stored on the remote entity according to the segment's dynamic or predefined size to generate segment hashes. The segment hashes correspond to the integrity hash generated by the authentication device. In this way, the remote entity compares the segment hashes with the integrity hash provided in the report. This comparison allows the remote entity to identify which segments have been modified.

[0022] The remote entity can then use information about the segments to perform further forensic investigation to identify the cause of the modification (e.g., a specific malicious attack) and can also provide mitigation instructions to the authentication device. The remote entity communicates the mitigation instructions to the authentication device in a report, acknowledgment, or other communication to cause the authentication device to undertake one or more mitigation actions. Mitigation actions may include restoring system data to a known valid state, disabling at least a portion of the authentication device to prevent further malicious modification, or other actions intended to thwart malicious attacks against the authentication device. In this manner, this approach can improve the security of resource-limited devices by ensuring the ability to perform authentication and identify malicious modification of system data when it occurs.

[0023] Referring to FIG. 1 , an example of a vehicle 100 is shown. As used herein, “vehicle” refers to any form of motorized transportation. In one or more embodiments, vehicle 100 is an automobile. While arrangements are described herein with respect to automobiles, it will be understood that embodiments are not limited to automobiles. In some embodiments, vehicle 100 may instead be an electronic device associated with transportation infrastructure (e.g., a roadside unit), a cloud-based system that communicates with mobile devices, or other devices that implement electronic systems potentially vulnerable to malicious attacks and therefore may benefit from the functionality described herein.

[0024] Vehicle 100 also includes various elements. It will be understood that in various embodiments, vehicle 100 may not include all of the elements shown in FIG. 1 . Vehicle 100 can have different combinations of the various elements shown in FIG. 1 . Furthermore, vehicle 100 can include elements in addition to those shown in FIG. 1 . In some arrangements, vehicle 100 may be implemented without one or more of the elements shown in FIG. 1 . While various elements are shown in FIG. 1 as being located within vehicle 100, it will be understood that one or more of these elements may be located external to vehicle 100. Furthermore, the illustrated elements may be provided, at least in part, as a remote service (e.g., a cloud computing service) that is physically remote.

[0025] Some of the possible elements of vehicle 100 are shown in FIG. 1 and described in conjunction with subsequent figures. Many of the elements in FIG. 1 will be described after the description of FIGS. 2-8 for brevity. Additionally, it will be understood that, where appropriate, reference numerals have been repeated in different figures to indicate corresponding, similar, or like elements for brevity and clarity. Furthermore, it will be understood that the embodiments described herein may be implemented using various combinations of the described elements.

[0026] In either case, vehicle 100 includes security system 170, which functions to improve the security of vehicle 100 by implementing a process to perform authentication to better protect system data against malicious attacks, particularly in resource-constrained environments. Furthermore, while security system 170 is depicted as a standalone component, in one or more embodiments, it is integrated with other systems in vehicle 100 to facilitate improved security of system / module functions related to autonomous driving and / or other control of vehicle 100. The described functions and methods will become more apparent with further description of the figures. Additionally, it should be understood that, as described herein, various functions are described as being performed by an authentication device and other functions are described as being performed by a remote entity that may request authentication. In this arrangement, security system 170 may be implemented as separate instances within the associated devices. Thus, the description of security system 170 may include distributed instances functioning in separate roles.

[0027] 2, one embodiment of security system 170 is further illustrated. As shown, security system 170 includes processor 110. As such, processor 110 may be a part of security system 170, or security system 170 may access processor 110 via a data bus or another communication path. In one or more embodiments, processor 110 is an application-specific integrated circuit configured to implement the functionality associated with control module 220. More generally, in one or more aspects, processor 110 is an electronic processor, such as a microprocessor, that, when executing encoded functions associated with security system 170, may perform various functions described herein. Furthermore, processor 110 or another electronic processing unit associated with security system 170 executes various programs (also referred to herein as software components and / or instructions) for securing / protecting security.

[0028] In various embodiments, the specific functionality of the program may vary but may include automated driving functions (e.g., ADAS functions, machine perception, mapping, object detection / identification, path planning, vehicle control routines, etc.), functions related to the control of vehicle 100, execution of infotainment systems within vehicle 100, operating systems and related components, etc. As such, various aspects of the program may relate to the functional safety of vehicle 100, sensitive / private information, system operation, etc., and may be targeted by attackers due to the sensitive / sensitive information associated therewith. Furthermore, it should be understood that the program itself may be structured in various ways but is typically comprised of multiple segments. Segments include data elements (e.g., variables) and various functions (i.e., code blocks associated with performing a particular function). Additionally, programs / software components, in at least one arrangement, are comprised of static data elements. Static data elements include aspects such as source files, text files, etc.

[0029] Additionally, while programs are generally described in functional terms, it should be understood that programs can take a variety of forms. That is, programs can include firmware, operating systems, applications, etc. In either case, as described herein, the programs and associated data form the system data (e.g., system data 240) described herein. As described in more detail below, system data 240 can be divided into segments of a particular size. Security system 170 can define the size dynamically, for example, according to the state of security system 170 or other devices, or can define the size as a predefined size (e.g., packet payload size, buffer size, etc.).

[0030] Continuing with the description of the elements of security system 170, in one embodiment, security system 170 includes a control module 220 and, in various configurations, memory 210 that stores additional elements (e.g., system data 240). Memory 210 may be random access memory (RAM), read-only memory (ROM), a hard disk drive, flash memory, or other suitable memory for storing module 220. In either case, control module 220 is computer-readable instructions that, when executed by processor 110, cause processor 110 to perform various functions disclosed herein. While in one or more embodiments, module 220 is instructions embodied in memory 210, in further aspects, module 220 includes hardware, such as a processing component (e.g., a controller), circuitry, or the like, for independently performing one or more of the described functions. As such, control module 220 may be embodied as instructions in memory 210 or as a standalone component, such as a system-on-chip (SoC), an ASIC, or another electronic device. Additionally, control module 220 may be further embodied in separate instances, such as an instance within vehicle 100 and an instance within a remote device, such as a cloud-based monitoring service or another vehicle. As described in more detail below, the remote device may be another entity that exchanges information with vehicle 100 to thereby verify the integrity of vehicle 100. Similarly, the remote device may be a cloud-based resource, such as an OEM's security monitoring service, responsible for maintaining the security of the manufacturer's vehicles.

[0031] Additionally, in one embodiment, security system 170 includes data store 230, which in one arrangement is an electronic-based data structure for storing information. For example, in one approach, data store 230 is a database stored in memory 210 or another suitable electronic storage medium (e.g., RAM, on-chip cache, etc.) and comprised of routines that can be executed by processor 110 to analyze the stored data, present the stored data, organize the stored data, etc. In either case, in one arrangement, data store 230 stores data used by control module 220 in performing various functions. In one embodiment, data store 230 includes, for example, system data 240 and reports 250, along with other information used by control module 220.

[0032] Additionally, processor 110 can include a trusted execution environment (TEE). The TEE, in at least one configuration, is a secure area of ​​processor 110 in which executing instructions (i.e., trusted programs) and associated data are protected and integrity maintained by the TEE, preventing malicious modification. Generally, the integrity of instructions and data within the TEE is related to the confidentiality of the TEE, which prevents entities outside the TEE from reading the data and / or modifying the instructions. The TEE can implement an immutable architecture for security, such as Software Guard Extensions (SGX), Secure Encryption Virtualization (SEV), TrustZone, or another secure architecture for authorizing the TEE. In either case, the TEE enables security system 170 to execute instructions in a protected area that prevents malicious modification, even if other aspects of security system 170 (e.g., system data) are maliciously modified.

[0033] Regarding the functionality of the control module 220, generally, the control module 220 includes instructions that function to control the processor 110 to verify the system data 240 in response to an authentication request. The system data 240 is typically the memory contents of a device's memory and includes program instructions, file configurations, logs, data objects, and other information used by a program during execution. The control module 220 hashes segments of the system data 240 to generate a representation of the segment as an integrity hash. As previously described, the control module 220 receives the system data 240 in chunks / segments of a specific size. The control module 220 can determine the size of the segments and control how the segments are obtained. The control module 220 can determine a predefined size according to the size of a buffer / cache or other memory (e.g., working memory associated with the control module 220), a protocol's defined transmission size (e.g., TCP packet payload size), or another attribute of the system 170 that defines the working memory of the control module 220. Alternatively, the control module 220 dynamically defines the size of the segments. In this approach, control module 220 can communicate with the process providing the segment to adapt the size depending on the current state of system 170. For example, control module 220 can adjust the size depending on available memory, such as the remaining amount of working memory in the TEE where control module 220 performs hashing and verification. As a further example, control module 220 may dynamically determine the size depending on other running processes in order to share available resources.

[0034] In either case, the control module 220 applies a cryptographic hash function (e.g., MD4, MD5, SHA-1, SHA-2, etc.) or a homomorphic hash function (e.g., LtHash, MuHash, AdHash, etc.) to the segments to derive an integrity hash. Once the control module 220 has generated the integrity hashes for the individual segments, the control module 220 can proceed to generate a root hash that collectively represents the integrity hashes. In at least one approach, the control module 220 generates the root hash using homomorphic hashing. Homomorphic hashing is a hashing algorithm such as LtHash, MuHash, or AdHash. Typically, the control module 220 generates the root hash by summing the hashes of all the segments. The control module 220 repeatedly performs a hashing process on the integrity hashes until they are combined to form the root hash. The control module 220 can use the root hash to compare with a reference hash formed in the same manner as the root hash, but from a known valid copy of the system data. In this way, the control module 220 can verify the system data 240.

[0035] Additional aspects of security system 170 and authentication requests are described in connection with subsequent figures. In any event, it should be understood that security system 170 generates hashes to verify and attest to the integrity of system data 240 on vehicle 100. In this manner, security system 170 can verify that software is valid and uncorrupted, thereby facilitating information exchange with remote devices (i.e., relying parties) by verifying that system data 240 has not been compromised and will not harm the remote device during the information exchange.

[0036] Additional aspects for protecting a vehicle's electronic systems from malicious attacks are described in connection with Figure 3. Figure 3 illustrates a method 300 related to performing remote attestation in a resource-constrained environment. Method 300 is described in terms of security system 170 of Figures 1 and 2. While method 300 is described in conjunction with security system 170, it should be understood that method 300 is not limited to being implemented within security system 170, but is merely one example of a system in which method 300 may be implemented.

[0037] At 310, the control module 220 monitors for authentication requests. The authentication requests may be generated automatically within the system 170 or may be received from a remote entity. For example, the remote entity generates the authentication request as a periodic monitoring function to continuously check the vehicle 100 for integrity. In a further example, the remote entity generates the authentication request when it connects with the vehicle 100 to provide services and / or receive information from the vehicle 100. Generally, the authentication request and subsequent verification serves as a way for the remote entity to verify the integrity of the vehicle 100. Alternatively, or additionally, the security system 170 generates internal requests according to a schedule. The schedule can define regular or irregular intervals for performing authentication. In at least one arrangement, the schedule defines a condition or event for triggering the authentication request, such as the occurrence of a connection request with another device, a specific program action, a timer, etc. In either case, the format of the authentication request itself may vary depending on the embodiment, but generally includes a generic request for security system 170 to initiate authentication, and may further include verification information about the requesting party, such as a signed digital certificate or other cryptographic elements to verify the identity of the source, and a freshness value, such as a counter or nonce, to avoid replay of old valid requests. In this manner, control module 220 monitors for authentication requests at 310 and proceeds with subsequent actions upon identifying the receipt of an authentication request.

[0038] At 320, the control module 220 retrieves segments of system data 240 in response to the authentication request. Generally, the control module 220 collects the segments according to a segment size. As previously described, the segment size can be predefined or dynamically determined. Note that, in one or more configurations, the process of performing authentication, as described at 320-380, occurs within the trusted execution environment (TEE) of the authentication device. For example, the authentication request and segments of data are passed to the TEE. The security system 170 and / or the TEE may be resource-constrained systems. That is, the system may have limited memory and / or other computational resources for performing authentication. Nevertheless, in one or more embodiments, the constrained system can collect / process data during authentication without having to pause execution of functions within the system's main execution environment. Otherwise, the constrained system works in cooperation with the system's main execution environment to collect and process data. Therefore, performing authentication on segments rather than the entire system data 240 allows the security system 170 to perform authentication more efficiently and avoid memory overflow issues.

[0039] At 330, the control module 220 generates a consistent hash of the segment according to a cryptographic or homomorphic hash function. Typically, the control module 220 generates the consistent hash individually as the segment is received, for example, within the TEE. The control module 220 performs the hash repeatedly as each segment is received.

[0040] At 340, control module 220 determines whether all segments have been hashed. If there are remaining segments, control module 220 proceeds to 330 to hash more segments and repeat this process until the last segment is identified. In one or more arrangements, control module 220 determines that all segments have been hashed according to a flag or other indicator received with the last segment. That is, system data 240 itself and / or a packet encapsulating a segment of system data 240 includes an indicator that the segment is the last segment of system data 240. If embedded as part of system data 240, the indicator may be buffer or padding bits that are simply appended to system data 240 if the segment does not fill a particular chunk / segment size.

[0041] At 350, the control module 220 uses the consistency hashes to generate a root hash according to a homomorphic hash function. That is, the control module 220 combines the consistency hashes using the homomorphic hash function to generate a single value that represents the current state of the entire system data 240. In this way, the control module 220 provides a single value that characterizes the system data 240.

[0042] At 360, the control module 220 determines the integrity of the system data by comparing the root hash to the reference hash. The reference hash is a hash formed in a similar manner to the root hash, but is a hash of the system data 240 at a time when the state of the system data 240 is known to be valid and uncorrupted. As such, the reference hash is used as a comparison to the known valid state of the system data 240. Identifying whether the root hash matches the reference hash then indicates whether the integrity of the system is valid or invalid. The validity indicated by the hash generally indicates whether a segment has been unauthorizedly altered, for example, by a malicious attack.

[0043] At 370, the control module 220 generates a report regarding the results of the comparison. The report may include different information depending on the results of the comparison. For example, if the control module 220 determines that the system data 240 is valid and its integrity is not compromised, the control module 220 generates a report that includes an indicator of the positive result and may further include a copy of the root hash as confirmation. However, if the result is negative, the control module 220 generates a report that includes a negative indicator along with the integrity hashes of the segments. By providing the integrity hashes, the system enables remote entities to perform forensic examination of the system data 240, as described further below.

[0044] At 380, the control module 220 provides a report responsive to the consistency. The control module 220 provides the report by communicating the report to the remote entity (i.e., the requesting device) via a communication channel, such as the Internet. After providing the report, the control module 220 can monitor for a subsequent confirmation communication from the remote entity. The response confirmation communication can include various information depending on the result. For example, a positive report may prompt the creation of a direct link / connection for exchanging information with the remote entity, and information about that connection may be included in the confirmation communication. If the report is negative, the confirmation communication can be a mitigation message that specifies a mitigation action to be taken by the security system 170. The mitigation message is configured to cause the verification device to perform the mitigation action. The mitigation action can be a different action or set of actions depending on the embodiment. Generally, the mitigation action is designed to remediate or at least mitigate further damage from the malicious attack. As an example, the mitigation action can include restoring the verification device's memory (i.e., system data 240), disabling at least a portion of the verification device (i.e., one or more systems in the vehicle 100), or another mitigation action.

[0045] For further explanation of the verification process, reference is made to Figures 4 and 5. Figure 4 illustrates an exemplary process flow 400 between a remote entity 405 and a vehicle 100, with the security system 170 performing authentication. As shown, the remote entity 405 sends a remote authentication request to initiate the authentication process. The vehicle 100 receives the request or initiates authentication according to a defined schedule. In either case, the request is forwarded to a trusted execution environment (TEE) 410. Figure 5 further illustrates the TEE 410. Figure 5 illustrates a method 300 performed within the TEE 410. For simplicity, the method 300 is shown in an abbreviated form. However, the illustration of the method 300 is not intended to be limiting and is merely illustrative of the method's execution within the environment of the TEE 410.

[0046] In either case, the TEE 410 includes a secure storage 500 that stores a reference hash 505. The comparison performed by the method 300 uses the reference hash 505 to verify the root hash generated from the system data 240. An authentication report is then generated within the TEE 410 and provided by the TEE 410. Returning to FIG. 4 , the vehicle 100 receives the authentication report and transmits it to the remote entity 405. The remote entity 405 proceeds to receive the authentication report and determine whether the authentication is complete with successful verification of the vehicle 100 or whether the verification failed. If unsuccessful, the remote entity 405 (i.e., the instance of the security system 170 running on the remote entity 405) proceeds to recreate an integrity hash in the form of segment hashes (identified as leaf hashes in FIG. 4 ) and compares those segment hashes with the integrity hash received from the vehicle 100. From this comparison, the remote entity 405 can identify areas of the system (i.e., segments of system data 240) that have been tampered with and, in at least one arrangement, perform mitigation or other actions (e.g., analysis, additional forensic investigation, etc.).

[0047] Additional aspects related to the use of remote attestation are described in connection with FIG. 6. FIG. 6 illustrates a method 600 related to requesting authentication and verifying the results of the authentication. Method 600 is described in terms of security system 170 of FIG. 2. While method 600 is described in conjunction with security system 170, it should be understood that method 600 is not limited to being implemented within security system 170, but rather is an example of a system in which method 600 may be implemented. Additionally, as illustrated in FIG. 6, method 600 is performed at a remote entity 405 that generates an authentication request to validate vehicle 100.

[0048] At 610, the remote entity generates and transmits an authentication request. In one arrangement, the remote entity generates the authentication request as a periodic monitoring function to check the ongoing integrity of vehicle 100. In a further example, the remote entity generates the authentication request when connecting with vehicle 100 to provide services and / or receive information from vehicle 100. Generally, the authentication request and subsequent verification serves as a way for the remote entity to verify the integrity of vehicle 100. The format of the authentication request itself may vary depending on the embodiment, but typically includes a generic request for the root hash of vehicle 100 and may further include verification information about the requesting party, such as a signed digital certificate or other cryptographic elements to verify the identity of the source.

[0049] At 620, the remote entity monitors for a response from the authentication device. For example, the control module 220 of the remote entity monitors for a communication from the authentication device responding to the original authentication request. If received, the control module 220 proceeds with method 600 by processing the response. Otherwise, monitoring continues.

[0050] At 630, the control module 220 parses the response from the authentication device to determine whether the authentication failed. Typically, the response includes information indicating the result, such as a flag or other identifier. In one arrangement, if the authentication failed, the response includes an integrity hash, which may also serve as a broad indicator of the result. In yet another arrangement, the response may also include a root hash and / or other information regarding the result. In either case, if the control module 220 determines that the authentication was successful, the control module 220 proceeds to generate a report, as described at 660. If the control module 220 determines that the authentication failed, the control module 220 performs additional functions, as described at 640-650.

[0051] At 640, the control module 220 proceeds to generate a segment hash from the verified version of the system data 240. The verified version of the system data 240 is a known, valid copy of the system data 240 stored at a remote entity. Therefore, the verified version should match the system data 240 stored at the vehicle 100. However, because the verification failed, the remote entity can instead use the locally stored, verified version to track the integrity error. In this way, the control module 220 generates the segment hash as a natural result of the integrity hash from the vehicle 100, but does so using known, valid information to provide a valid comparison point.

[0052] At 650, the control module 220 in the remote entity identifies the integrity failure from the hash tracking. Generally, the remote entity compares the segment hashes with the integrity hashes from the response by the vehicle 100 to determine the cause of the integrity failure (i.e., the specific segment that was changed). As part of identifying the cause of the failure, the remote entity may log the failure by saving information about the segment and additional information about the vehicle 100, such as geographic location, make / model / year, etc.

[0053] At 660, control module 220 generates a report regarding the authentication. That is, if authentication is successful, in one arrangement, control module 220 generates a report indicating successful authentication, which report may include a copy of the root hash provided by vehicle 100, and the copy of the root hash may be logged when the report is provided at 670. However, if authentication is unsuccessful, the remote entity generates the report, at least in part, as a communication to vehicle 100. That is, the remote entity may mitigate the integrity failure from the attack by deploying mitigation in the form of one or more mitigation actions identified in the report. Control module 220 may also record the cause of the integrity failure in its retained copy of the report and / or append other security-related log files obtained from vehicle 100.

[0054] At 670, the remote entity provides a report. The remote entity may provide the report by logging the report to a local authentication log and / or by communicating the report to vehicle 100. The remote entity may communicate the report to vehicle 100 as a deployment of a mitigation to correct the fault or at least prevent further damage. For example, a deployment of a mitigation is a control communicated to vehicle 100 that causes vehicle 100 to perform one or more mitigation actions. The actions may include restoring a software component to a previous state using a system image, instantiating a fail-safe mode within vehicle 100, or performing another action to repair the fault. Although a deployment of a mitigation is described as a control, the deployment may further include one or more files (e.g., images) that vehicle 100 uses when performing the mitigation.

[0055] The control module 220 in the vehicle 100 mitigates the integrity failure caused by the attack according to the deployment of the mitigation measures. That is, the vehicle 100 performs one or more actions to fix the integrity failure, either using existing functionality or through an executable file provided by a remote device. In this way, the security system 170 can use homomorphic hashing to protect the vehicle 100 and track failures as they occur, thereby improving the operation and robustness of the associated computing systems against attacks.

[0056] 7 illustrates an example remote entity 700 and the functions performed thereon to verify reports provided by vehicle 100. As shown, remote entity 405 performs a version of method 600, which is shown in an abbreviated form. In either case, remote entity 405 performs a different set of functions depending on the outcome of the authentication within vehicle 100. In particular, remote entity 405 uses hashes of segments provided by vehicle 100 when a failure occurs to identify tampered / compromised segments within vehicle 100.

[0057] A further example 800 is shown in FIG. 8 . Example 800 illustrates a process for performing authentication at vehicle 100 and verifying the results with remote entity 405. For example, as shown, vehicle 100 performs authentication and identifies that the hash calculated by the system does not match a known good hash. In that case, the vehicle generates an authentication report that includes the hash of the segment, along with the size of the segment / chunk, a failure indicator, etc. The vehicle 100 sends the report to remote entity 405. Remote entity 405 stores known good hashes (i.e., reference hashes) and can also generate segment hashes related to the reference hashes. The remote entity can then compare the integrity hash of the segment from vehicle 100 with the locally generated hash of the segment and, by comparing them, identify which segments have been modified / tampered with. As shown in example 800, it is discovered that the two segments do not match. In this way, security system 170 can maintain security throughout the authentication process while respecting system resource constraints by accommodating various segment sizes and enabling tracking of integrity failures, thereby improving the security of the implemented device.

[0058] Additionally, it should be understood that security system 170 of FIG. 1 can be configured in various arrangements using separate integrated circuits and / or electronic chips. In such an embodiment, control module 220 is embodied as a separate integrated circuit. The circuits are connected via connection paths, allowing signals to be communicated between the separate circuits. Of course, while separate integrated circuits are discussed, in various embodiments, the circuits may be integrated onto a common integrated circuit and / or integrated circuit substrate. Furthermore, the integrated circuits may be combined into fewer integrated circuits or split into more integrated circuits. In further embodiments, some of the functionality associated with module 220 may be embodied as firmware executable by a processor and stored in non-transitory memory. In yet another embodiment, module 220 is integrated as a hardware component of processor 110.

[0059] In other embodiments, the described methods and / or their equivalents may be implemented using computer-executable instructions. For example, in one embodiment, a non-transitory computer-readable medium is configured having stored thereon computer-executable instructions that, when executed by a machine (e.g., a processor, a computer, etc.), cause the machine (and / or associated components) to perform a method.

[0060] For ease of explanation, the methods illustrated in the figures are shown and described as a series of blocks; however, it should be understood that the methods are not limited to the order of the blocks, as some blocks may occur in a different order than shown and described and / or concurrently with other blocks. Furthermore, fewer than all of the blocks shown may be used to implement the illustrated methods. Blocks may be combined or separated into multiple components. Furthermore, additional and / or alternative methods may use additional blocks not shown.

[0061] FIG. 1 will now be described in detail as an example environment in which the systems and methods disclosed herein may operate. In some cases, vehicle 100 is configured to be selectively switched between an autonomous mode, one or more semi-autonomous operating modes, and / or a manual mode. Such switching may be performed in any suitable manner. "Manual mode" means that all or most of the driving and / or operation of the vehicle is performed according to inputs received from a user (e.g., a human driver).

[0062] In one or more embodiments, vehicle 100 is an autonomous vehicle. As used herein, "autonomous vehicle" refers to a vehicle operating in an autonomous mode. "Autonomous mode" refers to navigating and / or maneuvering vehicle 100 along a travel path using one or more computing systems that control vehicle 100 with minimal or no input from a human driver. In one or more embodiments, vehicle 100 is fully automated. In one embodiment, vehicle 100 is configured to have one or more semi-autonomous modes of operation, where one or more computing systems perform a portion of the navigation and / or maneuvering of vehicle 100 along a travel path, and a vehicle operator (i.e., driver) provides input to the vehicle to perform a portion of the navigation and / or maneuvering of vehicle 100 along a travel path. Such semi-autonomous operation may include supervisory control implemented by security system 170 to ensure vehicle 100 remains within defined state constraints.

[0063] Vehicle 100 may include one or more processors 110. In one or more arrangements, processor 110 may be the main processor of vehicle 100. For example, processor 110 may be an electronic control unit (ECU). Vehicle 100 may include one or more data stores 115 (e.g., data store 230) for storing one or more types of data. Data store 115 may include volatile memory and / or non-volatile memory. Examples of suitable data stores 115 include RAM (random access memory), flash memory, ROM (read-only memory), PROM (programmable read-only memory), EPROM (erasable programmable read-only memory), EEPROM (electrically erasable programmable read-only memory), registers, magnetic disks, optical disks, hard drives, or other suitable storage media, or any combination thereof. Data store 115 may be a component of processor 110, or data store 115 may be operably connected to processor 110 for use by the processor. As used throughout this specification, the terms "operably connected" or "communicatively connected" include direct or indirect connections, including connections without direct physical contact.

[0064] In one or more arrangements, one or more data stores 115 may include map data. The map data may include maps of one or more geographic areas. In some cases, the map data may include information (e.g., metadata, labels, etc.) about roads, traffic control devices, road markings, structures, features, and / or landmarks within the one or more geographic areas. In some cases, the map data may include aerial photographs or satellite imagery. In some cases, the map data may include ground views of areas, including 360-degree ground views. The map data may include measurements, dimensions, distances, and / or information of one or more items included in the map data and / or related to other items included in the map data. The map data may include digital maps including information about road geometry. The map data may further include feature-based map data, such as information about the relative positions of buildings, curbs, posts, etc. In one or more arrangements, the map data may include one or more terrain maps.

[0065] One or more data stores 115 may contain sensor data. In this context, "sensor data" means any information from sensors equipped on vehicle 100, including the functionality and other information of such sensors.

[0066] As described above, vehicle 100 can include sensor system 120. Sensor system 120 can include one or more sensors. A "sensor" refers to any device, component, and / or system that can detect, perceive, and / or sense something. One or more sensors can be configured to operate in real time. As used herein, the term "real time" refers to a level of processing responsiveness that a user or system perceives as sufficiently immediate to a particular process or decision being made, or that allows a processor to respond without being sent to some external process.

[0067] In an arrangement in which sensor system 120 includes multiple sensors, the sensors may operate independently of one another. Alternatively, two or more sensors may operate in combination with one another. In such cases, the two or more sensors may form a sensor network. Sensor system 120 and / or one or more sensors may be operatively connected to processor 110, data store 115, and / or another element of vehicle 100 (including any of the elements shown in FIG. 1). Sensor system 120 may acquire data of at least a portion of the environment external to vehicle 100.

[0068] The sensor system 120 may include any suitable type of sensor. Various examples of different types of sensors are described herein. However, it will be understood that embodiments are not limited to the particular sensors described. The sensor system 120 may include one or more vehicle sensors 121. The vehicle sensors 121 may detect, determine, and / or sense information about the vehicle 100 itself or the interior of the vehicle 100. In one or more arrangements, the vehicle sensors 121 may be configured to detect and / or sense changes in the position and orientation of the vehicle 100, such as based on inertial acceleration. In one or more arrangements, the vehicle sensors 121 may include one or more accelerometers, one or more gyroscopes, an inertial measurement unit (IMU), a dead reckoning system, a global navigation satellite system (GNSS), a global positioning system (GPS), a navigation system, and / or other suitable sensors. The vehicle sensors 121 may be configured to detect and / or sense one or more characteristics of the vehicle 100. In one or more arrangements, the vehicle sensors 121 may include a speedometer for determining the current speed of the vehicle 100. Additionally, vehicle sensors 121 may include sensors throughout the passenger compartment, such as pressure / weight sensors in the seats, seat belt sensors, cameras, etc.

[0069] Alternatively, or in addition, sensor system 120 may include one or more environmental sensors 122 configured to acquire and / or sense driving environment data. "Driving environment data" includes data or information regarding the external environment in which the autonomous vehicle is located, or one or more portions thereof. For example, one or more environmental sensors 122 may be configured to detect and / or sense obstacles and / or information / data regarding such obstacles in at least a portion of the external environment of vehicle 100. Such obstacles may be stationary and / or dynamic objects. One or more environmental sensors 122 may be configured to detect and / or sense other objects in the external environment of vehicle 100, such as, for example, lane markings, signs, traffic lights, traffic signals, lane markings, crosswalks, curbs near vehicle 100, off-road objects, etc.

[0070] Various examples of sensors for sensor system 120 are described herein. Exemplary sensors may be part of one or more environmental sensors 122 and / or one or more vehicle sensors 121. However, it will be understood that embodiments are not limited to the particular sensors described. By way of example, in one or more arrangements, sensor system 120 may include one or more radar sensors, one or more LIDAR sensors, one or more sonar sensors, and / or one or more cameras. In one or more arrangements, one or more cameras may be high dynamic range (HDR) cameras or infrared (IR) cameras.

[0071] Vehicle 100 may include an input system 130. An "input system" includes, but is not limited to, any device, component, system, element, arrangement, or group thereof that allows information / data to be input into a machine. Input system 130 may receive input from an occupant of the vehicle (e.g., an operator or passenger). Vehicle 100 may include an output system 140. An "output system" includes any device, component, arrangement, or group thereof that allows information / data to be presented to an occupant of the vehicle (e.g., a person, a vehicle occupant, etc.).

[0072] Vehicle 100 may include one or more vehicle systems 150. Various examples of one or more vehicle systems 150 are shown in FIG. 1 . However, vehicle 100 may include different combinations of systems than those shown in the given example. In one example, vehicle 100 may include a propulsion system, a braking system, a steering system, a throttle system, a transmission system, a signal system, a navigation system, etc. These systems, separately or in combination, may include one or more devices, components, and / or combinations thereof.

[0073] As an example, a navigation system may include one or more devices, applications, and / or combinations thereof configured to determine the geographic location of vehicle 100 and / or determine a route for vehicle 100. A navigation system may include one or more mapping applications for determining a route for vehicle 100. A navigation system may include a global positioning system, a local positioning system, or a geolocation system.

[0074] The processor 110, the security system 170, and / or the assistance systems 160 are operably connected to communicate with the various vehicle systems 150 and / or their individual components. For example, returning to FIG. 1 , the processor 110, the security system 170, and / or the assistance systems 160 may communicate to send and / or receive information from the various vehicle systems 150 to control the movement, speed, steering, heading, direction, etc. of the vehicle 100. The processor 110, the security system 170, and / or the assistance systems 160 may control some or all of these vehicle systems 150, thereby making them partially or fully autonomous.

[0075] Processor 110, security system 170, and / or assistance systems 160 may be operable to control the travel and / or steering of vehicle 100 by controlling vehicle systems 150 and / or one or more of its components. For example, when operating in an autonomous mode, processor 110, security system 170, and / or assistance systems 160 may control the direction and / or speed of vehicle 100. Processor 110, security system 170, and / or assistance systems 160 may cause vehicle 100 to accelerate (e.g., by increasing the supply of energy provided to the engine), decelerate (e.g., by reducing the supply of energy to the engine and / or by applying the brakes), and / or change direction (e.g., by turning the two front wheels).

[0076] Additionally, security system 170 and / or assistance system 160 may function to perform various driving-related tasks. Vehicle 100 may include one or more actuators. An actuator may be any element or combination of elements operable to modify, adjust, and / or alter one or more vehicle systems or components thereof in response to receiving a signal or other input from processor 110 and / or assistance system 160. Any suitable actuator may be used. For example, the one or more actuators may include a motor, a pneumatic actuator, a hydraulic piston, a relay, a solenoid, and / or a piezoelectric actuator, among others, by way of example only.

[0077] Vehicle 100 may include one or more modules, at least some of which are described herein. The modules may be implemented as computer-readable program code that, when executed by processor 110, performs one or more of the various processes described herein. One or more modules may be components of processor 110, or one or more modules may execute on and / or be distributed among other processing systems to which processor 110 is operatively connected. A module may include instructions (e.g., program logic) executable by one or more processors 110. Alternatively, or additionally, one or more data stores 115 may include such instructions.

[0078] In one or more arrangements, one or more of the modules described herein may include artificial or computational intelligence elements such as neural networks, fuzzy logic, large-scale language models (LLMs), or other machine learning algorithms. Further, in one or more arrangements, one or more modules may be distributed among multiple modules described herein. In one or more arrangements, two or more modules described herein may be combined into a single module.

[0079] Vehicle 100 may include one or more modules that form assistance system 160. Assistance system 160 may be configured to receive data from sensor system 120 and / or any other type of system capable of obtaining information about vehicle 100 and / or the vehicle's external environment. In one or more arrangements, assistance system 160 may use such data to generate one or more driving scene models. Assistance system 160 may determine the position and speed of vehicle 100. Assistance system 160 may determine the location of obstacles and other environmental features, including traffic signs, trees, shrubs, nearby vehicles, pedestrians, etc.

[0080] The assistance system 160 may be configured to receive and / or determine location information of obstacles in the external environment of the vehicle 100 for use by the processor 110 and / or one or more modules described herein, to estimate the position and orientation of the vehicle 100, the vehicle's position in global coordinates, based on signals from multiple satellites or any other data and / or signals that can be used to determine the current state of the vehicle 100 or the position of the vehicle 100 relative to the environment, for use in creating a map or determining the position of the vehicle 100 relative to the map data.

[0081] Assistance system 160, alone or in combination with security system 170, can be configured to determine a driving path, a current automated driving maneuver for vehicle 100, a future automated driving maneuver, and / or changes to the current automated driving maneuver based on data acquired by sensor system 120, a driving scene model, and / or data from any other suitable source. A "driving maneuver" refers to one or more actions that affect the movement of the vehicle. Examples of driving maneuvers include, but are not limited to, accelerating, decelerating, braking, turning, moving vehicle 100 laterally, changing lanes of travel, merging into lanes of travel, and / or reversing. Assistance system 160 can be configured to execute the determined driving maneuvers. Assistance system 160 can cause such automated driving maneuvers to be executed directly or indirectly. As used herein, "cause" or "causing" means, directly or indirectly, forcing, commanding, instructing, and / or enabling an event or action to occur, or at least creating a condition in which such an event or action may occur. Assistance systems 160 may be configured to perform various vehicle functions and / or to transmit data to, receive data from, exchange information with, and / or control vehicle 100 or one or more of its systems (e.g., one or more of vehicle systems 150).

[0082] Detailed embodiments are disclosed herein. However, it should be understood that the disclosed embodiments are intended as examples only. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art how to variously employ aspects of the present specification in substantially any suitable detailed structure. Furthermore, the terms and phrases used herein are not intended to be limiting, but rather to provide an understandable description of possible embodiments. While various embodiments are shown in Figures 1-8, the embodiments are not limited to the structures or applications shown.

[0083] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions for performing certain logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved.

[0084] The systems, components, and / or processes described above can be implemented in hardware or a combination of hardware and software, either centralized in one processing system or distributed across multiple interconnected processing systems. Any type of processing system or other apparatus adapted to perform the methods described herein is suitable. The combination of hardware and software can be a processing system with computer-usable program code that, when loaded and executed, controls the processing system to perform the methods described herein. The systems, components, and / or processes can also be embodied in a computer-readable storage, such as a computer program product or other data program storage device, tangibly embodying a program of instructions executable by a machine to perform the methods and processes described herein. These elements can also be embodied in an application product that, when loaded into a processing system, has all the features enabling the execution of the methods described herein and can perform these methods when loaded into a processing system.

[0085] Furthermore, the arrangements described herein may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein, e.g., stored thereon. Any combination of one or more computer-readable medium(s) may be utilized. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The phrase "computer-readable storage medium" refers to a non-transitory storage medium. The computer-readable medium may take forms including, but not limited to, non-volatile media and volatile media. Non-volatile media may include, for example, optical disks, magnetic disks, etc. Volatile media may include, for example, semiconductor memory, dynamic memory, etc. Examples of such computer-readable storage media include, but are not limited to, a floppy disk, a flexible disk, a hard disk, magnetic tape, another magnetic medium, an ASIC, a CD, another optical medium, RAM, ROM, a memory chip or card, a memory stick, and other media readable by a computer, a processor, or other electronic device. In the context of this specification, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0086] The following contains definitions of selected terms used herein. The definitions include various examples and / or forms of components that fall within the scope of the terms and that may be used in various embodiments. These examples are not intended to be limiting. Both singular and plural forms of a term can belong to a definition.

[0087] References to "one embodiment," "one embodiment," "one example," "one example," etc. indicate that the embodiment or example so described may include a particular feature, structure, characteristic, property, element, or limitation, but not all embodiments or examples necessarily include that particular feature, structure, characteristic, property, element, or limitation. Furthermore, repeated use of the phrase "in one embodiment" may, but does not necessarily, refer to the same embodiment.

[0088] As used herein, a "module" includes computer or electrical hardware components, firmware, non-transitory computer-readable media storing instructions, and / or combinations of these components configured to perform a function or action and / or cause another logic, method, and / or system to perform a function or action. A module may include an algorithmically controlled microprocessor, a discrete logic circuit (e.g., an ASIC), an analog circuit, a digital circuit, a programmed logic device, a memory device containing instructions that, when executed, execute an algorithm, etc. A module, in one or more embodiments, includes one or more CMOS gates, a combination of gates, or other circuit components. Where multiple modules are described, one or more embodiments include incorporating multiple modules into a single physical modular component. Similarly, where a single module is described, one or more embodiments include distributing the single module among multiple physical components.

[0089] Additionally, as used herein, a module includes a routine, program, object, component, data structure, etc. that performs a particular task or implements a particular data type. In a further aspect, memory generally stores the described modules. The memory associated with a module may be a buffer or cache integrated within a processor, RAM, ROM, flash memory, or another suitable electronic storage medium. In yet another aspect, modules contemplated by the present disclosure are implemented as an application-specific integrated circuit (ASIC), a hardware component of a system-on-chip (SoC), a programmable logic array (PLA), or another suitable hardware component incorporating a defined configuration set (e.g., instructions) to perform the disclosed functions.

[0090] In one or more arrangements, one or more of the modules described herein may include artificial intelligence or computational intelligence elements, such as neural networks, fuzzy logic, LLMs, or other machine learning algorithms. Further, in one or more arrangements, one or more of the modules may be distributed across multiple modules described herein. In one or more arrangements, two or more of the modules described herein may be combined into a single module.

[0091] Program code embodied in a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wired, fiber optic, cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations of aspects of the present arrangements may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as the C programming language or similar programming languages. The program code may run as a standalone software package, entirely on the user's computer, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider).

[0092] The terms "a" and "an," as used herein, are defined as one or more than one, not one. The term "plurality," as used herein, is defined as two or more than two. The term "another," as used herein, is defined as at least a second or more. The terms "comprises" and / or "has," as used herein, are defined as "comprises" (i.e., open language). The phrase "at least one of ... and ..." as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. As an example, the phrase "at least one of A, B, and C" includes A only, B only, C only, or any combination thereof (e.g., AB, AC, BC, or ABC).

[0093] Aspects of the present specification may be embodied in other forms without departing from the spirit or essential characteristics thereof, and reference should accordingly be made to the following claims, rather than the foregoing specification, as indicating the scope of the present specification. [Explanation of symbols]

[0094] 100: Vehicle, 110: Processor, 115: Data store, 120: Sensor system, 121: Vehicle sensor, 122: Environmental sensor, 120: Sensor system, 121: Vehicle sensor, 122: Environmental sensor, 130: Input system, 140: Output system, 150: Vehicle system, 160: Assistance system, 170: Security system, 210: Memory, 220: Control module, 230: Data store, 240: System data, 250: Report

Claims

1. one or more processors (110); a memory (210) communicatively coupled to the one or more processors; The memory includes a program that, when executed by one or more processors, instructions for retrieving a segment of system data in the authentication device in response to an authentication request; instructions for determining the integrity of system data by identifying whether a root hash consisting of integrity hashes of segments matches a reference hash; and instructions for causing a report to be provided in accordance with the consistency.

2. The control module includes instructions for determining consistency, instructions for generating an integrity hash of the segment according to a hash function; instructions for generating a root hash according to a homomorphic hash using the consistency hash; and and instructions for comparing the root hash with a reference hash to determine if the segment has been altered without authorization.

3. The instructions to obtain the segments, including instructions to collect the segments according to a segment size that is either predefined or dynamically defined according to available resources, including instructions to collect the segments according to a segment size that is either predefined or dynamically defined according to available resources; The security system of claim 1 , wherein the control module includes instructions for obtaining and validating the segment within a trusted execution environment (TEE) of the authentication device.

4. The instructions for providing a report, included by the control module, include instructions for generating the report to include an integrity hash if the integrity indicates that the system data is at least partially corrupted to facilitate tracking of which segments are corrupted; The security system of claim 1 , wherein the system data includes program instructions and program data.

5. The control module further includes instructions for verifying a segment of system data using the report at a remote entity that provided the authentication request; The security system of claim 1 , wherein the report includes an integrity hash and attribute information about the segment.

6. 6. The security system of claim 5, wherein the instructions included in the control module for validating the segments include instructions for calculating segment hashes for the segments of the system data from the validated data stored at the remote entity, and comparing the segment hashes to the integrity hash to identify which of one or more segments of the system data have been corrupted.

7. The control module further includes instructions for receiving, at the authentication device, a mitigation message in response to a report indicating that the integrity of the system data has been compromised, the mitigation message causing the authentication device to perform a mitigation action identified in the mitigation message; The security system of claim 1 , wherein the mitigation action includes one of repairing memory of the authentication device and disabling at least a portion of the authentication device.

8. 10. The security system of claim 1, wherein the security system is embedded within a vehicle and uses the root hash to perform authentication for remote entities.

9. When executed by one or more processors (110), the one or more processors: instructions for retrieving a segment of system data in the authentication device in response to an authentication request; instructions for determining the integrity of system data by identifying whether a root hash consisting of integrity hashes of segments matches a reference hash; and a non-transitory computer-readable medium storing instructions for causing a report to be provided in accordance with the consistency.

10. The command to determine consistency is instructions for generating an integrity hash of the segment according to a hash function; instructions for generating a root hash according to a homomorphic hash using the consistency hash; and and instructions for comparing the root hash to a reference hash to determine if the segment has been modified without authorization.

11. The instructions to obtain the segments include instructions to collect the segments according to a segment size that is either predefined or dynamically defined according to available resources; 10. The non-transitory computer-readable medium of claim 9, wherein the instructions for obtaining the segment and the instructions for verifying the segment are executed within a trusted execution environment (TEE) of the authentication device.

12. The instructions for providing the report include instructions for, if the integrity indicates that the system data is at least partially corrupted, generating the report to include an integrity hash to facilitate tracking of which segments are corrupted; The non-transitory computer-readable medium of claim 9 , wherein the system data includes program instructions and program data.

13. further comprising instructions for verifying a segment of system data at a remote entity that provided the authentication request using the report; The non-transitory computer-readable medium of claim 9 , wherein the report includes an integrity hash and attribute information about the segment.

14. obtaining a segment of system data in the authentication device in response to the authentication request; determining the integrity of the system data by identifying whether a root hash consisting of integrity hashes of segments matches a reference hash; and providing a report in accordance with the consistency.

15. Determining consistency is generating a consistency hash of the segment according to a hash function; generating a root hash according to a homomorphic hash using a consistent hash; and 15. The method of claim 14, comprising comparing a root hash to a reference hash to determine if the segment has been modified without authorization.

16. obtaining the segments includes collecting the segments according to a segment size that is either predefined or dynamically defined according to available resources; The method of claim 14 , wherein obtaining the segment and verifying the segment occurs within a trusted execution environment (TEE) of the authentication device.

17. Providing the report includes, if the integrity indicates that the system data is at least partially corrupted, generating the report to include an integrity hash to facilitate tracking of which segments are corrupted; The method of claim 14 , wherein the system data includes program instructions and program data.

18. Further comprising verifying a segment of system data at the remote entity that provided the authentication request using the report; The method of claim 14 , wherein the report includes an integrity hash and attribute information about the segment.

19. 20. The method of claim 18, wherein validating the segments includes calculating segment hashes for the segments of the system data from the validated data stored at the remote entity, and comparing the segment hashes to the integrity hash to identify which of the one or more segments of the system data are corrupted.

20. further comprising receiving, at the authentication device, a mitigation message in response to the report indicating that the integrity of the system data has been compromised, the mitigation message causing the authentication device to perform a mitigation action identified in the mitigation message; The method of claim 14 , wherein the mitigating action includes one of repairing memory of the authentication device and disabling at least a portion of the authentication device.

Images