Software trusted measurement method, device and equipment and computer readable storage medium

Abstract

The invention discloses a software trusted measurement method, device and equipment and a computer readable storage medium. According to the method, an expected behavior state machine is directly constructed based on a non-interference model, the problems of dependence of dynamic modeling on training data and feasibility of static modeling are fundamentally avoided, and a universal and feasible new software behavior credibility measurement normal form is provided.

Description

Technical Field

[0001] This application relates to the field of software security technology, specifically to a software trust measurement method, apparatus, device, and computer-readable storage medium. Background Technology

[0002] Trust measurement technology is a key means of monitoring and verifying the behavior of software during runtime. Currently, mainstream trust measurement technologies are divided into two categories: dynamic measurement and static measurement.

[0003] Dynamic metrics statistically generate behavioral models by running target software extensively in a controlled environment and collecting data on its benign behavior (such as system call sequences). This approach heavily relies on the coverage of training data and the runtime environment, and cannot exhaust all possible execution paths of the software, resulting in incomplete models that may fail when faced with unfamiliar inputs or environments. Static metrics, on the other hand, directly analyze the software's source code or binary code to deduce all possible execution paths and behaviors. However, this method is often difficult to obtain source code for, and static analysis of binary code is extremely complex, highly dependent on specific platforms and compilers, and lacks versatility.

[0004] Therefore, existing feasible measurement methods face the dilemma of insufficient model completeness or poor implementation feasibility. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a software trust measurement method, apparatus, device, and computer-readable storage medium.

[0006] In a first aspect, embodiments of this application provide a software trust measurement method, the software trust measurement method comprising: The security policy and the specified final security domain are constructed in the expected behavior state machine based on the non-interference model, wherein the security policy defines the interference or non-interference relationship between security domains. Acquire the atomic actions of the software to be measured during its operation, and construct the actual behavior sequence based on the acquired atomic actions; Based on the expected behavior state machine, a weak expectation function is used to calculate the expected behavior sequence corresponding to the actual behavior sequence, wherein the weak expectation function is used to filter out atomic actions that have an interfering relationship with the final security domain from the actual behavior sequence to form the expected behavior sequence. The credibility of the software to be measured is determined based on the actual behavior sequence and the expected behavior sequence.

[0007] Secondly, embodiments of this application provide a software trust measurement device, the software trust measurement device comprising: A definition module is used to construct a security policy in the expected behavior state machine based on a non-interference model and to specify the final security domain, wherein the security policy defines the interference or non-interference relationship between security domains; The acquisition module is used to acquire the atomic actions of the software to be measured during its operation and to construct the actual behavior sequence based on the acquired atomic actions. A construction module is used to calculate the expected behavior sequence corresponding to the actual behavior sequence based on the expected behavior state machine using a weak expectation function, wherein the weak expectation function is used to filter out atomic actions that have an interfering relationship with the final security domain from the actual behavior sequence to form the expected behavior sequence; The determination module is used to determine the credibility of the software to be measured based on the actual behavior sequence and the expected behavior sequence.

[0008] Thirdly, embodiments of this application provide a software trust measurement device, which includes a processor, a memory, and a software trust measurement program stored in the memory and executable by the processor, wherein when the software trust measurement program is executed by the processor, it implements the steps of the software trust measurement method as described in the first aspect.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing a software trust measurement program, wherein when the software trust measurement program is executed by a processor, it implements the steps of the software trust measurement method as described in the first aspect.

[0010] The beneficial effects of the technical solutions provided in this application include: In this embodiment, a security policy and a specified final security domain are constructed in the expected behavior state machine based on a non-interference model. The security policy defines the interference or non-interference relationships between security domains. Atomic actions of the software to be measured during operation are acquired, and an actual behavior sequence is constructed based on these actions. Based on the expected behavior state machine, a weak expectation function is used to calculate the expected behavior sequence corresponding to the actual behavior sequence. The weak expectation function is used to filter out atomic actions from the actual behavior sequence that have an interference relationship with the final security domain to form the expected behavior sequence. Based on the actual behavior sequence and the expected behavior sequence, the trustworthiness of the software to be measured is determined. Through this embodiment, the expected behavior state machine is directly constructed based on a non-interference model, fundamentally avoiding the dependence of dynamic modeling on training data and the feasibility problems of static modeling, providing a general and feasible new paradigm for software behavior trustworthiness measurement. Attached Figure Description

[0011] Figure 1This is a flowchart illustrating an embodiment of the software trust measurement method of this application; Figure 2 This is a flowchart illustrating another embodiment of the software trust measurement method of this application; Figure 3 In one embodiment, a dual architecture is provided where trusted computing nodes possess both computing and protection functions. Figure 4 This is a schematic diagram of the architecture upon which the software trust measurement method depends in one embodiment; Figure 5 This is a schematic diagram of the measurement module in one embodiment; Figure 6 This is a state transition diagram showing the actual and expected behavior in one embodiment; Figure 7 This is a schematic diagram of the functional modules of an embodiment of the software trust measurement device of this application; Figure 8 This is a schematic diagram of the hardware structure of the software trust measurement device involved in the embodiments of this application. Detailed Implementation

[0012] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0013] First, the background knowledge of the technical field to which this application pertains and the core ideas of the technical solution of this application are explained so that those skilled in the art can understand this application.

[0014] Trusted measurement technology is a key technology in trusted computing, and it is divided into two categories: static measurement and dynamic measurement. Static measurement, performed before the computing entity starts and control is transferred, uses signature or hash algorithms to calculate the measurement value of the static file of the object being measured, and compares it with a pre-recorded baseline value to determine whether the computing entity to be run meets expectations. Dynamic measurement, performed after the computing entity has gained control and is running, considers key aspects of its operation, such as its memory usage, execution environment, and software behavior.

[0015] Current dynamic metrics focus more on the integrity of runtime computational entities and are insufficient in measuring software behavior. Software behavior refers to the manifestation and state evolution of software operation, which can be characterized at different levels, from low-level binary instructions to high-level program statements, functions, and system calls. Since system calls are the interfaces provided by the operating system for applications to access system resources, software intrusion will be reflected in the executed system calls; therefore, the state of system calls can reflect the behavioral characteristics of the software to some extent. A system call-based software behavior model refers to a behavioral model used to characterize the normal behavioral characteristics of software, relying on system call-related information and a certain modeling method. Trustworthy dynamic metrics typically include the following four steps: (1) Construct behavioral expectations, i.e., collect baseline values; (2) Obtain runtime evidence of the measurement platform, that is, obtain the current measurement value of the process; (3) Credibility verification; (4) Behavioral decision-making.

