Data processing method and apparatus based on trusted execution environment

Abstract

The application relates to the computer technical field and provides a data processing method and device based on a trusted execution environment, which comprises the following steps: obtaining a current environment measurement value of the trusted execution environment, judging whether the current environment measurement value matches a preset measurement strategy; in response to the matching, unsealing a target key bound with the current environment measurement value in the trusted execution environment, and performing processing on to-be-processed data based on the target key to obtain a processing result; generating an output voucher, wherein the output voucher binds a result digest of the processing result, the current environment measurement value and an identity signature; in response to the current environment measurement value not matching or the trusted execution environment being unavailable, rejecting the processing of the to-be-processed data and generating a blocking record. The application binds key unsealing with measurement, ensures that only an expected trusted environment processes data, blocks degradation in an abnormal situation, and realizes a trusted closed loop of a data processing whole link.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a data processing method and apparatus based on a trusted execution environment. Background Technology

[0002] As intelligent agent systems begin to represent users or organizations in accessing business resources, invoking tools, processing identity credentials, and generating behavioral proofs, the intelligent agent runtime needs to perform operations such as identity signing, request proof, sensitive data anonymization, feature extraction, and local lightweight inference. Existing technologies commonly employ solutions including hardware key protection schemes, anonymization schemes within ordinary operating environments, trusted execution environment schemes, and remote proof schemes.

[0003] However, while the aforementioned solutions address private key protection, sensitive data processing, isolated execution, and environment verification, they still lack a unified mechanism to bind agent identity, trusted execution environment metrics, key decryption conditions, sensitive processing task lists, and certified output receipts in the context of agent runtime scenarios. Specifically, simply protecting the private key from leaving the hardware is insufficient to prove that the signing action occurred in an undisturbed runtime environment. Attackers can inject malicious code into a normal runtime environment to drive secure hardware to issue a seemingly legitimate request proof. Sensitive inputs and intermediate states are easily exposed when existing in plaintext in a normal runtime environment. External verifiers struggle to verify which trusted execution environment and code version generated the result. When the trusted execution environment is unavailable or the metrics are mismatched, the system reverts to a normal runtime environment, turning security degradation into an attack channel. Furthermore, sensitive data processing lacks task-level constraints, making it difficult to ensure that sensitive data is "processable but not visible."

[0004] Therefore, there is an urgent need for a data processing mechanism that can form a closed loop between identity signing, sensitive data processing, measurement proof, and output verification. Summary of the Invention

[0005] The purpose of this application is to provide a data processing method and apparatus based on a trusted execution environment, so as to alleviate the technical problems of untrusted signature environment and easy bypassing of security degradation in the prior art.

[0006] In a first aspect, the present invention provides a data processing method based on a trusted execution environment, comprising: Obtain the current environment metric value of the trusted execution environment, and determine whether the current environment metric value matches the preset metric strategy; In response to the matching, the target key bound to the current environment metric is unsealed within the trusted execution environment, and the data to be processed is processed based on the target key to obtain the processing result; Generate an output credential, which binds the result summary of the processing result, the current environment metric, and the identity signature; In response to a mismatch in the current environment metric or the unavailability of the trusted execution environment, the processing of the pending data is refused and a blocking record is generated.

[0007] In an optional implementation, the current environment metrics include code metrics and configuration metrics; The decryption conditions of the target key are bound to the current environment metric value. In response to the fact that both the code metric and the configuration metric match the preset metric policy, the target key is decrypted within the trusted execution environment.

[0008] In an optional implementation, the target key includes an identity signing key or a data processing key; the preset metric strategy includes a preset code hash value and a preset configuration hash value; the code metric is the hash value of the currently loaded code within the trusted execution environment, and the configuration metric is the hash value of the currently running configuration within the trusted execution environment; the method further includes: In response to the code metric being consistent with the preset code hash value and the configuration metric being consistent with the preset configuration hash value, the identity signing key or the data processing key is unsealed within the trusted execution environment; In response to the code metric being inconsistent with the preset code hash value or the configuration metric being inconsistent with the preset configuration hash value, the identity signing key and the data processing key are refused to be unsealed; The identity signing key is used to sign the request digest, target identifier, random number, timestamp, and agent identity number to generate the identity signature; The data processing key is used to perform at least one of the following processing on the data to be processed: decryption, desensitization, feature extraction, or local lightweight inference. The plaintext of the identity signing key and the data processing key does not leave the trusted execution environment, and the plaintext is destroyed within the trusted execution environment after processing is completed.

[0009] In an optional implementation, after unsealing the target key within the trusted execution environment, the method further includes: Establish an encrypted session for the data to be processed; The encrypted session includes a session key, a random number, a caller identifier, a target identifier, a request digest, and a validity period; The data to be processed is transmitted to the trusted execution environment in encrypted form through the encrypted session, and the plaintext of the data to be processed only appears within the trusted execution environment.

[0010] In an optional implementation, before processing the data to be processed within the trusted execution environment, the method further includes: Generate task constraint information, which includes task identifier, input data category, allowed processing type, output field set, prohibited output fields, retention policy, and clearing policy; The permitted processing types include at least one of identity request signing, request digest signing, sensitive field desensitization, feature extraction, local lightweight inference, or result digest generation; Within the trusted execution environment, the data to be processed is processed according to the task constraint information to obtain the processing result; In response to the processing result containing the prohibited output field, output is rejected and an exception is logged; After processing is completed, the plaintext, intermediate features, mapping table, and session key of the data to be processed are cleared or destroyed within the trusted execution environment.

[0011] In an optional implementation, the output credentials may further include the result category of the processing result, the metric proof of the trusted execution environment, and a proof chain reference; The output credentials bind the result summary, the result category, the current environment metric, the metric proof, and the proof chain reference through the identity signature, enabling external verifiers to verify the source of the processing result.

[0012] In an optional implementation, the output credentials may further include a request digest, a random number, an agent ID, and a processing time; The identity signature is generated by performing a signature on the result digest, the request digest, the random number, the agent's identity number, the current environment metric, the processing time, and the proof chain reference. The external verifier determines whether the processing result comes from the trusted execution environment and whether there is a replay by verifying the validity of the identity signature, the uniqueness of the random number, whether the processing time is within a valid time window, the consistency between the request digest and the original request, whether the current environment metric is within the allowed metric range, and the legality of the proof chain reference. If the verification passes, the external verifier receives the processing result; if the verification fails, the external verifier rejects the processing result and records the reason for rejection.

[0013] In an optional implementation, in response to the current environment metric not matching the preset metric policy, the target key failing to be unsealed, or the trusted execution environment being unavailable, the process of reverting to the normal operating environment to process the data to be processed is refused. The blocking record is generated, which includes the anomaly type, anomaly time, the current environmental metric, and the agent's identity number, for subsequent auditing and anomaly detection.

