Static measurement method and device based on dual-system architecture trusted computing scene

Abstract

The invention discloses a static measurement method and device based on a dual-system architecture trusted computing scene. The method comprises the steps that multi-dimensional file attribute data of a first executable file is obtained, and the first executable file is an executable file to be measured; determining that the first executable file is credible under the condition that a key attribute character string in multi-dimensional file attribute data of the first executable file hits in a first-level cache region of the Bloom filter and the multi-dimensional file attribute data of the first executable file hits in a second-level cache region of the fragment hash table, otherwise, determining that the first executable file is not credible; the key attribute character string comprises at least two-dimensional file attribute data in the multi-dimensional file attribute data, the Bloom filter is generated based on the key attribute character string in the multi-dimensional file attribute data of the reference executable file, and the fragment hash table is generated based on the multi-dimensional file attribute data of the reference executable file. The technical problem of low efficiency of static measurement in related technologies is solved.

Description

Technical Field

[0001] This application relates to the field of computer security, and more specifically, to a static measurement method and apparatus for a trusted computing scenario based on a dual-architecture system. Background Technology

[0002] This section is intended to provide background or context for the content set forth in the claims or specification, and the content described herein is not acknowledged as prior art simply because it is included in this section.

[0003] With the rapid development of information technology, cybersecurity threats are becoming increasingly severe. Trusted computing, as a technology that enhances computer system security through a combination of hardware and software, plays an increasingly important role in ensuring system security. Static metrics, as an important component of trusted computing, perform integrity measurements on executable files during system startup or program loading to ensure they have not been tampered with, serving as the first line of defense for system security.

[0004] In the field of trusted computing, static metrics, as a key technology for verifying system integrity, determine whether a file has been tampered with by calculating the hash value of an executable file in the system and comparing it with the hash value in a benchmark library.

[0005] Traditional static metrics methods typically use a single hash table to store the hash value and full path name of the executable file. The index of the hash table is calculated from the file's hash value, and each index position corresponds to a linked list used to handle hash collisions.

[0006] Traditional static metrics methods typically use a single hash table to store the hash value and full path name of the executable file. The index of the hash table is calculated from the file's hash value, and each index position corresponds to a linked list used to handle hash collisions.

[0007] The specific process is as follows: 1) Establish a benchmark library: Pre-scan and calculate the hash values ​​of all trusted executable files, and store them together with the file paths in the benchmark library on the system disk; 2) Static measurement: After the static measurement module starts, it reads the benchmark library file, loads it into memory, and saves it in a hash table structure. The execution operation of the executable file will trigger the hash table matching process of the static measurement. Based on the input file hash value as an index, it searches whether there is a corresponding entry in the hash table. By traversing and comparing the hash values ​​and file paths in the hash table, the integrity and origin of the file are verified.

[0008] Traditional static metric matching schemes use a hash table structure of single-dimensional file attributes, which has the following technical problems:

[0009] 1) Severe hash collisions: Using only file hash values ​​as indexes can lead to excessively long linked lists due to hash collisions (mapping to the same hash bucket) between different files, reducing query efficiency.

[0010] 2) Matching performance bottleneck: In large-scale systems, the number of files is huge. Traditional file integrity measurement relies entirely on the comparison of the full pure hash table, which is a single-threaded traversal of the linked list in the hash bucket of the corresponding index. This is inefficient and consumes a lot of resources. Without a multi-level caching mechanism, the matching efficiency is high.

[0011] 3) Waste of resources: Each measurement requires accessing the entire hash table, which consumes memory and computing resources.

[0012] 4) Security issues: Traditional methods lack a mechanism to verify the integrity of the benchmark library, which poses a risk of tampering.

[0013] 5) Low processing speed: Traditional methods for querying the complete hash table result in low query efficiency due to the large amount of data, which cannot meet the needs of high-concurrency scenarios.

[0014] The limitations of traditional static metric matching schemes are manifested in specific application scenarios as follows:

[0015] 1) Efficiency bottleneck: If the hash table query efficiency is low during the system startup phase, it will prolong the system startup time and seriously affect the user experience, such as server cold start delay; 2) Insufficient real-time performance: Trusted computing requires static measurement to be completed in milliseconds. Traditional single-level hash tables are difficult to meet real-time requirements when the file size increases, such as in cloud computing and other server scenarios; 3) Resource-constrained scenarios: In embedded devices (such as IoT terminals), memory and computing resources are limited. Long linked list traversal may exhaust resources, leading to verification failure. Summary of the Invention

[0016] This application provides a static measurement method and apparatus based on a dual-architecture trusted computing scenario. It combines a two-level cache architecture of sharded Bloom filters and sharded hash tables, and uses multi-threading technology to optimize query efficiency. It is suitable for scenarios such as fast file integrity verification and malicious tampering detection. This solution can at least solve the technical problem of low efficiency of static measurement in related technologies.

[0017] According to one aspect of the embodiments of this application, a static measurement method for a trusted computing scenario based on a dual-architecture system is provided, comprising: obtaining multidimensional file attribute data of a first executable file, wherein the first executable file is the executable file to be measured; determining that the first executable file is trustworthy if the key attribute string in the multidimensional file attribute data of the first executable file is hit in the first-level cache of a Bloom filter and the multidimensional file attribute data of the first executable file is hit in the second-level cache of a sharded hash table; otherwise, determining that the first executable file is untrustworthy; wherein the key attribute string includes at least two dimensions of file attribute data in the multidimensional file attribute data of the first executable file, the Bloom filter is generated based on the key attribute string in the multidimensional file attribute data of a benchmark executable file, and the sharded hash table is generated based on the multidimensional file attribute data of the benchmark executable file.

[0018] Optionally, if the key attribute string in the multidimensional file attribute data of the first executable file is found in the first-level cache of the Bloom filter and the multidimensional file attribute data of the first executable file is found in the second-level cache of the sharded hash table, the first executable file is determined to be trustworthy; otherwise, the first executable file is determined to be untrustworthy. This includes: searching for the key attribute string of the first executable file in the first-level cache of the Bloom filter; if the key attribute string of the first executable file is not found in the first-level cache of the Bloom filter, the first executable file is determined to be untrustworthy; if the key attribute string of the first executable file is found in the first-level cache of the Bloom filter, the multidimensional file attribute data of the first executable file is searched in the second-level cache of the sharded hash table; if the multidimensional file attribute data of the first executable file is not found in the second-level cache of the sharded hash table, the first executable file is determined to be untrustworthy; if the multidimensional file attribute data of the first executable file is found in the second-level cache of the sharded hash table, the first executable file is determined to be trustworthy.

[0019] Optionally, searching for the key attribute string of the first executable file through the first-level cache of the Bloom filter includes: calling a first hash algorithm to perform a hash operation on the key attribute string of the first executable file to obtain a first shard index; if a first shard position corresponding to the first shard index exists in the first-level cache, calling multiple second hash algorithms to perform a hash operation on the key attribute string of the first executable file to obtain multiple first indices, wherein the multiple second hash algorithms are different, and the multiple first indices correspond one-to-one with the multiple second hash algorithms; wherein, if a shard position corresponding to the first shard index does not exist in the first-level cache, it is determined that the first-level cache of the Bloom filter has not hit the key attribute string of the first executable file; if at least one of the values ​​corresponding to the multiple first indices in the bit array of the first shard position is not a target value, it is determined that the first-level cache of the Bloom filter has not hit the key attribute string of the first executable file; if all the values ​​corresponding to the multiple first indices in the bit array of the first shard position are target values, it is determined that the first-level cache of the Bloom filter has hit the key attribute string of the first executable file.

[0020] Optionally, before obtaining the multidimensional file attribute data of the first executable file, the method further includes: calling the first hash algorithm to perform a hash operation on the key attribute string of the trusted benchmark executable file to obtain a second shard index, thereby determining the second shard position corresponding to the second shard index in the first-level cache, each shard position corresponding to one Bloom filter; calling the plurality of second hash algorithms to perform a hash operation on the key attribute string of the benchmark executable file to obtain a plurality of second indices; setting the value corresponding to the plurality of second indices in the bit array of the second shard position to the target value, wherein the target value is different from the default value in the bit array.

