Zero trust multi-party secure data exchange method

Abstract

The present application relates to the technical field of network and information security, and particularly relates to a zero-trust multi-party secure data exchange method, which comprises the following steps: generating a zero-trust token and a capability authorization ticket and constructing context description data; performing authentication encryption on plaintext fragments and performing attribute-based encryption on data one-time keys to assemble a policy-carrying ciphertext container; in a trusted execution environment, recovering the data one-time key through joint challenge and threshold unsealing to complete authentication decryption, or realizing policy migration and transfer through proxy re-encryption; and aggregating the decryption and transfer events into a vector commitment and generating a time anchor, which is mapped into a next round of random base. The present application realizes fine-grained authorization at the key layer, plaintext-free transfer, event-level verifiable audit and fast revocation.

Description

Technical Field

[0001] This invention relates to the field of network and information security technology, and in particular to a zero-trust multi-party secure data exchange method. Background Technology

[0002] In an environment of multi-cloud architecture and accelerated industry collaboration, data needs to flow across boundaries between enterprises, research institutions, and regulatory bodies. Traditional approaches centered on network boundaries and channel control rely on static credentials and location assumptions, leading to common problems such as: decoupling channel access from data objects, allowing entities to expand laterally after entry; separation of keys and policies, resulting in delays in revocation and policy switching; cross-domain sharing often involves "decryption-re-encryption," exposing intermediate plaintext surfaces; and a lack of cryptographically verifiable binding between audit records and actual access actions, relying on weakly trusted evidence for post-event traceability. The industry urgently needs to shift the control focus from the channel layer to the key and ciphertext layer, achieving strong binding of identity, policies, and data throughout the entire chain, and introducing publicly verifiable audit and revocation mechanisms to meet compliance requirements and supply chain security scenarios. Summary of the Invention

[0003] To address the numerous problems existing in the prior art, this invention provides a zero-trust multi-party secure data exchange method. This invention uses context-described data and access policies as anchors, encapsulates the one-time key of the data in attribute-based encryption, and combines a trusted execution environment and threshold decapsulation to complete on-demand release; it re-encrypts through a proxy without plaintext transfer; and it forms a verifiable auditable and feedback random basis with vector commitments and time anchors to achieve cross-organizational ciphertext flow with policies and rapid revocation.

[0004] A zero-trust multi-party secure data exchange method includes the following steps:

[0005] Obtain a zero-trust token and capability authorization ticket, and generate context description data, including fields such as source identity, target group, dataset identifier, policy version, time epoch, and random basis;

[0006] Generate a one-time key for the data, slice the data to be exchanged into pieces, add context description data as additional data, perform authentication encryption on each plaintext piece, generate ciphertext pieces, perform attribute-based encryption on the one-time key for the data according to the access policy, calculate audit commitments and assemble them into a policy-bearing ciphertext container.

[0007] Within the Trusted Execution Environment, policy matching and verification of zero-trust tokens and capability authorization tickets are performed. A joint challenge is launched to the threshold key management node to obtain the unsealing share and synthesize a one-time data key within the Trusted Execution Environment. Authentication and decryption are performed on ciphertext fragments, or a new policy-bearing ciphertext container for sub-granting is generated through proxy re-encryption.

[0008] Based on the decryption and transfer events, audit logs are generated and aggregated into commitments. Time anchors are generated and mapped to the random basis of the next round of context description data.

[0009] Preferably, the payload of the zero trust token includes a device metric summary, a session counter, an issuance time, and an expiration time; the payload of the capability authorization ticket includes a set of access predicates and a revocation flag; and the border gateway registers sessions and establishes an anti-replay cache based on context description data.

[0010] Preferably, the authentication encryption uses context description data as additional data, and the slice-level random number is derived from the dataset identifier, slice index, time epoch, and random basis hash, so that the ciphertext slices and context description data form an integrity binding.

[0011] Preferably, the access policy is compiled into a linear secret-sharing structure, and attribute-based encryption uses this structure as the policy to encrypt the data with a one-time key. The one-time key is only decrypted when the access predicate is satisfied.

[0012] Preferably, the audit commitment is obtained by hashing the context description data, access policy identifier, number of ciphertext fragments and total number of bytes, and the policy-bearing ciphertext container consists of the context description data, the audit commitment, an attribute-based encryption key envelope and a sequence of ciphertext fragments.

[0013] Preferably, when performing policy matching, the Trusted Execution Environment (TEE) simultaneously verifies the validity period, revocation status, and subject consistency of the zero-trust token and the capability authorization ticket, and constructs a joint challenge including a hash digest of the audit commitment, TEE metric evidence, and a random number, which is then sent to the threshold key management node.

[0014] Preferably, the threshold key management node uses threshold signature verification joint challenge and returns unsealed share. The trusted execution environment combines the unsealed share to obtain a one-time data key, and performs authentication and decryption on the ciphertext fragments with context description data as additional data. Plaintext exists only in the controlled memory area and is cleared after processing.

[0015] Preferably, the proxy re-encryption performs policy migration on the attribute-based encryption key envelope within a trusted execution environment. The new policy carries a ciphertext container that keeps the ciphertext fragments unchanged, and only updates the target group field and policy version field in the attribute-based encryption key envelope and context description data.

[0016] Preferably, audit records are generated in a fixed field format and formed into commitment roots through vector commitment aggregation. Time anchors are calculated based on commitment roots and time information via a verifiable delay function. Time anchors are then used to generate a random basis for the next round of context description data through deterministic mapping.

[0017] Preferably, the epoch and policy updates are generated based on the statistical results of release events and sub-authorization events in the audit log. The updated information is synchronized to the threshold key management node and the border gateway. The subsequent issuance of zero trust tokens and capability authorization tickets adopts the updated time epoch and access predicate.

[0018] Compared with the prior art, the advantages and beneficial effects of the present invention are as follows:

[0019] By using context description data as additional data for authentication encryption and deriving it with shard-level random numbers, consistent binding and replay resistance are achieved between ciphertext sharding and identity, dataset, policy version, and time epoch. Attribute-based encryption of the one-time data key enables fine-grained key-level authorization and conditional desealing during cross-organizational access, preventing horizontal expansion after channel access. Joint challenges and threshold desealing by trusted execution environments and threshold key management nodes implement dual constraints on execution environment state and multi-party witnessing for key release, reducing the risk of single-point compromise. By proxying re-encryption and migrating only the attribute-based encryption key envelope, plaintext-free transfer and smooth policy switching are achieved, eliminating intermediate exposure during "decryption-re-encryption." Vector commitments and time anchors aggregate and time-bind decryption and transfer events, enabling event-level verifiable auditing and a rapidly revoked externally verifiable data chain. By deterministically mapping time anchors to the next round of random basis, governance facts provide feedback on the randomness of subsequent encapsulation, suppressing rollback and parallel fork attacks. A fixed layout for policy-carrying ciphertext containers enables cross-platform consistent parsing, rapid consistency verification, and low-cost forensics. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the method of the present invention. Detailed Implementation

[0021] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation.

[0022] like Figure 1 As shown, a zero-trust multi-party secure data exchange method includes the following steps:

[0023] Obtain a zero-trust token and capability authorization ticket, and generate context description data, including fields such as source identity, target group, dataset identifier, policy version, time epoch, and random basis;

[0024] Preferably, the payload of the zero trust token includes a device metric summary, a session counter, an issuance time, and an expiration time; the payload of the capability authorization ticket includes a set of access predicates and a revocation flag; and the border gateway registers sessions and establishes an anti-replay cache based on context description data.

[0025] This invention is based on remote measurement and continuous verification. The policy and authorization service verifies the startup chain, firmware version, trusted execution environment metrics, and session counts of the data provider, data requester, and border gateway, generating a measurement verification result. A zero-trust token is issued based on this result. The payload of the zero-trust token includes a device measurement digest, session counter, issuance time, and expiration time, and is signed with the organization's private key. The zero-trust token proves that the current operating environment is in an allowed state and supports immediate invalidation upon expiration or revocation.

[0026] Capability authorization tickets are used to express a set of access predicates and bind a revocation flag. The set of access predicates must include at least the role, target region, business purpose, and time epoch. The policy and authorization service signs the set of access predicates, the initial quota, and the revocation flag to form a capability authorization ticket. The validity of the capability authorization ticket is jointly defined by the time epoch and the revocation flag, enabling rapid mitigation in the event of policy tightening or a security incident.

