Trusted computing based whitelist measurement method, system, and medium, client

Abstract

The application discloses a kind of based on trusted computing's white list measurement method, system and medium, client.The method is used for client, client includes trusted agent service and Linux kernel hook function, method includes: trusted agent service receives measurement request, and according to measurement request determines the category of measurement object, and according to the category of measurement object selects corresponding measurement strategy and system white list, wherein, the category of measurement object includes static measurement object and dynamic measurement object;Linux kernel hook function, measurement object is measured using the selected measurement strategy and system white list, and measurement data is written into the bidirectional list of Linux kernel.The method defines the trusted root node of embedded terminal, and can be trusted from boot, kernel to application APP Whole chain's authentication.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a whitelist measurement method, system, medium, and client based on trusted computing. Background Technology

[0002] Information security typically encompasses three factors: confidentiality, integrity, and availability. With technological advancements, higher demands are being placed on the confidentiality and integrity of computer systems. To prevent computer systems from being subjected to more sophisticated external attacks—for example, hackers exploit the memory-mapped execution feature of Linux operating systems—they modify the memory-mapped process code to achieve their system attack objectives.

[0003] To address this, a method for dynamically measuring Linux kernel processes has been proposed in related technologies. This method includes: importing a measurement file (including a pre-defined executable ELF file) into the Linux kernel space; executing a program and comparing the first code of the executable ELF file with the first pre-defined code; if they are inconsistent, an alarm log is generated; when running the program and verifying the correctness of its bprm file, comparing the second code read from the executable ELF file with the second pre-defined code; if they are inconsistent, an alarm log is generated; after the program calls the __schedule() function, comparing the third code included in the process pointed to by the current macro with the third pre-defined code; if they are inconsistent, an alarm log is generated. However, this method only dynamically measures the process executing the executable ELF file, making the measurement method too limited. Furthermore, this method uses the procfs interface and the mmap() function to import the measurement file into the Linux kernel space for dynamic measurement, which requires a large amount of high-end memory. Summary of the Invention

[0004] The purpose of this invention is to propose a whitelist measurement method, system, medium, and client based on trusted computing, so as to perform trusted verification across the entire chain from boot and kernel to application APP by defining a trusted root node of the embedded terminal.

[0005] To achieve the above objectives, a first aspect of the present invention proposes a whitelist measurement method based on trusted computing. The method is used on a client, which includes a trusted proxy service and a Linux kernel hook function. The method includes: the trusted proxy service receiving a measurement request, determining the category of the measurement object based on the measurement request, and selecting a corresponding measurement strategy and system whitelist based on the category of the measurement object, wherein the category of the measurement object includes static measurement objects and dynamic measurement objects; and the Linux kernel hook function measuring the measurement object using the selected measurement strategy and system whitelist, and writing the measurement data into a doubly linked list in the Linux kernel.

[0006] In addition, the whitelist measurement method based on trusted computing in the above embodiments of the present invention may also have the following additional technical features:

[0007] According to an embodiment of the present invention, the method further includes: when the trusted proxy service detects a software upgrade or installation, sending a whitelist addition request to the management center, receiving a whitelist addition policy issued by the management center in response to the whitelist addition request, and updating the system whitelist according to the whitelist addition policy.

[0008] According to one embodiment of the present invention, the system whitelist includes a static metric whitelist and a dynamic metric whitelist. Updating the system whitelist according to the whitelist addition strategy includes: determining a target process according to the whitelist addition strategy; scanning files in the directory corresponding to the target process, calculating the hash value of the file, and storing the file's hash value, file size, file creation time, and file path in the static metric whitelist; and reading the ELF file corresponding to the target process, calculating the hash value of the ELF file, and storing the hash value of the ELF file in the dynamic metric whitelist.

[0009] According to an embodiment of the present invention, the static metric whitelist includes an application whitelist and a configuration whitelist, and the files in the corresponding directory include application files and configuration files. The hash value, size, creation time, and path of the application files are stored in the application whitelist, and the hash value, size, creation time, and path of the configuration files are stored in the configuration whitelist.