[0021] Optionally, searching for the multidimensional file attribute data of the first executable file through the secondary cache of the sharded hash table includes: calling a third hash algorithm to perform a hash operation on the multidimensional file attribute data of the first executable file to obtain a third shard index; if a third shard position corresponding to the third shard index exists in the secondary cache, calling a fourth hash algorithm to perform a hash operation on the multidimensional file attribute data of the first executable file to obtain a first hash bucket index within the third shard position, wherein the fourth hash algorithm is different from the third hash algorithm; and searching for the first executable file in the first hash bucket corresponding to the first hash bucket index. The multidimensional file attribute data; wherein, if there is no shard position corresponding to the third shard index in the second-level cache, it is determined that the second-level cache of the shard hash table does not hit the multidimensional file attribute data of the first executable file; if at least one-dimensional file attribute data of the first executable file is not found in the first hash bucket, it is determined that the second-level cache of the shard hash table does not hit the multidimensional file attribute data of the first executable file; if the multidimensional file attribute data of the first executable file is found in the first hash bucket, it is determined that the second-level cache of the shard hash table hits the multidimensional file attribute data of the first executable file.

[0022] Optionally, before obtaining the multidimensional file attribute data of the first executable file, the method further includes: calling the third hash algorithm to perform a hash operation on the multidimensional file attribute data of the trusted benchmark executable file to obtain a fourth shard index, thereby determining the fourth shard position corresponding to the fourth shard index in the secondary cache; calling the fourth hash algorithm to perform a hash operation on the multidimensional file attribute data of the benchmark executable file to obtain a second hash bucket index within the fourth shard position; and saving the multidimensional file attribute data of the benchmark executable file to the second hash bucket corresponding to the second hash bucket index.

[0023] Optionally, after obtaining the multidimensional file attribute data of the first executable file, the method further includes: when there are multiple first executable files to be measured, using a thread pool to process the measurement tasks of multiple first executable files in parallel.

[0024] According to another aspect of the embodiments of this application, a static measurement device based on a dual-architecture trusted computing scenario is also provided, comprising: an acquisition unit, configured to acquire multidimensional file attribute data of a first executable file, wherein the first executable file is the executable file to be measured; and a measurement unit, configured to determine that the first executable file is trustworthy if a key attribute string in the multidimensional file attribute data of the first executable file is hit in the first-level cache of a Bloom filter and the multidimensional file attribute data of the first executable file is hit in the second-level cache of a sharded hash table, otherwise determine that the first executable file is untrustworthy; wherein the key attribute string includes at least two dimensions of file attribute data in the multidimensional file attribute data of the first executable file, the Bloom filter is generated based on the key attribute string in the multidimensional file attribute data of a benchmark executable file, and the sharded hash table is generated based on the multidimensional file attribute data of the benchmark executable file.

[0025] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the storage medium including a stored program that executes the above-described method when the program is run.

[0026] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor performs the above-described method through the computer program.

[0027] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of any of the embodiments of the methods described above.

[0028] In this embodiment, multidimensional file attribute data of a first executable file is obtained, where the first executable file is the executable file to be measured. If the key attribute string in the multidimensional file attribute data of the first executable file is hit in the first-level cache of the Bloom filter and its multidimensional file attribute data is hit in the second-level cache of the sharded hash table, the first executable file is determined to be trustworthy; otherwise, the first executable file is determined to be untrustworthy. The key attribute string includes at least two dimensions of file attribute data from the multidimensional file attribute data. The Bloom filter is generated based on the key attribute string in the multidimensional file attribute data of the benchmark executable file, and the sharded hash table is generated based on the multidimensional file attribute data of the benchmark executable file. This solves the technical problem of low efficiency of static measurement in related technologies. Attached Figure Description

[0029] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0030] Figure 1 This is a schematic diagram of the hardware environment for a trusted computing scenario based on a dual-architecture design, according to an embodiment of this application.

[0031] Figure 2 This is a flowchart of an optional static measurement method for a trusted computing scenario based on a dual-architecture system, according to an embodiment of this application.

[0032] Figure 3 This is a schematic diagram of an optional disk benchmark library file creation process according to an embodiment of this application;

[0033] Figure 4 This is a schematic diagram of an optional benchmark library file update sequence according to an embodiment of this application;

[0034] Figure 5 This is a schematic diagram of an optional segmented Bloom filter structure according to an embodiment of this application;

[0035] Figure 6 This is a schematic diagram of an optional sharded hash table structure according to an embodiment of this application;

[0036] Figure 7 This is a schematic diagram of an optional benchmark library file loading and verification timing according to an embodiment of this application;

[0037] Figure 8 This is a schematic diagram of an optional fragmented Bloom filter query process according to an embodiment of this application;

[0038] Figure 9 This is a schematic diagram of an optional sharded hash table lookup process according to an embodiment of this application;

[0039] Figure 10 This is a schematic diagram of an optional second-level cache query verification sequence according to an embodiment of this application;

[0040] Figure 11 This is a schematic diagram of an optional benchmark library file update sequence according to an embodiment of this application;

[0041] Figure 12 This is a schematic diagram of an optional static measurement device for a trusted computing scenario based on a dual-architecture system, according to an embodiment of this application.

[0042] Figure 13 This is a structural block diagram of a terminal according to an embodiment of this application. Detailed Implementation

[0043] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0044] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0045] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0046] Trusted Computing (TC) is a technology that uses a combination of hardware and software to ensure the security and trustworthiness of computer systems. Its core objective is to protect the confidentiality, integrity, and availability of data and prevent malware, unauthorized access, and tampering by establishing and maintaining a trusted computing environment.

[0047] Dual Architecture: This refers to an architecture where the Trusted Computing Platform Module (TPCM) runs as a protective component on the Trusted Core (Management Core), while the UEFI BIOS, GRUB, and operating system run as computing components on the Computing Core.

[0048] TPCM (Trusted Platform Control Module): A trusted platform control module in a dual-architecture system, providing hardware-level secure storage, encryption, and measurement capabilities. It is a core component of trusted computing, running on a trusted core.

[0049] Trusted Core: The processor core that runs the TPCM module and is responsible for trusted computing-related tasks. It is separate from the computing core that runs the operating system and can access the resources of the computing core.

[0050] Computing Core: The processor core that runs the operating system and applications. It is separate from the trusted core and cannot access the resources of the trusted core.

[0051] Static Measurement: A key technology in trusted computing, it refers to the process of verifying the integrity of static files or components at system startup or a specific point in time. By calculating their hash values ​​and comparing them with pre-stored benchmark values, it ensures that these components have not been tampered with.

[0052] Reference Library: Stores information such as the hash value, file path, and file length of each trusted executable file, used for comparison with the file to be measured, and is the core data source for static measurement.

[0053] Bloom Filter: A highly space-efficient probabilistic data structure used to determine whether an element is in a set. It allows for a certain false positive rate but does not allow for false negatives.

[0054] Hash Table: A data structure that uses a hash function to map key-value pairs to specific locations in the table for fast lookup.

[0055] Hash collision: Different keys result in the same index value after being calculated using a hash function, which needs to be resolved using methods such as linked lists.

[0056] Digest Value: A fixed-length value obtained by hashing data, used to verify data integrity and consistency. In this scheme, it refers to a fixed-length value obtained by hashing the benchmark database, used to verify the integrity of the benchmark database.

[0057] As described in the background section, existing solutions lack multi-level caching and multi-threading technologies, making it difficult to balance speed and accuracy. With the continuous expansion of the system scale, the number of executable files stored in the benchmark library increases dramatically. Traditional hash tables, which use a single hash value as an index, gradually become less efficient during matching comparisons. As the benchmark library grows, the traversal time of a single-level index increases significantly. Especially when there are many hash collisions, a single-level hash index can cause files of different lengths to be mapped to the same hash bucket, drastically increasing the linked list traversal time. This slows down the matching speed of static metrics, severely impacting the real-time performance of static metrics and the overall system performance.