[0027] The context description data in this invention is a minimal set of business contexts, collaboratively generated by the data provider's border gateway and policy and authorization service: the source identity comes from the identity and access management directory, the target group is taken from the capability authorization ticket, the dataset identifier comes from the data directory registry center, the policy version and time epoch are returned by the policy and authorization service, and the random base is mapped from the genesis time anchor in the first round, and from the time anchor of the previous round in subsequent rounds; the generation timing is after the zero trust token and capability authorization ticket have been verified and before the encryption encapsulation is performed; a fixed field order label-length-value serialization is used, the character encoding is UTF-8, and the numerical value uses fixed-length unsigned encoding; it is frozen immediately after generation, throughout the current round of encapsulation, transmission, and decryption window, and is only reconstructed when the target group or policy version changes, and the new session references the new time epoch and random base after the governance side switches the time epoch; the context byte sequence is written into the header of the policy-bearing ciphertext container, and also serves as additional data for authentication encryption and input for audit commitment, without containing any business plaintext or key material, the border gateway only sees the fields and fingerprint, and the trusted execution environment performs consistency verification accordingly.

[0028] The context description data carries the minimum business information throughout the entire process. Fields include source identity, target group, dataset identifier, policy version, time epoch, and random base. Source identity identifies the data provider or requester; target group limits the scope of decryption; dataset identifier uniquely identifies the exchanged data object; policy version indicates the version of the access policy and compliance template; time epoch is used for rapid revocation and policy switching; and random base is used to derive fragment-level random numbers and bind them to the context during the encapsulation phase. The context description data is frozen after issuance and is only updated when the policy version or target group changes.

[0029] To obtain the initial random basis, this invention employs an initialization process of "commitment-disclosure-delayed solidification" within a trusted execution environment: multiple parties generate high-entropy seeds and issue commitments; after the commitments expire, they are disclosed and verified within the trusted execution environment; an initialization seed is obtained by synthesizing the seeds in a fixed order; this seed is then input into a verifiable delay function to calculate the genesis time anchor; subsequently, the genesis time anchor is combined with the dataset identifier and the initial policy version using a deterministic mapping to obtain the initial random basis written into the context description data; all commitments, disclosures, and calculation materials are synchronously used to generate audit records and aggregated into commitment roots for third-party review; when only one party has access, an initialization seed is generated within the trusted execution environment using true random numbers combined with metric evidence and monotonic counting; the initial random basis is still obtained through a verifiable delay function and the same deterministic mapping, and the audit is completed.

[0030] The border gateway registers sessions based on context description data, recording the subject identity, device identifier, dataset identifier, time epoch, and policy version. It establishes an anti-replay cache and maintains a session count. The anti-replay cache uses the session count and audit fingerprint as key-value pairs, rejecting duplicate or rollback requests. The cache only stores fingerprint and count information, not plaintext or keys. The border gateway performs routing and rate limiting based on the context description data but does not participate in decryption or key release.

[0031] The distribution of the aforementioned objects follows the principle of minimum exposure. Zero-trust tokens and capability authorization tickets are issued to the data provider and data requester, respectively. The border gateway only receives the number, revocation identifier, and context description data, and does not receive key materials. All objects are protected for integrity and authenticated from their source during transmission. The recipient must perform format verification, signature verification, and field consistency comparison to ensure that the subject identity, dataset identifier, time epoch, and policy version are consistent across all parties.

[0032] The principle behind this step is to use a metric-provable operating environment as the root of trust, replace long-term static credentials with short-term tokens and revocable tickets, and bind identity, data objects, and policy temporality with contextual description data. The effects of this design are twofold: firstly, any subsequent ciphertext encapsulation and decryption operations must reference and verify the same set of context fields and time epochs, avoiding cross-channel splicing and policy drift; secondly, the revocation flag and session count ensure that replay and rollback are intercepted at boundary points, reducing the verification pressure on subsequent stages.

[0033] In Example 1, Company A acts as the data provider, and Research Institution B acts as the data requester. Both companies' border gateways are connected to the same policy and authorization service. After startup, Company A and Research Institution B submit measurement reports respectively. The policy and authorization service generates a zero-trust token containing a device measurement summary, session counter, issuance time, and expiration time. Subsequently, Research Institution B requests access based on its business purpose. The policy and authorization service generates a capability authorization ticket, recording the role as analyst, the target region as a specified area, the business purpose as risk control analysis, the time epoch as the current epoch, and setting a revocation flag. Company A generates context description data based on its business task, filling in the source identity as Company A, the target group as Research Institution B's analysis team, the dataset identifier as a unique value, the policy version as the current version, the time epoch as the current epoch, and the random basis as a high-entropy value. The border gateways of Company A and Research Institution B register the session accordingly and create an anti-replay cache. Thereafter, any arriving encrypted encapsulation and decryption requests must carry fields consistent with this context description data. The border gateway compares the session count with the audit fingerprint; if they are inconsistent or duplicated, they refuse to forward the request.

[0034] Through the above implementation, this step completes the issuance of tokens and tickets, freezing of context description data, and anti-replay protection at the boundary without introducing complex computational expressions, ensuring consistency of identity, data objects, and policy temporality in subsequent encapsulation and decryption. The security contribution of this step is specifically reflected in three points: first, the short-term validity of the token is linked to the revocation flag, reducing the risk of misuse; second, the context description data provides a single source of truth across components, reducing parameter drift; and third, the anti-replay cache and session count form a pre-filter, avoiding processing invalid requests on the core key path, thereby improving overall attack resistance and traceability.

[0035] Generate a one-time key for the data, slice the data to be exchanged into pieces, add context description data as additional data, perform authentication encryption on each plaintext piece, generate ciphertext pieces, perform attribute-based encryption on the one-time key for the data according to the access policy, calculate audit commitments and assemble them into a policy-bearing ciphertext container.

[0036] This invention describes an implementation method for generating a one-time data key, performing authentication encryption on a piecewise basis, performing attribute-based encryption on the one-time data key according to the access policy, calculating audit commitments, and assembling it into a policy-carrying ciphertext container. This step, without generating long-term keys or storing plaintext, completes the encapsulation and transformation of "data and policy traveling with the ciphertext," providing a unique input carrier for subsequent on-demand key release and audit closed-loop.

[0037] First, based on the context description data frozen in the previous section, a one-time data key is generated and plaintext fragmentation is completed. The plaintext is fragmented according to a fixed fragment size, preserving the fragment order and total number of fragments. The one-time data key is generated using a high-entropy source, used only in this encapsulation process, and destroyed in memory in subsequent stages. The context description data is not modified and serves as the sole additional data source for subsequent binding and verification.

[0038] Subsequently, slice-level authentication encryption is performed using context description data as additional data. To ensure that slice-level random numbers are unpredictable and tied to business scenarios, an irreversible combination of dataset identifier, slice index, time epoch, and random basis is used to generate slice-level random numbers, which are then written into the authentication tag using context description data as additional data. The corresponding calculation expression is:

[0039]

[0040]

[0041] in, Indicates the first A random number, Represents a secure hash function. Indicates fixed-length truncation. Indicates the dataset identifier. Indicates slice index, Indicates a time era. Represents a random basis. Indicates the first Each authenticated encrypted ciphertext, This indicates an authentication encryption algorithm with an authentication tag. This represents a one-time key for data. Indicates the first One plaintext fragment, This represents the serialization result of the context description data. This binding ensures that any tampering with the context description data or fragment order is rejected during authentication verification. To achieve "policy encapsulated with the key rather than with the channel," the access policy is compiled into a linear secret-shared structure, and attribute-based encryption is performed on the one-time key of the data, which can only be decapsulated if the set of access predicates is satisfied. The corresponding computation expression is: ,in, This indicates an attribute-based encryption key envelope. Indicates access policy This is a conditional encryption operator. The access policy consists of attributes such as role, target region, business purpose, and time epoch. It is compiled using a linear secret-sharing structure to support the determination and decryption of the attribute set in subsequent steps. To achieve external verification of the consistency between the encapsulated content and the context without revealing the plaintext and key, an audit commitment is calculated and recorded in the container header. The audit commitment covers the context description data, access policy identifier, number of ciphertext fragments, and total number of bytes. The corresponding calculation expression is: ,in, Indicates an audit commitment, Indicates the access policy identifier, Indicates the number of ciphertext fragments. This indicates the total number of bytes in the encrypted message. This commitment will be used as a unique fingerprint in subsequent release and auditing processes.