[0014] In a second aspect, the present invention provides a data processing apparatus based on a trusted execution environment, comprising: The metric matching module is configured to obtain the current environment metric value of the trusted execution environment and determine whether the current environment metric value matches a preset metric strategy. The key decryption processing module is configured to, in response to matching, decrypt the target key bound to the current environment metric within the trusted execution environment, and perform processing on the data to be processed based on the target key to obtain the processing result; The output credential generation module is configured to generate output credentials, wherein the output credential binds the result summary of the processing result, the current environment metric value, and the identity signature. The blocking module is configured to refuse to process the data to be processed and generate a blocking record in response to a mismatch in the current environment metric or an unavailable trusted execution environment.

[0015] In an optional implementation, the metric matching module is further configured to obtain the code metric and configuration metric of the trusted execution environment, and compare the code metric and the configuration metric with the preset metric strategy; In response to the fact that both the code metric and the configuration metric match the preset metric policy, the key decryption processing module is allowed to perform the key decryption operation.

[0016] Beneficial effects: This application binds the unsealing conditions of the identity signing key to the trusted execution environment metric. Only the expected trusted environment and expected code can use the key to complete the signing, thus preventing the normal environment from driving the hardware to sign out the request with a legitimate appearance.

[0017] This application ensures that sensitive inputs, de-identified mapping tables, feature vectors, and intermediate states are not exposed in plaintext in the normal operating environment through secure entry sessions, task lists, and processing within a trusted execution environment.

[0018] This application generates a certified output receipt, binding the result digest, request digest, random number, agent identity, code metric, configuration metric, and proof chain. External verifiers can determine whether the result was generated by the expected trusted environment. Fourth, it prevents security degradation from becoming a bypass path. This application blocks execution when the trusted execution environment is unavailable, the metric is inconsistent, the task is unauthorized, the proof expires, or there is a replay, preventing a return to a normal operating environment to continue processing equally sensitive tasks.

[0019] Enhance the controllability of sensitive data processing. This application restricts permitted processing types, output fields, prohibited output fields, and retention policies through a sensitive data processing task list, thus providing clear boundaries for desensitization, feature extraction, and local inference.

[0020] The certified receipts and downgrade blocking records output by this application can serve as factual inputs for subsequent behavior evidence preservation, anomaly detection, credit profiling, and regulatory auditing.

[0021] Enhance the credibility of external results. External verifiers should not only see a typical business result or signature, but should also be able to verify request digests, random numbers, environmental metrics, code versions, task list boundaries, and identity signatures to determine whether the result comes from the expected trusted processing chain. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of the system architecture of an embodiment of this application; Figure 2 This is a schematic flowchart of a data processing method based on a trusted execution environment according to an embodiment of this application; Figure 3 This is a schematic diagram of data object relationships in an embodiment of this application; Figure 4 This is a schematic diagram of the downgrade blocking process according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a data processing device based on a trusted execution environment according to an embodiment of this application. Detailed Implementation

[0024] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0025] Figure 2 As shown, this embodiment provides a data processing method based on a trusted execution environment. Figure 1 As shown, this method constructs a core defense framework for metric matching, key decryption, certified output, and downgrade blocking through the interactive collaboration of the ordinary running area scheduling module 10, trusted execution environment module 20, metric policy registry 30, metric binding key sealing module 40, secure entry session module 50, sensitive processing task list module 60, certified output receipt module 70, external verification module 80, and downgrade blocking and auditing module 90.

[0026] The normal operating area scheduling module 10 runs in a normal operating environment and is responsible for network communication, task scheduling, non-sensitive preprocessing, and interaction with external systems. This module does not directly access the agent's identity signature private key, does not store sensitive input plaintext, and does not perform core processing that requires trusted proof.

[0027] The Trusted Execution Environment (TEX) module 20 is an isolated execution boundary that carries trusted code. It can be implemented by a security chip, a secure execution zone, a trusted execution domain, a trusted container, a trusted virtualization environment, or a computing unit within a hardware security module. This module runs identity signing programs, sensitive data processing programs, proof generation programs, and intermediate state destruction programs.

[0028] The metric policy registry 30 stores records of allowed trusted environment metrics. Each metric record includes at least the trusted environment type, code hash, configuration hash, metric version, proof chain source, allowed operation set, enabled status, and validity period. The system only allows subsequent key decryption and sensitive processing steps when the current environment metric matches a valid record in the registry.

[0029] The metric binding key sealing module 40 stores key sealing packages bound to agent identity and environmental metrics. Each key sealing package includes at least the agent identity number, key purpose, hardware anchor reference, metric conditions, allowed operations, sealed ciphertext, sealed version, and sealed state. Within the trusted execution environment, this module determines whether the current metric meets the sealing conditions. If it does, the identity signing key or processing key is unsealed; otherwise, unsealing is refused.

[0030] The Secure Entry Session Module 50 is responsible for establishing an encrypted session between the normal operating zone and the trusted execution environment. This module generates a session key, a random number, a caller identifier, a target identifier, a request digest, a timestamp, and an expiration date for each processing step, ensuring that sensitive input enters the trusted execution environment in encrypted form and is bound to the current request.

[0031] The Sensitive Processing Task List module 60 defines the processing tasks that are allowed to be executed within the trusted execution environment. Each task list includes at least a task identifier, input data category, allowed processing type, output field set, prohibited output fields, retention policy, zeroing policy, policy version, and approval status. Allowed processing types may include one or more of the following: identity request signing, request digest signing, sensitive field desensitization, feature extraction, local lightweight inference, and result digest generation.

[0032] The certified output receipt module 70 generates proof of the processing result within a trusted execution environment. The certified output receipt includes at least the agent's identity number, task identifier, result digest, result category, trusted environment metric, code hash, configuration hash, proof random number, request digest, processing time, proof chain reference, and identity signature. This receipt serves to prove that the result was generated by a specific agent in a specific trusted environment and with a specific code version for a specific request.

[0033] The external verification module 80 is used by resource verification parties, business systems, regulatory audit systems, or collaborative intelligent agents. This module verifies the identity signature, request digest, random number, time window, trusted environment metric, code hash, proof chain, and identity status in the certified output receipt, and determines whether the result can be accepted.

[0034] The downgrade blocking and auditing module 90 is responsible for handling anomalies such as unavailable trusted execution environment, metric mismatch, expired proof, random number replay, key decryption failure, task list not allowed, and out-of-bounds output fields. When an anomaly is hit, the downgrade blocking and auditing module 90 generates a downgrade blocking record, refuses to continue signing or outputting sensitive processing results, and writes the blocking fact into the audit or event chain.