[0058] Therefore, improving the query efficiency of the benchmark database hash table during static measurement has become a key issue that urgently needs to be addressed in the field of trusted computing. In addition, ensuring the security and integrity of the benchmark database is also an important issue.

[0059] According to one aspect of the embodiments of this application, a method embodiment of a static measurement method based on a dual-architecture trusted computing scenario is provided.

[0060] This solution is applicable to dual-system trusted computing scenarios (the architecture of which is as follows) Figure 1 The static measurement mechanism used (shown) is based on a two-level cache (multi-dimensional file attribute fragmented Bloom filter + multi-dimensional file attribute fragmented hash table) and multi-threading technology. It establishes a fragmented Bloom filter indexed by the multi-dimensional file attributes (including file path information, file hash value, file size, etc.) and a fragmented hash table indexed by the hash values ​​of these attributes. The fragmented Bloom filter data serves as the first-level cache, and the fragmented hash table as the second-level cache. A thread pool is used to process file measurement tasks in parallel. If the first-level cache misses, tampering is directly detected; if a cache hit occurs, precise verification of the second-level cache is triggered. This mechanism significantly improves the matching speed and efficiency of static measurement functions in trusted computing scenarios and, combined with TPCM standard application scenarios, ensures the security of the benchmark library.

[0061] The core of this application lies in constructing a two-level caching mechanism, combining a multi-dimensional file attribute sharded Bloom filter (first-level cache) and a multi-dimensional file attribute sharded hash table (second-level cache), fully utilizing the processor's multi-core resources, and achieving efficient concurrent queries through multi-threading technology. Figure 2 This is a flowchart of an optional static measurement method for a trusted computing scenario based on a dual-architecture system, according to an embodiment of this application. Figure 2 As shown, the method may include the following steps:

[0062] Step S202: Obtain multi-dimensional file attribute data of the first executable file, which is the executable file to be measured. When there are multiple first executable files to be measured, a thread pool can be used to process the measurement tasks of multiple first executable files in parallel.

[0063] Step S204: If the key attribute string in the multidimensional file attribute data of the first executable file is hit in the first-level cache of the Bloom filter and the multidimensional file attribute data of the first executable file is hit in the second-level cache of the sharded hash table, the first executable file is determined to be trustworthy; otherwise, the first executable file is determined to be untrustworthy.

[0064] The key attribute string includes at least two-dimensional file attribute data from the multidimensional file attribute data of the first executable file. The Bloom filter is generated based on the key attribute string from the multidimensional file attribute data of the benchmark executable file. The sharded hash table is generated based on the multidimensional file attribute data of the benchmark executable file.

[0065] It should be noted that the process for creating, loading, and matching the above-mentioned benchmark executable file is as follows:

[0066] 1) Establishing a benchmark library process

[0067] The system iterates through all executable files, acquiring attribute information for each file, including file path, hash value, and size. The file size, hash value, and path information are then stored in a baseline library file on disk. The computational core reads the baseline library file data and sends it to the trusted core to calculate the digest value. The digest value is then saved in the trusted core's digest value storage area. The trusted core returns the digest value processing result to the computational core, completing the baseline library creation process. The disk baseline library file creation process is as follows: Figure 3 As shown, the update sequence of the benchmark library file is as follows: Figure 4 As shown.

[0068] 2) Baseline library loading process

[0069] The process calculates and retrieves the path, size, and hash value of the file to be matched, combining them into a multi-dimensional attribute information string, such as "file path + size + hash value". First, a Bloom filter is added to the first-level cache, using multi-threading to add sharded Bloom filters. Three different hash functions H1, H2, and H3 are selected, with a bit vector length of L, initially all bits set to 0. For each file's key attribute combination string, the hash value is calculated using H1, H2, and H3 respectively, resulting in h1, h2, and h3. The corresponding positions in the bit vector for h1, h2, and h3 are then set to 1. This completes the Bloom filter construction, used to quickly determine if a file's key attribute combination is possible. Next, a full hash table is added to the second-level cache, using multi-threading to populate nodes mapped to different hash bucket positions.

[0070] 3) Benchmark Library Matching and Comparison Process

[0071] When multiple file static measurement requests arrive, multi-threading is employed. First, a first-level cache (Bloom filter) lookup is performed. Using the input file's multi-dimensional attribute information, a hash algorithm calculates the corresponding index positions for different files. Then, multi-threaded parallel lookup operations are performed on the Bloom filters of different shards. If the lookup for that file returns a miss, the file is considered tampered with, and its status is returned as untrusted. If the lookup hits, the second-level cache shard hash table lookup process is initiated.

[0072] Example of Bloom filter filtering: The key attribute combination string is hashed using H1, H2, and H3 respectively, resulting in h1', h2', and h3'. The bits corresponding to h1', h2', and h3' in the Bloom filter bit vector are checked to see if all bits are 1. If not all bits are 1, it means the key attribute combination for the file does not exist, the measurement result is "not found," and the measurement ends. If all bits are 1, the hash table lookup step begins. A second-level cache (sharded hash table) lookup is only performed if the first-level cache is hit. Using the input file attribute information, multi-threading is used to perform parallel table lookups on multiple different file measurement requests (when multiple static measurement requests for different files arrive simultaneously). Different files are mapped to different shard locations. Each thread finds the corresponding hash table location and performs a parallel query operation, using different hash algorithms to find the hash table bucket corresponding to the file. The linked lists in the bucket are traversed, and the hash value is compared with the file's full path name. If a match is successful, the file is returned as trustworthy; if a change in the hash value is found, the file has been tampered with and is untrustworthy.

[0073] The implementation method of step S204 is as follows:

[0074] 1) Locate the key attribute string of the first executable file through the first-level cache of the Bloom filter.

[0075] A pre-established sharded Bloom filter structure is defined as follows: The first hash algorithm is invoked to perform a hash operation on the key attribute string of the trusted benchmark executable file to obtain a second shard index, thereby determining the second shard position corresponding to the second shard index in the first-level cache. Each shard position corresponds to one Bloom filter. The multiple second hash algorithms are invoked to perform a hash operation on the key attribute string of the benchmark executable file to obtain multiple second indices. The values ​​corresponding to the multiple second indices in the bit array of the second shard position are set to the target value, which is different from the default value in the bit array.

[0076] For example, in the design of a fragmented Bloom filter structure based on multidimensional file attribute data, a multidimensional file attribute fragmented Bloom filter (MFABF) is used to store the compression features of legitimate file attributes. Multiple attribute data such as file path information, file hash value, and file size are introduced. The multidimensional attributes of the file (such as the string "file path + size + hash value") are combined using a hash function to generate unique key values ​​to construct the fragmented Bloom filter. Its memory data area serves as a first-level cache. Different files can be mapped to different fragmented Bloom filters according to the key values ​​mentioned above. Each fragmented Bloom filter uses a separate locking mechanism, facilitating subsequent asynchronous parallel query operations on each fragmented Bloom filter using multiple threads for quickly predicting whether a file is trustworthy.

[0077] Then you can use a Bloom filter to perform queries:

[0078] The process involves several steps: First, a first hash algorithm is used to hash the key attribute string of the first executable file to obtain a first shard index. If a first shard position corresponding to the first shard index exists in the first-level cache, multiple second hash algorithms are used to hash the key attribute string of the first executable file to obtain multiple first indices. These multiple second hash algorithms are different, and each first index corresponds one-to-one with a different second hash algorithm. If no shard position corresponding to the first shard index exists in the first-level cache, it is determined that the first-level cache of the Bloom filter has not hit the key attribute string of the first executable file. If at least one of the values ​​corresponding to the multiple first indices in the bit array of the first shard position is not a target value, it is determined that the first-level cache of the Bloom filter has not hit the key attribute string of the first executable file. If all the values ​​corresponding to the multiple first indices in the bit array of the first shard position are target values, it is determined that the first-level cache of the Bloom filter has hit the key attribute string of the first executable file.

[0079] 2) If the critical attribute string of the first executable file is not hit in the first-level cache of the Bloom filter, the first executable file is determined to be untrusted.