[0010] According to an embodiment of the present invention, when the category of the measurement object is a static measurement object, the step of measuring the measurement object using the selected measurement strategy and the system whitelist includes: calculating the hash value of the measurement object to obtain a first hash value; matching the first hash value with the hash values ​​in the selected static measurement whitelist; if the matching fails, generating corresponding measurement data according to the target static measurement mode.

[0011] According to one embodiment of the present invention, when the target static measurement mode is an alarm mode, alarm measurement data is generated; when the target static measurement mode is an interception mode, interception measurement data is generated.

[0012] According to one embodiment of the present invention, the trusted proxy service receives a mode configuration policy issued by the management center and configures the target static measurement mode according to the configuration policy.

[0013] According to an embodiment of the present invention, when the category of the measurement object is a dynamic measurement object, the step of measuring the measurement object using the selected measurement strategy and the system whitelist includes: calculating the hash value of the measurement object to obtain a second hash value; matching the second hash value with the hash value in the selected dynamic measurement whitelist; and generating corresponding alarm measurement data if the matching fails.

[0014] According to one embodiment of the present invention, the method further includes: the trusted proxy service periodically reading the measurement data in the doubly linked list and reporting the read measurement data to a local database and / or a remote database.

[0015] To achieve the above objectives, a second aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, it implements the aforementioned whitelist measurement method based on trusted computing.

[0016] To achieve the above objectives, a third aspect of the present invention provides a client comprising: a trusted proxy service, configured to receive a measurement request, determine the category of the measurement object based on the measurement request, and select a corresponding measurement strategy and system whitelist based on the category of the measurement object, wherein the category of the measurement object includes static measurement objects and dynamic measurement objects; and a Linux kernel hook function, configured to measure the measurement object using the selected measurement strategy and system whitelist, and write the measurement data into a doubly linked list in the Linux kernel.

[0017] In addition, the client of the above embodiments of the present invention may also have the following additional technical features:

[0018] According to one embodiment of the present invention, the trusted proxy service is further configured to: send a whitelist addition request to the management center when a software upgrade or installation is detected, receive a whitelist addition policy issued by the management center in response to the whitelist addition request, and update the system whitelist according to the whitelist addition policy.

[0019] According to one embodiment of the present invention, the system whitelist includes a static measurement whitelist and a dynamic measurement whitelist. When the trusted proxy service updates the system whitelist according to the whitelist addition policy, it specifically performs the following steps: determining the target process according to the whitelist addition policy; scanning the files in the directory corresponding to the target process, calculating the hash value of the file, and storing the hash value, file size, file creation time, and file path of the file in the static measurement whitelist; and reading the ELF file corresponding to the target process, calculating the hash value of the ELF file, and storing the hash value of the ELF file in the dynamic measurement whitelist.

[0020] To achieve the above objectives, a fourth aspect of the present invention proposes a whitelist measurement system based on trusted computing. The system includes: the aforementioned client; and a management center, configured to receive a whitelist addition request sent by the client's trusted proxy service when it detects a software upgrade or installation, and to issue a corresponding whitelist addition policy to the trusted proxy service in response to the whitelist addition request, so that the trusted proxy service updates the system whitelist according to the whitelist addition policy.

[0021] This invention discloses a trusted computing-based whitelist measurement method, system, medium, and client. It defines a trusted root node for the client, enabling trusted verification across the entire chain from boot and kernel to the application (APP). Specifically, it utilizes a whitelist library and a whitelist management mechanism to control the operation and installation of client software, ensuring that illegal or unauthorized applications cannot execute. This guarantees the secure and stable operation of the client and avoids the drawbacks of endlessly searching for malicious programs and code, as well as the lagging nature of blacklist mechanisms. Simultaneously, the generated measurement data is written to a doubly linked list in the Linux kernel, preventing other processes from viewing it and ensuring the integrity of the measurement data. Attached Figure Description

[0022] Figure 1 This is a flowchart of the whitelist measurement method based on trusted computing in the first embodiment of the present invention;

[0023] Figure 2 This is a flowchart of the whitelist measurement method based on trusted computing according to the second embodiment of the present invention;

[0024] Figure 3This is a flowchart of the whitelist measurement method based on trusted computing, according to the third embodiment of the present invention.

[0025] Figure 4 This is a flowchart of the whitelist measurement method based on trusted computing according to the fourth embodiment of the present invention;