[0035] First, a trusted environment measurement policy can be registered. The system administrator or governance module will write the trusted environment type, code hash, configuration hash, proof chain, allowed operation set, and validity period allowed to perform agent identity signing and sensitive processing into the measurement policy registry 30.

[0036] Continue starting the Trusted Execution Environment (TEX) and generating current metrics. The TEX module 20 loads the signing program and sensitivity handling program, generates current code metrics, configuration metrics, and environment integrity metrics, and sends the metric values ​​to the metric policy registry 30 for matching.

[0037] Continue unsealing the key according to the metric conditions. The metric-bound key sealing module 40 checks whether the current metric meets the unsealing conditions of the key sealing package. If it does, the agent identity signature key or processing key is unsealed within the trusted execution environment; if it does not, unsealing is rejected, and a downgrade blocking process is initiated. The plaintext key does not leave the trusted execution environment.

[0038] Continue establishing a secure entry session. The secure entry session module 50 generates a session key, random number, caller, target, request digest, and expiration date for the current call, and uses an encrypted channel to transmit sensitive input to the trusted execution environment. The normal execution zone scheduling module 10 is only responsible for transmitting ciphertext and scheduling status; it does not read plaintext.

[0039] Continue generating and validating the sensitive processing task list. The sensitive processing task list module 60 generates a task list based on the request type, specifying the input category, allowed processing actions, output fields, prohibited output fields, retention policy, and zeroing policy. The trusted execution environment module 20 verifies whether the task list is valid; if a task is unauthorized or its output fields are out of range, execution is refused.

[0040] Processing continues within the Trusted Execution Environment (TEE). Within the trusted boundary, the TEE module 20 decrypts sensitive inputs and performs tasks such as identity request signing, sensitive field desensitization, feature extraction, local lightweight inference, or result digest generation according to the task list. Plaintext, intermediate features, mapping tables, and temporary keys generated during processing exist only within the TEE.

[0041] Continue generating results and destroying intermediate states. After processing, the Trusted Execution Environment module 20 outputs allowed fields and a result digest according to the task list, and performs zeroing or destruction on the plaintext input, intermediate states, temporary mapping tables, and session keys. If an output field contains a prohibited field from the task list, the output is rejected and an exception is logged.

[0042] Continue generating certified output receipts. The certified output receipt module 70 binds the result digest, result category, request digest, random number, agent identity, code metric, configuration metric, proof chain reference, and processing time, and generates a signature using the identity signing key or proof key unsealed within the trusted execution environment.

[0043] Continue with external verification and output. The external verification module 80 verifies the signature, random number, time window, request digest, trusted environment metric, code hash, proof chain, and agent identity state in the receipt. If verification passes, the external system receives the result; if verification fails, the result is rejected and the reason is recorded.

[0044] Continue with the downgrade blocking. If, during the aforementioned process, the trusted environment becomes unavailable, the metric mismatch occurs, the key decryption fails, the task list is not allowed, the proof expires, the random number is replayed, the request digest is inconsistent, or the output goes out of bounds, the downgrade blocking and auditing module 90 will cause the current task to fail-stop, refusing to return to the normal operating environment to continue performing the same sensitive processing, and will generate a downgrade blocking record.

[0045] like Figure 2 As shown, the method may include the following steps: Step S210: Obtain the current environment metric value of the trusted execution environment and determine whether the current environment metric value matches the preset metric strategy.

[0046] Specifically, after the Trusted Execution Environment (TEE) module 20 starts and loads the signing program and sensitive data processing program, it generates a current environment metric value, which reflects the integrity status of the current operating environment. The metric policy registry 30 pre-stores trusted environment metric records that allow the execution of agent identity signing and sensitive processing. The system sends the current environment metric value to the metric policy registry 30 for comparison. This matching judgment is a prerequisite for the entire trusted processing closed loop. Only when the current environment metric value matches the preset metric policy can it be said that the current trusted execution environment is in the expected trusted state, and has not been tampered with or injected with malicious code, thus providing a secure foundation for subsequent key decryption. If the environment is untrustworthy, all subsequent operations will be meaningless; therefore, this step constitutes the first line of defense.

[0047] In step S220, in response to the matching, the target key bound to the current environment metric is unsealed within the trusted execution environment, and the data to be processed is processed based on the target key to obtain the processing result.

[0048] Specifically, after a successful metric match, the metric-bound key sealing module 40 checks whether the current metric meets the desealing conditions of the key sealing packet. If so, the target key is desealed within the trusted execution environment. The desealing conditions of the target key are bound to the current environment metric value, meaning that the key is not only physically protected but also logically usable only under specific environmental conditions. The desealed target key is then directly processed within the trusted execution environment, performing operations such as identity signing, sensitive data desensitization, or feature extraction. Since both the desealing and processing are completed within the trusted boundary, the ordinary runtime area scheduling module 10 is only responsible for transmitting ciphertext and scheduling status, without accessing plaintext data, thus ensuring the security of sensitive data during processing. This causal relationship between metric and key binding effectively avoids the risk of a tampered ordinary environment driving hardware to sign out a legitimate facade request.

[0049] Step S230: Generate output credentials. The output credentials bind the result summary of the processing result, the current environment metric, and the identity signature.

[0050] Specifically, after processing, the certificate-enabled output receipt module 70 generates an output certificate within the trusted execution environment. The output certificate not only contains the processing result itself, but more importantly, it binds the result summary, the current environment metric, and the identity signature. This binding relationship forms the core of the anti-counterfeiting logic: when an external verifier receives the output certificate, it can not only verify the validity of the identity signature, but also confirm which trusted execution environment and code version generated the result through the current environment metric. Without this binding, attackers could forge processing results or use an illegitimate environment to generate seemingly legitimate signatures; by binding the result with the environment state and the signature, an inseparable chain of evidence is formed, significantly improving the verifiability and external acceptance of the result.

[0051] In step S240, in response to a mismatch in the current environment metric or an unavailable trusted execution environment, the processing of the pending data is rejected and a blocking record is generated.

[0052] Specifically, when the system detects in step S210 that the current environmental metric does not match the preset metric policy, or that the trusted execution environment is unavailable during operation, the downgrade blocking and auditing module 90 will trigger a fail-stop mechanism. The system refuses to process the data to be processed and refuses to return to the normal operating environment to continue executing equally sensitive tasks, while generating a blocking record. The blocking record contains information such as the anomaly type, anomaly time, current environmental metric, and agent identity number, which is used for subsequent auditing and anomaly detection. The design logic of this mechanism is that when the security defense is breached or the environment is abnormal, continuing processing will only increase the risk; the correct approach is to stop immediately and preserve evidence. By refusing to downgrade to the normal operating environment, the system prevents security downgrade from becoming a channel for attackers to bypass trusted verification, thereby closing the entire defense system and ensuring the trustworthiness of the entire data processing chain.