[0016] For step one, based on the different methods of collecting software system call information during modeling, system call-based behavioral modeling can be mainly divided into dynamic modeling and static modeling. Dynamic modeling primarily utilizes dynamic training to establish a normal program behavior model. This method requires sufficient training data, extensive benign execution of the program, monitoring and recording system call information under these execution conditions to generate a behavioral model. The accuracy of its baseline values ​​depends on the external input during training, the execution environment, and the coverage of the training data; it cannot capture all possible execution paths of the program. Conversely, static modeling does not directly run the program but performs static analysis on the program's source code or binary code to extract relevant information such as system calls, thereby establishing a corresponding behavioral model. While static modeling can extract all possible execution paths, it is not always feasible because the source code is often unavailable, and static analysis of binary code is platform-dependent and complex.

[0017] Reliable dynamic metrics require constructing behavioral expectations. Since dynamic and static modeling each have their advantages and disadvantages, the accuracy of dynamic modeling benchmarks depends on the external input during training, the execution environment, and the coverage of the training data, making it impossible to capture all possible execution paths of the program. While static modeling can extract all possible execution paths, it is not always feasible; the source code is often unavailable, and static analysis of binary code is platform-dependent and complex. Therefore, other more effective methods need to be considered.

[0018] This application proposes a software trust measurement method. The basic idea is as follows: based on a non-interference model, and under the condition of satisfying the Reference Monitor Assumption (RMA), an actual behavior state machine and an expected behavior state machine are constructed. From the observer's perspective, the expected behavior state machine is equivalent to the actual behavior state machine under the corresponding interference / non-interference policy. The expected behavior state machine is not constructed using conventional dynamic or static modeling methods, but rather using a non-interference security policy. The expected behavior state machine includes the corresponding non-interference / interference security policy and the system's final security domain. When an actual behavior α is received, the corresponding security policy is executed, and it is determined whether the executed expected result behavior / state is consistent with the actual behavior / state.

[0019] The basic method of this application is to treat critical actions such as system calls as atomic actions, divide the corresponding atomic actions into security domains, regard the actual software behavior α as a sequence of critical actions, and calculate the expected behavior β based on the non-interference relationship between the security domains to which all critical actions in α belong. After obtaining α, β and the corresponding state, the consistency of behavior or system state is determined, thereby determining the trustworthiness of the software.

[0020] When the expected behavior state machine executes with atomic actions or action sequences α of the actual behavior, if the safety domain of atomic action a does not interfere with the final safety domain of the expected behavior state machine, then the corresponding atomic action in the expected behavior β of atomic action a is empty, and the state of the expected behavior state machine will not change. In this case, reliability can be determined by comparing whether α and β are consistent. Furthermore, in this scenario, the expected behavior state machine needs to perform less work, effectively simplifying the complexity of metric calculations. If the safety domain of atomic action a interferes with the final safety domain of the expected behavior state machine, then the behavior of the corresponding atomic action a in the expected behavior β is calculated to determine whether the behavior conforms to the policy and whether the corresponding state is normal.

[0021] Building state machines requires attention to atomic actions, and system calls are a primary type of atomic action. Existing software behavior models based on system calls either neglect parameters or are sensitive to direct or indirect modification of parameters. That is, they only consider the syntactic features of system calls, not their semantics. Direct or indirect modification of parameters can lead to the failure of reliable judgments. For example, directly modifying parameters—such as using different fd (file descriptor) values ​​in Linux that actually point to the same object—or indirectly modifying the file pointed to by the parameter—for example, using the same fd value but actually representing different objects—can also lead to inaccurate judgments.

[0022] This application parses the underlying system objects from system call parameters and constructs a software behavior model based on these system objects. The behavioral state of this model is represented by all system objects associated with the software, thus endowing the state with semantic information. Furthermore, since the behavioral state is associated with system calls, and system calls themselves can be considered atomic actions, the state of the software system is also linked to the software behavior. Simultaneously, by utilizing the state information in the actual behavioral state machine and combining it with object requirements in the security policy, the trustworthiness of objects is determined. Moreover, focusing solely on atomic actions of system call classes is insufficient; critical actions in user-mode that are not system calls, such as user-mode drivers, also require attention.

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0024] In a first aspect, embodiments of this application provide a method for measuring software trustworthiness.

[0025] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the software trustworthiness measurement method of this application. Figure 1 As shown, software trust measurement methods include: Step S10: Construct the security policy and specify the final security domain in the expected behavior state machine based on the non-interference model, wherein the security policy defines the interference or non-interference relationship between security domains; In this embodiment, during the preprocessing stage before the software to be measured runs, a security strategy is defined based on a non-interference model. The core of this strategy is defining a series of security domains and the interference or non-interference relationships between them. Based on this strategy, an Expected Behavior State Machine (EMA) is constructed, and a final security domain is specified.

[0026] Based on the non-interference model, the defined security policies include: Definition 1: A system M can be represented by a state machine, which contains the following elements: (1) A state machine S, which contains a unique initial state s0.

[0027] (2) A set of atomic actions A, which contains all atomic actions.

[0028] (3) A set of behaviors B, which contains all behaviors consisting of connections of atomic actions. If we use... Representing a connection of atomic actions, an example of an action is α=a0. a1 ...... a n , where ai (0≤i≤n)∈A.

[0029] (4) An output set O, which contains all the output results observed using atomic actions.

[0030] (5) A security domain set D, which contains all the security domains in the system.

[0031] (6) Interference relationship and non-interference relationship represent the authorization / prohibition of information flow between two security domains, respectively, and the two are complementary sets.

[0032] (7) Action-Security Domain Mapping Function dom: A→D, returns the security domain dom(a) to which each atomic action a∈A belongs.

[0033] (8) Single-step state transition function: step: S×A→S, describes the single-step state transition of system M.

[0034] (9) Multistep state transition function: multisteps: S×B→S. If Λ represents the empty action, then multisteps can be expressed as:

[0035] It describes the behavior α=a0 of system M when it performs actions from state s∈S. a1 ...... a n The new state that is reached afterward.

[0036] (10) Behcon: S×A→O, which gives the result o∈O that the outside world can observe when the system M is in a certain state s∈S and the action a∈A.

[0037] In this application, s, t, etc. are used to represent system states, a, b to represent atomic actions, α, β, γ, etc. to represent behaviors (sequences of atomic actions), and u, v, etc. to represent security domains.

[0038] The granularity of atomic actions in the above definition can vary, and can be input, program statements, function calls or system calls, commands or machine instructions, etc. After an atomic action is executed, system M transitions from one state to another.

[0039] Software behavior refers to the manifestation and state evolution of software operation. It can be characterized at different levels, from low-level binary instructions to high-level program statements, functions, and system calls. In essence, it corresponds to the state transitions of system M. Without loss of generality, this application primarily uses atomic actions of system calls and key actions in user mode for explanation, but it can also be explained from other levels such as program statements and functions.