[0026] Figure 5 This is a structural diagram of the client in an embodiment of the present invention;

[0027] Figure 6 This is a flowchart of the whitelist measurement method based on trusted computing according to the fifth embodiment of the present invention;

[0028] Figure 7 This is a structural diagram of a whitelist measurement system based on trusted computing, according to an embodiment of the present invention. Detailed Implementation

[0029] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0030] The following description, with reference to the accompanying drawings, illustrates the whitelist measurement method, system, medium, and client based on trusted computing proposed in embodiments of the present invention.

[0031] Figure 1 This is a flowchart of a whitelist measurement method based on trusted computing, according to an embodiment of the present invention. The method is used on a client, which includes a trusted proxy service and Linux kernel hook functions.

[0032] like Figure 1 As shown, the method includes:

[0033] S11, the trusted proxy service receives the measurement request, determines the category of the measurement object based on the measurement request, and selects the corresponding measurement strategy and system whitelist based on the category of the measurement object. The categories of the measurement object include static measurement objects and dynamic measurement objects.

[0034] Specifically, the whitelist types for the trusted proxy service include bprm executables, dynamic libraries, shell scripts, and configuration files. Each item in the whitelist requires four parameters: the hash value of the measured file path and content, the file's creation time, the file path, and the file size.

[0035] S12 is a Linux kernel hook function that uses the selected measurement strategy and system whitelist to measure the target object and writes the measurement data into a doubly linked list in the Linux kernel.

[0036] Therefore, this method defines a trusted root node for both static and dynamic measurement objects, enabling both static and dynamic measurements and providing trusted verification across the entire chain from boot and kernel to application (APP). Furthermore, writing the generated measurement data to a doubly linked list in the Linux kernel prevents other processes from viewing it, ensuring the integrity of the measurement data.

[0037] In some embodiments, the whitelist measurement method based on trusted computing may include: when a trusted proxy service detects a software upgrade or installation, it sends a whitelist addition request to the management center, receives a whitelist addition policy issued by the management center in response to the whitelist addition request, and updates the system whitelist according to the whitelist addition policy.

[0038] By updating the system whitelist upon completion of binary file compilation (i.e., software upgrade or installation), the recalculation of static and dynamic metric whitelists is eliminated, resolving the issues of numerous metric files and long deployment times. If the client needs to redeploy the software, only the binary file and whitelist need to be updated together to complete the deployment.

[0039] In some embodiments, such as Figure 2 As shown, the whitelist measurement method based on trusted computing may include: the system whitelist includes a static measurement whitelist and a dynamic measurement whitelist, and the system whitelist is updated according to the whitelist addition strategy, including:

[0040] S21, determine the target process based on the whitelist addition strategy.

[0041] S22, scan the files in the directory corresponding to the target process, calculate the hash value of the file, and store the hash value, file size, file creation time, and file path of the file in the static metric whitelist.

[0042] S23, read the ELF file corresponding to the target process, calculate the hash value of the ELF file, and store the hash value of the ELF file in the dynamic metric whitelist.

[0043] Specifically, the four parameters in the static metrics (i.e., hash value, file size, file creation time, and file path) and the one parameter in the dynamic metrics (the hash value of the ELF file) can be directly written to the temporary release file when the binary file is compiled, thus solving the problem of many metric files and long deployment time during deployment.

[0044] In some embodiments, the whitelist measurement method based on trusted computing may include: a static measurement whitelist including an application whitelist and a configuration whitelist, and the files in the corresponding directory including application files and configuration files, wherein the hash value, application file size, application file creation time, and application file path of the application file are stored in the application whitelist, and the hash value, configuration file size, configuration file creation time, and configuration file path of the configuration file are stored in the configuration whitelist.

[0045] Specifically, whitelists can be set for applications and configuration files respectively, so that the corresponding whitelists can be directly called for matching during measurement, which can shorten the matching time.

[0046] In some embodiments, the whitelist measurement method based on trusted computing may include: generating alarm measurement data when the target static measurement mode is alarm mode; and generating interception measurement data when the target static measurement mode is interception mode.