[0042] Once the aforementioned objects are complete, the assembly strategy carries the ciphertext container. The container contains contextual description data, audit commitments, an attribute-based encryption key envelope, and a sequence of ciphertext fragments. It is serialized using deterministic field ordering and bounded encoding to avoid ambiguity caused by parsing differences. To support source tracing, a source signature can be attached to the outer layer of the container; this signature does not participate in decryption determination but is only used for tracing and evidence collection.

[0043] The principle behind this step lies in achieving a triple binding through two layers of encryption and a commitment: authentication encryption binds each ciphertext fragment to context description data and fragment order; attribute-based encryption binds the one-time data key to the access policy; and the audit commitment binds the container-level structure to the context description data. These three elements work together to ensure that even if the ciphertext is transmitted across multiple domains, its decryption determination and audit verification are based on the same context and policy, avoiding security vulnerabilities such as "ciphertext and policy mismatch."

[0044] The effects of this step are reflected in four aspects. First, the one-time key for data does not leave the container, avoiding long-term key exposure and cross-session association. Second, the additional data binding of authentication encryption prevents replay and cross-container splicing from being rejected at the decryption entry point. Third, attribute-based encryption enables fine-grained authorization across organizations, with access control completed at the key layer. Fourth, the audit commitment provides an entry point for container integrity verification that does not rely on plaintext, supporting subsequent time anchoring and forensic processes.

[0045] In Example 2, the data provides a direction policy and authorization service registration access policy and context description data. The system generates a one-time key for the data based on a high-entropy source, and the log data is segmented into consecutive fragments. For each fragment, the system obtains a fragment-level random number by hashing based on the dataset identifier, fragment index, time epoch, and random basis; authentication encryption is performed with the context description data as additional data to obtain ciphertext fragments. Subsequently, the system compiles the access policy into a linear secret-sharing structure and performs attribute-based encryption on the one-time key to obtain an attribute-based encryption key envelope. The system calculates an audit commitment based on the context description data, access policy identifier, number of ciphertext fragments, and total number of bytes, and encodes the context description data, audit commitment, attribute-based encryption key envelope, and ciphertext fragment sequence into a policy-carrying ciphertext container in a fixed field order. This container serves as the sole input carrier for subsequent on-demand key release and plaintext-free transfer. When transmitted between different organizations, neither party needs to access the plaintext or the one-time key to complete decryption and streaming decryption based on the access policy in a trusted execution environment. This embodiment enables the strong binding of data, policies, and context on the encapsulation side, providing a verifiable structural foundation for subsequent release and auditing.

[0046] Preferably, the authentication encryption uses context description data as additional data, and the slice-level random number is derived from the dataset identifier, slice index, time epoch, and random basis hash, so that the ciphertext slices and context description data form an integrity binding.

[0047] This invention describes an implementation method where "authentication encryption uses context description data as supplementary data, and fragment-level random numbers are derived from the dataset identifier, fragment index, time epoch, and random basis hash, thus forming an integrity binding between ciphertext fragments and context description data." This step merges the business context, fragment sequence, and randomness source into an indivisible verification element on the encapsulation side, and verifies the same element on the decryption side, thereby maintaining consistency in judgment under cross-organizational transmission and multi-stage forwarding conditions.

[0048] This invention employs an authentication encryption algorithm with authentication tags. Context description data is written as additional data into the authentication tags, and slice-level random numbers are derived in a deterministic manner. The context description data is frozen in the preceding steps and includes the source identity, target group, dataset identifier, policy version, time epoch, and random basis. To avoid verification mismatches caused by serialization differences, the context description data uses a fixed field order and fixed-length encoding to form a unique serialization result, which is used as additional data for authentication.

[0049] The derivation of slice-level random numbers follows a fixed mapping, ensuring that the same dataset yields different random number sequences across different time epochs or random bases, thus preventing cross-epoch replay and cross-container concatenation. The core calculation expression is as follows:

[0050]

[0051]

[0052] in, For the first Each piece of random numbers, For secure hash functions, For fixed-length truncation operators, Identify the dataset. For slice index, For the era of time, It is a random basis. For the first Each authenticated encrypted ciphertext, An authentication encryption algorithm with identification tags. One-time key for data, For the first One plaintext fragment, This describes the serialized result of the data within the context. During decryption, the authentication encryption algorithm verifies the input random number and the additional data. If any field does not match the encapsulation side, authentication fails and no plaintext is output.

[0053] The design intent of the derived mapping is to incorporate four dimensions into the random number space simultaneously: dataset identifiers ensure object uniqueness, slice indexes are used to locate inter-slice order, time epochs are used for policy temporal switching, and the random base is used to introduce an independent source of common entropy. This mapping achieves the following effects: First, when the policy version or time epoch changes, the entire random number sequence migrates, and the old container cannot be authenticated in the new epoch; second, within the same time epoch, adjusting the random base will cause the random number sequence and authentication label to change simultaneously, blocking cross-batch splicing; third, when the slice order is scrambled, inserted, or repeatedly forwarded, the authentication label and slice index do not match, and authentication fails.

[0054] To mitigate implementation risks, the serialization of the context description data employs a tag-plus-length-plus-value encoding method, with all fields written in a predetermined order. The slice index is a consecutive integer starting from zero. The number of ciphertext slices and the total number of bytes are recorded separately in the container header for boundary detection and consistency verification. The one-time data key is a high-entropy random value that only exists within the encapsulation and trusted execution environment decryption window and is not persistently stored.

[0055] The connection between this step and the subsequent release process is reflected in two aspects: First, both the joint challenge and the audit commitment contain contextual fingerprints, which the decryption side can use to check whether the encapsulation and release links are consistent; Second, the vector commitment and time anchor record the processing facts at the window level. When the subsequent epoch switches, the new time epoch will participate in random number derivation, binding the randomness of the new container with the governance facts.

[0056] In Example 3, Company A segments log data into consecutive fragments of a fixed size. Company A generates random numbers for each fragment using hash truncation based on the dataset identifier, fragment index, time epoch, and random base. The serialized result of the context description data is then used as additional data to input into the authentication encryption algorithm, resulting in ciphertext fragments that are written to a container. Research Institution B, receiving the container within a trusted execution environment, obtains context description data, time epoch, and random base consistent with the container from the policy and authorization service. It calculates random numbers using the same mapping and calls the authentication decryption interface. If Research Institution B combines the container with mismatched context description data, the authentication encryption algorithm fails to verify and does not output plaintext. If a third party attempts to mix fragments from different datasets into the container, the fragment index and random number sequence will be inconsistent, also resulting in authentication failure. This example demonstrates that, without shared plaintext or shared long-term keys, the encapsulation and decryption sides can achieve strong binding and consistency verification solely based on context description data and deterministic derivation mappings, thereby enabling robust data exchange across organizations and processes.

[0057] Preferably, the access policy is compiled into a linear secret-sharing structure, and attribute-based encryption uses this structure as the policy to encrypt the data with a one-time key. The one-time key is only decrypted when the access predicate is satisfied.

[0058] This invention describes an implementation where "the access policy is compiled into a linear secret-sharing structure, attribute-based encryption uses this structure as the policy to encrypt a one-time data key, and the one-time data key is only decrypted when the access predicate is satisfied." The goal of this step is to move access control from the channel layer to the key layer on the encapsulation side, achieving fine-grained authorization and anti-collusion control across organizational environments by performing attribute-based encryption on the one-time data key.

[0059] The access policy originates from the set of access predicates determined in the preceding steps, and includes at least the role, target region, business purpose, and time epoch. To obtain a deterministic and verifiable decision structure, a linear secret-sharing structure is used for compilation. The compilation process takes the policy expression as input and outputs a policy matrix and a mapping from rows to attributes. The core generation relation is: ,in, For share vectors, For a matrix of linear secret sharing structure, Let be a vector, with its first element being a randomly selected secret element and the remainder elements being random values. The row-to-attribute mapping function uniquely maps each row of the matrix to an attribute name. The compiled result is deterministic under the same policy expression, used for synchronization in subsequent encryption and decryption decisions.

[0060] The one-time data key, used as a session key for symmetric encryption, needs to be encapsulated using a policy matrix. The encapsulation end performs attribute-based encryption on the one-time data key to obtain the key encapsulation, denoted as: ,in, For attribute-based encryption key encapsulation, This is an attribute-based cryptographic operator that takes a policy matrix and a row-to-attribute mapping as parameters. One-time key for data, This is a mapping function from rows to attributes. The key envelope contains only policy-related group elements and the key encapsulation result, and does not contain any plaintext data. This envelope, together with the audit commitment and context description data in the container, forms a structured binding, but access decisions are entirely determined by the policy matrix and the attribute set.