[0040] Definition 2: A structured system M includes the following: (1) Storage unit set N: Each storage unit in the system has a unique name. The set of all these names constitutes the storage unit set N, also called the name set N. Storage units include register units, memory units, secondary storage units, cache, etc.

[0041] (2) Value set V: When the state is fixed, each storage unit has a specific value v. The set of all storage unit values ​​constitutes the value set V.

[0042] (3) Contents function: S×N→V, the content function returns the value v∈V in the state s∈S and name n∈N.

[0043] (4) The observation function: D→P(N) gives the set of names that can be observed in the security region u∈D. Here, P is the power set computation.

[0044] (5) The modification function alter: D→P(N) gives the set of names that can be modified in the security region u∈D. Here, P is the power set calculation.

[0045] Typically, the state of system M is determined by the values ​​of all storage units within M. Storage units include registers, memory locations, and disk sectors. Some of these storage units are unobservable (e.g., internal storage), while others are exposed to the observer; some are read-only, while others are read-and-write; some are lossy, while others are non-lossy, and so on. The values ​​of all these storage units determine the current state of system M. Refer to Definition 3 below.

[0046] Definition 3: Reference Monitor Assumption (RMA). A reference monitor monitors the operation of the system and must satisfy the following three assumptions.

[0047] Assumption 1: Consistency of storage units of equivalent states: Two states are equivalent if and only if their storage units have the same value.

[0048] Assumption 2: Consistency of storage unit modifications for equivalent states: If two states are equivalent, then when they modify storage units, it must be guaranteed that the storage units are modified to the same value.

[0049] Assumption 3: Storage unit modification authorization: If action a modifies the value of a storage unit, then the security domain dom(a) mentioned in a must have the authorization to modify the storage unit.

[0050] For system M, security domains are divided based on function and the scope of information flow. If a security domain u does not interfere with another domain, then operations issued by domain u are also invisible to domain v. That is, security domain u and security domain v are isolated.

[0051] Interference relationships between security domains can be divided into direct interference relationships and indirect interference relationships.

[0052] Example 1, assume the system functions as follows: from the input domain u i Receive all inputs, filtered by the u domain f Sensitive information is identified and then encrypted using the u domain. e Encryption, and finally the encrypted ciphertext is transmitted through the network domain u n It was reported that u f Only through the encryption machine intermediary u e Indirectly transmit information to u n , then u i with u f u f with u e u e with u n For direct interference, u i u f Information in the middle cannot be directly transmitted to the network u n Therefore u i u f with u n It is interference-free.

[0053] The symbol = represents a direct interference relationship, the symbol ≠ represents a no-interference relationship, and the symbol ≈ represents an indirect interference relationship.

[0054] Definition 4: The indirect interference relationship u≈w is defined as follows:

[0055] Taking the example above, the direct interference relationship is: .

[0056] No interference relationship u i u f respectively and u nThe existence of an indirect interference relationship, i.e., u i ≈u n u f ≈u n .

[0057] Definition 5: The set of interference sources is defined as sources: B × D → P(D), and the recursive definition of the set of interference sources is sources(Λ, u) = {u}, and:

[0058] The meaning of the interference source set is to extract all security domains that have (direct or indirect) interference relationships with u to form the (interference source) set.

[0059] Definition 6: The weak expectation function wexp: B × D → B, is recursively defined as follows: wexp(Λ, u) = Λ, and:

[0060] The weak expectation function essentially retains all actions that have a direct or indirect interference relationship with the security domain u, and deletes all other actions, thereby obtaining the expected behavior under the security policy.

[0061] The intuitive meaning of a weak expectation function is as follows: if a security domain u is non-interfering with another domain v, then operations performed by security domain u are invisible to security domain v; that is, security domain u does not interfere with security domain v, and security domain v does not need to pay attention to operations performed by security domain u. This application utilizes this characteristic to define expected non-interfering relationships in security policies. On the one hand, constructing the baseline value for the trust metric is relatively simple; on the other hand, it also simplifies the calculation of expected behavior.

[0062] The reliability determination method is that for any behavior and any security domain, the actual behavior and the expected behavior are always consistent. Therefore, for a centralized system, this application constructs an actual behavior state machine and an expected behavior state machine, and determines whether the states always remain equivalent during their synchronous execution.

[0063] The actual behavioral state machine represents the machine continuously receiving actions from behavior α and reaching new states. All possible equivalent states in this state machine are merged to obtain a new state machine, denoted as MA. MA corresponds to the execution of application software.

[0064] The expected behavior state machine represents the continuous reception of actions from behavior α under the control of a security policy, execution according to a weak expectation function, and corresponding state transitions. Merging all possible equivalent states yields a new state machine, denoted as EMA. EMA corresponds to the execution of the security policy and the weak expectation function.

[0065] This application models a real-world behavioral state machine. Referring to Definition 2, the state of system M is composed of the values ​​of all storage units in M. While observing all storage units is theoretically meaningful, it is difficult to implement in practice. Therefore, this application maps the state of system M to the state of processes, all of which are user-mode processes. The state of a process consists of four elements: (1) Global Activity Object Table; (2) Process isolation information table; (3) The object values ​​that the process has already read: values-observe(u); (4) The current actual stored object values ​​(n).

[0066] The process isolation information table (SIS) represents shared paths between processes, such as inter-process communication objects and information flows. These objects are also part of the global active object table (GAO). Different processes can access these objects, and they may reside in different security domains. The SIS is a prerequisite for a process to observe objects; only non-isolated processes can perform further access operations. For model simplification, operations invisible to ordinary processes, such as modifying security flags in access control policies, are not currently categorized under process states.

[0067] Accordingly, based on the type of atomic action 'a' issued by the process that can change the process state, they can be divided into four categories: (1) Modify the global active object table to create or delete objects; (2) Modifying the process isolation information table allows for the creation or deletion of shared paths between processes; (3) READ can add an object value to values-observe(u); (4) WRITE can change the stored object-values(n).

[0068] Processes should be strictly controlled by the established access control policies. Only operations verified by the access control mechanism can be executed. Modifying the security flags of processes or objects can only be performed by security administrators and trusted processes. Such operations are protected privileged operations within the system. This application does not consider such operations.

[0069] Defining atomic actions that change the state of a process is to define the critical work of the system. These generally include system calls as well as some critical operations that do not involve system calls, such as user-mode driven critical operations or inter-process custom data transfer operations.

[0070] Considering the semantics of atomic operations such as system calls, this application will construct a software behavior model based on actions that affect changes in process state, and treat the atomic actions or behaviors performed by an object as the object's state.

[0071] In the corresponding process state model, the system object corresponds to the global active object table, and its object can be represented as a tuple (objname, objtype), where objname represents the object name, uniquely identifying an object; objtype represents the object type, such as process object, thread object, file object, etc.