[0047] Specifically, when starting or stopping a process's measurement process, the Linux kernel calls the hook function of the LSM (Linux Security Module) module to check if the process's hash value matches the hash value in the application's whitelist. If they don't match, it indicates that the process has been tampered with. At this point, if alert mode is set, an alert message is generated and stored in the doubly linked alert list; if interception mode is set, a non-zero return value will indicate that the measurement failed. Simultaneously, the client system can return error messages based on the error enumeration.

[0048] In some embodiments, the whitelist measurement method based on trusted computing may include: the trusted proxy service receiving the mode configuration policy issued by the management center and configuring the target static measurement mode according to the configuration policy.

[0049] Specifically, the target static measurement mode can be set to alarm mode or interception mode as needed.

[0050] In some embodiments, the whitelist measurement method based on trusted computing may include: a trusted proxy service periodically reading measurement data from a doubly linked list and reporting the read measurement data to a local database and / or a remote database. This facilitates subsequent viewing.

[0051] In some embodiments, such as Figure 3 As shown, the whitelist-based measurement method based on trusted computing may include: when the category of the measurement object is a static measurement object, measuring the measurement object using the selected measurement strategy and the system whitelist, including:

[0052] S31, calculate the hash value of the measurement object to obtain the first hash value.

[0053] S32, match the first hash value with the hash values ​​in the selected static metric whitelist.

[0054] S33. If the match fails, the corresponding measurement data will be generated according to the target static measurement mode.

[0055] Specifically, the static measurement process can include the following three aspects:

[0056] Firstly, the measurement process for a process is started or stopped. The Linux kernel calls the hook function of the LSM (Linux Security Module) module to check whether the process's hash value matches the hash values ​​in the whitelist. If they do not match, it indicates that the process has been tampered with, and corresponding measurement data is generated according to the target static measurement pattern.

[0057] Secondly, modify the configuration file measurement process. If you want to modify the configuration whitelist, first check if the process that modifies the configuration file has permission to do so, that is, whether its hash value exists in the process whitelist. If it exists, you can modify it directly; otherwise, return an error.

[0058] Thirdly, the process access permission measurement process. Different processes have different access permissions for certain paths and files. When it is determined through hash value matching that a file or path cannot be accessed by the current process, the current process will fail to open it.

[0059] In some embodiments, such as Figure 4 As shown, the whitelist-based measurement method based on trusted computing may include: when the category of the measurement object is a dynamic measurement object, measuring the measurement object using the selected measurement strategy and the system whitelist, including:

[0060] S41, calculate the hash value of the measurement object to obtain the second hash value.

[0061] S42, match the second hash value with the hash values ​​in the selected dynamic metric whitelist.

[0062] S43. If a match fails, corresponding alarm metrics data will be generated.

[0063] Specifically, when the trusted agent program receives the scanning policy task, it performs a hash calculation on the code segment of the binary file and stores the hash value in the local database and the remote server. After the process starts, the Linux kernel calls the hook function of the LSM (Linux Security Module) module. The hook function periodically retrieves the data of the code segment in memory, calculates the hash value, and compares it with the hash values ​​of code segments in the whitelist. If they are not equal, audit information (i.e., measurement data) is generated and reported to the remote server.

[0064] In summary, the whitelist-based measurement method based on trusted computing in this invention defines a trusted root node for embedded terminals, enabling trusted verification across the entire chain from boot and kernel to application (APP). Specifically, it utilizes a whitelist library and a whitelist management mechanism to control the operation and installation of client software, ensuring that illegal or unauthorized applications cannot execute, thereby guaranteeing the secure and stable operation of the client. This avoids the drawbacks of blacklist mechanisms, such as endlessly searching for malicious programs and code and lagging protection. Simultaneously, the generated measurement data is written to a doubly linked list in the Linux kernel, preventing other processes from viewing it and ensuring the integrity of the measurement data.

[0065] Based on the aforementioned whitelist measurement method based on trusted computing, this embodiment of the invention also proposes a computer-readable storage medium.

[0066] In this embodiment, a computer program is stored on a computer-readable storage medium. When the computer program is executed by a processor, it implements the aforementioned whitelist measurement method based on trusted computing.

[0067] Figure 5 This is a structural diagram of the client in an embodiment of the present invention.

[0068] like Figure 5 As shown, client 500 includes trusted proxy service 501 and Linux kernel hook function 502.