[0053] In some embodiments, the dimensions of the environment metrics and the underlying implementation of key decryption are further described in detail. The current environment metrics include code metrics and configuration metrics; the decryption conditions of the target key are bound to the current environment metrics, and the target key is decrypted within the trusted execution environment in response to both the code metrics and configuration metrics matching the preset metric policy.

[0054] Specifically, in step S210, the current environment metric value generated by the Trusted Execution Environment (TEE) module 20 is not a single-dimensional value, but a multi-dimensional metric system composed of code metrics and configuration metrics. The code metric reflects the hash value of the currently loaded code within the TEE, and the configuration metric reflects the hash value of the currently running configuration within the TEE. The preset metric strategy includes preset code hash values ​​and preset configuration hash values. The system compares the code metric with the preset code hash value, and simultaneously compares the configuration metric with the preset configuration hash value. Only when both the code metric and the preset code hash value are consistent is the current environment metric value determined to match the preset metric strategy. The design logic of this dual verification mechanism is as follows: verifying only the code hash can only guarantee that the running program code has not been tampered with, but it cannot prevent attackers from indirectly affecting the processing logic by modifying environment configuration parameters (such as security policies, memory allocation, permission settings, etc.). After introducing configuration metrics, the system can ensure that not only the code itself is as expected, but its runtime configuration state is also as expected. Thus, a complete environmental integrity verification defense line is built on both code and configuration dimensions, which greatly improves the runtime credibility of the signature action.

[0055] The target key includes an identity signing key or a data processing key; in response to the code metric being consistent with the preset code hash value and the configuration metric being consistent with the preset configuration hash value, the identity signing key or the data processing key is unsealed within the trusted execution environment; in response to the code metric being inconsistent with the preset code hash value or the configuration metric being inconsistent with the preset configuration hash value, the identity signing key and the data processing key are refused to be unsealed; the identity signing key is used to sign the request digest, target identifier, random number, timestamp, and agent identity number to generate an identity signature; the data processing key is used to perform at least one of the following processing on the data to be processed: decryption, desensitization, feature extraction, or local lightweight inference; the plaintext of the identity signing key and the data processing key does not leave the trusted execution environment, and the plaintext is destroyed within the trusted execution environment after processing is completed.

[0056] Specifically, in step S220, the metric binding key storage module 40 stores the metric binding key storage package. For example... Figure 3As shown, the metric binding key sealing package includes at least the following data fields: agent identity number, key purpose, hardware anchor reference, metric conditions, allowed operations, sealed ciphertext, sealed version, and sealed status. After the double verification passes, module 40 checks whether the current metric meets the metric conditions in the sealing package. If it does, the corresponding key is unsealed within the trusted execution environment (TEE). The identity signing key and data processing key have distinct uses: the identity signing key is dedicated to signing key information such as request digests, target identifiers, random numbers, timestamps, and agent identity numbers to generate an identity signature, ensuring the non-repudiation of agent behavior; the data processing key is used to perform specific data processing operations such as decryption, desensitization, feature extraction, or local lightweight inference on the data to be processed. Regardless of the key type, its plaintext never leaves the TEE, and after processing, the system destroys the plaintext within the TEE. This constraint of plaintext not leaving the TEE and being destroyed after processing cuts off the path to key leakage from both physical and logical levels. Even if an attacker controls the normal operating environment, they cannot obtain the key plaintext, reducing the risk of sensitive data exposure.

[0057] It should be understood that the trusted execution environment, proof chain, and key sealing method in the above embodiments can all be implemented using various equivalent alternatives. Regarding the form of the trusted execution environment, in addition to the forms shown in the above embodiments, it can also be implemented by a security chip, a secure execution zone, a mobile trusted execution environment, a trusted container, a trusted virtual machine, server trusted execution hardware, computing units in a hardware security module, or combinations thereof, as long as an isolated execution boundary can be provided. For the proof chain, it can be provided by a hardware vendor root, an enterprise-built root, an operator hardware root, a cloud vendor trusted root, a regulatory-approved trusted root, or a multi-root cross-verification method, as long as the external verifier can verify that the current code and configuration are within the permissible measurement range. Regarding the key sealing method, the identity signature key can be derived from the hardware anchor and then sealed, or it can be generated within the trusted execution environment and registered by the identity system, or it can be injected into the trusted execution environment for temporary use after authorization by an external hardware security module. These variations are all within the scope of protection of this application, and different methods do not affect the core idea that key use is controlled by measurement conditions.

[0058] In some embodiments, the data transmission and processing constraint mechanism after the target key is unsealed is further described in detail. After the target key is unsealed in the trusted execution environment, an encrypted session for the data to be processed is established; the encrypted session includes a session key, a random number, a caller identifier, a target identifier, a request digest, and a validity period; the data to be processed is transmitted to the trusted execution environment in encrypted form through the encrypted session, and the plaintext of the data to be processed only appears within the trusted execution environment.

[0059] Specifically, after decrypting the target key in step S220, the secure entry session module 50 establishes an encrypted session for the current call. For example... Figure 3 As shown, the secure entry session packet contains data fields such as session key, random number, caller identifier, target identifier, request digest, and validity period. Upon receiving the data to be processed, the normal runtime scheduling module 10 does not parse it. Instead, it encrypts it into ciphertext using the session key and transmits it to the Trusted Execution Environment (TEE) module 20 through an encrypted channel. The normal runtime scheduling module 10 is only responsible for transmitting the ciphertext and scheduling status; it does not read the plaintext. This design establishes a defense-in-depth system where plaintext does not leave the TEE. Even if an attacker controls the memory or file system of the normal runtime environment, they cannot obtain the plaintext content of sensitive inputs, thereby reducing the risk of data exposure during transmission and scheduling. The session key and random number ensure the uniqueness and non-replayability of each session, the request digest binds the current session to a specific business request, and the validity period prevents the session from being suspended for a long time or abused.

[0060] Before processing the data to be processed within the trusted execution environment, task constraint information is generated. This information includes a task identifier, input data category, allowed processing types, output field set, prohibited output fields, retention policy, and zeroing policy. Allowed processing types include at least one of identity request signing, request digest signing, sensitive field desensitization, feature extraction, local lightweight inference, or result digest generation. Within the trusted execution environment, the data to be processed is processed according to the task constraint information to obtain the processing result. In response to the processing result containing prohibited output fields, output is rejected and an exception is logged. After processing, the plaintext, intermediate features, mapping table, and session key of the data to be processed are zeroed or destroyed within the trusted execution environment.