[0072] An object operation is an atomic action or behavior. An atomic action can be abstracted as a 5-tuple (pid, opid, opname, flag, objectlist). The PID is the identifier of the process to which the object operation belongs, used to distinguish between different process operations; opid is the number of the object operation, used to uniquely identify each object operation; opname is the name of the object operation; The flag indicates whether an operation changes the object's state and whether the operation is a close / delete type operation. One part indicates whether the operation can change the object's state, such as create and write. The other part indicates that the operation is a "close" type operation, which means that the operation will end the object's lifecycle, such as deleting the object from the program's current object list.

[0073] objectlist={object1, object2, object3,…, object m} represents the collection of system objects being operated on.

[0074] The behavior of object operations is an ordered set of atomic actions, corresponding to α=a0 in Definition 1. a1 ...... a n .

[0075] Changes in an object's state are caused by operations performed on it; therefore, object operation information can be used to describe the object's state. This is represented as "object operation | operation parameters". For example, for a file read operation, the operation information "Read|ByteOffset_Length" indicates that Length bytes are read from the offset position of ByteOffset. Based on the flag of the object operation, simple calculations can be performed on this state during the measurement process, and corresponding reliability determinations can be made.

[0076] The object state sequence information objstatelist is used to represent the sequence of state transitions of an object during program execution {objstate1, objstate2, objstate3, ..., objstate...} n In the sequence, each element `objstate` represents the object's state. The object's state changes continuously during program execution, from when the object is created or opened to when it is closed or deleted.

[0077] In the process state, both the object values ​​that the process has already read (values-observe(u)) and the object values ​​that are currently stored (object-values(n)) can be represented by object state information.

[0078] The process isolation table describes shared paths between processes. These shared paths include, but are not limited to, operating system-level inter-process communication, different processes accessing the same object via system calls, and one process's output being another process's input. These shared paths also describe the security domains to which processes belong and the interference relationships between these domains. Process trustworthiness requires preventing unexpected interference and ensuring that actual behavior and results are consistent with expected behavior.

[0079] Further, in one embodiment, step S10 includes: The system is divided into multiple security domains; each atomic action is mapped to its respective security domain; based on the security domain to which the atomic action belongs, interference or non-interference relationships are defined between different security domains; and a final security domain is specified from the multiple security domains based on the system function or information flow objective.

[0080] In this embodiment, step S10 is completed during the preprocessing stage, not during actual runtime. The system security domain includes the security domain for each user process and the kernel's security domain, and its main construction method is as follows: Step S101: Determine the resources and data accessed by the system, and divide them into different security domains according to process division, the scope of information flow, and the security level of the information. Normally, a process has at least one security domain. If a process completely accesses resources and data within the user layer, then one security domain is sufficient. If the process needs to access the kernel or has interfaces with other processes, proceed to step S102.

[0081] Step S102: Determine the security domain for each atomic action of each process on resources and data. Atomic actions include system calls and user-mode critical operations, which are the aforementioned atomic actions that change the process state. The security domain for each atomic action is determined according to the security domains of the resources and data accessed by the process; the set of these security domains constitutes the process's security domains.

[0082] Step S102 can be further divided into steps S1021 and S1022.

[0083] Step S1021: If a process uses system calls to access kernel-level resources, since the security domain of a system call belongs to the kernel level, which is isolated in the operating system design (e.g., process control, file system control, system control, memory management, network socket control, etc.), different types of system calls can be divided into different security domains, and these security domains do not interfere with each other. If a process expects to call a system call, it means that the process's security domain interferes with the security domain to which that type of system call belongs. Conversely, if a process does not expect to call a certain type of system call, then the process's security domain and the security domain to which that type of system call belongs should not interfere with each other.

[0084] Step S1022: For critical user-mode actions, such as user-mode driver operations, due to memory mapping, the application directly accesses the hardware in user mode by accessing memory to implement driver logic, skipping system calls. Therefore, a separate trust base needs to be written for these interfaces to capture and measure such accesses by the application. Operations on this mapped address space can be divided into a separate security domain, accessible only to a limited number of processes, while the security domains of other processes remain unaffected.

[0085] Step S103: Based on the atomic actions of processes on resources and data in the system and the corresponding security domains, define the interference relationship or non-interference relationship between different security domains.

[0086] Once the security domain and interference relationships are determined, the security policy in the EMA can be constructed. The security policy, as the configuration of the measurement module, describes the expected behavior of a process. That is, what the process is expected to do, or what it is expected not to do. The expected behavior can adopt a non-interference information flow security policy or an interference information flow security policy. The two security policies are essentially equivalent. Generally, using a non-interference information flow security policy is less complex. A breakdown is as follows: For atomic actions of system call classes, analyze the system calls used by the process, determine the type of system call, and determine the interference relationship between the security domain to which the process belongs and the security domain of the system call class.

[0087] 1) For example, if process p does not involve any system calls, then a policy can be defined in the EMA as follows: Security domain u of process p p It does not interfere with the security domains of any system call class.

[0088] 2) For example, if process p only processes network data and is not allowed to create child processes, then a policy can be defined in the EMA as follows: Security domain u of process p p It does not interfere with the security domains of process control classes.

[0089] 3) For example, if a process needs to use system calls from file system classes, but the process can only read the corresponding file and cannot write to or delete it, then a policy can be defined in EMA as follows: Security domain u of process p p It interferes with the file system control class security field, but the operation parameter for the file system control class security field can only be read.

[0090] For critical user-mode actions, based on the atomic actions involved in constructing the security domain, analyze the operations actually called by the process to determine the interference relationship between the security domain to which the process belongs and the security domain to which this type of resource belongs.

[0091] 1) For example, if process p operates on a user-mode driver, after the kernel has completed the address space mapping, process p can read, write, or control that address space, but cannot delete it. Other processes cannot access this mapped space. Then, a policy can be defined in the EMA as follows: Security domain u of process p p Because the buffer interferes with the security domain to which the mapped space belongs, operations on this buffer can only use read, write, and ioctl parameters; deletion is not allowed. p It is free from interference with other security domains.

[0092] 2) For example, if process p outputs information and process q reads that information, and the communication between processes p and q is not through the inter-process communication mechanism provided by the operating system, but is directly controlled by a custom buffer, then a policy can be defined in the EMA as follows: Security domain u of process p p If there is interference with the security domain to which the buffer belongs, the operation parameter for this buffer can only be write.

[0093] Security domain u of process q q If there is interference with the security domain to which the buffer belongs, the operation parameter for this buffer can only be read.

[0094] The security domains of other processes do not interfere with the security domain to which the buffer belongs.

[0095] In addition to the interference / non-interference security policy, auxiliary security policies can also be defined in EMA to check the integrity of an object when atomic actions cannot be fully captured.

[0096] For example, define the following strategy: the communication buffer used by process p and process q cannot be deleted.

[0097] Step S104: Determine the final security domain in the EMA, which is used to observe whether the EMA and MA are equivalent.