[0080] 3) If the first executable file's key attribute string is hit in the first-level cache of the Bloom filter, the multidimensional file attribute data of the first executable file is searched through the second-level cache of the sharded hash table.

[0081] A sharded hash table structure is pre-established based on the multidimensional file attribute data: the third hash algorithm is called to perform a hash operation on the multidimensional file attribute data of the trusted benchmark executable file to obtain a fourth shard index, thereby determining the fourth shard position corresponding to the fourth shard index in the secondary cache; the fourth hash algorithm is called to perform a hash operation on the multidimensional file attribute data of the benchmark executable file to obtain a second hash bucket index within the fourth shard position; the multidimensional file attribute data of the benchmark executable file is saved to the second hash bucket corresponding to the second hash bucket index.

[0082] For example, in the design of a sharded hash table structure based on multidimensional file attribute data, a multidimensional file attribute sharded hash table (MFAHT) is first constructed to store the complete hash values ​​of valid file attributes. Multiple attribute data such as file path information, file hash value, and file size are introduced. The multidimensional attributes of the file (such as the string "file path + size + hash value") are combined using a hash function to generate unique keys, thus constructing the sharded hash table. Its memory data area serves as a secondary cache. Files with different attributes can be mapped to different sharded hash tables according to the keys described above. Each sharded hash table uses a separate locking mechanism, facilitating asynchronous parallel precise table lookup operations on each sharded hash table using multiple threads after a Bloom filter hit in the primary cache.

[0083] Then, queries can be performed using a sharded hash table structure based on file multidimensional attribute data:

[0084] A third hash algorithm is invoked to perform a hash operation on the multidimensional file attribute data of the first executable file to obtain a third shard index. If a third shard position corresponding to the third shard index exists in the secondary cache, a fourth hash algorithm is invoked to perform a hash operation on the multidimensional file attribute data of the first executable file to obtain a first hash bucket index within the third shard position. The fourth hash algorithm is different from the third hash algorithm. The multidimensional file attribute data of the first executable file is then searched in the first hash bucket corresponding to the first hash bucket index.

[0085] If no shard position corresponding to the third shard index exists in the secondary cache, it is determined that the secondary cache of the shard hash table does not contain the multidimensional file attribute data of the first executable file; if at least one-dimensional file attribute data of the first executable file is not found in the first hash bucket, it is determined that the secondary cache of the shard hash table does not contain the multidimensional file attribute data of the first executable file; if the multidimensional file attribute data of the first executable file is found in the first hash bucket, it is determined that the secondary cache of the shard hash table contains the multidimensional file attribute data of the first executable file.

[0086] 4) If the multidimensional file attribute data of the first executable file is not found in the secondary cache of the sharded hash table, the first executable file is determined to be untrusted.

[0087] 5) If the multidimensional file attribute data of the first executable file is hit in the secondary cache of the sharded hash table, the first executable file is determined to be trustworthy.

[0088] The technical solution of this application can solve the following problems: 1) Low efficiency of static measurement matching: Traditional hash table design is prone to hash collisions under large-scale data, resulting in low efficiency of static measurement matching; traditional file integrity measurement relies on full hash table comparison, which requires traversing all file attributes, resulting in low efficiency and high resource consumption; traditional hash tables do not have a sharding design, and cannot utilize the multi-core resources of the processor for asynchronous parallel table lookup operations, while sharding design can also reduce hash collisions; 2) Risk of misjudgment in single-level caching: Single-level caching mechanisms (such as pure Bloom filters) have the risk of misjudgment and cannot be directly used for deterministic judgment in trusted computing; single-level caching mechanisms (such as pure hash table matching) have the low matching efficiency problem mentioned in point 1 above; 3) Security problem of benchmark library: Under the TPCM standard, how to ensure that the benchmark library is not tampered with and to verify it during reading.

[0089] As an optional embodiment, the technical solution of this application is further described in detail below with reference to specific implementation methods:

[0090] 1) A fragmented Bloom filter structure indexed by file multidimensional attribute data:

[0091] A Bloom filter is a highly space-efficient probabilistic data structure used to determine whether an element is in a set. It allows for a certain false positive rate but does not allow for false negatives. A Bloom filter consists of a large bit array and multiple hash functions. Its working principle is as follows: Initialization: Create a bit array of length m, with all bits initialized to 0; Adding elements: For each element to be added, calculate the hash value using k hash functions and set the corresponding bit array position to 1; Querying elements: For the queried element, also calculate the hash value using k hash functions and check if the corresponding bit array position is all 1. If it is, the element is considered to possibly exist in the set; otherwise, it definitely does not exist. Its characteristics are as follows: extremely high space efficiency, with a smaller memory footprint compared to hash tables; fast query speed, with a time complexity of O(k), where k is the number of hash functions; however, there is a false positive rate, as elements not in the set may be falsely identified as existing because the hash results of different elements may overlap, causing bits to be incorrectly marked as 1.

[0092] The sharded Bloom filter query scheme uses multi-dimensional file attribute data (file path information, file hash value, file size) to form a key file attribute string. For this key attribute string, a hash algorithm is used to first calculate the index of a specific shard position in the sharded Bloom filter. Then, multiple hash algorithms are used to calculate multiple first indices for the bit array at that shard position. It is then determined whether all these indices are 1. If they are 1, it indicates a hit (successful query), and the file is likely trustworthy, requiring further verification using the second-level cache sharded hash table. If they are 0, it indicates a miss (not found), meaning the file being measured has been tampered with and is untrustworthy. Each time static metric matching is required, a query operation is first performed on the sharded Bloom filter data in the first-level cache. If the query operation returns a "miss" result, the file to be measured is considered tampered with. If all Bloom filter query operations return "hit" results, then a precise query operation is performed on the second-level cache sharded hash table data.

[0093] Example of a piecewise Bloom filter (C language):

[0094] #define SHARD_COUNT 1024 / / Number of shards

[0095] #define BF_SIZE 1048576 / / Size of each Bloom filter (1MB)

[0096] / / Bloom filter segment structure

[0097] typedef struct{

[0098] pthread_mutex_t lock;

[0099] unsigned char*bits;

[0100] ShardBF;

[0101] / / Global fragmented Bloom filter

[0102] ShardBF shards[SHARD_COUNT];

[0103] The structure of a fragmented Bloom filter based on multidimensional file attributes is as follows: Figure 5 As shown.

[0104] 2) A fragmented hash table structure indexed by file multidimensional attribute data:

[0105] This scheme defines a sharded hash table that uses multiple file attribute data (file path information, file hash value, file size). First, it calculates the index 1 of the shard position according to hash algorithm 1, and then calculates the index 2 of the specific hash bucket at that shard position according to hash algorithm 2. It then locates a certain hash node linked list through index 1 and index 2. This node linked list stores detailed file attribute information (file path information, file hash value) for comparison during querying.

[0106] Each time static metric matching is required, a multi-threaded query operation is first performed on the sharded Bloom filter data in the first-level cache. If the query result in the first-level cache exists, the query continues to the multi-dimensional file attribute sharded hash table in the second-level cache. If the file attribute data returned by the second-level cache hash table is consistent, the metric file is considered to be in a trustworthy state; otherwise, if the file attribute data is inconsistent, the file is considered to have been tampered with.

[0107] Example of a sharded hash table structure (C language):

[0108]

[0109] A fragmented hash table structure based on multidimensional file attributes is as follows: Figure 6 As shown.

[0110] 3) Create a benchmark library file:

[0111] During system initialization, the benchmark library management module scans all executable files in the system, including critical files during startup and executable files used during system runtime. For each executable file, it calculates its file size and hash value, and saves the file size, hash value, and full file path information to a benchmark library file on the system disk. Then, it sends instructions to the TPCM via shared memory communication. The TPCM calculates the digest value of the benchmark library file and saves it in its digest value storage area. After receiving a message indicating successful digest value saving, the benchmark library management module encrypts and saves the benchmark library file. At this point, the benchmark library storing trusted file information is successfully established.