[0061] The decryption side holds the private key material bound to the attribute set. The one-time key can only be recovered from the key envelope if the attribute sets of the participants satisfy the policy matrix. The linear reconstruction condition for satisfaction is: there exists a set of reconstruction coefficients such that the linear combination of the shares corresponding to the covered rows equals the secret element, i.e.: ,in, The set of row indices corresponding to the satisfied attribute. For reconstruction coefficients, For the bank's share, Let be the secret element corresponding to the first element of the vector. When the above relationship holds, the desealing algorithm outputs the one-time key for the data; otherwise, desealing fails and no information about the one-time key for the data is revealed. Due to the linear independence of the linear secret sharing structure, private key materials from multiple subjects that do not satisfy the policy cannot obtain effective reconstruction coefficients through collusion, forming a natural anti-collusion constraint.

[0062] In the application scenario of this invention, the time epoch attribute is used for rapid revocation and policy switching. The time epoch appears as a mandatory option in the row-to-attribute mapping of the policy matrix as an access predicate. When the governance side issues a new time epoch, the original attribute set will no longer satisfy the new policy matrix. Even if the decryption side holds other attributes that meet the conditions, it cannot reconstruct the secret element, thus failing to decrypt the one-time key for the data. This method avoids relying on a long-link revocation list to check hop-by-hop in the pass path, improving the immediacy of revocation.

[0063] The above method works in conjunction with the container encapsulation process. The encapsulation end first performs slice-level authentication encryption and calculates the audit commitment. Then, it performs attribute-based encryption on the one-time data key, generating a key envelope and writing it into the container. Upon receiving the container, the decryption end does not directly access the internal structure of the key envelope. Instead, it attempts to decapsulate the key envelope using a set of attributes within a trusted execution environment (TEA). If the satisfaction check passes, the one-time data key is returned to the TEA for authentication and decryption within the corresponding window. After the window is completed, the TEA performs verifiable deletion on the one-time data key, and the governance side updates the time anchor accordingly and switches the time epoch when necessary.

[0064] The effects of this step are reflected in three aspects. First, the coupling of authorization determination and key desealing eliminates the trust assumption at the channel level. Second, the linear secret-sharing structure provides strict satisfaction and linear reconstruction conditions, prohibiting collusion desealing by different entities across key attributes. Third, the time epoch, as a mandatory attribute, transforms revocation from list matching to an immediate decision based on attribute non-satisfaction, shortening the policy convergence path.

[0065] In Example 4, Company A acts as the encapsulation end, and Research Institution B acts as the decryption end. Company A forms an access policy based on the combination of access predicates with the roles of data analysis, target regions of the internal network, business purposes of model training, and time epochs of the current epoch. This policy is then compiled into a linear secret-sharing structure, resulting in a policy matrix and a row-to-attribute mapping. Company A performs attribute-based encryption on the one-time data key, generating a key envelope and writing it into the container header. Research Institution B's access subject holds private key material bound to an attribute set, which includes the roles of data analysis, target regions of the internal network, business purposes of model training, and time epochs of the current epoch. Research Institution B loads the container and private key material into a trusted execution environment. The decapsulation algorithm calculates the reconstruction coefficients based on the linear reconstruction condition of satisfaction, decapsulates the key envelope, and recovers the one-time data key. If Research Institution B's time epoch lags behind the governance side, the time epoch row in the row-to-attribute mapping is not overwritten, the reconstruction condition is not met, decapsulation fails, and the one-time data key is not output. This embodiment demonstrates that the policy expression is transformed into a computable satisfaction determination through a linear secret sharing structure, and is executed with the same structure at the encapsulation and decryption ends, ensuring that access control is closed at the key layer and has a fast response capability to revocation and policy switching.

[0066] Preferably, the audit commitment is obtained by hashing the context description data, access policy identifier, number of ciphertext fragments and total number of bytes, and the policy-bearing ciphertext container consists of the context description data, the audit commitment, an attribute-based encryption key envelope and a sequence of ciphertext fragments.

[0067] This invention describes the composition of audit commitments and the assembly of policy-carrying ciphertext containers. The goal is to form a publicly verifiable container-level fingerprint on the encapsulation side, and to encapsulate the context description data, audit commitments, attribute-based encryption key encapsulation, and ciphertext fragment sequence with a fixed structure, enabling subsequent participants to complete consistency verification and forensics without accessing the plaintext and symmetric keys.

[0068] Audit commitments are used to bind the integrity of critical container metadata, covering context description data, access policy identifiers, number of encrypted fragments, and total bytes. Context description data is encoded into a single byte sequence using a fixed field order. The access policy identifier is a unique identifier obtained by normalizing the policy expression. The number of encrypted fragments and total bytes are the actual counts generated in this round of encapsulation. The calculation expression for the audit commitment is: ,in, Indicates an audit commitment, Represents a secure hash function. This indicates the serialization result of the context description data. Indicates the access policy identifier. Indicates the number of ciphertext fragments. This indicates the total number of bytes in the ciphertext. Once these four items are determined, they are frozen; any change to any one will result in a change to the audit commitment. This design allows the container to be quickly verified by third parties using minimal materials even after cross-domain transmission and multiple forwardings.

[0069] The policy-carrying ciphertext container employs a deterministic layout. The container header contains contextual description data and an audit commitment, followed by an attribute-based encryption key envelope, and the tail contains the ciphertext fragment sequence. To avoid parsing ambiguity, each field is written in a three-segment encoded order: tag, length, and value. The fragment sequence maintains a monotonically increasing fragment index. The container separately records the number of fragments and the total number of bytes for boundary checks and rapid rejection at the decryption entry point. A source signature may be attached to the outer layer of the container for tracing the source entity and encapsulation time; the source signature does not participate in the decryption permission decision.

[0070] In principle, the audit commitment achieves three bindings. First, it binds the context description data to the container structure, allowing the decryption entry point to determine whether the container conforms to the expected business context. Second, it binds the access policy identifier to the container; when the governance side releases a new policy version or switches time epochs, older containers will fail consistency checks under the new policy. Third, it binds statistics to the container; any shard insertion, deletion, or rearrangement will be detected. Due to the use of a collision-resistant secure hash function, forgery and replacement are computationally infeasible.

[0071] The policy-based encryption key envelope within the ciphertext container assumes access control responsibilities, the ciphertext fragment sequence assumes data payload responsibilities, and the audit commitment assumes verifiable fingerprint responsibilities. These three components have clearly defined roles and are mutually restrictive: the key envelope is only unsealed when the access predicate is satisfied; the ciphertext fragment sequence is bound to context description data via authentication tags; and the audit commitment unifies and solidifies the structural information of both, forming a closed loop of "policy-context-structure." This closed loop provides two benefits in the subsequent release and audit phases: first, the release side can perform static consistency checks before entering the trusted execution environment, rejecting containers with significant anomalies; second, the audit side can complete point verification based solely on the audit commitment and index information, lowering the threshold for evidence collection.

[0072] In Example 5, after the data provider completes the fragment-level authentication encryption, the number of ciphertext fragments is counted as an integer, and the total number of bytes is the cumulative value corresponding to that integer. The access policy identifier is generated by standardization of the current policy version and predicate set. The context description data is serialized into a single byte sequence according to a fixed field order. The audit commitment is calculated based on the above four items. Subsequently, the context description data, audit commitment, attribute-based encryption key envelope, and ciphertext fragment sequence sorted by fragment index are written sequentially to form a policy-bearing ciphertext container. This container is transmitted to the decryption side after being registered at the border gateway. The decryption side first performs structural verification based on the field order and count information of the context description data, and then performs a consistency comparison with the governance side policy directory using the same access policy identifier. After the verification is passed, it enters the trusted execution environment, attempts to decrypt the one-time key of the data based on the attribute-based encryption key envelope and the local attribute set, and then performs authentication decryption piecewise. If a fragment is lost or replaced during transmission, and the total number of bytes or the number of fragments is inconsistent with the audit commitment, the verification immediately fails, and no plaintext is generated.

[0073] Through the above design, the audit commitment provides a stable and publicly verifiable fingerprint for the container; the fixed layout of the policy-carrying ciphertext container provides a consistent resolution and verification boundary for different implementation entities; the combination of the two ensures that cross-organizational data exchange still has verifiable consistency and traceability without sharing plaintext and long-term keys.