[0098] The final security domain can be determined based on different functions and the direction of information flow. For example, in the example mentioned above, "un" can be selected as the final security domain.

[0099] This embodiment details the specific steps of "constructing the expected behavior state machine and specifying the final security domain." It uses an application that needs to read local configuration files and send data to a remote server as an example.

[0100] Step 1: Divide the security domains. Analyze the resources the process needs to access: local configuration file (config.txt) and network sockets. Based on the information flow target (to prevent unauthorized transmission of configuration file data), divide the process into three security domains: file reading domain (D_file), network sending domain (D_net), and an application logic domain (D_app) representing the process's own logic.

[0101] Step 2: Map atomic actions. Categorize possible atomic actions: map open(“config.txt”) and read(fd) to D_file; map socket() and send(sockfd) to D_net; map some pure memory computation operations to D_app.

[0102] Step 3: Define the interference relationship. Based on the security objective definition: D_file can interfere with D_app (the application can read the configuration), D_app can interfere with D_net (the application can send data), but D_file must not interfere with D_net (configuration file data cannot flow directly to the network).

[0103] Step 4: Specify the final security domain. To achieve the "leakage prevention" goal, the network transmission domain (D_net) is selected as the final security domain. This means that subsequent weak expectation functions will filter behavior from the perspective of D_net, only caring about those actions that ultimately affect network transmission.

[0104] Step S20: Obtain the atomic actions of the software to be measured during its operation, and construct the actual behavior sequence based on the obtained atomic actions; Step S30: Based on the expected behavior state machine, calculate the expected behavior sequence corresponding to the actual behavior sequence using a weak expectation function, wherein the weak expectation function is used to filter out atomic actions that have an interfering relationship with the final security domain from the actual behavior sequence to form the expected behavior sequence. Step S40: Determine the credibility of the software to be measured based on the actual behavior sequence and the expected behavior sequence.

[0105] In this embodiment, when the software to be measured (e.g., a network service process) starts running, the monitoring module (e.g., a kernel-mode agent) continuously captures its atomic actions (e.g., system calls send and open) and assembles them into an actual behavior sequence α. Subsequently, the expected behavior state machine begins operation. It receives the actual behavior sequence α and processes it using a weak expectation function. The weak expectation function's role is to filter out atomic actions from sequence α that interfere with the final security domain (i.e., can affect the final security domain state), and filter out actions that do not interfere, thereby generating an expected behavior sequence β. Finally, the reliability of the software behavior is determined by comparing the consistency between the actual behavior sequence α and the expected behavior sequence β (e.g., comparing whether the two sequences are completely identical, or comparing whether the system states after executing both are equivalent). If α and β are consistent, the software is deemed reliable; if they are inconsistent (e.g., the actual behavior includes sensitive operations that should not appear in the expected behavior and do not interfere with the final security domain), the software is deemed unreliable, and response measures such as terminating the process can be taken.

[0106] The core advantage of this application's embodiments is that its behavioral expectation (β) does not come from historical learning or code analysis of the software itself, but from an externally defined security policy (without interference), thus completely eliminating the dependence on training data or source code.

[0107] Steps S20 to S40 are completed during the software execution phase, see reference. Figure 2 , Figure 2 This is a flowchart illustrating another embodiment of the software trustworthiness measurement method of this application. Figure 2 As shown, the measurement module operates within the trusted component, specifically including the following steps: The measurement module is initialized, which takes precedence over the initialization of the application (i.e., the software to be measured) and the measurement agent module; The measurement module synchronizes the trusted initial state S0 of the proxy module. The measurement module receives behavior α from the measurement agent module via a trusted communication protocol; Based on the security domain information and Definition 5, calculate the set of interference sources; Based on the security policy and Definition 6, calculate the expected behavior β under the security policy; Determine if there is a deviation between α and β. If there is a deviation, the behavior is considered untrustworthy; otherwise, it is considered trustworthy. Furthermore, if the measurement module has a security policy for the object class, it determines whether the security policy requirements are met by referring to the global activity object table based on this security policy. The measurement module feeds back the measurement results to the measurement agent module.

[0108] For the actual behavioral state machine, the measurement agent module runs on the computing component, but its runtime environment needs to be ensured to be trustworthy through certain means. The measurement agent module collects information from the actual runtime behavior of the application, capturing information in both user space and kernel space. The user space information may have multiple instances running in different processes. The steps involved are as follows: The kernel attitude quantity proxy module synchronizes the initial state of the measurement module; The kernel attitude proxy module captures system calls and parses the lowest-level system objects from the system call parameters, thereby overcoming the sensitivity of system call parameters and resisting direct and indirect modification of system call parameters; The user attitude proxy module captures key user-state behaviors; The user attitude quantity proxy module sends the captured user-mode key behaviors to the kernel attitude quantity proxy module. The kernel attitude proxy sends the actual behavior of the application to the measurement module for measurement via a trusted communication protocol; The metrics agent module receives the results from the metrics module, determines whether the application should terminate or continue running, and then sends the results back to the user.

[0109] In addition to determining the difference in behavior between the actual behavior state machine and the expected behavior state machine, we can also use existing information to help determine the object and its state information.

[0110] After the user attitude proxy module sends the captured key user-mode behaviors to the kernel attitude proxy module, the following steps can be added: The kernel attitude proxy module records the object operation quintuple information or action sequence executed by the application this time, calculates the existence status of the object based on the object operation's tag, and updates the corresponding global active object table.

[0111] If process p is expected to have no interference with a certain security domain u, then the measurement module does not need to execute various actions of security domain u when implementing the security policy. However, if process p is maliciously attacked, it may actually execute an action in the security domain during execution, resulting in different states after execution and being judged as untrustworthy. Therefore, starting from the same state, the measurement module only needs to execute actions with direct or indirect interference relationships, without needing to undergo training through benign execution, which simplifies the overall measurement calculation.

[0112] In this embodiment, system calls and key user-mode operations are used to record the actual behavior of the application. Based on a non-interference model, the expected behavior of the software is characterized by the non-interference relationship between security domains. Reliability is measured by determining whether there is a deviation between the actual behavior of the current code and the expected behavior. The proposed method requires no learning or training process and no prior knowledge.

[0113] When modeling the actual behavior of software, we analyze not only system calls but also key user-mode operations, enabling unified processing. We also analyze the parameters of system calls and key user-mode actions, as well as the lowest-level objects involved, recording them in the process's global active object table, overcoming the sensitivity of system call parameters. This information is used as auxiliary information to check the state of objects, such as whether an object exists.

[0114] Furthermore, in one embodiment, obtaining the atomic actions of the software to be measured during its operation includes: The system calls triggered by the software to be measured during operation are captured, and the underlying system objects are parsed from the parameters of the system calls; atomic actions are constructed based on the underlying system objects.

