Sandbox type trusted data space construction method and equipment based on trusted verification architecture

Abstract

The invention discloses a sandbox type trusted data space construction method and equipment based on a trusted verification architecture, belongs to the technical field of data security circulation and trusted computing, and aims to overcome the defects that a traditional sandbox behavior is unknowable and untrusted and a strategy is rigid. The method comprises the following steps of: starting a sandbox in a hardware trusted execution environment and generating a task unique context identifier; intercepting system call by a monitoring agent; generating a chained operation certificate containing preorder certificate hash; compiling an advanced security policy into a deterministic finite automaton executable policy set; and the auditing unit is used for generating a decision instruction in an illegal scale, storing the chain anchor point to the non-tampering system, forcibly executing decision and generating a Merkel tree evidence. The equipment correspondingly comprises a sandbox management module, a behavior monitoring module, a strategy compiling module, a verification judgment module and an auditing execution module. The full-flow transparent tracing of the operation in the sandbox is realized, the strategy dynamic adaptation is supported, and the problem that a traditional sandbox monitoring log is easy to counterfeit and difficult to verify is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data security circulation and trusted computing, in particular to a sandbox-type trusted data space construction method and device based on a trusted verification architecture. BACKGROUND

[0002] Under the background of increasing demand for modern data protection, the "sandbox" technology in traditional data bearing environment has been widely used in various industries. The traditional sandbox technology mainly uses the form of container or virtual machine to isolate untrusted code from the external environment, preventing the external environment from being threatened by potential threats. Its core design philosophy is to achieve one-way isolation to protect the external environment from internal code damage. However, in the face of emerging data space security requirements, this sandbox technology shows some obvious shortcomings.

[0003] Firstly, the behavior-agnostic and untrusted problem faced by the traditional sandbox technology is particularly prominent. The processing of data in the sandbox is like a "black box" to the data provider, and its internal operation cannot be transparently and reliably monitored and audited. Even if there are monitoring logs, the authenticity and integrity of these logs cannot be guaranteed, resulting in a significant reduction in data protection effectiveness. The lack of transparency and credibility makes it difficult for the sandbox to fully meet the requirements of detailed management and monitoring of internal data in the data space scenario.

[0004] Secondly, the traditional sandbox technology has the defect of rigid strategy. Its security policy is usually pre-set and difficult to adapt to changing application environments and complex internal threats. In the face of dynamic computing tasks and unknown attack methods, it is difficult for pre-set static strategies to effectively block and prevent data theft through application vulnerabilities in real time. Therefore, the traditional sandbox technology often appears to be inadequate when facing new internal or external threats, and it is difficult to provide comprehensive data security protection. SUMMARY

[0005] In view of the above-mentioned problems existing in the prior art, the purpose of the present application is to provide a sandbox-type trusted data space construction method and device based on a trusted verification architecture to solve the problems raised in the background art.

[0006] To solve the above technical problems, the present application adopts the following technical solutions: The present application provides a sandbox-type trusted data space construction method based on a trusted verification architecture, comprising the following steps: S1, starting a sandbox in a hardware trusted execution environment, and generating a unique task context identifier for each data processing task to be run in the sandbox; S2, intercepting, by a monitoring agent in the trusted execution environment, a system call sequence issued by the data processing task, generating, for each system call sequence, an atomic operation record containing an operation type, an operation object and a current timestamp, binding the task context identifier with the atomic operation record to form a context-bound operation credential; S3, compiling a high-level security policy defined by a data provider into an executable verification policy set composed of operation type and object mode rules; S4, streaming the operation credential generated in step S2 to an external verification engine, which performs real-time matching analysis on the sequence of operation credentials according to the executable verification policy set generated in step S3; When the credential sequence matches the restriction rule in the executable verification policy set, a signed policy decision instruction is generated; S5, sending the policy decision instruction back to the sandbox environment and enforcing it by the monitoring agent to interrupt the violation operation; At the same time, an audit record is generated, and an unalterable audit unit for integrity verification is generated based on the audit record.

[0007] In one or more embodiments of the present application, the step of generating the unique task context identifier includes: calculating a cryptographic hash value of the executable file of the data processing task as a file fingerprint; obtaining a unique instance ID assigned by the current sandbox instance, obtaining a high-precision timestamp of the current system; concatenating the file fingerprint, instance ID and high-precision timestamp, and calculating a first hash value for the concatenated data; combining the first hash value with a random number generated by a cryptographically secure pseudo-random number generator, and calculating a second hash value, taking the output of the second hash value as the task context identifier.

[0008] In one or more embodiments of the present application, before calculating the second hash value, the step of combining the first hash value with the random number is specifically: performing an exclusive OR operation on the first hash value and the random number, taking the operation result as the input of the second hash value; or, sequentially concatenating the first hash value and the random number, taking the concatenated result as the input of the second hash value.

[0009] In one or more embodiments of the present application, the specific step of generating the context-bound operation credential is: introducing the hash value of the previous operation credential as input when generating the current operation credential, the specific step is: adding a field for storing the hash value of the previous credential in the data structure of the atomic operation record, and performing hash calculation and digital signature on the complete data structure containing the task context identifier, the atomic operation record and the hash value of the previous credential; wherein the hash value of the first operation credential is filled with a preset initial value.