[0074] Within the trusted execution environment, policy matching and verification of zero trust tokens and capability authorization tickets are performed. A joint challenge is launched to the threshold key management node to obtain the unsealing share and synthesize a one-time data key within the trusted execution environment. Authentication and decryption are performed on ciphertext fragments, or a new policy-bearing ciphertext container for sub-granting is generated through proxy re-encryption.

[0075] This invention describes an implementation method for performing policy matching and credential verification within a trusted execution environment (TEA), initiating a joint challenge to the threshold key management node to obtain an unsealing share, synthesizing a one-time data key within the TEA, performing authentication and decryption on ciphertext fragments, and generating a new policy-bearing ciphertext container for sub-granting via proxy re-encryption. This process forms a closed-loop control between the key layer and the execution environment layer, without relying on channel trust.

[0076] The Trusted Execution Environment (TEE) first loads the policy-carrying encrypted container and its corresponding context description data, zero-trust token, and capability authorization ticket, performing format verification and field consistency checks. Then, within the TEE, policy matching is completed: satisfaction is determined based on the linear secret-sharing structure of the access policy and the local attribute set; simultaneously, the validity period, revocation status, and subject consistency of the zero-trust token and capability authorization ticket are verified, and the time epoch is checked to be consistent with the time epoch of the context description data. To resist rollback, the TEE reads a monotonic counter and solidifies the current metric evidence and the counter value into a metric digest.

[0077] After all the above checks pass, the Trusted Execution Environment (TEX) constructs a joint challenge. The core computation expression is: ,in, Indicating a joint challenge, Represents a secure hash function. Indicates an audit commitment, This represents the serialization result of evidence for trusted execution environment metrics. This represents a random number generated by a trusted execution environment. The joint challenge binds the container fingerprint, execution environment state, and session non-repeatability together, allowing the threshold key management node to verify the timeliness and authenticity of the request.

[0078] The Trusted Execution Environment (TEE) sends a joint challenge and an attribute-based cryptographic key encapsulated to distributed threshold key management nodes. Each threshold key management node verifies the joint challenge and performs partial unsealing, returning the unsealing share bound to the joint challenge. Upon receiving the unsealing share that has reached the threshold, the TEE performs a synthesis operation to recover the one-time key for the data. The core computation expression is: ,in, This represents a one-time key for data. Represents the threshold synthesis function. This represents the set of shares to be unsealed. This represents the set of node indices that have reached the threshold. Synthesis is performed solely within the trusted execution environment's memory; the synthesized data is a one-time key that neither leaves the domain nor is written to disk.

[0079] After obtaining the one-time key, the trusted execution environment performs authentication and decryption on the ciphertext fragments within the current window, using context description data consistent with that of the encapsulation side as additional data during decryption. The core calculation expression is: ,in, Indicates the first One plaintext fragment, This indicates an authentication / decryption operator with an authentication tag. Indicates the first Each encrypted fragment, This indicates the serialization result of the context description data. Any inconsistency between the context field and the encapsulation side will result in authentication failure and no plaintext output. After window processing is complete, the trusted execution environment clears the plaintext buffer and derived intermediate values, and marks the data one-time key as a pending deletion item, which is then submitted to subsequent governance steps for a verifiable deletion certificate.

[0080] When business operations require cross-organizational delegation and the recipient's access policy differs from the current policy, the Trusted Execution Environment (TEE) performs agent re-encryption to generate a new policy-bearing ciphertext container for delegation. This process does not touch the plaintext, does not change the ciphertext fragment sequence, only performs policy migration on the attribute-based encryption key envelope, and updates the target group and policy version in the context description data. The core calculation expression is: ,in, This indicates a new attribute-based cryptographic key envelope. Indicates the proxy re-encryption operator, This represents the outer envelope of the original attribute-based encryption key. Indicates the original access policy. Indicates the target access policy. This represents a re-encrypted token generated by the executable environment based on joint challenge and metric evidence. The new policy-carrying ciphertext container consists of updated context description data, the original audit commitment or a recalculated audit commitment after necessary field adjustments, a new attribute-based encryption key encapsulation, and the original ciphertext fragment sequence.

[0081] The effects of the above process are reflected in three aspects. First, key release is subject to both joint challenge and threshold verification, meaning a single node cannot decrypt independently, and cross-session replay cannot pass the joint verification of metrics and random numbers. Second, authentication and decryption strongly bind context description data to ciphertext fragments, rejecting any cross-container splicing or field tampering at the decryption entry point. Third, proxy re-encryption achieves policy migration without introducing intermediate plaintext, maintaining the stability of ciphertext fragments while reducing data exposure.

[0082] In Example 6, Financial Institution A acts as the encapsulation side, and Research Institution B acts as the decryption side. Research Institution B loads a policy-bearing ciphertext container, context description data, a zero-trust token, and a capability authorization ticket into a Trusted Execution Environment (TEE), completing policy matching and credential verification. The TEE calculates a joint challenge based on audit commitments and metric evidence, sends partial unsealing requests to three geographically dispersed threshold key management nodes, and synthesizes a one-time data key upon receiving the unsealing share that meets the threshold. The TEE performs authentication and decryption on ciphertext fragments by window, sending plaintext fragment streams into a read-only buffer for analysis tasks to consume, and immediately clearing it after the window ends. If Research Institution B needs to transfer the same data to Partner C, the TEE generates a re-encryption token based on the target access policy, performs proxy re-encryption to obtain a new attribute-based encryption key envelope, updates the target group and policy version, and outputs a new policy-bearing ciphertext container for transfer. Throughout the entire process, no plaintext or one-time data key is exposed outside the TEE, and all operations can be verified by subsequent governance steps based on fingerprints and time anchors.

[0083] Preferably, when performing policy matching, the Trusted Execution Environment (TEE) simultaneously verifies the validity period, revocation status, and subject consistency of the zero-trust token and the capability authorization ticket, and constructs a joint challenge including a hash digest of the audit commitment, TEE metric evidence, and a random number, which is then sent to the threshold key management node.

[0084] This invention describes the implementation method and technical effects of constructing a joint challenge and sending it to the threshold key management node after completing policy matching and credential verification in a trusted execution environment. The goal is to bind the container fingerprint, execution environment state, and session freshness as a single verification object before key release, and return the unsealing share only after independent verification by distributed nodes.

[0085] The trusted execution environment loads a policy-carrying encrypted container, context description data, zero-trust token, and capability authorization ticket. First, it performs format and field consistency checks to confirm that the subject identity, device identifier, dataset identifier, policy version, and epoch are consistent with the context description data. Then, it performs policy matching, determining satisfaction based on the compiled linear secret sharing structure and local attribute set. The validity period check, revocation status query, and subject consistency check of the zero-trust token and capability authorization ticket are performed in parallel. If any check fails, the process terminates and does not enter the key release path.

[0086] To establish externally verifiable trust in the execution environment, the trusted execution environment generates metric evidence and locks session counts, forming a non-rollbackable metric digest. Based on this, the trusted execution environment generates random numbers as a source of session freshness, which are combined with the container's audit commitment and metric evidence to form a joint challenge. The core calculation expression is: ,in, For the joint challenge; For secure hash functions; For audit commitment; The serialization result of evidence for a trusted execution environment metric; This is a random number generated by a trusted execution environment. Together, these three elements ensure that each request corresponds one-to-one with a specific container, execution environment, and session, preventing replay and cross-container splicing.

[0087] The Trusted Execution Environment (TEE) sends a joint challenge and attribute-based cryptographic key encapsulated to multiple geographically and administratively separated threshold key management nodes. Each node independently verifies the joint challenge and revocation information, returning the unsealed share bound to the joint challenge only if the verification passes. Because the joint challenge includes metric evidence and a random number, historical shares cannot be reused, and cross-session replication will be rejected. Only after reaching the threshold number does the TEE synthesize a one-time key locally and enter it for authentication and decryption within the window; if the threshold is not reached or any node's verification fails, no key or plaintext is generated.

[0088] The technical effects of this design are as follows: First, it moves the three elements of authorization determination forward to before key release, so any abnormal credentials are intercepted before the threshold is reached; second, it strongly binds key release to the specific execution environment by measuring evidence, avoiding key leakage paths outside the trusted execution environment; third, it ensures request freshness by combining random numbers and session counts, suppressing rollback attacks; and fourth, the mutual independent verification of distributed nodes reduces the risk of single point of compromise.