[0115] In this embodiment, when a system call (e.g., `write(fd, buf, count)`) triggered by the software being measured during operation is captured, the system call number and surface parameters are not recorded in detail. The measurement proxy module delves into the parameters of this system call, tracing back to the lowest-level system object it operates on. For example, for the file descriptor `fd` in the parameters, the measurement proxy module parses out the kernel object it currently points to, such as an inode structure representing the file ` / home / user / secret.txt`. Then, based on this underlying system object (such as the inode), a description of the atomic action is constructed, rather than simply based on the value of `fd`. In this way, even if an attacker attempts to deceive the measurement system through file descriptor reuse (the `fd` value remains unchanged but the file it points to has been maliciously replaced) or by directly modifying the `fd` value, because the measurement is based on an unchanging kernel object identifier, it can still accurately identify that the software is actually accessing the sensitive object `secret.txt`, thus ensuring the accuracy of the measurement.

[0116] Furthermore, in one embodiment, obtaining the atomic actions of the software to be measured during its operation further includes: The user-mode key operations that do not involve system calls are obtained during the operation of the software to be measured. These user-mode key operations include user-mode driver operations and inter-process custom data transfer operations.

[0117] This embodiment further illustrates another type of atomic action that needs to be monitored, besides system calls. For certain critical user-mode operations, such as: 1) User-mode drivers: A process maps the register space of a hardware device to user-mode address 0x7f0000 using mmap, and then directly reads and writes to this address using mov instructions to implement driver logic. This process does not involve system calls. 2) Custom inter-process communication: Process A and process B exchange data through a shared memory region shm_block agreed upon by both parties, using custom pointer operations for reading and writing, also bypassing system calls. Such operations are captured by a user-mode metric proxy module (e.g., injected into the process as a dynamic link library) and reported as atomic actions. This ensures the integrity of metric coverage, and even if malicious behavior attempts to be carried out through non-standard channels (bypassing system calls), it can still be effectively monitored.

[0118] Furthermore, in one embodiment, calculating the expected behavior sequence corresponding to the actual behavior sequence using a weak expectation function includes: Based on the actual behavior sequence and the final security domain, calculate the interference source set, which includes all security domains that have a direct or indirect interference relationship with the final security domain. From the actual behavior sequence, atomic actions whose security domains are located in the set of interference sources are selected to form the expected behavior sequence.

[0119] In this embodiment, it is assumed that the final security domain is D_net. When an actual action sequence α is received, such as [operation A (D_file), operation B (D_app), operation C (D_app), operation D (D_net)].

[0120] Step 1: Calculate the interference source set. Based on the predefined interference relationship (D_file ≠ D_net, D_app = D_net), calculate the interference source set sources(α, D_net) for the sequence α and the final safe domain D_net. According to the recursive calculation in Definition 5, this set contains all domains that can directly or indirectly interfere with D_net, and the result is {D_app, D_net}. Note that D_file is not included in the set because it does not interfere with D_net.

[0121] Step 2: Filtering to determine the expected behavior. According to the definition of the weak expectation function wexp, each action in sequence α is traversed, retaining only those whose safety domain belongs to the aforementioned set of interference sources {D_app, D_net}. Therefore, operation A (D_file) is filtered out, while operations B (D_app), C (D_app), and D (D_net) are retained. The final expected behavior sequence β is [operation B, operation C, operation D]. This process formally realizes "the behavior that should occur from the perspective of the final safety domain".

[0122] Further, in one embodiment, step S40 includes: The credibility of the software to be measured is determined based on the consistency between the actual behavior sequence and the expected behavior sequence. Alternatively, the credibility of the software to be measured can be determined based on the equivalence between the actual system state resulting from the execution of the actual behavior sequence and the expected system state resulting from the execution of the expected behavior sequence.

[0123] In this embodiment, credibility determination is divided into two methods: behavior sequence comparison and system state equivalence comparison. Wherein: Behavior sequence alignment: After calculating the actual behavior sequence α and the expected behavior sequence β, the two sequences are directly compared. For example, α is [read(fd1), write(fd2), send(sock)], and β is [send(sock)] (assuming only send interferes with the final security domain). The system will compare the two sequences item by item. If they are completely consistent (i.e., all actions in α except send are correctly filtered), the sequence is deemed trustworthy. If α contains actions not in β (e.g., an extra unauthorized write), or the order is incorrect, the sequence is deemed untrustworthy. This method is simple to implement and has low computational overhead.

[0124] System state equivalence comparison: The system maintains a process state view, including its associated global active object table, object values, etc. After the actual behavior sequence α and the expected behavior sequence β are executed respectively (or sequentially on the same state machine), it checks whether the system has reached an equivalent state. For example, after α is executed, the process opens a file F; after β is executed, since the policy stipulates that the file operation does not interfere with the final security domain, the expected behavior does not include this operation, therefore the process state should not contain file F. If the two states are inconsistent (i.e., an object or value that should not exist in the expected state appears in the actual state), then it is deemed untrustworthy. This method can detect more covert attacks, such as attacks where the attacker executes an operation that does not affect the behavior sequence but changes the underlying state of the system.

[0125] You can choose to use either method based on your actual needs.

[0126] Further, in one embodiment, step S40 includes: The credibility of the software to be measured is determined based on the consistency between the actual behavior sequence and the expected behavior sequence, and based on the equivalence between the actual system state resulting from the execution of the actual behavior sequence and the expected system state resulting from the execution of the expected behavior sequence.

[0127] In this embodiment, a behavior sequence comparison is first performed. For example, α represents [operation A, operation B, operation C], and β represents [operation B, operation C]. If α and β are inconsistent (operation A is added), the first judgment result is untrustworthy, and the software is directly judged as untrustworthy without further complex state comparisons. If α and β are consistent, the first judgment result is trustworthy, but a final judgment is not made immediately. Instead, a system state equivalence comparison is performed. The system state equivalence comparison checks whether the system state after actually executing α is equivalent to the system state after the expected execution of β. For example, although the behavior sequence is consistent, if the content of a critical file is maliciously tampered with during actual execution (but this tampering operation is not reflected in the behavior sequence, such as direct modification through memory), the system state equivalence comparison will detect the inconsistency, resulting in a second judgment result of untrustworthiness, and ultimately, the software is judged as untrustworthy. This two-level judgment mechanism ensures both rapid response in most cases (first-level rapid comparison) and in-depth inspection when necessary (second-level state comparison), achieving a good balance between security and efficiency.

[0128] By first performing a lightweight behavior sequence comparison, followed by a heavyweight system state equivalence comparison, and skipping the state comparison when the behavior sequence comparison fails, the efficiency of the judgment is optimized. Simultaneously, the combination of these two levels of comparison constitutes defense in depth, enabling more comprehensive detection of various types of attacks, including complex attacks that attempt to forge normal behavior sequences but cannot completely forge the system state, thereby enhancing the strength of security protection while ensuring system performance.