[0061] Specifically, prior to the execution phase of step S220, the sensitive processing task list module 60 generates task constraint information. For example... Figure 3As shown, the sensitive processing task list includes fields such as task identifier, input data category, allowed processing type, output field set, prohibited output fields, retention policy, and zeroing policy. The Trusted Execution Environment (TEE) module 20 strictly processes the data to be processed according to the task constraint information. The allowed processing type restricts the set of actions that can be performed within the TEE. For example, when the allowed processing type is only sensitive field desensitization, the system refuses to perform local lightweight inference operations. This mechanism with limited processing boundaries ensures that sensitive data can only be processed in the intended way. During processing, if the generated processing result contains prohibited output fields explicitly specified in the task constraint information, such as the original identity verification number or complete medical indicators, the system will refuse to output and record the anomaly, while triggering the downgrade blocking and auditing module 90. This logic prevents the leakage of sensitive information due to code logic errors or malicious tampering. After processing, the system performs zeroing or destruction operations on the plaintext, intermediate features, mapping table, and session key of the data to be processed within the TEE to ensure that the intermediate state does not remain in memory. This embodiment clarifies the input category, allowed processing actions, output fields, and prohibited output fields through task constraint information, giving clear boundaries to desensitization, feature extraction, and local inference, enhancing the controllability of sensitive processing, and ensuring that sensitive data can be processed but not seen.

[0062] It should be understood that the permitted processing types are not limited to those listed above. They can also be extended to sensitive field classification, risk label generation, encrypted index generation, data minimization summaries, privacy budget deduction, or verifiable aggregation preprocessing, depending on business needs. The specific fields and values ​​of the task constraint information can be configured by the system administrator or governance module according to different business scenarios and security levels, as long as the processing boundaries of the data to be processed can be limited.

[0063] In some embodiments, the steps for generating output credentials and the verification process of the external verifier are further described in detail. The output credentials also include the result category of the processing result, the metric proof of the trusted execution environment, and the proof chain reference; the output credentials bind the result digest, result category, current environment metric value, metric proof, and proof chain reference through identity signature, enabling the external verifier to verify the source of the processing result.

[0064] Specifically, in step S230, the certificate-enabled output receipt module 70 generates an output certificate within a trusted execution environment. For example... Figure 3As shown, the certified output receipt includes data fields such as agent identity number, task identifier, result summary, result category, trusted environment metric, code hash, configuration hash, proof random number, request summary, processing time, proof chain reference, and identity signature. The result category indicates whether the output is an anonymized result, a feature vector, or a signed receipt; the metric proof and proof chain reference provide third-party endorsement of the current environment's credibility. The output credential binds these core fields together with the identity signature, forming an indivisible chain of evidence. The anti-counterfeiting logic of this design is that when an external verifier receives the output credential, they can not only verify the validity of the identity signature but also confirm which trusted execution environment and code version generated the result through the current environment metric and proof chain reference. Without this binding, attackers could forge processing results or generate seemingly legitimate signatures using illegitimate environments; by binding the result with the environment state and signature, the verifiability and external acceptance of the result are significantly improved.

[0065] The output credentials also include a request digest, a random number, an agent identity number, and a processing time. The identity signature is generated by performing a signature on the result digest, request digest, random number, agent identity number, current environment metric, processing time, and proof chain reference. The external verifier verifies the validity of the identity signature, the uniqueness of the random number, whether the processing time is within a valid time window, the consistency between the request digest and the original request, whether the current environment metric is within the allowed metric range, and the legality of the proof chain reference to determine whether the processing result comes from a trusted execution environment and whether there is replay. In response to successful verification, the external verifier accepts the processing result; in response to failed verification, the external verifier rejects the processing result and records the reason for rejection.

[0066] Specifically, the external verification module 80 is used by the resource verification party, business system, regulatory audit system, or collaborative intelligent agent. When the external verification party receives the certified output receipt, it initiates a complete verification process. First, it verifies the validity of the identity signature to confirm that the receipt has not been tampered with; then, it verifies the uniqueness of the random number to prevent attackers from intercepting old receipts for replay attacks; simultaneously, it checks whether the processing time is within the valid time window to prevent expired receipts from being accepted; subsequently, it compares the consistency between the request digest and the original request to ensure that the processing action corresponding to the receipt was indeed initiated for the current business request; in addition, it verifies whether the current environment metric is within the allowed metric range and the legality of the proof chain reference to confirm that the signature action indeed occurred in an untampered, expected trusted environment. Only when all the above verification items pass will the external verification party accept the processing result; if any verification fails, the external verification party will reject the processing result and record the reason for rejection, and may trigger the degradation blocking and audit module 90. This embodiment adds fields such as request digest, random number, and processing time to the output credentials, enabling external verifiers to fully verify the source of the results and prevent replay. It establishes algorithm-level support for source verification and replay prevention, further improving the external result acceptance capability.

[0067] It should be understood that the output proof format in the above embodiments can be implemented in various variations. Besides the signed receipt format shown in the above embodiments, the output proof format can also be replaced with a remote proof quote, a verifiable credential, a transparent log receipt, a timestamp proof, or a combination of multiple proofs. For example, lightweight verifiable credentials can be used in scenarios requiring high-frequency verification, while transparent log receipts can be used in scenarios requiring strong regulatory traceability. These variations all fall within the scope of protection of this application, as long as they enable external verification parties to verify the source of the processing result.

[0068] In some embodiments, the steps of refusing to process the pending data and generating a blocking record are further described in detail. In response to a mismatch between the current environment metric and a preset metric policy, failure to decrypt the target key, or unavailability of the trusted execution environment, the process of processing the pending data is refused to return to the normal operating environment; a blocking record is generated, which includes the anomaly type, anomaly time, current environment metric, and agent identity number, for subsequent auditing and anomaly detection.

[0069] Specifically, such as Figure 4As shown, the degradation blocking process includes four typical branches. The first is metric mismatch: when the current environment metric value generated by the Trusted Execution Environment (TEE) module 20 does not match the preset metric policy in the metric policy registry 30, the system refuses to unblock the target key. The second is task list disallowance: when the sensitive processing task list module 60 determines that a task is unauthorized or the output field is out of range, the system refuses to process sensitive input. The third is expired proof or random number replay: when the external verification module 80 determines that the proof in the certified output receipt is expired or the random number has been replayed, the external verification party refuses to accept the result. The fourth is TEE unavailable: when the system detects that the TEE module 20 cannot start or respond, the system refuses to fall back to the normal operating environment to process equally sensitive tasks. All four abnormal branches trigger the degradation blocking and auditing module 90, causing the current task to fail-stop, that is, immediately stopping execution and refusing to fall back to the normal operating environment to continue processing the pending data. The design logic of this principle is that when the security defense is breached or the environment is abnormal, continuing processing will only increase the risk; the correct approach is to stop immediately and preserve evidence. By refusing to downgrade to a normal operating environment, the system prevents security downgrades from becoming a channel for attackers to bypass trusted verification, thereby closing the entire defense system and ensuring the trustworthiness of the entire data processing chain.