[0089] In Example 7, the research institution loads a container within a Trusted Execution Environment (TEE) and completes policy matching and credential verification. The TEE reads the metric report and session count, generates metric evidence, calls a true random number generator to generate random numbers, and calculates the joint challenge according to the aforementioned formula. Subsequently, it concurrently sends the joint challenge and key envelope to three threshold key management nodes. Each node verifies whether the audit commitment belongs to the valid container directory, whether the zero-trust token and capability authorization ticket have been revoked, and whether the metric evidence is within the allowed set. After verifying the signature of the joint challenge, it returns the unsealing share. Upon receiving the unsealing share that reaches the threshold, the TEE synthesizes a one-time data key and performs authentication and decryption on the encrypted fragments within the window. If any node reports revocation or the metric evidence is not in the allowed set, the TEE records the failure event and terminates the process without outputting plaintext. This example demonstrates that the joint challenge, without exposing plaintext and the symmetric key, strictly controls key release under the triple constraints of container fingerprint, execution environment state, and session freshness, thereby meeting the zero-trust requirements for cross-organizational data exchange.

[0090] Preferably, the threshold key management node uses threshold signature verification joint challenge and returns unsealed share. The trusted execution environment combines the unsealed share to obtain a one-time data key, and performs authentication and decryption on the ciphertext fragments with context description data as additional data. Plaintext exists only in the controlled memory area and is cleared after processing.

[0091] This invention describes an implementation method for completing a joint challenge in a trusted execution environment, including sending data out, the threshold key management node returning the unsealing share, synthesizing a one-time key for data in the trusted execution environment, and performing authentication and decryption on ciphertext fragments. The aim is to strongly bind key release to the execution environment state, container fingerprint, and session freshness, thereby avoiding channel trust and single point of failure risks.

[0092] After completing policy matching and credential verification, the Trusted Execution Environment (TEE) calculates the joint challenge according to the aforementioned definition and sends the joint challenge along with the attribute-based cryptographic key to threshold key management nodes distributed across different trust domains. Each threshold key management node performs threshold signature verification and revocation list verification on the joint challenge, generating and returning the unsealing share bound to the joint challenge only when all verifications pass. Node-side processing revolves around two core products: one is the aggregation of threshold signatures for the joint challenge, and the other is the unsealing share strongly bound to the joint challenge. The corresponding core relationships are: ， ,in, For the threshold signature aggregation result, For threshold signature operators, For the joint challenge, For the first The unsealing share generated by each threshold key management node. For the partial unblocking operator bound to the joint challenge, This is an attribute-based cryptographic key encapsulation. Because the unsealed share is bound to a joint challenge, historical shares cannot be reused in new sessions.

[0093] Upon receiving the required number of unsealed shares, the trusted execution environment performs synthesis within the protected memory space to recover the one-time data key. The core computation expression is: ,in, One-time key for data, For threshold synthesis function, To reach the threshold set of unblocking shares, This is the set of node indexes participating in the synthesis. The synthesis process occurs only in the trusted execution environment's memory, and immediately after completion, it enters the slice-level decryption window. During the authentication and decryption phase, the trusted execution environment verifies and decrypts each ciphertext slice according to the same additional data used on the encapsulation side. The corresponding calculation expression is: ,in, For the first One plaintext fragment, For authentication decryption operators with identification tags, For the first Each encrypted fragment, This describes the serialization result of the context description data. If any context field, random number, or slice index is inconsistent with the encapsulation side, authentication will fail and no plaintext will be output.

[0094] To control plaintext exposure, the Trusted Execution Environment (TEE) sets up a read-only controlled memory region for plaintext, employing a fixed window size and a post-use cleanup strategy. After processing each piece or window, the TEE clears the plaintext buffer and derived intermediate values, and marks the data with a one-time key as an object to be deleted, so that subsequent governance processes can generate verifiable deletion proofs. In abnormal branches, such as when the unsealing share does not reach the threshold, threshold signature verification fails, or authentication decryption fails, the TEE records a failure fingerprint, stops the process, and does not generate plaintext.

[0095] The technical benefits of this process are as follows: First, key release is witnessed by multiple nodes, and single-point compromise will not lead to key leakage; Second, the one-time data key is bound to the joint challenge, and replay and cross-container splicing cannot pass the node-side verification; Third, authentication and decryption use context description data as additional data to ensure that ciphertext fragments correspond one-to-one with the business context; Fourth, controlled memory areas and post-use cleanup limit the lifecycle of plaintext, providing a prerequisite for subsequent verifiable deletion.

[0096] In Example 8, Organization A, as the data receiver, loads a policy-carrying ciphertext container and context description data into its Trusted Execution Environment (TEE). After completing policy matching and credential verification, it generates a joint challenge based on the aforementioned joint challenge definition and sends it in parallel to three threshold key management nodes located in different regions. Each node verifies the joint challenge using a threshold signature and checks its revocation status before returning the unsealed share bound to the joint challenge. Upon receiving the unsealed share that has reached the threshold, the TEE synthesizes a one-time data key locally, performs authentication and decryption on the ciphertext fragments in window order, writes the plaintext into controlled memory for subsequent analysis module consumption, and clears the controlled memory and intermediate derivations at the end of each window. During this period, even if an old share returned by a node is intercepted, the TEE and other nodes will reject the share because it is inconsistent with the current joint challenge, and the process security is not affected. As can be seen from this example, the linkage mechanism of threshold signature, partial unsealing, and controlled window decryption forms a closed-loop control of key release, decryption execution, and plaintext management, thereby meeting the security and verifiability requirements of zero-trust multi-party data exchange.

[0097] Preferably, the proxy re-encryption performs policy migration on the attribute-based encryption key envelope within a trusted execution environment. The new policy carries a ciphertext container that keeps the ciphertext fragments unchanged, and only updates the target group field and policy version field in the attribute-based encryption key envelope and context description data.

[0098] This invention describes an implementation method for performing proxy re-encryption within a trusted execution environment to complete policy migration. This step, based on the principle of maintaining ciphertext fragmentation stability, involves changes only at the key and context layers, enabling the same data to be transferred without plaintext between different access policies and target groups.

[0099] The Trusted Execution Environment (TEE) loads a policy carrying a ciphertext container and local credentials, having already completed policy matching, credential verification, and joint challenge generation through previous steps. Based on this, the TEE derives a re-encryption token and migrates the policy by encapsulating the attribute-based encryption key. The core computational relationship is as follows: ， ,in, For re-encrypted tokens; Generate operators for tokens; For the joint challenge; The serialization result of evidence for a trusted execution environment metric; The original access policy remains unchanged. For target access strategy; The original attribute-based encryption key is encapsulated in an outer layer; This is an external encapsulation of the migrated attribute-based encryption key. The re-encryption token is bound to a federated challenge and metric evidence, is valid only in the current session, and is not exported outside the trusted execution environment.

[0100] To ensure verifiable consistency of containers during cross-domain transmission, the new policy-carrying ciphertext container maintains its ciphertext fragment sequence unchanged, updating only the attribute-based encryption key envelope and the target group and policy version fields in the context description data. After the context description data is updated, it is reserialized to obtain a new context byte sequence, which is then used to calculate a new audit commitment to maintain the container-level fingerprint and structure binding. The corresponding relationship is as follows: ， ,in, For the new context byte sequence; For fixed-order encoding operators; The context description data for the target group field and the policy version field has been updated; For the new audit commitment; For secure hash functions; Identify the target access policy; The number of ciphertext fragments; This represents the total number of bytes in the ciphertext. Since the ciphertext fragmentation remains constant, the statistical value is... and This remains unchanged, making it easy to quickly compare load consistency before and after migration on the network side.

[0101] The new policy carries a ciphertext container with a fixed layout, consisting of new context description data, a new audit commitment, a migrated attribute-based encryption key envelope, and the original ciphertext fragment sequence. Authentication tags are still verified on the decryption side with the new context description data as additional data; any call requests inconsistent with the updated target group or policy version will be rejected. This design ensures that policy migration only affects access decisions and context binding, without altering the data payload, thus significantly reducing storage and bandwidth costs in cross-party transfers.

[0102] The technical benefits of this step are reflected in three aspects. First, the policy migration is completed within a trusted execution environment, and the re-encryption token exists briefly and is bound to the federated challenge, preventing it from being copied and used in other sessions. Second, the ciphertext sharding remains unchanged, eliminating the need for data re-encryption and avoiding link blockages and audit breakpoints caused by re-encapsulation. Third, the new audit commitment covers the updated context and policy identifier, making the migration behavior verifiable on-chain evidence, facilitating subsequent auditing and traceability.