[0112] 4) Load and verify the benchmark library:

[0113] When the static metrics module of Trusted Computing starts, it first sends a command to tpcm to perform digest verification on the benchmark library files.

[0114] After the TPCM digest verification passes, the static metrics module decrypts and loads the benchmark library file data into memory. The memory data is divided into a level 1 cache and a level 2 cache. The level 1 cache uses a sharded Bloom filter to store file attribute information, while the level 2 cache uses a sharded hash table. If data already exists in the hash table bucket (i.e., a hash collision), the new data is stored in a linked list. The sharded hash table only stores the file's hash value and file path information for data comparison; file size information is not stored in the hash table to avoid excessive memory consumption. The benchmark library file loading and verification sequence is as follows: Figure 7 As shown.

[0115] 5) Static metric file matching process:

[0116] When an executable file attempts to execute, the static metrics function is triggered, and the following metrics matching process is executed.

[0117] First, a multi-threaded query is performed on the first-level cache sharded Bloom filter, followed by a multi-threaded query on the second-level cache sharded hash table. Information about the file to be tested is obtained: during static measurement, the size, hash value, and full path information of the executable file to be tested are obtained. The hash value is calculated and combined into a multi-dimensional attribute information string for the file, such as file path + size + hash value. The sharded Bloom filter is then searched: taking an example with 10 files awaiting static measurement, the sharded index value of the sharded Bloom filter for each of the 10 files is calculated based on the 10 multi-dimensional attribute information strings. Ten threads are used to query the 10 index positions of the sharded Bloom filter in parallel. If the file is not found, it indicates that it has been tampered with and is considered untrusted. If the file is found, the following steps are performed to query the sharded hash table. The query process for the first-level cache sharded Bloom filter is as follows: Figure 8 As shown.

[0118] The search process involves a sharded hash table. Taking an example of 10 files awaiting static measurement simultaneously: Based on the 10 multi-dimensional attribute information strings of the 10 files, the shard index values ​​of the corresponding sharded hash tables are calculated. Ten threads then query the 10 index positions in parallel. For each thread, based on the file's multi-dimensional attribute information string, different hash algorithms are used to calculate the position index of a hash bucket at that shard position. The linked list of the located hash table buckets is then traversed, comparing all stored hash values ​​and file full path information with the hash value and full path information of the file to be tested. If the comparison information is inconsistent, the file is considered to have been tampered with and its status is unreliable. If the comparison information is consistent, the file's status is considered reliable.

[0119] The process of querying the sharded hash table of the second-level cache is as follows: Figure 9As shown, the second-level cache query verification sequence is as follows: Figure 10 shown

[0120] 6) Secure storage and updating of the benchmark library:

[0121] Benchmark Library Storage: The established benchmark library files are stored on the operating system's disk. Simultaneously, a digest value for the benchmark library files is calculated and sent to the TPCM trusted core for safekeeping, preventing tampering. Benchmark Library Update: When the benchmark library needs updating, the digest value of the benchmark library files is updated synchronously and sent to the TPCM trusted core for safekeeping. Each update operation uses shared memory communication between the trusted core and the computation core to ensure the security and reliability of data transmission. Each benchmark library update notifies the static metrics module to update the two-dimensional hash table in memory. Benchmark Library Verification: Before each reading of the benchmark library, the digest value of the benchmark library files is first sent to the TPCM trusted core for verification. Only after successful verification can subsequent reading and matching operations proceed, thus ensuring the integrity and trustworthiness of the benchmark library. The benchmark library file update sequence is as follows: Figure 11 As shown.

[0122] 7) Security mechanisms:

[0123] Digest Value Verification: By calculating and verifying the digest values ​​of the benchmark library, the integrity of the library is ensured, and malicious tampering is prevented. TPCM Storage: The digest values ​​of the benchmark library are stored in the TPCM trusted core, leveraging the security features of TPCM to guarantee the security of the digest values. Secure Communication: The trusted core and the computing core communicate through a secure channel, such as using shared memory combined with access control mechanisms, to prevent information leakage and tampering.

[0124] 8) Multi-threaded processing mechanism

[0125] Initialize the thread pool: Based on system resources and requirements, initialize a thread pool of appropriate size. For example, in Linux systems, the pthread library can be used to create and manage thread pools.

[0126] The sharded Bloom filter and sharded hash table processing mechanism uses multidimensional file attribute data to calculate sharding indexes based on different hash algorithms. Multiple tasks targeting different sharding indexes are then created and distributed to a thread pool. Multiple threads in the thread pool, after receiving their assigned tasks, sequentially and in parallel query the Bloom filter and hash table for different shards. Thread safety is ensured by employing a read-write lock (ReentrantReadWriteLock) to implement concurrency control, allowing multi-threaded parallel queries and single-threaded writes. The technical innovations in this application include at least the following:

[0127] (1) Layered caching architecture: By introducing a first-level cache and a second-level cache mechanism, the first-level cache is first checked by a sharded Bloom filter, and then the second-level cache is checked by a sharded hash table. If the first-level cache misses, the metric file is considered to have been tampered with. If the first-level cache hits, the second-level cache is then checked for exact verification. This layered caching architecture utilizes the space efficiency of the Bloom filter and the accuracy of the hash table to form a two-layer link of "fast filtering-exact verification", reducing more than 90% of invalid hash table queries. (2) Multi-dimensional attribute fusion verification: Because multi-dimensional file attribute information is used, attackers need to forge the file size, file path information and file hash value at the same time to bypass the verification, which significantly increases the difficulty of tampering and also reduces the probability of hash collisions compared to the single hash value method. (3) Multi-threaded parallel query mechanism: Because a sharded Bloom filter and a sharded hash table data structure are used, each shard is locked independently to reduce contention. At the same time, multi-core processor resources can be fully utilized to perform concurrent queries in a multi-threaded manner, eliminating the single-threaded serial bottleneck and greatly improving the speed of static metric queries. The hash table query phase achieves multi-threaded parallel search of multi-core processors through data sharding, and the query time decreases linearly with the number of threads (the theoretical speedup is close to the number of threads). (4) Baseline library file digest value verification mechanism: Combining the security features of TPCM, the baseline library is prevented from being tampered with by calculating and verifying the digest value of the baseline library file, ensuring the security and integrity of the baseline library, thereby enhancing the overall security of the system.

[0128] The technical effects of adopting the technical solution of this application are as follows: (1) Improve the query efficiency of trusted computing static measurement: the first-level cache intercepts invalid requests, the second-level cache ensures accuracy, and the overall efficiency is improved by more than 50%; the Bloom filter quickly excludes tampered files, reduces more than 90% of hash table queries, significantly improves the query efficiency of hash tables, and speeds up the static measurement in trusted computing scenarios. (2) Resource optimization: using a multi-dimensional file attribute Bloom filter, the memory usage is only 1 / 10 of the full hash table, which is suitable for resource-constrained scenarios. The hierarchical design reduces the access frequency to the full hash table and reduces memory and CPU usage. (3) Deterministic judgment: combined with the two-level caching mechanism, the trusted status confirmation is completed in milliseconds. (4) Make trusted computing adaptable to large-scale data scenarios: multi-threading and sharding technology can effectively handle executable files in large-scale systems, which is suitable for large-scale benchmark libraries and can effectively cope with the performance challenges brought about by the growth of the benchmark library, achieving high concurrency and low latency. (5) Enhanced security: the digest value verification mechanism of the benchmark library ensures the integrity of the benchmark library, prevents malicious tampering, and provides reliable protection for static measurement. (6) Improved accuracy and real-time performance of trusted computing: Enhanced accuracy and real-time performance of trusted computing static metrics, improving overall system security and stability.

[0129] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0130] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0131] According to another aspect of the embodiments of this application, a static measurement device for a dual-architecture trusted computing scenario is also provided for implementing the above-described static measurement method for the dual-architecture trusted computing scenario. Figure 12 This is a schematic diagram of an optional static measurement device for a trusted computing scenario based on a dual-architecture design, according to an embodiment of this application. Figure 12 As shown, the device may include:

[0132] The acquisition unit 1201 is used to acquire multidimensional file attribute data of the first executable file, wherein the first executable file is the executable file to be measured;

[0133] The measurement unit 1203 is used to determine that the first executable file is trustworthy if the key attribute string in the multidimensional file attribute data of the first executable file is hit in the first-level cache of the Bloom filter and the multidimensional file attribute data of the first executable file is hit in the second-level cache of the sharded hash table; otherwise, it determines that the first executable file is untrustworthy.

[0134] The key attribute string includes at least two-dimensional file attribute data from the multidimensional file attribute data of the first executable file. The Bloom filter is generated based on the key attribute string from the multidimensional file attribute data of the benchmark executable file. The sharded hash table is generated based on the multidimensional file attribute data of the benchmark executable file.

[0135] Optionally, the metric unit is further configured to: search for the key attribute string of the first executable file in the first-level cache of the Bloom filter; if the key attribute string of the first executable file is not found in the first-level cache of the Bloom filter, determine that the first executable file is untrustworthy; if the key attribute string of the first executable file is found in the first-level cache of the Bloom filter, search for the multidimensional file attribute data of the first executable file in the second-level cache of the sharded hash table; if the multidimensional file attribute data of the first executable file is not found in the second-level cache of the sharded hash table, determine that the first executable file is untrustworthy; if the multidimensional file attribute data of the first executable file is found in the second-level cache of the sharded hash table, determine that the first executable file is trustworthy.

[0136] Optionally, the metric unit is further configured to: invoke a first hash algorithm to perform a hash operation on the key attribute string of the first executable file to obtain a first shard index; if a first shard position corresponding to the first shard index exists in the first-level cache, invoke multiple second hash algorithms to perform a hash operation on the key attribute string of the first executable file to obtain multiple first indices, wherein the multiple second hash algorithms are different, and the multiple first indices correspond one-to-one with the multiple second hash algorithms; wherein, if a shard position corresponding to the first shard index does not exist in the first-level cache, it is determined that the first-level cache of the Bloom filter does not hit the key attribute string of the first executable file; if at least one of the values ​​corresponding to the multiple first indices in the bit array of the first shard position is not a target value, it is determined that the first-level cache of the Bloom filter does not hit the key attribute string of the first executable file; if all the values ​​corresponding to the multiple first indices in the bit array of the first shard position are target values, it is determined that the first-level cache of the Bloom filter hits the key attribute string of the first executable file.

[0137] Optionally, the metric unit is further configured to: invoke the first hash algorithm to perform a hash operation on the key attribute string of the trusted benchmark executable file to obtain a second shard index, thereby determining the second shard position corresponding to the second shard index in the first-level cache, each shard position corresponding to one of the Bloom filters; invoke the plurality of second hash algorithms to perform a hash operation on the key attribute string of the benchmark executable file to obtain a plurality of second indices; set the value corresponding to the plurality of second indices in the bit array of the second shard position to the target value, wherein the target value is different from the default value in the bit array.

[0138] Optionally, searching for the multidimensional file attribute data of the first executable file through the secondary cache of the sharded hash table includes: calling a third hash algorithm to perform a hash operation on the multidimensional file attribute data of the first executable file to obtain a third shard index; if a third shard position corresponding to the third shard index exists in the secondary cache, calling a fourth hash algorithm to perform a hash operation on the multidimensional file attribute data of the first executable file to obtain a first hash bucket index within the third shard position, wherein the fourth hash algorithm is different from the third hash algorithm; and searching for the first executable file in the first hash bucket corresponding to the first hash bucket index. The multidimensional file attribute data; wherein, if there is no shard position corresponding to the third shard index in the second-level cache, it is determined that the second-level cache of the shard hash table does not hit the multidimensional file attribute data of the first executable file; if at least one-dimensional file attribute data of the first executable file is not found in the first hash bucket, it is determined that the second-level cache of the shard hash table does not hit the multidimensional file attribute data of the first executable file; if the multidimensional file attribute data of the first executable file is found in the first hash bucket, it is determined that the second-level cache of the shard hash table hits the multidimensional file attribute data of the first executable file.

[0139] Optionally, the metric unit is further configured to: invoke the third hash algorithm to perform a hash operation on the multidimensional file attribute data of the trusted benchmark executable file to obtain a fourth shard index, thereby determining the fourth shard position corresponding to the fourth shard index in the secondary cache; invoke the fourth hash algorithm to perform a hash operation on the multidimensional file attribute data of the benchmark executable file to obtain a second hash bucket index within the fourth shard position; and save the multidimensional file attribute data of the benchmark executable file to the second hash bucket corresponding to the second hash bucket index.

[0140] Optionally, the measurement unit is also used to: after obtaining the multidimensional file attribute data of the first executable file, if there are multiple first executable files to be measured, use a thread pool to process the measurement tasks of multiple first executable files in parallel.

[0141] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should also be noted that the above modules, as part of the device, can run in a corresponding hardware environment, and can be implemented through software or hardware, wherein the hardware environment includes a network environment.

[0142] According to another aspect of the embodiments of this application, a server or trusted terminal is also provided for implementing the above-described static measurement method for a trusted computing scenario based on a dual-architecture system.

[0143] This solution is applicable to a dual-architecture system (i.e., a computing subsystem and a security subsystem) that operates in parallel with security measures. The computing and security subsystems are securely isolated from each other and can interact through a dedicated access channel. The security subsystem has higher control privileges than the computing subsystem. It can access the computing subsystem's memory and I / O peripherals without restriction, and it can also control the computing subsystem. However, the computing subsystem cannot access the security subsystem's memory or I / O peripherals, nor can it control the security subsystem. The computing and security subsystems have their own independent hardware resources to support computing and security tasks, including CPU, memory, and storage.

[0144] To facilitate the modification of existing computer motherboards (i.e., computing subsystems), the protection subsystem of this application, a novel external board type, can be adopted. This board integrates core components such as TPCM, TCM, BIOS chip (including BIOS1, BIOS2, and BIOS3), timing control circuit CPLD (denoted as CPLD2, while the CPLD on the computer motherboard is denoted as CPLD1), and standard interfaces into the board. The card slots, motherboard, circuits, and other hardware on the computer motherboard do not need to be customized. The original BIOS chip position on the motherboard can be left unused by installing a socket. Then, the signal lines originally connected to the BIOS chip can be guided to the external board through methods such as flying wires (i.e., directly soldering thin wires) or pins.

[0145] When the motherboard powers on and loads the BIOS, CPLD2, under its control, receives a reset signal from BIOS1 (the signal sending module) and continuously sends a reset signal to the CPU, preventing the CPU from entering execution mode. Simultaneously, CPLD2 wakes up the TPCM (causing it to boot before the CPU). The TPCM performs a self-test and then verifies the integrity of CPLD2 and the BIOS (BIOS2 and BIOS3). If the verification fails, the motherboard does not boot. If the verification succeeds, the TPCM interacts with CPLD2 to release the reset signal control, triggering the CPU to boot, and then continues the other boot processes, establishing a trust chain. This method ensures the security and integrity of the system boot process. The TPCM connects to the motherboard via an interface for data transmission and command interaction. It can directly access the motherboard's memory to read and measure memory data and control processes within it. Through its proactive measurement mechanism, the TPCM can proactively initiate real-time measurements of the system and application running status during system operation, ensuring that critical information is not illegally altered and guaranteeing the safe and stable operation of the system and applications.