[0010] In one or more embodiments of the present application, the verification engine is configured to perform the following steps: the verification engine periodically determines the hash value of the latest context-bound operation credential currently received as the head hash of the context-bound operation credential hash chain as the chain anchor point in response to the end of the data processing task in the sandbox or in response to generating a policy decision instruction in step S4; the chain anchor point is sent to an external, tamper-proof storage system for storage; when it is necessary to verify the integrity of the operation credential within a period of time, the corresponding chain anchor point is obtained from the storage system, and the continuity of the entire hash chain from the operation credential corresponding to the chain anchor point to a known trusted credential is verified according to the hash chain.

[0011] In one or more embodiments of the present application, in step S3, the high-level security policy is compiled into a verification policy set, the specific steps including: parsing the natural language or domain-specific language description in the high-level security policy; converting the natural language or domain-specific language description into a policy model represented by a finite state machine, the state transition conditions of the finite state machine being defined by operation type and object mode rules; compiling the policy model into rule code based on the state transition logic of deterministic finite automata, the rule code being executable by the verification engine by querying the state transition table.

[0012] In one or more embodiments of the present application, in the policy model represented by the finite state machine, there is a state transition path for limiting data flow; the state transition condition of the state transition path is specifically: the transition condition from the initial state to the first intermediate state is that an operation credential whose operation type is read and whose operation object matches the first predefined mode is received; the transition condition from the first intermediate state to the violation state is that an operation credential whose operation type is connection or sending and whose operation object matches the second predefined mode is received; wherein the first predefined mode is used to define a protected data resource, and the second predefined mode is used to define a restricted network endpoint.

[0013] In one or more embodiments of the present application, the verification engine performs the process of the rule code by querying a state transition table, specifically: the verification engine maintains an independent state machine instance in memory for each active task context identifier; when a new operation credential arrives, the verification engine locates the corresponding state machine instance according to the task context identifier bound by the operation credential, and queries the state transition table with the operation type and operation object of the operation credential as a joint query key to drive the state machine instance to perform state transition.

[0014] In one or more embodiments of the present application, in step S5, the tamper-proof audit unit specifically calculates a Merkle tree root hash of the data of the audit unit; submits the root hash and a current timestamp to a blockchain network or a time-stamping authority together to obtain a verifiable receipt containing time proof.

[0015] The application provides a sandbox-based trusted data space construction device based on a trusted verification architecture, which comprises a sandbox management module, a behavior monitoring module, a policy compiling module, a verification decision module and an execution audit module. The sandbox management module is used for starting a sandbox in a hardware-based trusted execution environment and generating a unique task context identifier for each data processing task to be run in the sandbox. The behavior monitoring module is used for intercepting a system call sequence issued by the data processing task through a monitoring agent residing in the trusted execution environment, generating an atomic operation record for each system call sequence, binding the task context identifier with the atomic operation record to form a context-bound operation credential. The policy compiling module is used for compiling a high-level security policy defined by a data provider outside the sandbox into an executable verification policy set. The verification decision module is used for streaming the context-bound operation credential to an external verification engine in real time. The verification engine performs real-time matching analysis on the sequence of operation credentials according to the executable verification policy set and generates and signs a policy decision instruction. The execution audit module is used for sending the policy decision instruction back to the sandbox environment and enforcing it by the monitoring agent to interrupt a violation operation, generate an audit record and generate a tamper-proof audit unit for integrity check based on the audit record.

[0016] The application has the beneficial effects that: a basic isolated environment is constructed through a hardware trusted execution environment, a unique CID is generated for a data processing task and a chain operation credential is established, a chain anchor point, a blockchain of an audit unit and a time-stamping evidence are combined, the black box state of data processing in the sandbox is completely broken, transparent tracing and log trusted check of the whole operation process are realized, and the problem of easy forgery and difficult verification of a traditional sandbox monitoring log is solved. Meanwhile, the advanced security policies of data providers are parsed and compiled into executable rules based on deterministic finite automata, supporting multi-step violation model matching and dynamic policy adjustment. This overcomes the limitations of traditional static policies in adapting to complex threats, and can accurately block linked violations such as the outward dissemination of confidential data after reading it. Ultimately, a full lifecycle trust assurance system is formed, which is trustworthy in the environment, traceable in operation, controllable in policy, and verifiable in audit. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of a sandbox-based trusted data space construction method based on a trusted verification architecture in one embodiment of the present invention; Figure 2 This is a flowchart of the hardware TEE sandbox startup and task context identifier generation in one embodiment of the present invention; Figure 3 This is a flowchart of system call interception and operation credential generation in one embodiment of the present invention; Figure 4 This is a flowchart of the advanced security policy compilation process in one embodiment of the present invention; Figure 5 This is a flowchart of the verification engine matching and adjudication generation process in one embodiment of the present invention; Figure 6 This is a flowchart illustrating the generation process of the adjudication execution and auditing unit in one embodiment of the present invention; Figure 7 This is a multi-module linkage flowchart of a sandbox-type trusted data space construction device based on a trusted verification architecture in one embodiment of the present invention. Figure 1 ; Figure 8 This is a multi-module linkage flowchart of a sandbox-type trusted data space construction device based on a trusted verification architecture in one embodiment of the present invention. Figure 2 . Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Example 1: like Figures 1-6 As shown, a sandbox-based trusted data space construction method based on a trusted verification architecture in one embodiment of the present invention includes the following steps: S1. Launch the sandbox in the Intel SGX or AMD SEV hardware-based Trusted Execution Environment (TEE) and initialize the sandbox instance. Utilize the hardware isolation features of the TEE to ensure the immutability of the sandbox runtime environment. Generate a unique Task Context Identifier (CID) for each data processing task to be run within the sandbox, serving as an identity identifier throughout the task's lifecycle.