[0103] In Example 9, Company A, as the data provider, grants different access permissions to the same dataset to Partner B. Company A initially sets the access policy to internal analysis, with the policy matrix corresponding to a specific policy identifier. It generates an attribute-based encrypted key envelope and outputs a policy-carrying ciphertext container. Subsequently, Company A needs to transfer the data to Partner B's research team, adjusting the access policy to research purposes, the target group to the research team, and incrementing the policy version. Company A's Trusted Execution Environment (TEA) generates a re-encryption token based on the joint challenge and metric evidence of the current session. It then calls the re-encryption operator to perform policy migration on the original attribute-based encrypted key envelope, obtaining a new attribute-based encrypted key envelope. Simultaneously, it updates the target group field and policy version field in the context description data and recalculates the audit commitment. Finally, a new policy-carrying ciphertext container is formed and delivered to Partner B. Partner B uses its attribute set within the TEA to deseal the new attribute-based encrypted key envelope. If its attributes satisfy the new access policy, it restores the one-time data key and authenticates and decrypts the original ciphertext fragments; otherwise, desealing fails and no plaintext is generated. This embodiment demonstrates that by implementing policy migration and context updates through proxy re-encryption within a trusted execution environment, cross-organizational transfer can be completed without touching the plaintext or changing the ciphertext fragments, while maintaining audit verifiability and continuity of access control.

[0104] Based on the decryption and transfer events, audit logs are generated and aggregated into commitments. Time anchors are generated and mapped to the random basis of the next round of context description data.

[0105] This invention describes an implementation method for generating audit logs based on decryption and transfer events, aggregating them into commitments, generating time anchors, and mapping these time anchors to a random basis for the next round of context description data. The goal is to solidify the execution facts into externally verifiable evidence without exposing plaintext and symmetric keys, and to transform this evidence into a source of randomness in subsequent encapsulation stages, thus forming a closed loop at the process level.

[0106] Audit logs are generated using a standardized field format, including event type, window processing result, container-level audit commitment, trusted execution environment metric evidence summary, timestamp, session count, number of encrypted fragments, and total bytes. The decryption log indicates whether decryption was successful and specifies the range of fragments consumed, as well as the target group and policy version before and after the transfer of the event log policy. All fields are encoded in a fixed order to avoid parsing ambiguity.

[0107] To facilitate aggregation and verification, the element hash is first calculated for each event record, and then a vector commitment is constructed. The core calculation expression is:

[0108]

[0109]

[0110] in, Indicates the first Hash of event records, Represents a secure hash function. Represents standardized event logging. Represents the root of a vector commitment. The vector commitment construction operator is represented. This indicates the number of events included in this aggregation. Proof-of-existence queries can be used to verify the existence of any event during subsequent audits without disclosing all records. Time anchors are used to correlate the governance facts of the current batch with external time, while also providing unpredictable common entropy for the next round of encapsulation.

[0111] The time anchor message is obtained by hashing the vector commitment root with the time information, and then evaluated using a verifiable delay function. The core calculation expression is: , ,in, Indicates a time-anchored message. The encoding result representing standard time information. Indicates time anchor output. This indicates a verifiable delay function. This represents the preset delay parameter. The time anchor output, along with the delay parameter and supporting documentation, is published for independent verification by any third party. To feed governance facts back to the encapsulation phase, the time anchor output is mapped to the data object's identity and policy state as the next round's random basis. The core calculation expression is:

[0112]

[0113] in, Indicates the next round of random basis, Indicates the dataset identifier, This indicates the policy version identifier. The next round of context description data uses this random base as one of the inputs for deriving slice-level random numbers, and the constraints on slice-level random number derivation and authentication encryption mentioned above are naturally inherited from this.

[0114] The above process yields three effects. First, the execution facts of decryption and sublicense are solidified into publicly verifiable structured evidence through vector commitments; any replay, deletion, or order alteration will lead to inconsistencies in the commitments. Second, the time anchor binds the evidence to a standard time and introduces a verifiable delay, preventing short-cycle rollbacks. Third, the time anchor output is deterministically mapped to become the next round's random basis, strongly coupling the randomness of subsequent encapsulation with the previous round's governance facts, thereby compressing the attacker's choice space at the system level.

[0115] In Example 10, the data receiver completes authentication and decryption of a window in a trusted execution environment, generating two successful decryption event records. Subsequently, based on business needs, a policy migration is performed on the same container, and a new policy-bearing ciphertext container is output, generating one transfer event record. The system encodes the three event records in a fixed order and calculates the element hashes for each, then constructs a vector commitment root. Using the vector commitment root and the current standard time encoding as input, a time anchor message is calculated, and a verifiable delay function is called to obtain the time anchor output, which, along with verification materials, is written into the audit archive. Based on this, the system calculates the next round of random basis and fills it into the next round of context description data for slice-level random number derivation and additional data binding. When an external auditor requests verification of a decryption event, the system returns the vector commitment root, the encoding of the event record, the query point proof, and the time anchor materials, which the auditor uses to independently complete the verification. This example demonstrates that record aggregation, time anchor generation, and random basis mapping achieve external verifiability and randomness feedback of governance evidence without exposing plaintext and symmetric keys, forming a closed loop of decryption and transfer to a new round of encapsulation.

[0116] Preferably, audit records are generated in a fixed field format and formed into commitment roots through vector commitment aggregation. Time anchors are calculated based on commitment roots and time information via a verifiable delay function. Time anchors are then used to generate a random basis for the next round of context description data through deterministic mapping.

[0117] This invention revolves around the standardization of audit records, vector commitment aggregation and time anchor generation, and the implementation of mapping the deterministic nature of time anchors to a random basis for the next round of context description data. The aim is to solidify execution facts such as decryption and transfer into externally verifiable evidence, and then feed this evidence back to the source of randomness on the encapsulation side, forming a closed loop.

[0118] Audit logs are generated using a fixed field order and an encoding method that includes labels, lengths, and values. Fields include event type, container-level audit commitment, trusted execution environment metric evidence digest, timestamp, session count, number of encrypted fragments, total number of encrypted bytes, and fragment order range. This encoding ensures that any implementation entity generates the same byte sequence for the same fact, avoiding verification failures caused by parsing differences. After log generation, the logs enter the aggregation phase.

[0119] The aggregation uses vector commitments to support subsequent point query verification. First, an element hash is generated for each record, then the commitment root is constructed. The core calculation expression is:

[0120]

[0121]

[0122] For the first Hash of event records; For secure hash functions; To standardize event logging; The commitment root of the vector commitment; Construct operators for vector commitments; The number of records to be aggregated. The system maintains a commitment root and necessary index mappings to provide point proofs during external verification without exposing all records. Time anchors are used to bind the governance facts of this batch to standard time, while providing a consistent common entropy to all participants. Time anchor messages are obtained by hashing the commitment root and time information, then inputting a verifiable delay function to calculate the time anchor output. The core calculation expression is: , , For time-anchored messages; The encoding result for standard time information; Output as a time anchor; A verifiable delay function; This is the preset delay parameter.

[0123] The system publishes time-anchored outputs along with publicly available verification materials for the delay function, enabling any third party to independently verify message and time consistency and detect rollback behavior. To feed governance facts back to the next round of encapsulation, the system maps the time-anchored outputs to data object identities and policy states using a random basis. The core calculation expression is: , For the next round of random basis; Output as a time anchor; Identify the dataset; This serves as the policy version identifier. The next round's context description data directly carries this random base as one of the inputs for shard-level random number derivation, thereby coupling the execution and audit facts of the previous round into the cryptographically encapsulated randomness of the next round.

[0124] The above mechanism brings three benefits. First, aggregation based on commitment roots allows any event to be independently verified through point proofs without exposing other records, reducing the cost of evidence collection. Second, time anchors introduce verifiable delays, preventing short-cycle rollbacks or parallel forks and ensuring that governance facts progress monotonically. Third, the deterministic mapping of the random basis injects subsequent randomness into governance facts, preventing attackers from rolling back after decryption without being "recorded" in the next round.

[0125] In Example 11, the data receiver completes a decryption window and performs a policy migration within a trusted execution environment. The system generates audit records for two decryption events and one transfer event, encodes them in a fixed order, calculates element hashes, and constructs a commitment root. The commitment root and standard time are then encoded into a time anchor message, a verifiable delay function is called to obtain the time anchor output, and corresponding verification materials are published. Based on the time anchor output, dataset identifier, and policy version, the system calculates the next round of random basis and writes it into the next round of context description data. When an external auditor requests verification of one of the decryption events, the system provides the commitment root, the encoding of the event record, point proof, and time anchor materials, allowing the auditor to independently complete the verification without accessing the plaintext or key. This example demonstrates that the combination of record standardization, vector commitment, and time anchors ensures the external verifiability of the execution facts and uses the verification results to drive the randomness of the next round of encapsulation, forming a closed loop from execution to governance to randomness.