[0146] BIOS1 is a signal transmission module. It begins sending reset signals upon power-up and before TPCM verification. Its code contains reset signal transmission logic. Physical protection ensures attackers cannot modify the initial control logic. Physical write protection combined with digital signature verification meets the basic requirements of trusted computing. BIOS2 is a read-only area used to store unmodifiable code. Through board locking, unmodifiable code (such as initialization code and trusted measurement logic) is permanently stored in the read-only area. Static logic is also stored there. Hardware locks (such as fuses and write-protection pins) prevent accidental modification or tampering. The read-only code undergoes signature verification, and TPCM verifies its integrity during initialization. This dual-layered physical and logical defense design enhances the BIOS's trustworthiness and security. BIOS3 is a read-write-configurable area. Its configuration items mainly involve hardware parameters. The physical storage blocks of the configuration item area only allow write operations authorized by TPCM. The SPI interface for the configuration item area... The Flash chip select signal is controlled by CPLD2. By default, the motherboard's access to the configuration item area is disconnected. Only after authorization by TPCM will CPLD2 switch control of the SPI bus to the motherboard, allowing temporary access. The process is as follows: the motherboard sends a configuration item read / write request to TPCM and provides a short-term access token issued by TPCM. TPCM generates a one-time session key. After completing authentication and permission checks, TPCM sends an authorization command to CPLD2, dynamically enabling hardware permissions. At the same time, write operations are encrypted and protected for integrity when writing configuration items. All configuration item modification records are signed by TPCM and written to the secure storage area to prevent log tampering.The read / write area stores the parts that need to be dynamically updated and modified by authorized entities. Access control for this part is handled by the TPCM. This may include frequently written content such as user settings, log data, runtime data, temporary data, and firmware update cache. The TPCM strictly restricts access permissions through access control policies. For example, the write process is as follows: the motherboard sends a write request to the TPCM, including the target address, plaintext data, and operation certificate. The TPCM verifies the motherboard's identity, checks operation permissions, generates a unique root key for the device, and derives a session key (such as an SM4 key) based on the request context. Plaintext data is then encrypted using the session key. For integrity protection, the TPCM writes ciphertext to the read / write area via a hardware isolation bus (such as a private SPI channel). Simultaneously, operation details (operator, time, target address hash) are signed by the TPCM and written to the security log area. The read process is as follows: the motherboard sends a read request to the TPCM, the TPCM verifies authorization and generates a temporary decryption token, the TPCM reads the ciphertext data from the read / write area, decrypts the data using the session key, and the plaintext is only cached in the TPCM's internal secure memory. The plaintext is returned to the motherboard via an encrypted channel, and the cache is immediately cleared upon completion. Simultaneously, operation details are signed by the TPCM and written to the security log area to prevent log tampering.

[0147] Utilizing the dual architecture with the aforementioned external boards, a trusted operation control strategy can be rapidly generated based on big data in a trusted environment: 1) Collect multi-dimensional data, call the trusted agent of the trusted terminal to detect the multi-dimensional data of the trusted process in its computing component in the trusted security environment, including static characteristics (execution type, file hash, file signature, file permissions, dependency library information, compilation time, compiler version, file digital certificate information, file modification time and access permission change history), dynamic characteristics (memory usage, CPU utilization, opened files, network access connections, system call sequence, memory request permissions, interaction behavior with other processes, resource consumption trends, abnormal exit and crash information), contextual characteristics (parent process, user, group, startup parameters, runtime environment variables, working directory and file system mount point), and sensitive behavior characteristics (accessed sensitive files, queried specific network ports, accessed critical system resources, monitoring records of processes with special markers); 2) Update the whitelist, clean, standardize and normalize this four-dimensional data on the server. The data set of this four-dimensional data constitutes all the static fingerprint information of the trusted process. Data such as file hashes, signatures, and permissions, as well as dynamic action access ranges (such as memory usage ranges and memory allocation attributes), are used as the basis for updating the whitelist and sent to trusted terminals. During operation, trusted terminals collect four-dimensional data of trusted processes and compare them with the whitelist. If a process is outside the whitelist's allowed range, it is reported to the server through a trusted proxy. The server checks the process, and if the change is within the allowed range (such as small changes or fewer than 3 fluctuating features), it is updated to the composite whitelist and sent to trusted terminals for further updates until the whitelist no longer changes. 3) The trusted whitelist benchmark is fed into the prediction strategy model for training. This model uses information from the whitelist to predict which processes are safe and which may be potential threats. Through iterative methods, the model can analyze process behavior characteristics, resource usage, and other data, and compare them with trusted processes in the whitelist to make predictions. 4) For any terminal using the dual-system architecture of this application, based on the prediction strategy model, execution control policies can be created and issued to the process to be controlled. These policies will guide the system on how to respond to different processes. For example, for processes predicted to be trustworthy, the system can grant them normal running privileges and resource allocation; while for processes predicted to be potential threats, the system can take measures such as restricting their operation, isolating and observing them, or terminating them.

[0148] For trusted terminals with a dual architecture using the above external boards, if the Linux kernel of the trusted terminal has the CONFIG_JUMP_LABLE compilation option enabled, then the server acting as the trusted management center can generate and send verification content to the trusted terminal based on the characteristics that the Jump Label will not change after loading, the instructions of the static code marked by the Jump Label are the same after each compilation, and the instructions of the dynamic code marked by the Jump Label may change after each compilation. This allows for the measurement of the Linux system running on the computing component of the trusted terminal. If the measurement passes, it indicates that the Linux system is trustworthy; otherwise, its operation is restricted according to the corresponding control policy. Specifically, the following steps are taken: 1) The baseline value can be generated directly on the trusted terminal. When the Linux kernel code of the trusted terminal runs for the first time, the hash value of the Jump Label table is calculated to obtain the baseline value of the Jump Label table, which is then stored in the baseline value library. The hash value of the static code marked in the Jump Label table is calculated to obtain the baseline value of the static code, which is also stored in the baseline value library. The Jump Label table is measured, and after the measurement passes, key verification information is extracted from the Jump Label table and stored in the baseline value library. Alternatively, the baseline value library can be generated using verification content issued by the Trusted Management Center. The baseline value of the static code in the issued verification content is directly stored in the baseline value library. The address of the Jump Label table in the issued verification content is converted, and then the hash value of the Jump Label table is calculated using TPCM to obtain the baseline value of the Jump Label table, which is then stored in the baseline value library. After converting the address of the Jump Label table in the issued verification content, the baseline value of the static code is extracted from the Jump Label table and stored in the baseline value library. 1) Extract key verification information from the Label table and store it in the benchmark value library; 2) Verify the benchmark value: The trusted terminal calculates the hash value of the local Jump Label table and compares it with the benchmark value of the Jump Label table in the benchmark value library to measure the Jump Label table. It also calculates the hash value of the static code marked in the local Jump Label table and compares it with the benchmark value of the static code marked in the Jump Label table in the benchmark value library to measure the static code marked in the Jump Label table. Finally, it compares the key information in the dynamic code marked in the local Jump Label table with the key verification information of the Jump Label table in the benchmark value library to measure the dynamic code marked in the Jump Label table.

[0149] Figure 13 This is a structural block diagram of a trusted terminal according to an embodiment of this application, such as... Figure 13 As shown, the terminal may include: one or more (only one is shown in the figure) processors 1301, memory 1303, and transmission devices 1305, such as... Figure 13 As shown, the terminal may also include input / output devices 1307.

[0150] The memory 1303 can be used to store software programs and modules, such as the program instructions / modules corresponding to the static measurement method and device based on the dual-architecture trusted computing scenario in this embodiment. The processor 1301 executes various functional applications and data processing by running the software programs and modules stored in the memory 1303, thereby realizing the aforementioned static measurement method based on the dual-architecture trusted computing scenario. The memory 1303 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1303 may further include memory remotely located relative to the processor 1301, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0151] The aforementioned transmission device 1305 is used to receive or send data via a network, and can also be used for data transfer between the processor and memory. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 1305 includes a Network Interface Controller (NIC), which can be connected to other network devices and routers via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 1305 is a radio frequency (RF) module used for wireless communication with the Internet.

[0152] Specifically, memory 1303 is used to store application programs.

[0153] The processor 1301 can invoke the application program stored in the memory 1303 via the transmission device 1305 to perform the following steps:

[0154] Obtain multidimensional file attribute data of a first executable file, wherein the first executable file is the executable file to be measured; if the key attribute string in the multidimensional file attribute data of the first executable file is hit in the first-level cache of the Bloom filter and the multidimensional file attribute data of the first executable file is hit in the second-level cache of the sharded hash table, the first executable file is determined to be trustworthy; otherwise, the first executable file is determined to be untrustworthy; wherein the key attribute string includes at least two dimensions of file attribute data in the multidimensional file attribute data of the first executable file, the Bloom filter is generated based on the key attribute string in the multidimensional file attribute data of the benchmark executable file, and the sharded hash table is generated based on the multidimensional file attribute data of the benchmark executable file.