[0069] Trusted proxy service 501 is used to receive measurement requests, determine the category of the measurement object based on the measurement request, and select the corresponding measurement strategy and system whitelist based on the category of the measurement object. The category of the measurement object includes static measurement objects and dynamic measurement objects. Linux kernel hook function 502 is used to measure the measurement object using the selected measurement strategy and system whitelist, and write the measurement data into the doubly linked list of the Linux kernel.

[0070] In some embodiments, the client 500 may further include: the trusted proxy service is also used to: send a whitelist addition request to the management center when a software upgrade or installation is detected, receive a whitelist addition policy issued by the management center in response to the whitelist addition request, and update the system whitelist according to the whitelist addition policy.

[0071] In some embodiments, client 500 may further include: a system whitelist including a static measurement whitelist and a dynamic measurement whitelist; when the trusted proxy service updates the system whitelist according to the whitelist addition policy, the method is as follows: Figure 6 As shown:

[0072] S61 determines the target process based on the whitelist addition strategy.

[0073] S62 scans the files in the directory corresponding to the target process, calculates the hash value of the file, and stores the hash value, file size, file creation time, and file path of the file in the static metric whitelist.

[0074] S63, read the ELF file corresponding to the target process, calculate the hash value of the ELF file, and store the hash value of the ELF file in the dynamic metric whitelist.

[0075] It should be noted that for other specific implementations of the client in the embodiments of the present invention, please refer to the specific implementation of the whitelist measurement method based on trusted computing in the above embodiments of the present invention.

[0076] The client in this embodiment of the invention defines a trusted root node for the embedded terminal, enabling trusted verification across the entire chain from boot and kernel to application (APP). Specifically, a whitelist library is used, employing a whitelist management mechanism to control the operation and installation of client software, ensuring that illegal or unauthorized applications cannot execute. This guarantees the secure and stable operation of the client, avoiding the endless searching for malicious programs and code, and the drawbacks of blacklist mechanisms such as lagging protection. Simultaneously, the generated measurement data is written to a doubly linked list in the Linux kernel, preventing other processes from viewing it and ensuring the integrity of the measurement data.

[0077] Figure 7 This is a structural diagram of a whitelist measurement system based on trusted computing, according to an embodiment of the present invention.

[0078] like Figure 7 As shown, system 700 includes client 500 and management center 701 as described in the above embodiments.

[0079] Management Center 701 is used to receive whitelist addition requests sent by the Trusted Proxy Service of Client 500 when a software upgrade or installation is detected, and to issue corresponding whitelist addition policies to the Trusted Proxy Service in response to the whitelist addition requests, so that the Trusted Proxy Service can update the system whitelist according to the whitelist addition policies.

[0080] The whitelist measurement system based on trusted computing in this invention can perform trusted verification across the entire chain from boot and kernel to application (APP). Simultaneously, the generated measurement data is written to a doubly linked list in the Linux kernel, preventing other processes from viewing it and ensuring the integrity of the measurement data.

[0081] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0082] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0083] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0084] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0085] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0086] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0087] In this invention, unless otherwise explicitly specified and limited, "above" or "below" the second feature can mean that the first feature is in direct contact with the second feature, or that the first feature is in indirect contact with the second feature through an intermediate medium. Furthermore, "above," "over," and "on top" of the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.