[0126] Preferably, the epoch and policy updates are generated based on the statistical results of release events and sub-authorization events in the audit log. The updated information is synchronized to the threshold key management node and the border gateway. The subsequent issuance of zero trust tokens and capability authorization tickets adopts the updated time epoch and access predicate.

[0127] This invention describes the generation, distribution, and activation mechanism of epoch and policy updates. The goal is to form a verifiable and rollbackable governance loop without exposing plaintext and symmetric keys, using audit records as the sole source of fact, and to enable subsequent zero-trust tokens and capability authorization tickets to automatically inherit the updated time epoch and access predicate.

[0128] The governance module periodically reads archived audit records, which originate from decryption and transfer events. The fields have been standardized and aggregated using vector commitment as described in previous sections. Within a fixed sliding window, the governance module counts events, tracks temporal fluctuations, and identifies anomaly indicators to form decision metrics. The core decision uses the following expression:

[0129]

[0130] in, This is an indicator of whether an update should be triggered. This represents the number of events allowed within the window. This represents the number of rejection events within the window. It is a sequence of time intervals between two consecutive transfer events; Let V be the variance of the sequence; The percentage of anomalies obtained through anomaly detection; This is the governance threshold. If any condition is met, epoch and policy convergence are triggered. Upon triggering, a new time epoch and access predicate set are generated. The time epoch is updated using discrete incrementing: ,in, For the current time era, For a new time epoch. The access predicate set performs a convergent mapping based on the statistical context: ,in, For the currently accessed predicate set, For the updated set of access predicates, This is a context composed of audit record statistics. The convergence mapping, without altering the authorization model, narrows the geographical scope, usage, rate caps, or mandatory attributes (including time epochs), and adds a revocation flag increment for high-risk entities.

[0131] The governance side generates an update package based on this information. The update package includes the new time epoch, the updated set of access predicates, the effective time, the revocation flag increment, and the commitment root reference, and is signed by the organization's private key. To ensure consistency across the access plane, the update package is synchronized to all threshold key management nodes and border gateways: Threshold key management nodes update their local authorization policies and revocation directories upon receiving the update package and return a signed confirmation; border gateways refresh their session registration and anti-replay caches upon receiving the update package and switch the time epoch and access predicate index used for fast verification. Synchronization is completed based on the signature sets of each node; nodes that do not confirm are marked as downgraded services to prevent the old policy from continuing to be effective in the key path.

[0132] Newly issued zero-trust tokens and capability authorization tickets are required to carry a new time epoch and access predicate set. Zero-trust tokens and capability authorization tickets with old time epochs are first rejected at the border gateway, and then fail to unlock the one-time data key at the trusted execution environment because the time epoch attribute is not satisfied. This two-layer constraint ensures that updates take effect immediately and can be independently verified. To reduce service jitter, the governance side can set a gray-scale implementation period. During the gray-scale period, only old sessions targeting low-risk datasets are allowed to terminate naturally, while new sessions always apply the new time epoch and access predicate set.

[0133] The update process is linked to the time anchor. The governance side combines the commitment root used for decision-making with time information to form a time anchor message. The time anchor output, calculated using a verifiable delay function, is published along with the update package, allowing any third party to verify "which audit facts led to this update." In the next round of encapsulation, the time anchor output is deterministically mapped to a new random basis. The aforementioned slice-level random number derivation and authentication encryption naturally inherit this random basis, creating a cross-round coupling between governance facts and cryptographic randomness.

[0134] In Example 12, the statistical window is the most recent 24 hours. Within the window, 1200 events were allowed and 180 events were rejected, resulting in a rejection rate of 0.13. The variance of the time interval between transfer events exceeded the threshold; the anomaly rate did not exceed the limit. According to the judgment expression, an update was triggered due to the transfer timing fluctuation exceeding the limit. The governance end calculates a new time epoch, narrows the geographical range and lowers the rate cap in the access predicate set, and adds some subjects to the revocation flag increment, generating and signing an update package. The update package is synchronized to three threshold key management nodes and two border gateways. After the nodes return signature confirmation, new zero-trust tokens and capability authorization tickets begin to be issued. Subsequent sessions arriving in the old time epoch are rejected at the border gateways, and new sessions are matched and unblocked within the trusted execution environment according to the new time epoch and access predicate set. This example demonstrates that this mechanism, based on audit records, uses verifiable time anchors and commitment roots to connect the decision-making, distribution, and activation stages, making epoch and policy updates traceable, verifiable, and able to immediately constrain subsequent data exchange processes.

[0135] The above are merely embodiments of this application and are not intended to limit the scope 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 the claims of this application.

Claims

1. A zero-trust multi-party secure data exchange method, characterized in that, Includes the following steps: Obtain a zero-trust token and capability authorization ticket, and generate context description data, including fields such as source identity, target group, dataset identifier, policy version, time epoch, and random basis; Generate a one-time key for the data, slice the data to be exchanged into pieces, add context description data as additional data, perform authentication encryption on each plaintext piece, generate ciphertext pieces, perform attribute-based encryption on the one-time key for the data according to the access policy, calculate audit commitments and assemble them into a policy-bearing ciphertext container. Within the Trusted Execution Environment, policy matching and verification of zero-trust tokens and capability authorization tickets are performed. A joint challenge is launched to the threshold key management node to obtain the unsealing share and synthesize a one-time data key within the Trusted Execution Environment. Authentication and decryption are performed on ciphertext fragments, or a new policy-bearing ciphertext container for sub-granting is generated through proxy re-encryption. Based on the decryption and transfer events, audit logs are generated and aggregated into commitments. Time anchors are generated and mapped to the random basis of the next round of context description data.

2. The method according to claim 1, characterized in that, The payload of a zero-trust token includes a device metric summary, a session counter, an issuance time, and an expiration time. The payload of a capability authorization ticket includes a set of access predicates and a revocation flag. The border gateway registers sessions and establishes an anti-replay cache based on context description data.

3. The method according to claim 1, characterized in that, The authentication encryption uses context description data as additional data, and the slice-level random number is derived from the dataset identifier, slice index, time epoch and random basis hash, so that the ciphertext slices and context description data form an integrity binding.

4. The method according to claim 1, characterized in that, The access policy is compiled into a linear secret-sharing structure. Attribute-based encryption uses this structure as the policy to encrypt the data with a one-time key. The one-time key is only decrypted when the access predicate is satisfied.

5. The method according to claim 1, characterized in that, The audit commitment is calculated by hashing the context description data, access policy identifier, number of ciphertext fragments, and total number of bytes. The policy-bearing ciphertext container consists of the context description data, the audit commitment, an attribute-based encryption key envelope, and a sequence of ciphertext fragments.

6. The method according to claim 1, characterized in that, When performing policy matching, the Trusted Execution Environment (TEE) simultaneously verifies the validity period, revocation status, and subject consistency of the zero-trust token and capability authorization ticket, and constructs a joint challenge including a hash digest containing audit commitments, TEE metric evidence, and a random number, which is then sent to the threshold key management node.

7. The method according to claim 1, characterized in that, The threshold key management node uses threshold signature verification joint challenge and returns unsealed share. The trusted execution environment combines the unsealed share to obtain a one-time key for the data, and performs authentication and decryption on the ciphertext fragments with context description data as additional data. Plaintext exists only in the controlled memory area and is cleared after processing.

8. The method according to claim 1, characterized in that, The proxy re-encryption performs policy migration on the attribute-based encryption key envelope within a trusted execution environment. The new policy carries the ciphertext container while keeping the ciphertext fragments unchanged, and only updates the target group field and policy version field in the attribute-based encryption key envelope and context description data.

9. The method according to claim 1, characterized in that, Audit records are generated in a fixed field format and formed into commitment roots through vector commitment aggregation. Time anchors are calculated based on commitment roots and time information using a verifiable delay function. Time anchors are then used to generate a random basis for the next round of context description data through deterministic mapping.

10. The method according to claim 1, characterized in that, The epoch and policy updates are generated based on the statistical results of release events and sub-authorization events in the audit log. The updated information is synchronized to the threshold key management node and the border gateway. The subsequent issuance of zero trust tokens and capability authorization tickets adopts the updated time epoch and access predicate.

Images