[0155] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0156] Those skilled in the art will understand that Figure 13 The structure shown is for illustrative purposes only. The terminal can be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal devices. Figure 13 This does not limit the structure of the aforementioned electronic device. For example, the terminal may also include components that are more... Figure 13 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 13 The different configurations shown.

[0157] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0158] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to execute program code for a static measurement method based on a dual-architecture trusted computing scenario.

[0159] Optionally, in this embodiment, the storage medium may be located on at least one of the network devices in the network shown in the above embodiment.

[0160] Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps:

[0161] Obtain multidimensional file attribute data of a first executable file, wherein the first executable file is the executable file to be measured; if the key attribute string in the multidimensional file attribute data of the first executable file is hit in the first-level cache of the Bloom filter and the multidimensional file attribute data of the first executable file is hit in the second-level cache of the sharded hash table, the first executable file is determined to be trustworthy; otherwise, the first executable file is determined to be untrustworthy; wherein the key attribute string includes at least two dimensions of file attribute data in the multidimensional file attribute data of the first executable file, the Bloom filter is generated based on the key attribute string in the multidimensional file attribute data of the benchmark executable file, and the sharded hash table is generated based on the multidimensional file attribute data of the benchmark executable file.

[0162] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0163] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0164] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0165] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0166] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0167] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

[0168] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0169] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0170] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A static measurement method for trusted computing scenarios based on a dual-architecture model, characterized in that, include: Obtain multidimensional file attribute data of the first executable file, wherein the first executable file is the executable file to be measured; If the key attribute string in the multidimensional file attribute data of the first executable file is hit in the first-level cache of the Bloom filter and the multidimensional file attribute data of the first executable file is hit in the second-level cache of the sharded hash table, the first executable file is determined to be trustworthy; otherwise, the first executable file is determined to be untrustworthy. The key attribute string includes at least two-dimensional file attribute data from the multidimensional file attribute data of the first executable file, the Bloom filter is generated based on the key attribute string from the multidimensional file attribute data of the benchmark executable file, and the sharded hash table is generated based on the multidimensional file attribute data of the benchmark executable file.

2. The method according to claim 1, characterized in that, If the key attribute string in the multidimensional file attribute data of the first executable file is hit in the first-level cache of the Bloom filter, and the multidimensional file attribute data of the first executable file is hit in the second-level cache of the sharded hash table, then the first executable file is determined to be trustworthy; otherwise, the first executable file is determined to be untrustworthy, including: The key attribute string of the first executable file is searched through the first-level cache of the Bloom filter; If the critical attribute string of the first executable file is not hit in the first-level cache of the Bloom filter, the first executable file is determined to be untrusted. If the first-level cache of the Bloom filter hits the key attribute string of the first executable file, the multidimensional file attribute data of the first executable file is searched through the second-level cache of the sharded hash table; If the multidimensional file attribute data of the first executable file is not found in the secondary cache of the fragmented hash table, the first executable file is determined to be untrustworthy. If the multidimensional file attribute data of the first executable file is hit in the secondary cache of the sharded hash table, the first executable file is determined to be trustworthy.

3. The method according to claim 2, characterized in that, The first executable file's key attribute strings are searched through the first-level cache of the Bloom filter, including: The first hash algorithm is invoked to perform a hash operation on the key attribute string of the first executable file to obtain the first slice index; If a first shard position corresponding to the first shard index exists in the first-level cache, multiple second hash algorithms are invoked to perform hash operations on the key attribute string of the first executable file to obtain multiple first indices. The multiple second hash algorithms are different, and the multiple first indices correspond one-to-one with the multiple second hash algorithms. Specifically, if there is no shard position corresponding to the first shard index in the first-level cache, it is determined that the first-level cache of the Bloom filter has not hit the key attribute string of the first executable file; if at least one of the values ​​corresponding to the plurality of first indices in the bit array of the first shard position is not a target value, it is determined that the first-level cache of the Bloom filter has not hit the key attribute string of the first executable file; if all the values ​​corresponding to the plurality of first indices in the bit array of the first shard position are target values, it is determined that the first-level cache of the Bloom filter has hit the key attribute string of the first executable file.

4. The method according to claim 3, characterized in that, Before obtaining the multidimensional file attribute data of the first executable file, the method further includes: The first hash algorithm is invoked to perform a hash operation on the key attribute string of the trusted baseline executable file to obtain the second shard index, thereby determining the second shard position corresponding to the second shard index in the first-level cache, and each shard position corresponds to one Bloom filter; The multiple second hash algorithms are invoked to perform hash operations on the key attribute strings of the baseline executable file, resulting in multiple second indices; Set the values ​​corresponding to the plurality of second indices in the bit array at the second slice position to the target value, wherein the target value is different from the default value in the bit array.

5. The method according to claim 2, characterized in that, The multidimensional file attribute data of the first executable file is retrieved through the second-level cache of the fragmented hash table, including: The third hash algorithm is called to perform a hash operation on the multidimensional file attribute data of the first executable file to obtain the third slice index; If a third shard position corresponding to the third shard index exists in the secondary cache, the fourth hash algorithm is called to perform a hash operation on the multidimensional file attribute data of the first executable file to obtain the first hash bucket index within the third shard position. The fourth hash algorithm is different from the third hash algorithm. Search for the multidimensional file attribute data of the first executable file in the first hash bucket corresponding to the first hash bucket index; Specifically, if no shard position corresponding to the third shard index exists in the secondary cache, it is determined that the secondary cache of the shard hash table does not contain the multidimensional file attribute data of the first executable file; if at least one-dimensional file attribute data of the first executable file is not found in the first hash bucket, it is determined that the secondary cache of the shard hash table does not contain the multidimensional file attribute data of the first executable file; if the multidimensional file attribute data of the first executable file is found in the first hash bucket, it is determined that the secondary cache of the shard hash table contains the multidimensional file attribute data of the first executable file.

6. The method according to claim 5, characterized in that, Before obtaining the multidimensional file attribute data of the first executable file, the method further includes: The third hash algorithm is invoked to perform a hash operation on the multidimensional file attribute data of the trusted baseline executable file to obtain the fourth slice index, thereby determining the fourth slice position corresponding to the fourth slice index in the second-level cache. The fourth hash algorithm is invoked to perform a hash operation on the multidimensional file attribute data of the baseline executable file to obtain the second hash bucket index within the fourth slice location; The multidimensional file attribute data of the benchmark executable file is saved to the second hash bucket corresponding to the second hash bucket index.

7. The method according to any one of claims 1 to 6, characterized in that, After obtaining the multidimensional file attribute data of the first executable file, the method further includes: When there are multiple first executable files to be measured, a thread pool is used to process the measurement tasks of multiple first executable files in parallel.

8. A static measurement device for a trusted computing scenario based on a dual-architecture system, characterized in that, include: The acquisition unit is used to acquire multidimensional file attribute data of the first executable file, wherein the first executable file is the executable file to be measured; The measurement unit is used to determine that the first executable file is trustworthy if the key attribute string in the multidimensional file attribute data of the first executable file is hit in the first-level cache of the Bloom filter and the multidimensional file attribute data of the first executable file is hit in the second-level cache of the sharded hash table; otherwise, it determines that the first executable file is untrustworthy. The key attribute string includes at least two-dimensional file attribute data from the multidimensional file attribute data of the first executable file, the Bloom filter is generated based on the key attribute string from the multidimensional file attribute data of the benchmark executable file, and the sharded hash table is generated based on the multidimensional file attribute data of the benchmark executable file.

9. A computer-readable storage medium, characterized in that, The storage medium includes a stored program, wherein the program executes the method described in any one of claims 1 to 7 when it is run.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the method described in any one of claims 1 to 7 through the computer program.

Images