[0021] The steps for generating a unique task context identifier include: The cryptographic hash value of the executable file for the data processing task is calculated as the file fingerprint. The file fingerprint calculation method is as follows: in, Indicates the first The executable file for each task. Represents a file fingerprint.

[0022] In the formula, a cryptographic hash function is used to hash the first... The executable file for each task ( The calculation yields a 256-bit fixed-length hash value. This will form a unique and rigid mapping relationship with the executable file's code, structure, configuration, and other immutable essential attributes: If the core binary content of the corresponding executable file remains unchanged, then Unchanged, but if the core content of the document changes... Inevitable change, thus through Uniquely identify and lock the computational data processing task.

[0023] The core content is not superficial attributes such as filename, storage path, and modification time.

[0024] In other words, if If any minor change occurs to its core essential attributes, such as code tampering, configuration modification, or the injection of malicious modules, then... This will fundamentally change due to the avalanche effect of hash functions. Through It uniquely identifies and locks the identity of the program execution entity for the data processing task, providing a foundation for the uniqueness and anti-forgery properties of subsequent task context identifiers.

[0025] After obtaining the file fingerprint, the unique instance ID assigned to the current sandbox instance and the high-precision timestamp of the current system are obtained. Then the file fingerprint, instance ID and high-precision timestamp are spliced, and the first hash value is calculated for the spliced data. The calculation method of the first hash value is: In the formula, is the sandbox instance ID, is the microsecond-level timestamp, and the microsecond-level timestamp can avoid task conflicts under the same instance, is a string splicing function used to splice byte streams in order.

[0026] After obtaining the first hash value, the first hash value is combined with a random number generated by a cryptographically secure pseudo-random number generator, and a second hash value is calculated. The output of the second hash value is used as the task context identifier. When calculating the second hash value, the first hash value is combined with the random number, and then the second hash value is calculated, and the second hash value is used as the task context identifier without additional conversion. When calculating the second hash value, the first hash value is XORed with the random number, or the first hash value is sequentially spliced with the random number, and the operation result of the XOR operation or the sequential splicing with the random number is used as the input of the second hash value.

[0027] When the first hash value is XORed with the random number, the calculation method of the second hash value is: In the formula, is a cryptographically secure pseudo-random number, is 256 bits, generated by a cryptographically secure pseudo-random number generator (CSPRNG), and generated by an elliptic curve cryptography mechanism. is an XOR operation to confuse and to improve the randomness of .

[0028] The second hash value is obtained by XORing the first hash value with the random number. Since the XOR operation is a high-efficiency bit operation supported by the CPU by nature, the generation of and the second hash value takes negligible time and does not increase significant performance overhead. And due to the irreversibility of the XOR operation, even if the attacker obtains the task context identifier of , it is impossible to deduce or from . By using the characteristics of the hash function being a one-way function and the inverse operation of XOR, only when and are known, can The characteristics of the task context identifier make it impossible for attackers to obtain the core parameters through brute force or mathematical derivation, and the superposition of sensitive information such as file fingerprints that attackers cannot obtain forms a multi-layered anti-attack system that blocks malicious behaviors such as task context identifier forgery and task impersonation at the source.

[0029] Further, the combination of XOR operation and secondary hash does not depend on specific hardware environment and is compatible with different types of trusted execution environment and encryption algorithms, has good scalability, and reserves flexible space for subsequent system upgrade or algorithm iteration.

[0030] When the first hash value and the random number are sequentially spliced, the calculation method of the second hash value is: The sequential splicing calculation method of the first hash value and the random number directly combines the 256-bit and the 256-bit into a 512-bit input stream, fully retaining the task association deterministic entropy of and the unpredictable random entropy of without modifying the bit distribution of either party, maximizing the utilization of entropy values. This design allows the hash function to fully utilize the complementarity of double entropy values, ensuring strong binding of the task context identifier with the task program and the running environment, then injecting unpredictable random factors, even in extreme cases there is a risk of repetition, but the completely random nature of will result in a completely different input stream after splicing, generating a globally unique after hashing, further reducing the collision probability of the task context identifier from a mathematical level. Compared with XOR operation, splicing does not cause entropy value loss due to bit flipping, and the anti-collision property is more robust.

[0031] The calculation method of the second hash value can also use the combination of XOR and hash to form a complement for different scenarios: when the scene places more emphasis on entropy value maximization, compatibility, and implementation simplicity, the splicing method is the optimal solution. When the scene places more emphasis on bit confusion strength, the XOR method can be selected. This flexible design allows the entire task context identifier generation scheme to adapt to different security requirements, hardware performance, and deployment environments, while the generated also has the core properties of unique identification and unforgeability.

[0032] S2, intercepting the system call sequence issued by the data processing task through the monitoring agent residing in the trusted execution environment, generating an atomic operation record containing the operation type, operation object and current timestamp for each system call sequence, binding the task context identifier with the atomic operation record to form a context-bound operation credential, and forming a chain association.

[0033] The atomic operation record is calculated as follows: In the formula, represents the atomic operation record corresponding to the jth system call of the ith task, represents the type of the jth operation of the ith task, represents the object of the jth operation of the ith task, represents the high-precision timestamp of the jth operation of the ith task.

[0034] From the intercepted system call, the operation type, operation object and operation time, which are three core information that cannot be tampered with, are extracted to form the minimum trusted record unit of single operation, avoiding the interference of redundant information in subsequent verification.

[0035] The specific steps of generating the context-bound operation credential are as follows: when generating the current operation credential, the hash value of the previous operation credential is introduced as input, a field for storing the hash value of the previous credential is added in the data structure of the atomic operation record, and the complete data structure containing the task context identifier, atomic operation record and hash value of the previous credential is subjected to hash calculation and digital signature. The hash value of the first operation credential is filled with a preset initial value.

[0036] Through the context-bound operation credential scheme, the problem that the traditional monitoring log is easy to be tampered with by a single piece can be solved, and a win-win or lose-lose association relationship is formed through chain hashing to ensure the integrity of the operation record.

[0037] In addition, the hash value of the previous credential is introduced in each operation credential to form a chain structure, ensuring the continuity and tamper resistance of the operation sequence. Any tampered credential will cause the hash chain to break, which can be quickly detected.

[0038] The complete data structure of the operation credential is as follows: In the formula, represents the complete basic data before generating the operation credential, represents the context identifier of the ith task, which is used to bind the task identity to which the operation belongs, and ensure that the operation can be traced back to a specific task, represents the atomic record of the jth operation of the ith task, This represents the hash value of the previous operation credential, enabling a chained association of operation sequences. The function of this formula is to integrate the task context identifier, AOR, and preceding operation associations into a single data unit, providing a complete data source for the subsequent generation of immutable and traceable operation credentials.

[0039] The calculation method for generating operation vouchers is as follows: In the formula, This represents the context binding operation credential corresponding to the j-th operation of the i-th task. This refers to a cryptographic hash function, primarily used to ensure... The integrity, as long as Any modification will completely change the hash result. This indicates the use of the monitoring agent's private key. Sign the hash result. This indicates the private key of the monitoring agent residing within the TEE, held only by the MA, ensuring that the credential originates from a trusted TEE environment and cannot be forged. The formula employs a dual mechanism of hashing and signing to guarantee the integrity and trustworthiness of the operation credential, allowing subsequent verification engines to confirm that the operation credential indeed originates from a legitimate monitoring agent within the TEE and that its content has not been tampered with.

[0040] S3. Outside the sandbox, the advanced security policies defined by the data provider are compiled into an executable set of verification policies consisting of operation types and object pattern rules. Policy compilation transforms the advanced security policies defined by the data provider in natural language or domain-specific languages ​​(DSLs) into an executable rule set based on deterministic finite automata (DFA), supporting real-time matching. S3 is triggered when the provider submits a new advanced security policy or when an existing policy needs to be updated.

[0041] The specific steps for compiling the advanced security policy into a verification policy set are as follows: parsing the natural language or domain-specific language description in the advanced security policy, converting the natural language or domain-specific language description into a policy model represented by a finite state machine, the state transition conditions of the finite state machine being defined by operation type and object pattern rules, compiling the policy model into rule code based on the state transition logic of a deterministic finite automaton, and the rule code being executed by the verification engine by querying the state transition table.

[0042] Furthermore, the Advanced Security Policy Model (ASPM) is a formalized definition of a Finite State Machine (FSM). Specifically, the ASPM is defined as follows: In the formula, Represents a set of states, including the initial state. This indicates that the task has not yet performed any operations. For example, the AI ​​model in the sandbox has just started and has not yet performed operations such as file reading or network connection. ... This is represented as an intermediate state, indicating that the task has performed a compliant operation but has not triggered a violation, for example... This corresponds to files that have been read from a specific directory. This indicates a violation status, meaning the task has triggered a violation of policy restrictions, such as connecting to an external IP after reading a file.

[0043] Represented as an input alphabet, it represents the combination of operations that can trigger state changes. Each element is a tuple of operation type and object pattern rule. The former is the operation behavior of the task, such as reading or connecting, and the latter is the matching pattern of the operation object, such as file path, IP range regular expression or range rule.

[0044] The state transition function defines the mapping logic between the current state, the combination of operations, and the next state. It is the core execution rule of the policy, and its calculation formula is: In the formula, This represents the current state of the strategy. The type of operation actually performed by the task. This is represented as an object matching function, used to determine whether the object being operated on matches the pattern. The result of the judgment returns a boolean value. This indicates the next state the policy enters after performing this operation.

[0045] Finite state machines (FDMs) are logical models of policies, but machines cannot execute them efficiently directly. Therefore, they need to be compiled into an executable form of deterministic finite automata (DFAs). The output of a DFA compilation is as follows: In the formula, This represents the DFA state transition table, which is mainly used for storing... Mapping enables fast queries. This is an executable set of verification strategies, and the final output is a combination of the FSM logical model and the DFA state transition table, which the verification engine can load directly. The operation vouchers are matched in real time by looking up a table.

[0046] In summary, the core principle of S3 is to transform advanced security policies—which are easily understood by data providers but cannot be directly executed by machines—into a set of verification rules that can be executed by machines in real time and efficiently through formal modeling and executable compilation. Essentially, it eliminates the ambiguity of natural language, converting business-oriented security requirements into structured machine-executable logic.

[0047] Compared to the static rules of traditional sandboxes that only allow for single operations, FSM and DFA can match multi-step operation sequences, such as chain violations involving reading classified files and then connecting to external IPs, thus covering more realistic attack scenarios. In terms of maintainability, when data providers adjust security policies by modifying protected file paths or updating restricted IP ranges, only recompiling and generating new rules is required. This approach eliminates the need to modify the core logic of the verification engine, significantly reducing system maintenance costs. Therefore, the sandbox-based trusted data space construction method based on the trusted verification architecture can support arbitrarily complex security policies and adapt to the personalized data protection needs of different industries such as government, healthcare, and finance.

[0048] S4. The context-bound operation credentials generated in step S2 are transmitted to an external verification engine in real time via streaming. The verification engine performs real-time matching analysis on the sequence of operation credentials based on the executable verification policy set generated in step S3. When a credential sequence matches a restriction rule in the executable verification policy set, a policy adjudication instruction is generated and signed. The triggering conditions for S4 are: the verification engine receives a new operation credential or the state transitions to a violation state. .

[0049] The calculation methods for state transition and violation judgment are as follows: In the formula, the verification engine calls the state transition function. If calculated In this state, it means that the operation has triggered the restriction rules.

[0050] The calculation method for generating the ruling order: in, To verify the engine's private key, It uses an asymmetric private key to ensure the credibility of the source of the ruling instructions. This refers to the triggering restriction rule, specifically meaning... The kth rule in the [theory / system]. This indicates a policy decision instruction, the contents of which include the task ID, trigger credentials, rule information, etc.

[0051] When the verification engine detects At that time, an adjudication command will be generated to forcibly interrupt the violation operation, and will utilize... The ruling is digitally signed. It possesses the attributes of being immutable and having a trusted source. Upon receiving an adjudication command, the monitoring agent within the sandbox will first verify the public key of the verification engine. Only after verifying the validity of the signature and confirming that it is a legitimate ruling will the violation interruption be executed. This method can prevent attackers from forging ruling instructions to interfere with the task.

[0052] Specifically, the verification engine is configured to perform the following steps: the verification engine periodically responds to the end of the data processing task in the sandbox or to the generation of a policy adjudication instruction in step S4, determines the hash value of the latest context-bound operation credential received as the head hash of the current context-bound operation credential hash chain, uses it as the chain anchor, and sends the chain anchor to an external, tamper-proof evidence storage system for storage.

[0053] The termination trigger condition for data processing tasks within the sandbox is as follows: when a task within the sandbox completes the preset data processing flow and actively sends a task termination signal to the sandbox, the verification engine receives this signal and triggers the generation of a chain anchor. When a task terminates normally, its operation credential hash chain has been fully generated. At this point, the hash value of the latest credential is used as the chain anchor to ensure that the chain anchor corresponds to a complete operation sequence. Subsequent audits can verify the integrity of the entire task's operation record through this anchor.

[0054] The trigger condition for generating a policy adjudication instruction in step S4 is as follows: when the verification engine detects a violation, it generates a policy adjudication instruction and simultaneously triggers the generation of a chain anchor. When a task is interrupted due to a violation, the operation sequence terminates prematurely. At this time, the latest operation credential is the final node of the entire operation chain. Taking its hash value as the chain anchor ensures that the violation and all previous operations are completely recorded and anchored, preventing attackers from tampering with the generated operation credential after the task is interrupted.

[0055] When it is necessary to verify the integrity of an operation certificate over a period of time, the corresponding chain anchor is obtained from the evidence storage system, and the continuity of the entire hash chain is verified by tracing back from the operation certificate corresponding to the chain anchor to a known trusted certificate.

[0056] In other words, when the verification engine finishes a task or generates an adjudication instruction, it stores the hash value of the latest credential as a chain anchor in an immutable system. During verification, the chain anchor is traced back to check the continuity of the hash chain and confirm that the operation record has not been tampered with.

[0057] Specifically, the chain anchor is the hash value of the latest credential for the current task, serving as a trusted benchmark in the evidence storage system. The chain anchor is calculated as follows: In the formula, This represents the last operation credential and is the most recent credential at the end of the task or when a decision is generated. It is triggered only when the task ends normally or when a policy decision instruction is generated. These two points in time are critical closing points in the task operation sequence, ensuring that the chain anchor covers all tasks.

[0058] The calculation method for hash chain integrity verification is as follows: In the formula, This indicates the sequence number of the last operation document corresponding to the chain anchor point. Indicates the serial number of a known trusted credential. This represents a logical AND operation. If all equations are true, the verification passes. In other words, it returns True when all conditions are met. The hash used to verify whether the hash of the m-th voucher is equal to that of the (m+1)-th voucher. Its essence is the verification anchor of hash chain continuity. It links scattered operation credentials into an immutable operation trajectory, which not only ensures the authenticity and integrity of operation records, but also supports efficient compliance auditing. It is the core technical guarantee for the traceability of operations and the immutability of records in the entire trusted data space.

[0059] Chain-anchored notarization technology significantly reduces the amount of notarized data at the source by storing the hash values ​​of massive amounts of data on the blockchain, rather than the data itself, effectively lowering storage costs. Furthermore, leveraging the inherent immutability of blockchain ensures the absolute trustworthiness of the chain anchor itself, providing a solid foundation of trust for the entire verification system. It is on this foundation of trust that the reverse traceability verification mechanism operates efficiently, allowing users to perform partial verification as needed without traversing all historical credentials, thus greatly improving verification efficiency.

[0060] The core principle of step S4 is to achieve dynamic compliance verification of operation sequences through real-time streaming and DFA rule matching, ensure the credibility of adjudication instructions through digital signatures, and construct an integrity verification system for operation records using chain anchors and tamper-proof evidence storage. Essentially, it transforms the entire process of operation monitoring, violation blocking, record storage, and audit verification into automated logic that can be efficiently executed by machines and possesses trustworthy attributes.

[0061] Step S4, through streaming operation credentials and using a deterministic finite automaton (DFA) for real-time matching, can trigger an adjudication and directly interrupt the execution of a task if a violation occurs, thus preventing data leakage at the source and achieving a shift from post-event auditing to real-time blocking. To ensure the security and credibility of the adjudication instructions themselves, all instructions must be signed with the verification engine's private key. The monitoring agent within the sandbox must verify the signature before execution, effectively preventing attackers from forging malicious instructions. In the evidence storage stage, the system only needs to store the chain anchor, rather than the complete operation credential, on the blockchain, reducing the amount of evidence storage data by more than 99%, significantly lowering storage costs and enabling it to easily support large-scale scenarios with hundreds of thousands or even millions of tasks. During post-event auditing, the continuity of the hash chain can be traced and verified using this chain anchor without traversing all operation credentials.

[0062] S5. Send the policy decision instruction back to the sandbox environment and have it forcibly executed by the monitoring agent to interrupt the violation. At the same time, generate an audit record and generate an immutable audit unit for integrity verification based on the audit record. The data structure of the audit record includes the operation credentials bound to the context corresponding to this policy decision, the rules in the set of verification policies triggered, and the generated policy decision instruction.

[0063] The core logic of step S5 is to construct a complete closed loop for blocking violations and solidifying evidence: After the policy adjudication instruction generated by the verification engine is transmitted to the sandbox via an encrypted channel, the monitoring agent within the TEE completes the signature legality verification. Subsequently, it interrupts the violation operation through coercive measures such as blocking system calls and freezing task processes, ensuring that the risk is immediately controllable. At the same time, the monitoring agent generates a structured audit record containing the violation task identifier, the operation credential that triggered the violation, the corresponding restriction rules, the adjudication instruction, the execution result, and the timestamp, comprehensively preserving the complete context of the violation event and providing core evidence for subsequent compliance audits and accountability.

[0064] To ensure the immutability and verifiability of audit records, an immutable audit unit is generated based on the audit records: First, the audit record is converted into leaf node hashes using a cryptographic hash function. Then, the root hash is recursively calculated using a Merkle tree. Subsequently, this root hash, along with the audit timestamp and task identifier, is packaged and submitted to a blockchain network or an authoritative timestamp authorization institution to generate a verifiable receipt containing time proof and storage address. This design significantly reduces storage costs through Merkle tree compression while leveraging the immutability of blockchain and authoritative institutions to ensure the authenticity and time traceability of audit evidence. It supports rapid third-party verification and perfectly adapts to the audit requirements of highly compliant scenarios.

[0065] Example 2: In the strategy model represented by a finite state machine, a state transition path is defined to restrict the flow of data. The specific state transition conditions for the state transition path are: The transition condition from the initial state to the first intermediate state is: receiving an operation credential whose operation type is read and whose operation object matches the first predefined pattern; The transition condition from the first intermediate state to the violation state is: receiving an operation credential whose operation type is connection or send and whose operation object matches the second predefined pattern; The first predefined pattern is used to define protected data resources, and the second predefined pattern is used to define restricted network endpoints.

[0066] The validation engine executes rule code by querying the state transition table, specifically as follows: The verification engine maintains a separate state machine instance in memory for each active task context identifier; When a new operation credential arrives, the verification engine locates the corresponding state machine instance based on the task context identifier bound to the operation credential, and uses the operation type and operation object of the operation credential as the join query key to query the state transition table and drive the state machine instance to perform state transition.

[0067] In this embodiment, precise control over data flow is achieved through formal rule modeling and multi-task independent verification. On one hand, in the finite state machine strategy model, dedicated transition paths are constructed for the initial state, the first intermediate state, and the violation state, transforming the data flow restriction rules into unambiguous state transition logic: a read operation matching a first predefined pattern serves as the trigger condition for the transition from the initial state to the first intermediate state, and a connect or send operation matching a second predefined pattern serves as the trigger condition for the transition from the intermediate state to the violation state, clearly defining the criteria for judging high-risk data flows. On the other hand, the verification engine maintains an independent state machine instance for each active task context identifier. When a new operation credential arrives, the corresponding instance is first located through the task context identifier, and then the operation type and operation object of the operation credential are used as a joint query key to query the state transition table to drive the state machine transition, ensuring that rule execution is strongly bound to specific tasks and achieving precise tracking of one task, one state.

[0068] Example 3: like Figures 7-8 As shown, an embodiment of the present invention discloses a sandbox-based trusted data space construction device based on a trusted verification architecture, comprising a sandbox management module, a behavior monitoring module, a policy compilation module, a verification and adjudication module, and an execution audit module. Through the organic collaboration of these five core modules, end-to-end trusted assurance is achieved from environment initialization, behavior capture, policy verification to adjudication execution and audit traceability. The modules exchange data and coordinate control through well-defined interfaces, forming a clearly structured and fully functional technical system.

[0069] The sandbox management module, serving as the foundational support layer of the device, is responsible for establishing the trusted execution environment and managing task identities. This module launches sandbox instances within the hardware-based trusted execution environment, generating unique task context identifiers for each data processing task to be run within the sandbox using multi-layered cryptographic techniques. Specifically, the sandbox management module first calculates the cryptographic hash value of the task's executable file as a file fingerprint, then combines this with the unique identifier of the sandbox instance and a high-precision timestamp. After two hash calculations and random number enhancement processing, a task context identifier with strong uniqueness and anti-forgery capabilities is finally generated. This design ensures that each task has an immutable and verifiable digital identity.

[0070] The behavior monitoring module, acting as the data acquisition layer, is deployed within the trusted execution environment to achieve fine-grained capture and credential processing of operational behaviors. This module intercepts the system call sequences issued by data processing tasks in real time through a monitoring agent, generating an atomic operation record for each system call that includes the operation type, operation object, and a precise timestamp. The module employs an innovative hash chain technique to cryptographically bind the task context identifier to the atomic operation record, forming a context-bound operation credential with temporal correlation. This design not only ensures the integrity of individual operations but also maintains the continuity and non-repudiation of the operation sequence.

[0071] The policy compilation module acts as the central hub for policy transformation, translating abstract security requirements into executable verification logic. This module receives high-level security policies defined by data providers, which can be described using natural language or domain-specific languages. Through three key steps—parsing, transformation, and compilation—the module first parses the semantic structure of the policy, then converts it into a policy model based on a finite state machine, and finally compiles it into state transition rule code that the verification engine can directly execute. This compilation process enables complex security policies to be accurately understood and efficiently executed by the machine.

[0072] The verification and adjudication module, as the core processing unit of the device, enables real-time behavior analysis and dynamic security adjudication. This module receives the operation credential stream generated by the behavior monitoring module, loads the executable verification policy set generated by the policy compilation module through the verification engine, and performs real-time pattern matching and analysis on the operation credential sequence. When an operation sequence violating the security policy is detected, the module immediately generates a digitally signed policy adjudication instruction. Simultaneously, this module is also responsible for maintaining the integrity of the operation credential hash chain, periodically submitting the chain head hash as a trust anchor to an external blockchain or timestamp service provider to establish an immutable audit benchmark.

[0073] The audit module forms the closed-loop control terminal of the device, ensuring the mandatory implementation of security policies and the traceability of the entire process. This module reliably transmits the policy decision instructions generated by the verification decision module back to the sandbox environment, and uses a monitoring agent to interrupt and handle violations in real time. While executing security decisions, the module automatically generates structured audit logs, fully containing the operation credentials that triggered the decision, relevant security rules, and the executed decision instructions. Through Merkle tree hashing and timestamp notarization technology, the module constructs an immutable audit unit, providing cryptographic-level evidence support for post-event auditing and accountability.

[0074] In the above embodiments, the deep collaboration and precise coordination of the five modules achieve three technical effects: First, it completely solves the technical problem of unknowable and untrustworthy behavior within the sandbox, establishing a verifiable behavior tracing mechanism through a hardware-level trusted environment and cryptographic technology. Second, it effectively overcomes the rigidity of traditional security policies, achieving flexible adaptation and intelligent execution of security policies through dynamic compilation and real-time verification. Finally, it constructs a complete data security trust system, forming a closed loop of trusted assurance throughout the entire lifecycle, from environment initialization to behavior monitoring, and from policy verification to audit tracing.

[0075] In practical deployment, the device of this invention requires coordinated support at both the hardware and software levels. At the hardware level, it requires a processor platform supporting a Trusted Execution Environment (TEA), such as Intel SGX or AMD SEV technology, to provide hardware-level security isolation and cryptographic safeguards. At the software level, five core components need to be deployed according to a modular architecture. These components exchange data through a secure communication protocol, collectively constructing a complete and trusted data space solution. During implementation, parameters and rules for the policy compilation module and verification and adjudication module can be optimized and customized according to specific business scenario requirements to achieve the best security effect and performance.

[0076] Obviously, the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention also intends to include these modifications and variations.

Claims

1. A sandboxed trusted data space construction method based on a trusted verification architecture, characterized in that, The method comprises the following steps: S1, starting a sandbox in a hardware trusted execution environment, and generating a unique task context identifier for each data processing task to be run in the sandbox; S2, intercepting system call sequences issued by the data processing task through a monitoring agent in the trusted execution environment, generating an atomic operation record containing operation type, operation object and current timestamp for each system call sequence, binding the task context identifier with the atomic operation record to form a context-bound operation credential; S3, compiling the high-level security policy defined by the data provider into an executable verification policy set composed of operation type and object mode rules; S4, streaming the operation credential generated in step S2 to an external verification engine, which performs real-time matching analysis on the sequence of operation credentials according to the executable verification policy set generated in step S3; When the credential sequence matches the restriction rule in the executable verification policy set, a signed policy decision instruction is generated; S5, sending the policy decision instruction back to the sandbox environment and enforcing it by the monitoring agent to interrupt the violation operation; At the same time, an audit record is generated, and an unalterable audit unit for integrity verification is generated based on the audit record.

2. The sandboxed trusted data space construction method based on a trusted verification architecture according to claim 1, characterized in that, The step of generating the unique task context identifier comprises: Calculating the cryptographic hash value of the executable file of the data processing task as a file fingerprint; Obtaining a unique instance ID assigned to the current sandbox instance and obtaining a high-precision timestamp of the current system; Splicing the file fingerprint, instance ID and high-precision timestamp, and calculating a first hash value of the spliced data; Combining the first hash value with a random number generated by a cryptographically secure pseudo-random number generator, and calculating a second hash value, taking the output of the second hash value as the task context identifier.

3. The sandboxed trusted data space construction method based on a trusted verification architecture according to claim 2, characterized in that, Before calculating the second hash value, the step of combining the first hash value with the random number is specifically: XORing the first hash value with the random number, and taking the operation result as the input of the second hash value; Or, Sequentially splicing the first hash value with the random number, and taking the spliced result as the input of the second hash value.

4. The sandboxed trusted data space construction method based on a trusted verification architecture according to claim 1, characterized in that, The specific steps for generating the context-bound operation credential are: When generating the current operation credential, the hash value of the previous operation credential is introduced as input, and the specific steps are: In the data structure of the atomic operation record, a field for storing the previous credential hash value is added, and the complete data structure containing the task context identifier, the atomic operation record and the previous credential hash value is subjected to hash calculation and digital signature; Wherein, the previous credential hash value of the first operation credential is filled with a preset initial value.

5. The sandboxed trusted data space construction method based on a trusted verification architecture according to claim 4, characterized in that, The verification engine is configured to perform the following steps: The verification engine periodically determines, as a chain head hash of a current context-bound operation credential hash chain, a hash value of a latest context-bound operation credential currently received, in response to an end of a data processing task in the sandbox or in response to generating a one-time policy decision instruction in step S4; The chain head hash is sent to an external, tamper-proof storage system for storage; When it is necessary to verify the integrity of operation credentials within a period of time, the corresponding chain head hash is obtained from the storage system, and the continuity of the entire hash chain from the operation credential corresponding to the chain head hash to a known trusted credential is verified in reverse according to the hash chain.

6. The sandboxed trusted data space construction method based on a trusted attestation architecture of claim 1, wherein, In step S3, the high-level security policy is compiled into a verification policy set, and the specific steps include: parsing the natural language or domain-specific language description in the high-level security policy; converting the natural language or domain-specific language description into a policy model represented by a finite state machine, wherein the state transition conditions of the finite state machine are defined by operation type and object pattern rules; compiling the policy model into rule code based on the state transition logic of deterministic finite automata, which can be executed by the verification engine by querying a state transition table.

7. The sandboxed trusted data space construction method based on a trusted attestation architecture according to claim 6, characterized in that, In the policy model represented by the finite state machine, a state transition path for limiting data flow is defined; The state transition conditions of the state transition path are as follows: the transition condition from the initial state to the first intermediate state is that an operation credential whose operation type is read and whose operation object matches a first predefined pattern is received; the transition condition from the first intermediate state to the violation state is that an operation credential whose operation type is connection or sending and whose operation object matches a second predefined pattern is received; wherein the first predefined pattern is used to define a protected data resource, and the second predefined pattern is used to define a restricted network endpoint.

8. The sandboxed trusted data space construction method based on a trusted verification architecture according to claim 6 or 7, characterized in that, The process of the verification engine executing the rule code by querying the state transition table is as follows: The verification engine maintains a separate state machine instance in memory for each active task context identifier; When a new operation credential arrives, the verification engine locates the corresponding state machine instance according to the task context identifier bound to the operation credential, and queries the state transition table with the operation type and operation object of the operation credential as joint query keys to drive the state machine instance to transition.

9. The sandboxed trusted data space construction method based on a trusted attestation architecture of claim 1, wherein, In step S5, the tamper-proof audit unit is specifically: calculating a Merkle tree root hash of the data of the audit unit; submitting the root hash and a current timestamp to a blockchain network or a time-stamping authority to obtain a verifiable receipt containing a time proof.

10. A sandboxed trusted data space construction device based on a trusted attestation architecture, characterized in that, It includes: a sandbox management module for starting a sandbox in a hardware-based trusted execution environment and generating a unique task context identifier for each data processing task to be run in the sandbox; a behavior monitoring module for intercepting system call sequences issued by the data processing task through a monitoring agent residing in the trusted execution environment, generating an atomic operation record for each system call sequence, binding the task context identifier with the atomic operation record to form a context-bound operation credential; a policy compiling module for compiling the high-level security policy defined by the data provider outside the sandbox into an executable verification policy set; a verification decision module for streaming the context-bound operation credential to an external verification engine in real time, the verification engine performing real-time matching analysis on the sequence of operation credentials according to the executable verification policy set and generating and signing a policy decision instruction; an execution auditing module for sending the policy decision instruction back to the sandbox environment and enforcing the same by the monitoring agent to interrupt a violation operation while generating an audit record and generating an unalterable audit unit for integrity verification based on the audit record.

Images