[0070] Upon triggering a block, the downgrade blocking and auditing module 90 generates a blocking record. The blocking record includes fields such as anomaly type, anomaly time, current environmental metric value, and agent identity number. The anomaly type indicates the specific reason for triggering the block, such as metric mismatch, key decryption failure, unauthorized task, or expired proof; the anomaly time records the precise time the block occurred; the current environmental metric value preserves a snapshot of the environmental state at the time of the anomaly; and the agent identity number is associated with the specific agent that triggered the anomaly. These fields together constitute a complete audit evidence chain, facilitating subsequent auditing and anomaly detection. For example, when the system detects that the same agent triggers metric mismatch anomalies multiple times within a short period, it can determine that the agent may be at risk of being tampered with, thereby taking further governance and disposal measures. This embodiment, by generating a blocking record containing the above fields, facilitates integration with the identity, credit, and auditing systems, providing factual input for subsequent behavior evidence storage, anomaly detection, credit profiling, and regulatory auditing.

[0071] Specifically, combined Figure 3 This document details the data object relationships in the measurement-bound trusted processing. The data objects in this application include at least trusted environment measurement records, measurement-bound key storage packages, sensitive processing task lists, secure entry session packets, and certified output receipts.

[0072] Specifically: Trusted Environment Measurement Records define "what environments and code can be executed"; Measurement-Bound Key Encapsulation Packages define "what keys can be used under what measurement"; Sensitive Processing Task Lists define "how sensitive inputs can be processed and output"; Secure Entry Session Packages define "how this request and sensitive inputs are bound"; and Certificated Output Receipts define "how the source of the result is verified externally".

[0073] Specifically, the trusted environment metric records correspond to the output of the metric policy registry 30. Each record includes at least: trusted environment type, code hash, configuration hash, metric version, proof chain source, allowed operation set, enabled status, and validity period. Only when the code metric and configuration metric reported by the current TEE are completely consistent with the "valid + enabled" records in the registry will the process proceed to the next step.

[0074] The metric binding key archive package corresponds to the output of the metric binding key archive module 40. The archive package includes at least: agent identity number, key purpose, hardware anchor reference, metric conditions, allowed operations, archive ciphertext, archive version, and archive status.

[0075] In this system, the plaintext key is sealed in ciphertext, and the desealing action occurs within the TEE (Trusted Environment Equipment). The prerequisite for desealing is that the preceding "Trusted Environment Measurement Record" is successfully matched. In this way, the private key will neither leave the TEE nor be desealed by an environment with an incompatible measurement.

[0076] The sensitive processing task list corresponds to the output of the sensitive processing task list module 60. Each list includes at least: task identifier, input data category, allowed processing type, output field set, prohibited output fields, retention policy, zeroing policy, policy version, and approval status. Allowed processing types may include identity request signing, request digest signing, sensitive field desensitization, feature extraction, local lightweight inference, and result digest generation, etc.

[0077] This is key to achieving "processable but invisible". For example, in a medical scenario, only "health dimension score, risk category, and result summary" are allowed to be output, while the output of raw indicator details is explicitly prohibited. This creates a dual constraint of "whitelist + blacklist" on the processing procedures within the TEE.

[0078] The Secure Entry Session Packet corresponds to the output of the Secure Entry Session Module 50. It generates for each processing session: session key, random number, caller identifier, target identifier, request digest, timestamp, and expiration date, enabling sensitive input to enter the TEE in encrypted form and binding it to the current request.

[0079] Among them, the 10 modules in the normal operating area only transmit ciphertext and scheduling status, and do not read plaintext; sensitive inputs are only decrypted within the TEE. Random numbers and time windows also provide support for subsequent replay protection.

[0080] The certified output receipt corresponds to the output of the certified output receipt module 70. The receipt includes at least: agent identity number, task identifier, result digest, result category, trusted environment metric, code hash, configuration hash, proof random number, request digest, processing time, proof chain reference, and identity signature.

[0081] The receipt binds "who (agent identity) + where (environmental metric / code hash) + what request (request digest / random number) + what result (result digest) + who signed the document (identity signature)" into a self-explanatory proof. The external verification module 80 verifies based on this, without needing to trust the ordinary runtime area.

[0082] Specifically, the trusted environment metric record determines whether the metric-bound key archive can be unsealed. The unsealed key, within the encrypted session established by the secure entry session packet, processes sensitive inputs according to the boundaries of the sensitive processing task list. After processing, a certified output receipt serves as proof. Failure to verify the data object at any stage will trigger an additional step. Figure 4 Downgrade blocking.

[0083] like Figure 4 As shown, the downgrade blocking process includes four typical branches: First, metric mismatch, the system refuses to unseal the key. Second, the task list does not allow it, the system refuses to process sensitive input. Third, proof expires or random number replay occurs, the external verification module rejects the result. Fourth, the trusted execution environment is unavailable, the system refuses to fall back to the normal operating environment to process equally sensitive tasks.

[0084] First type of branch: When the current code metric, configuration metric, and metric policy registry 30 reported by TEE are inconsistent with the valid records, the metric binding key sealing module 40 will not perform unsealing.

[0085] The second type of branch: When the processing action or output field requested by the request exceeds the authorized scope of the sensitive processing task list module 60, the processing program in the TEE refuses to execute; if the processing result attempts to carry prohibited output fields, it will also be rejected in the output stage.

[0086] The third type of branch: When the external verification module 80 verifies the certificate output receipt, if it finds that the timestamp exceeds the time window or the random number has been used (replay), it will refuse to accept the result.

[0087] The fourth type of branch: When the TEE is unavailable, the certificate expires, or other abnormalities occur, the downgrade blocking and auditing module 90 causes the current task to fail-stop, explicitly disallowing it from returning to the normal operating environment to continue performing the same sensitive processing.

[0088] The common exit point for all four types of branches: a downgrade blocking record. Downgrade blocking and auditing module 90 generates the downgrade blocking record and writes it into the audit or event chain.

[0089] It should be understood that degradation strategies can be configured according to scenarios. In scenarios involving strong oversight, highly sensitive data, and irreversible side effects, the system adopts a strict rejection policy, meaning that once an abnormal branch is triggered, the task is immediately terminated and a blocking record is generated, disallowing any form of degradation processing. In low-sensitivity scenarios, the system can employ strategies such as manual review, degradation prompts, outputting only non-sensitive summaries, or delayed processing. For example, when the trusted execution environment is unavailable, the system can prompt the user to retry later, or delay the processing of non-sensitive parts until the trusted environment is restored, while recording the degradation event for auditing purposes. These variations all fall within the scope of protection of this application, as long as they prevent security degradation from becoming an attack channel.