[0129] Furthermore, it should be noted that trusted computing refers to simultaneous security protection during computation, ensuring the entire computation process is measurable, controllable, and uninterrupted, guaranteeing that the computation results always match expectations. A trusted computing system consists of trusted computing nodes and trusted connections between them, providing an appropriate level of security for its network environment. (Refer to...) Figure 3 , Figure 3 This is a dual architecture in one embodiment, where trusted computing nodes possess both computational and security functions. For example... Figure 3As shown, a trusted computing node consists of trusted components and computing components. The computing components provide computing, storage, and network resources for the program, mainly comprising general-purpose hardware and firmware, operating system and middleware, application programs, and network components. The trusted components primarily measure and monitor the computing components, with monitoring functionality being optional depending on different integrity measurement modes. The trusted components also support trusted computing function calls such as cryptographic algorithms, platform identity trust, and platform data security protection. The computing system components and trusted components within the trusted computing node are logically independent, forming a dual architecture with both computing and protection functions.

[0130] Figure 4 This is a schematic diagram of the architecture upon which the software trust measurement method in one embodiment depends. For example... Figure 4 As shown, the architecture upon which the software trust measurement method relies includes a measurement module and a measurement proxy module. The measurement module resides in the trusted component, while the measurement proxy module resides in the computation component. The measurement proxy module can be further subdivided into a user attitude measurement proxy module and a kernel attitude measurement proxy module. The trustworthiness of the measurement proxy module can be guaranteed through other means. For example, it can be achieved by hardening the kernel using existing technologies or by employing hardware-software security architectures such as TrustZone. The user attitude measurement proxy module can have multiple instances.

[0131] The metrics agent module primarily captures key actions and behaviors of the application. Among them: The main functions of the user attitude quantity proxy module include: intercepting critical user-space operations and data and passing them to the kernel attitude quantity proxy module; receiving measurement control commands from the user or the kernel attitude quantity proxy module; and receiving measurement result data from the kernel attitude quantity proxy module and feeding it back to the user. The interception of critical user-space operations and data is primarily used for critical user-space operations, such as those of user-space drivers, where reading and writing the addresses mapped by the driver are considered critical operations. One possible implementation method is that the user attitude quantity proxy module provides a corresponding trusted base (read / write operation interface) for the user-space driver. The user-space driver in the application needs to call this interface, and the hook functions of this interface perform measurement-related processing.

[0132] The main functions of the kernel attitude quantity proxy module include: capturing system calls and corresponding parameter information of the monitored process in real time and passing them to the measurement module; receiving measurement control commands from the user or the measurement module; receiving measurement result data from the measurement module and feeding it back to the user attitude quantity proxy module; and the kernel attitude quantity proxy module can also inspect the objects of the object as needed.

[0133] The main functions of the measurement module include: receiving the data to be measured from the kernel attitude quantity proxy module, calculating the expected behavior, and determining the consistency between the data to be measured and the expected behavior. It also involves issuing corresponding measurement control commands and transmitting the corresponding measurement results to the kernel attitude quantity proxy module.

[0134] Figure 5 This is a schematic diagram of the measurement module in one embodiment. The measurement module includes configuration information and a software operation module, wherein security domain information and security policies serve as the configuration information of the measurement module; the initialization module, object and state inspection module, interference set calculation module, expected behavior calculation module, measurement determination module, and interface control, policy reading, etc., constitute the software operation module.

[0135] The interface control module interacts with the measurement agent module, while the policy reading module is the interface required by the measurement module to read the security policy in the expected behavior state machine.

[0136] The object and state inspection module serves as supplementary information for trustworthiness determination and is not mandatory. If the metric proxy module is sufficiently powerful, it can analyze whether the object's state has changed or whether the object exists based on captured actions. If the metric module defines object or state-related strategies, these can be used as a benchmark for judgment.

[0137] Security domain information and security policies can be static firmware or information dynamically input in a trusted manner. This application is not limited to specific implementation methods.

[0138] Security domain information includes the security domain itself, the interference relationships between security domains, and the security domain to which each action belongs.

[0139] Security domains are used to delineate the authorized and prohibited areas of information flow. For example, different security levels define different security domains. Agents or entities within a specific security domain interact with the system by presenting actions to the system and observing the results.

[0140] The interference set calculation module extracts all security domains that have a direct or indirect interference relationship with security domain u to form an interference source set. Referring to the example above: Interference relationship is , The final security domain is u n a i1 is domain u i The action in, a e1 and a e2 is domain u e The action in, a f1 is domain u f The actions in the text, and the interference source sets for each behavior are as follows: ,sources( , )={ }; ,sources( , )={ }; ,sources( , )={ }; ,sources( , )={ }; ,sources( , )={ }; ,sources( , )={ }; The expected behavior calculation module calculates the corresponding expected behavior according to Definition 6, such as... Figure 6 The lower half of the diagram is shown. The upper half contains the state transition information of the actual behavioral state machine. Circles in the diagram represent states, arrows between circles represent actions that trigger state transitions, and dashed lines between circles represent the synchronous execution of MA and EMA. Figure 6 This is a state transition diagram showing the actual behavior and expected behavior in one embodiment.

[0141] For state S3, MA receives action a. i2 However, EMA receives Λ (empty), which leads to inconsistency between actual and expected behavior.

[0142] Secondly, embodiments of this application also provide a software trust measurement device.

[0143] In one embodiment, reference is made to Figure 7 , Figure 7 This is a functional module diagram of an embodiment of the software trust measurement device of this application. Figure 7 As shown, the software trust measurement device includes: Definition module 10 is used to construct a security policy in the expected behavior state machine based on the non-interference model and specify the final security domain, wherein the security policy defines the interference or non-interference relationship between security domains; The acquisition module 20 is used to acquire the atomic actions of the software to be measured during its operation and to construct the actual behavior sequence based on the acquired atomic actions. The construction module 30 is used to calculate the expected behavior sequence corresponding to the actual behavior sequence based on the expected behavior state machine using a weak expectation function, wherein the weak expectation function is used to filter out atomic actions that have an interfering relationship with the final security domain from the actual behavior sequence to form the expected behavior sequence. The determination module 40 is used to determine the credibility of the software to be measured based on the actual behavior sequence and the expected behavior sequence.

[0144] Furthermore, in one embodiment, module 10 is defined for: Divide the system into multiple security domains; Map each atomic action to its corresponding security domain; Based on the security domain to which the atomic action belongs, define the interference relationship or non-interference relationship between different security domains; Based on the system function or information flow objective, a final security domain is specified from the plurality of security domains.