[0088] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A whitelist measurement method based on trusted computing, characterized in that, The method is used on a client that has a trusted proxy service and Linux kernel hook functions, and the method includes: The trusted proxy service receives a measurement request, determines the category of the measurement object based on the measurement request, and selects the corresponding measurement strategy and system whitelist based on the category of the measurement object. The category of the measurement object includes static measurement objects and dynamic measurement objects. The Linux kernel hook function uses the selected measurement strategy and system whitelist to measure the measurement object and writes the measurement data into the Linux kernel's doubly linked list. When the trusted proxy service detects a software upgrade or installation, it sends a whitelist addition request to the management center, receives the whitelist addition policy issued by the management center in response to the whitelist addition request, and updates the system whitelist according to the whitelist addition policy. The system whitelist includes a static metric whitelist and a dynamic metric whitelist. Updating the system whitelist according to the whitelist addition strategy includes: The target process is determined based on the whitelist addition strategy; Scan the files in the directory corresponding to the target process, calculate the hash value of each file, and store the hash value, file size, file creation time, and file path of each file in the static metric whitelist; and Read the ELF file corresponding to the target process, calculate the hash value of the ELF file, and store the hash value of the ELF file in the dynamic metric whitelist; When the category of the measurement object is a static measurement object, the step of measuring the measurement object using the selected measurement strategy and the system whitelist includes: The first hash value is obtained by calculating the hash value of the metric object; Match the first hash value with the hash values ​​in the selected static metric whitelist; If the match fails, the corresponding measurement data will be generated according to the target static measurement pattern; Specifically, when the target static measurement mode is alarm mode, alarm measurement data is generated; when the target static measurement mode is interception mode, interception measurement data is generated. In alarm mode, the generated alarm information is stored in an alarm doubly linked list, and in interception mode, a non-zero return value is used to determine measurement failure.

2. The method according to claim 1, characterized in that, The static metric whitelist includes an application whitelist and a configuration whitelist. The corresponding directory contains application files and configuration files. The application file's hash value, application file size, application file creation time, and application file path are stored in the application whitelist, and the configuration file's hash value, configuration file size, configuration file creation time, and configuration file path are stored in the configuration whitelist.

3. The method according to claim 1, characterized in that, The method further includes: The trusted proxy service receives the mode configuration policy issued by the management center and configures the target static measurement mode according to the configuration policy.

4. The method according to claim 1, characterized in that, When the category of the measurement object is a dynamic measurement object, the step of measuring the measurement object using the selected measurement strategy and system whitelist includes: The second hash value is obtained by calculating the hash value of the metric object; The second hash value is matched with the hash values ​​in the selected dynamic metric whitelist; If a match fails, corresponding alarm metrics will be generated.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: The trusted proxy service periodically reads the measurement data from the doubly linked list and reports the read measurement data to the local database and / or remote database.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-5.

7. A client application, characterized in that, For implementing the method as described in any one of claims 1-5, comprising: A trusted proxy service is used to receive measurement requests, determine the category of the measurement object based on the measurement request, and select the corresponding measurement strategy and system whitelist based on the category of the measurement object. The category of the measurement object includes static measurement objects and dynamic measurement objects. Linux kernel hook functions are used to measure the object using the selected measurement strategy and system whitelist, and write the measurement data into a doubly linked list in the Linux kernel. The trusted proxy service is also used for: When a software upgrade or installation is detected, a whitelist addition request is sent to the management center, and the whitelist addition policy issued by the management center in response to the whitelist addition request is received, and the system whitelist is updated according to the whitelist addition policy. The system whitelist includes a static measurement whitelist and a dynamic measurement whitelist. When the trusted proxy service updates the system whitelist according to the whitelist addition policy, it is specifically used for: The target process is determined based on the whitelist addition strategy; Scan the files in the directory corresponding to the target process, calculate the hash value of each file, and store the hash value, file size, file creation time, and file path of each file in the static metric whitelist; and Read the ELF file corresponding to the target process, calculate the hash value of the ELF file, and store the hash value of the ELF file in the dynamic metric whitelist; When the category of the measurement object is a static measurement object, the step of measuring the measurement object using the selected measurement strategy and the system whitelist includes: The first hash value is obtained by calculating the hash value of the metric object; Match the first hash value with the hash values ​​in the selected static metric whitelist; If the match fails, the corresponding measurement data will be generated according to the target static measurement pattern; Specifically, when the target static measurement mode is alarm mode, alarm measurement data is generated; when the target static measurement mode is interception mode, interception measurement data is generated; wherein, in the alarm mode, the generated alarm information is stored in the alarm doubly linked list, and in the interception mode, a non-zero return value is used to determine that the measurement has failed.

8. A whitelist measurement system based on trusted computing, characterized in that, The system includes: The client according to claim 7; The management center is used to receive whitelist addition requests sent by the client's trusted proxy service when it detects software upgrades or installations, and to issue corresponding whitelist addition policies to the trusted proxy service in response to the whitelist addition requests, so that the trusted proxy service updates the system whitelist according to the whitelist addition policies.

Images