[0090] The following describes the overall operational performance using two specific business scenarios.

[0091] Scenario 1: Medical auxiliary analysis.

[0092] The agent needs to access external medical auxiliary analysis resources. After receiving the user's raw health data, the normal operating zone scheduling module 10 does not parse the entire plaintext in the normal operating environment. Instead, it establishes an encrypted session through the secure entry session module 50, encrypting the raw health data and sending it to the trusted execution environment module 20. After starting and loading the medical analysis program, the trusted execution environment module 20 generates the current environment metric value and matches it with the preset metric policy in the metric policy registry 30. Upon successful matching, the metric binding key sealing module 40 decrypts the data processing key within the trusted execution environment. Based on the task constraint information generated by the sensitive processing task list module 60, the trusted execution environment module 20 only allows the output of health dimension scores and risk categories, disallowing the output of raw indicator details. During processing, the data processing key decrypts the raw health data and performs local lightweight inference to obtain the health dimension score and risk category. After processing, the trusted execution environment module 20 clears or destroys the plaintext, intermediate features, and session key of the raw health data. The certificate-based output receipt module 70 generates an output certificate that binds a summary of the health dimension score and risk category results, the current environment metric, and an identity signature. This allows the external verifier 80 to confirm that the score was generated by a specified trusted code, rather than being forged by an ordinary environment. The external verifier 80 determines whether the processing result originates from a trusted execution environment by verifying the validity of the identity signature and whether the current environment metric is within the allowed range. After successful verification, the external verifier 80 receives the health dimension score and risk category. This scenario demonstrates the effects of "processable but invisible" and "certified output" through specific data flow, ensuring the security of sensitive medical data during processing and the verifiability of the results.

[0093] Scenario 2: Requesting proof of signature.

[0094] The agent needs to submit a request for proof to the business resources. Instead of using a private key for signing in the normal operating area, the Trusted Execution Environment (TEE) module 20 decrypts the identity signing key after metric matching. Specifically, the TEE module 20 generates the current environment metric value and matches it against the preset metric policy in the metric policy registry 30. After successful matching, the metric binding key sealing module 40 decrypts the identity signing key within the TEE. The TEE module 20 binds the request digest, target identifier, random number, timestamp, and agent identity number, and then uses the identity signing key to perform signing to generate an identity signature. The certificate output receipt module 70 generates an output certificate that binds the result digest, the current environment metric value, and the identity signature. When verifying the request proof, the external verification module 80 not only verifies the validity of the signature but also verifies that the signature originates from the expected trusted environment metric. Specifically, the external verification module 80 verifies the validity of the identity signature, the uniqueness of the random number, whether the processing time is within a valid time window, the consistency between the request digest and the original request, whether the current environment metric is within the allowed metric range, and the legality of the proof chain reference. This determines whether the processing result originates from a trusted execution environment and whether replay occurs. Upon successful verification, the external verification party 80 receives the request proof. This scenario, by completing the signature within a trusted execution environment and binding the signature to environment metrics, avoids the risk of injected environment-driven hardware signing off on legitimate requests, thus improving the runtime credibility of the signature action and the acceptance capability of external results.

[0095] Neither of the two scenarios introduced new technical features. Instead, the technical solutions from the aforementioned embodiments were applied to specific business scenarios, demonstrating the end-to-end operational effect and proving the industrial applicability and commercial value of the solutions.

[0096] This embodiment provides a data processing device based on a trusted execution environment. For example... Figure 5 As shown, the device includes a metric matching module 501, a key decryption processing module 502, an output credential generation module 503, and a blocking module 504. Through the configuration and interactive collaboration of these modules, the device maps the trusted processing closed loop in the aforementioned method embodiments into a product-level functional module architecture, providing protection for infringement evidence collection at the entity level.

[0097] The metric matching module 501 is configured to obtain the current environment metric value of the trusted execution environment and determine whether the current environment metric value matches the preset metric strategy.

[0098] Specifically, the measurement matching module 501 corresponds to the interaction logic between the Trusted Execution Environment module 20 and the measurement policy registry 30 in the aforementioned system architecture. Upon device startup, the measurement matching module 501 is responsible for collecting runtime status data within the Trusted Execution Environment and comparing it with a preset security baseline. This module acts as the security gate for the entire device; only when the current environment is determined to be in the expected trusted state is subsequent modules allowed to perform sensitive operations. By separating the environment verification function into the measurement matching module 501, the security verification logic and business processing logic are physically or logically decoupled. Even if the business processing module is tampered with, the measurement matching module 501 can still intercept illegal requests.

[0099] The key decryption processing module 502 is configured to decrypt the target key bound to the current environment metric in response to matching within the trusted execution environment, and perform processing on the data to be processed based on the target key to obtain the processing result.

[0100] Specifically, the key desealing processing module 502 corresponds to the combination of the internal processing logic of the metric binding key sealing module 40 and the trusted execution environment module 20. Upon receiving a successful matching signal from the metric matching module 501, the key desealing processing module 502 reads the sealed key ciphertext within the trusted boundary and performs the desealing operation. The desealed target key directly participates in processing operations such as decryption, desensitization, or signing of the data to be processed within this module. Because key desealing and data processing are both completed within the same module and within the trusted execution environment, the ordinary running area scheduling module 10 can only transmit ciphertext data through the secure entry session module 50 and cannot intervene in the key usage process, thus ensuring the security of sensitive data during processing.

[0101] The output credential generation module 503 is configured to generate output credentials, which bind the result summary of the processing result, the current environment metric value, and the identity signature.

[0102] Specifically, the output credential generation module 503 corresponds to the certificate-enabled output receipt module 70. After the key decryption processing module 502 completes data processing, the output credential generation module 503 is responsible for extracting a digest of the processing result and collecting the current environmental metric value. Then, it uses the decrypted identity signing key to sign and bind the aforementioned information. The output credential generated by this module not only contains the business result but also includes proof of the environmental state, enabling the external verification module 80 to verify the credibility of the result's source by checking the credential. This design internalizes the proof generation process within the device, avoiding the risk of the processing result being intercepted or tampered with during the output process and becoming untraceable.

[0103] Blocking module 504 is configured to refuse to process pending data and generate a blocking record in response to a mismatch in the current environment metric or an unavailable trusted execution environment.

[0104] Specifically, the blocking module 504 corresponds to the degradation blocking and auditing module 90. When the metric matching module 501 determines that the environment is abnormal, or the system detects that the trusted execution environment is unavailable, the blocking module 504 immediately takes over control, forcibly terminates the current task, and refuses to return to the normal operating environment to perform the same sensitive processing. At the same time, the blocking module 504 generates a blocking record containing information such as the abnormality type, time, and metric value, and writes it to the audit log. The existence of this module enables the device to have fail-stop capability when facing environmental degradation or attacks, preventing security degradation from becoming a channel for attackers to bypass trusted verification.