[0145] Furthermore, in one embodiment, the acquisition module 20 is used for: The system calls triggered by the software to be measured during operation are captured, and the underlying system objects are parsed from the parameters of the system calls; Atomic actions are constructed based on the underlying system objects.

[0146] Furthermore, in one embodiment, the acquisition module 20 is used for: The user-mode key operations that do not involve system calls are obtained during the operation of the software to be measured. These user-mode key operations include user-mode driver operations and inter-process custom data transfer operations.

[0147] Furthermore, in one embodiment, the construction module 30 is used for: Based on the actual behavior sequence and the final security domain, calculate the interference source set, which includes all security domains that have a direct or indirect interference relationship with the final security domain. From the actual behavior sequence, atomic actions whose security domains are located in the set of interference sources are selected to form the expected behavior sequence.

[0148] Furthermore, in one embodiment, the determination module 40 is used for: The credibility of the software to be measured is determined based on the consistency between the actual behavior sequence and the expected behavior sequence. Alternatively, the credibility of the software to be measured can be determined based on the equivalence between the actual system state resulting from the execution of the actual behavior sequence and the expected system state resulting from the execution of the expected behavior sequence.

[0149] Furthermore, in one embodiment, the determination module 40 is used for: The credibility of the software to be measured is determined based on the consistency between the actual behavior sequence and the expected behavior sequence, and based on the equivalence between the actual system state resulting from the execution of the actual behavior sequence and the expected system state resulting from the execution of the expected behavior sequence.

[0150] The functions of each module in the software trust measurement device correspond to the steps in the software trust measurement method embodiment, and their functions and implementation processes will not be described in detail here.

[0151] Thirdly, embodiments of this application provide a software trust measurement device, which can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0152] Reference Figure 8 , Figure 8 This is a schematic diagram of the hardware structure of the software trust measurement device involved in the embodiments of this application. In the embodiments of this application, the software trust measurement device may include a processor, a memory, a communication interface, and a communication bus.

[0153] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0154] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within the software trust measurement device, as well as interfaces used for interconnecting the software trust measurement device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0155] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0156] The processor can be a general-purpose processor, which can call a software trust measurement program stored in memory and execute the software trust measurement method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the software trust measurement program is called can be referred to in the various embodiments of the software trust measurement method of this application, and will not be repeated here.

[0157] Those skilled in the art will understand that Figure 8 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0158] Fourthly, embodiments of this application also provide a computer-readable storage medium.

[0159] The present application has a software trust measurement program stored on a computer-readable storage medium, wherein when the software trust measurement program is executed by a processor, it implements the steps of the software trust measurement method as described above.

[0160] The method implemented when the software trust measurement program is executed can be referred to in various embodiments of the software trust measurement method of this application, and will not be repeated here.

[0161] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0162] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0163] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0164] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0165] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0166] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of 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) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0167] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A software trustworthiness measurement method, characterized in that, The software trustworthiness measurement method includes: The security policy and the specified final security domain are constructed in the expected behavior state machine based on the non-interference model, wherein the security policy defines the interference or non-interference relationship between security domains. Acquire the atomic actions of the software to be measured during its operation, and construct the actual behavior sequence based on the acquired atomic actions; Based on the expected behavior state machine, a weak expectation function is used to calculate the expected behavior sequence corresponding to the actual behavior sequence, wherein the weak expectation function is used to filter out atomic actions that have an interfering relationship with the final security domain from the actual behavior sequence to form the expected behavior sequence. The credibility of the software to be measured is determined based on the actual behavior sequence and the expected behavior sequence.

2. The software trustworthiness measurement method according to claim 1, characterized in that, The security strategy and the specified final security domain in the construction of the expected behavior state machine based on the non-interference model include: Divide the system into multiple security domains; Map each atomic action to its corresponding security domain; Based on the security domain to which the atomic action belongs, define the interference relationship or non-interference relationship between different security domains; Based on the system function or information flow objective, a final security domain is specified from the plurality of security domains.

3. The software trustworthiness measurement method according to claim 1, characterized in that, The atomic actions taken by the software being measured during its execution include: The system calls triggered by the software to be measured during operation are captured, and the underlying system objects are parsed from the parameters of the system calls; Atomic actions are constructed based on the underlying system objects.

4. The software trustworthiness measurement method as described in claim 3, characterized in that, Obtaining the atomic actions of the software being measured during its execution also includes: The user-mode key operations that do not involve system calls are obtained during the operation of the software to be measured. These user-mode key operations include user-mode driver operations and inter-process custom data transfer operations.

5. The software trustworthiness measurement method according to claim 1, characterized in that, Calculating the expected behavior sequence corresponding to the actual behavior sequence using a weak expectation function includes: Based on the actual behavior sequence and the final security domain, calculate the interference source set, which includes all security domains that have a direct or indirect interference relationship with the final security domain. From the actual behavior sequence, atomic actions whose security domains are located in the set of interference sources are selected to form the expected behavior sequence.

6. The software trustworthiness measurement method according to claim 1, characterized in that, The reliability of the software to be measured is determined based on the actual behavior sequence and the expected behavior sequence, including: The credibility of the software to be measured is determined based on the consistency between the actual behavior sequence and the expected behavior sequence. Alternatively, the credibility of the software to be measured can be determined based on the equivalence between the actual system state resulting from the execution of the actual behavior sequence and the expected system state resulting from the execution of the expected behavior sequence.

7. The software trustworthiness measurement method according to claim 1, characterized in that, The reliability of the software to be measured is determined based on the actual behavior sequence and the expected behavior sequence, including: The credibility of the software to be measured is determined based on the consistency between the actual behavior sequence and the expected behavior sequence, and based on the equivalence between the actual system state resulting from the execution of the actual behavior sequence and the expected system state resulting from the execution of the expected behavior sequence.

8. A software trust measurement device, characterized in that, The software trust measurement device includes: A definition module is used to construct a security policy in the expected behavior state machine based on a non-interference model and to specify the final security domain, wherein the security policy defines the interference or non-interference relationship between security domains; The acquisition module is used to acquire the atomic actions of the software to be measured during its operation and to construct the actual behavior sequence based on the acquired atomic actions. A construction module is used to calculate the expected behavior sequence corresponding to the actual behavior sequence based on the expected behavior state machine using a weak expectation function, wherein the weak expectation function is used to filter out atomic actions that have an interfering relationship with the final security domain from the actual behavior sequence to form the expected behavior sequence; The determination module is used to determine the credibility of the software to be measured based on the actual behavior sequence and the expected behavior sequence.

9. A software trust measurement device, characterized in that, The software trust measurement device includes a processor, a memory, and a software trust measurement program stored in the memory and executable by the processor, wherein when the software trust measurement program is executed by the processor, it implements the steps of the software trust measurement method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a software trust measurement program, wherein when the software trust measurement program is executed by a processor, it implements the steps of the software trust measurement method as described in any one of claims 1 to 7.

Images