[0105] Based on the above device architecture, the measurement matching module 501 is further configured to obtain the code measurement and configuration measurement of the trusted execution environment, and compare the code measurement and configuration measurement with the preset measurement strategy; in response to the fact that both the code measurement and configuration measurement match the preset measurement strategy, the key desealing processing module 502 is allowed to perform the key desealing operation.

[0106] Specifically, when performing verification, the metric matching module 501 does not perform a single-dimensional judgment, but simultaneously acquires both code metrics and configuration metrics. The code metric reflects the hash value of the currently loaded code within the trusted execution environment, while the configuration metric reflects the hash value of the currently running configuration. The metric matching module 501 rigorously compares these two metric values ​​with the baseline values ​​in the preset metric strategy. Only when both the code metric and the preset code hash value are consistent, does the metric matching module 501 send a release signal to the key desealing processing module 502. This dual verification mechanism ensures that not only has the program code itself not been tampered with, but its runtime configuration state also meets expectations. This constructs a complete environmental integrity verification defense line across both code and configuration dimensions, significantly improving the reliability of the device's operational state and ensuring that the key desealing processing module 502 will not perform operations in an indirectly tampered environment.

[0107] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

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

[0109] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0110] It should be noted that if the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0111] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0112] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A data processing method based on a trusted execution environment, characterized in that, include: Obtain the current environment metric value of the trusted execution environment, and determine whether the current environment metric value matches the preset metric strategy; In response to the matching, the target key bound to the current environment metric is unsealed within the trusted execution environment, and the data to be processed is processed based on the target key to obtain the processing result; Generate an output credential, which binds the result summary of the processing result, the current environment metric, and the identity signature; In response to a mismatch in the current environment metric or the unavailability of the trusted execution environment, the processing of the pending data is refused and a blocking record is generated.

2. The method according to claim 1, characterized in that, The current environment metrics include code metrics and configuration metrics; The decryption conditions of the target key are bound to the current environment metric value. In response to the fact that both the code metric and the configuration metric match the preset metric policy, the target key is decrypted within the trusted execution environment.

3. The method according to claim 2, characterized in that, The target key includes an identity signing key or a data processing key; the preset measurement strategy includes a preset code hash value and a preset configuration hash value; The code metric is the hash value of the currently loaded code within the trusted execution environment, and the configuration metric is the hash value of the currently running configuration within the trusted execution environment; The method further includes: In response to the code metric being consistent with the preset code hash value and the configuration metric being consistent with the preset configuration hash value, the identity signing key or the data processing key is unsealed within the trusted execution environment; In response to the code metric being inconsistent with the preset code hash value or the configuration metric being inconsistent with the preset configuration hash value, the identity signing key and the data processing key are refused to be unsealed; The identity signing key is used to sign the request digest, target identifier, random number, timestamp, and agent identity number to generate the identity signature; The data processing key is used to perform at least one of the following processing on the data to be processed: decryption, desensitization, feature extraction, or local lightweight inference. The plaintext of the identity signing key and the data processing key does not leave the trusted execution environment, and the plaintext is destroyed within the trusted execution environment after processing is completed.

4. The method according to claim 2, characterized in that, After unsealing the target key within the trusted execution environment, the process further includes: Establish an encrypted session for the data to be processed; The encrypted session includes a session key, a random number, a caller identifier, a target identifier, a request digest, and a validity period; The data to be processed is transmitted to the trusted execution environment in encrypted form through the encrypted session, and the plaintext of the data to be processed only appears within the trusted execution environment.

5. The method according to claim 4, characterized in that, Before processing the data to be processed within the trusted execution environment, the method further includes: Generate task constraint information, which includes task identifier, input data category, allowed processing type, output field set, prohibited output fields, retention policy, and clearing policy; The permitted processing types include at least one of identity request signing, request digest signing, sensitive field desensitization, feature extraction, local lightweight inference, or result digest generation; Within the trusted execution environment, the data to be processed is processed according to the task constraint information to obtain the processing result; In response to the processing result containing the prohibited output field, output is rejected and an exception is logged; After processing is completed, the plaintext, intermediate features, mapping table, and session key of the data to be processed are cleared or destroyed within the trusted execution environment.

6. The method according to claim 1, characterized in that, The output credentials also include the result category of the processing result, the metric proof of the trusted execution environment, and the proof chain reference; The output credentials bind the result summary, the result category, the current environment metric, the metric proof, and the proof chain reference through the identity signature, enabling external verifiers to verify the source of the processing result.

7. The method according to claim 6, characterized in that, The output credentials also include a request digest, a random number, an agent ID, and a processing time. The identity signature is generated by performing a signature on the result digest, the request digest, the random number, the agent's identity number, the current environment metric, the processing time, and the proof chain reference. The external verifier determines whether the processing result comes from the trusted execution environment and whether there is a replay by verifying the validity of the identity signature, the uniqueness of the random number, whether the processing time is within a valid time window, the consistency between the request digest and the original request, whether the current environment metric is within the allowed metric range, and the legality of the proof chain reference. Upon successful verification, the external verification party receives the processing result. In response to the verification failure, the external verifier rejects the processing result and records the reason for rejection.

8. The method according to claim 1, characterized in that, In response to a mismatch between the current environment metric and the preset metric strategy, a failure to decrypt the target key, or an unavailable trusted execution environment, the system refuses to return to the normal operating environment to process the data to be processed. The blocking record is generated, which includes the anomaly type, anomaly time, the current environmental metric, and the agent's identity number, for subsequent auditing and anomaly detection.

9. A data processing apparatus based on a trusted execution environment, characterized in that, include: The metric matching module is configured to obtain the current environment metric value of the trusted execution environment and determine whether the current environment metric value matches a preset metric strategy. The key decryption processing module is configured to, in response to matching, decrypt the target key bound to the current environment metric within the trusted execution environment, and perform processing on the data to be processed based on the target key to obtain the processing result; The output credential generation module is configured to generate output credentials, wherein the output credential binds the result summary of the processing result, the current environment metric value, and the identity signature. The blocking module is configured to refuse to process the data to be processed and generate a blocking record in response to a mismatch in the current environment metric or an unavailable trusted execution environment.

10. The apparatus according to claim 9, characterized in that, The metric matching module is further configured to obtain the code metric and configuration metric of the trusted execution environment, and compare the code metric and the configuration metric with the preset metric strategy; In response to the fact that both the code metric and the configuration metric match the preset metric policy, the key decryption processing module is allowed to perform the key decryption operation.

Images