On-chain strategy-driven cross-institutional data sharing system and method

Abstract

This invention discloses an on-chain policy-driven cross-institutional data sharing system and method, relating to the field of data sharing, including: a data sharing platform; the data sharing platform includes a key management module and an audit aggregation module; the key management module is used to initially verify and validate the remote proof of the trusted execution environment in the access request, and generate audit evidence based on the remote proof verification result and report it to the audit aggregation module; the audit aggregation module is used to store the audit evidence in a queue to be aggregated and return a temporary audit receipt; the key management module is used to construct a key package based on the remote proof verification result and the temporary audit receipt, and send it to the trusted execution environment of the data user; the trusted execution environment is used to unseal or use the key package, generate a usage proof and send it to the audit aggregation module; the audit aggregation module is used to store the usage proof in the queue to be aggregated. This invention achieves a technical binding between on-chain policy and key distribution.

Description

Technical Field

[0001] This invention relates to the field of data sharing technology, and in particular to an on-chain policy-driven cross-institutional data sharing system and method. Background Technology

[0002] With the rapid development of industry collaboration, intergovernmental communication, and data-driven services, cross-agency data sharing has become a necessary means to meet business collaboration and data value mining needs. However, data providers and data users often exist in different trust domains. While ensuring data sovereignty, privacy, and compliance, data providers need to conditionally grant data access or usage rights to multiple recipients in different domains under policy control. These cross-agency sharing scenarios place high demands on security, revocability, audit verifiability, and scalability costs.

[0003] The main existing technologies for cross-domain data sharing or controlled access include: centralized or distributed access control and authentication mechanisms, key encapsulation technology, on-chain technology for information such as policy digests, authorization records or decentralized identity identifiers (DIDs), Trusted Execution Environment (TEE) combined with remote proof technology, and smart contract or on-chain custody mechanisms.

[0004] Although the above technologies can be applied individually or in combination to cross-organizational data sharing, several key technical shortcomings still exist in practical applications, including:

[0005] (1) On-chain policy and key availability are disconnected: Most current solutions only record policy summaries or authorization events on the chain, but cannot technically ensure that the key or decryption material obtained by the recipient will become invalid when the on-chain is revoked; that is, even if the revocation or policy change occurs on the chain, if the recipient has a long-term valid key or decryption material, he / she may still continue to access the data off the chain, making it difficult to enforce the revocation.

[0006] (2) High cost of repeatedly generating / distributing ciphertext or repackaging for each recipient: Traditional methods based on envelope encryption or PRE often require generating an independent ciphertext copy for each recipient or performing proportional re-encryption / repackaging operations, resulting in storage, transmission and management costs increasing linearly with the number of recipients, which is not conducive to large-scale data sharing.

[0007] (3) The risk of plaintext or key being exported in an uncontrollable environment is high and the evidence for subsequent accountability is insufficient: When decryption occurs in an untrusted or unprovable environment, plaintext or key is easily exported or misused; even if a violation occurs, the lack of a complete and tamper-proof audit chain and signature evidence makes it difficult to assign responsibility and trace the incident afterward.

[0008] (4) Payment escrow and key distribution lack a reliable atomic linkage mechanism and on-chain information exposes sensitive metadata: In scenarios where payment / escrow is required as a prerequisite for authorization, common solutions cannot guarantee atomicity and verifiability in "pay first, receive later" or "receive first, pay later" scenarios; at the same time, if complete authorization information or resource metadata is recorded directly on the chain, it may leak commercially sensitive information or user privacy. Summary of the Invention

[0009] To address the technical problems existing in the background art, this invention proposes an on-chain policy-driven cross-institutional data sharing system and method.

[0010] This invention proposes an on-chain policy-driven cross-institutional data sharing system, comprising: a data user terminal, a data sharing platform, and a trust service provider; the data sharing platform includes a key management module and an audit aggregation module, and the trust service provider includes a blockchain and a DID management module.

[0011] The data user sends a signed access request to the key management module; the key management module performs a preliminary verification of the access request; if the preliminary verification passes, it performs remote verification of the trusted execution environment of the data user to obtain the remote verification result; based on the preliminary verification result and the remote verification result, it generates signed audit evidence and reports the audit evidence to the audit aggregation module; the audit aggregation module stores the audit evidence in the batch aggregation queue and simultaneously returns a temporary audit receipt to the key management module.

[0012] The key management module is also used to construct key packages based on preliminary verification results, remote proof verification results, temporary audit receipts, and preset resource policy constraints; sign the key packages; and send the signed key packages to the trusted execution environment of the data user through a trusted secure session. The trusted execution environment is used to unseal or use the key packages, generate a signed proof of use, and send the signed proof of use to the audit aggregation module. The audit aggregation module is also used to store the proof of use in the batch aggregation queue.

[0013] The audit aggregation module is also used to batch aggregate the queue to be aggregated, obtain the Merkle tree, calculate the Merkle root hash, write the Merkle root hash into the blockchain, generate a signed final audit receipt, and send it to the key management module and the trusted execution environment.

[0014] Preferably, the preliminary verification includes request integrity and signature verification, DID status verification, and on-chain authorization verification; wherein, request integrity and signature verification, DID status verification, and on-chain authorization verification are performed sequentially; if any one of the verifications fails, the preliminary verification is deemed to have failed, a rejection response and a rejection record including the rejection reason are generated, and the response is reported to the audit aggregation module, which stores the rejection record in the batch aggregation queue; if all verifications are successful, the preliminary verification is deemed to have passed.

[0015] Preferably, remote proof verification includes: sequentially executing certificate chain and signature verification, capability item-by-item comparison and measurement value / environment fingerprint verification, independent verification of evidence citation, conditional access policy determination, and anti-replay and liveness checks; if any of the verifications, checks, determinations, or checks fails, the remote proof verification is deemed unsuccessful, a rejection response and a rejection record including the rejection reason are generated, and the rejection record is reported to the audit aggregation module; if all are successful, the remote proof verification of the trusted execution environment is deemed successful and the remote proof verification result is obtained.

[0016] Preferably, before storing audit evidence or proof of use into the batch aggregation queue, the audit aggregation module is also used to perform integrity and signature verification on the audit evidence or proof of use.

[0017] Preferably, a key package is constructed based on the preliminary verification results, remote proof verification results, temporary audit receipts, and preset resource policy constraints, specifically including:

[0018] Based on the preliminary verification results, remote proof verification results, temporary audit receipts, and preset resource policy constraints, analyze whether the data user meets the conditions for obtaining the key packet; the analysis results are divided into three categories: allowed, allowed but restricted, and rejected.

[0019] If the analysis result is allowed or allowed but restricted, extract the symmetric data encryption key and the public key of the data user corresponding to the target shared resource from the DID management module, and encrypt it using the public key of the data user to obtain the key ciphertext.

[0020] Based on the key ciphertext, a key package is generated; wherein the key package includes: key ciphertext, key package ID, target trusted execution environment ID, target public key fingerprint, validity period, usage constraints, temporary audit receipt ID or its hash and authorized TXID digest; and the ID in the temporary audit receipt is written into the audit receipt ID of the key package.

[0021] Preferably, the signed key packet is sent to the trusted execution environment of the data user through a trusted secure session, specifically including:

[0022] The key management module establishes a trusted secure session with the trusted execution environment of the data user.

[0023] During the establishment of a trusted secure session, the key management module and the trusted execution environment verify each other's identities through two-way remote authentication and negotiate the session symmetric key based on the key exchange protocol.

[0024] The key management module sends the signed key packet to the trusted execution environment of the data user through a trusted secure session and generates an audit log of the event; the session symmetric key is not written to the DID management module and is not transmitted in plaintext.

[0025] Preferably, the trusted execution environment is used to unseal or use the key packet to generate a signed proof of use, specifically including: the trusted execution environment using its private key to unseal the key ciphertext to obtain the key plaintext; using the key plaintext to perform controlled access or streaming processing on the resource ciphertext of the target shared resource; and after the entire process of streaming processing is completed or each step of controlled access is completed, the trusted execution environment generates a proof of use and signs the proof of use using its private key.

[0026] Preferably, the trusted execution environment is also used to continuously monitor policy violations and operational anomalies; if an anomaly is detected or a revocation command signed by the key management module is received, the trusted execution environment immediately stops further decryption and output, and securely destroys or zeroes the plaintext key and related session symmetric key within isolation, generates a signed anomaly proof or a signed confirmation message, and reports it to the key management module and the audit aggregation module; wherein, the signed anomaly proof or the signed confirmation message includes the revocation ID, destruction timestamp, trusted execution environment ID, remote proof digest hash, and trusted execution environment capability set identifier;

[0027] After receiving the revocation confirmation from the trusted execution environment, the key management module is also used to mark the key package as revoked and update the status in the local and on-chain audit logs.

[0028] Preferably, the key management module and the audit aggregation module are also used to monitor on-chain events; when an authorization event occurs in the strategy contract, the key management module and the audit aggregation module are respectively used to receive the authorization event and store the summary of the authorization event in their respective local event queues.

[0029] When a revocation event occurs in a strategy contract, the revocation event is triggered on-chain and a digest is written. The key management module listens for the revocation event and determines whether there are any unexpired key packages. If not, it only records the revocation time and stores it on the chain. If so, it marks the corresponding key package as revoked, updates the local state, and sends a revocation notification or issues an immediate revocation command to the trusted session. The revocation event is recorded as audit evidence and anchored on the chain in the next batch, forming a verifiable revocation record.

[0030] Preferably, it also includes a data provider, which is used to acquire the target shared resource, generate a symmetric data encryption key for the target shared resource, and encrypt the target shared resource using the symmetric data encryption key to obtain resource ciphertext; store the resource ciphertext; generate a resource fingerprint based on a single resource ciphertext, write the resource fingerprint into the blockchain, and send the symmetric data encryption key to the DID management module of the data sharing platform.

[0031] Preferably, before sending an access request to the data sharing platform, the data user also confirms the target shared resource; prepares the access request based on the target shared resource; determines whether payment has been made; if not, performs on-chain authorization and payment on the encrypted resource of the target shared resource in the blockchain's strategy contract; obtains the on-chain payment / authorization TXID returned by the strategy contract and writes the on-chain payment / authorization TXID into the access request; if yes, directly writes the on-chain payment / authorization TXID into the access request and digitally signs the access request.

[0032] Preferably, before confirming the target shared resource, the data user also submits a device registration application to the DID management module of the data sharing platform; wherein, the device registration application includes device information and requester identification information; receives the requester's DID and device registration receipt returned by the DID management module of the data sharing platform; the trusted execution environment is used to generate a public-private key pair for remote proof verification and a random number and corresponding logic for the session; the fingerprint of the public key in the public-private key pair, the trusted execution environment ID, and the device registration receipt are associated, the association relationship is stored, and the association relationship between the public key and the public key identity in the public-private key pair is sent to the DID management module of the data sharing platform.

[0033] Secondly, the present invention also proposes an on-chain policy-driven cross-institutional data sharing method, applied to the on-chain policy-driven cross-institutional data sharing system described in any one of the first aspects, comprising:

[0034] The data user sends a signed access request to the key management module; the key management module performs a preliminary verification of the access request; if the preliminary verification passes, it performs remote verification of the trusted execution environment of the data user to obtain the remote verification result; based on the preliminary verification result and the remote verification result, it generates signed audit evidence and reports the audit evidence to the audit aggregation module; the audit aggregation module stores the audit evidence in the batch aggregation queue and returns a temporary audit receipt to the key management module.

[0035] The key management module constructs a key package based on the preliminary verification results, remote proof verification results, temporary audit receipts, and preset resource policy constraints. It then signs the key package and sends it to the trusted execution environment of the data user through a trusted secure session. The trusted execution environment unseals or uses the key package, generates a signed proof of use, and sends the signed proof of use to the audit aggregation module. The audit aggregation module stores the proof of use in the batch aggregation queue.

[0036] The audit aggregation module performs batch aggregation on the queue to be aggregated, obtains a Merkle tree, calculates the Merkle root hash, writes the Merkle root hash into the blockchain, generates a signed final audit receipt, and sends it to the key management module and the trusted execution environment.

[0037] The on-chain policy-driven cross-institutional data sharing system and method proposed in this invention have the following significant advantages:

[0038] (1) Achieve technical binding between on-chain policy and key distribution to realize controllable revocation and timeliness control: By taking on-chain authorization / revocation events, the preliminary verification results of the key management module and the remote proof verification results, the local policy verification results and the temporary audit receipt ID returned by the audit aggregation module as the necessary prerequisites for key package distribution, the on-chain policy changes can be technically detected by the key management module and the trusted execution environment and affect the generation or availability of key packages; this technical binding significantly reduces the risk of "invalid on-chain revocation (access can continue off-chain)" and improves the enforceability and compliance proof capability of access control;

[0039] (2) Reduce the complexity of ciphertext storage and transmission, and improve system scalability and cost efficiency: The architecture of "single ciphertext + receiver key packet" is adopted, which stores only one copy of the resource ciphertext encrypted by the symmetric data encryption key, and generates a small key packet for each data user. This architecture reduces the storage complexity of the resource ciphertext from O(N) to O(1) (N is the number of receivers), which significantly saves storage and transmission costs in scenarios with a large number of receivers, and reduces the occupation of storage system and network bandwidth;

[0040] (3) Limit the use of keys / plaintext to a provable trusted execution environment to reduce the risk of leakage and enhance the ability to hold people accountable after the fact: By remotely verifying the trusted execution environment before distribution, limiting the plaintext processing path within the trusted execution environment, and requiring the trusted execution environment to generate a signed proof of use, combined with audit aggregation and on-chain anchoring mechanism, a closed loop of off-chain evidence and on-chain immutable anchoring is formed, so that whether decryption / use occurs in the trusted environment can be technically verified, thereby improving the efficiency of post-event responsibility attribution and evidence collection.

[0041] (4) Achieve verifiable atomic linkage between payment / escrow and key distribution, while minimizing the exposure of sensitive information on the chain: By recording only the authorization digest or identifier on the chain and triggering the event by the strategy contract, the key management module must confirm the on-chain event and receive the temporary audit receipt before it can distribute the key package. This establishes a verifiable prerequisite relationship between "paid / authorized" and "key distribution" at the technical level, and suppresses the situation of obtaining the key first and then refusing payment or paying first and then not distributing the key. At the same time, only recording the digest on the chain avoids the leakage of commercially sensitive metadata.

[0042] (5) Enhance the ability to balance audit efficiency and privacy protection: The audit aggregation module constructs Merkle root hashes in batches and puts the Merkle root hashes on the chain, which not only retains the tamper-proof audit anchors to meet compliance verification, but also saves the original sensitive audit evidence off the chain and controls it according to permissions, thereby achieving a technical balance between privacy and audit verifiability. Attached Figure Description

[0043] Figure 1 This is a flowchart illustrating an on-chain policy-driven cross-organizational data sharing method in one embodiment of the present invention. Detailed Implementation

[0044] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0045] In a first aspect, the present invention proposes an on-chain policy-driven cross-institutional data sharing system, comprising: a data user terminal, a data sharing platform, and a trust service provider; the data sharing platform includes a key management module and an audit aggregation module; the trust service provider includes a blockchain and a DID management module.

[0046] The data user sends a signed access request to the key management module; the key management module performs a preliminary verification of the access request; if the preliminary verification passes, it performs remote verification of the trusted execution environment of the data user to obtain the remote verification result; based on the preliminary verification result and the remote verification result, it generates signed audit evidence and reports the audit evidence to the audit aggregation module; the audit aggregation module stores the audit evidence in the batch aggregation queue and returns a temporary audit receipt to the key management module.

[0047] The key management module is also used to construct key packages based on preliminary verification results, remote proof verification results, temporary audit receipts, and preset resource policy constraints; sign the key packages; and send the signed key packages to the trusted execution environment of the data user through a trusted secure session. The trusted execution environment is used to unseal or use the key packages, generate a signed proof of use, and send the signed proof of use to the audit aggregation module. The audit aggregation module is also used to store the proof of use in the batch aggregation queue.

[0048] The audit aggregation module is also used to batch aggregate the queue to be aggregated, obtain the Merkle tree, calculate the Merkle root hash, write the Merkle root hash into the blockchain, generate a signed final audit receipt, and send it to the key management module and the trusted execution environment.

[0049] This invention uses on-chain authorization / revocation events, the preliminary verification results of the key management module, the remote proof verification results, the local policy verification results, and the temporary audit receipt ID returned by the audit aggregation module as essential prerequisites for key package issuance. This ensures that on-chain policy changes can be detected by the key management module and the trusted execution environment, thus affecting the generation or availability of key packages. This technical binding significantly reduces the risk of "invalid on-chain revocation (access can continue off-chain)," and improves the enforceability and compliance proof capabilities of access control.

[0050] The architecture adopts a "single ciphertext + receiver key encapsulation" approach, storing only one copy of the resource ciphertext encrypted with a symmetric data encryption key, while generating a small key packet for each data user. This architecture reduces the storage complexity of the resource ciphertext, significantly saves storage and transmission costs in scenarios with many receivers, and reduces the occupation of storage systems and network bandwidth.

[0051] By remotely verifying the trusted execution environment before distribution, limiting the plaintext processing path within the trusted execution environment, and requiring the trusted execution environment to generate a signed proof of use, combined with audit aggregation and on-chain anchoring mechanisms, a closed loop of off-chain evidence and on-chain immutable anchoring is formed. This allows for technical verification of whether decryption / use occurred within the trusted environment, improving post-event liability attribution and evidence collection efficiency.

[0052] Moreover, the audit aggregation module constructs Merkle root hashes in batches and puts them on the blockchain, which not only preserves the tamper-proof audit anchors to meet compliance verification, but also saves the original sensitive audit evidence off-chain and controls it according to permissions, thereby achieving a technical balance between privacy and audit verifiability.

[0053] It should be understood that, in this embodiment, the term Trusted Execution Environment (TEE) refers to an isolated execution environment that is policy-defined and has remote proof capabilities; it is compatible with hardware TEE but has a broader definition, such as a policy-defined Trusted Environment.

[0054] In other words, a trusted execution environment not only includes traditional hardware-isolated execution environments such as Intel SGX and ARM TrustZone, but can also be extended to refer to the set of runtime capabilities described by the platform or its agent nodes based on claims. Specifically, a trusted execution environment indicates the presence of one or more of the following environment capabilities, which are listed in verifiable claims that the platform can generate and issue, and can be verified by the key management module or a third-party remote verification service: hardware isolation capabilities, sandboxing / containerization capabilities, privacy computing capabilities, and any runtime security / trust capabilities defined by the platform and that can be proven.

[0055] The capability set of a trusted execution environment is embodied in verifiable statements issued by the operator's platform. A verifiable statement should include an identifier for each capability, a capability version / measurement (such as a mirror hash or implementation version), an issuer identifier, a timestamp, and a digital signature, enabling third parties to perform demonstrable verification of the device's capabilities upon receiving a request. This statement can be a proof reference directly issued by the hardware platform, or a verification receipt issued by a trusted software agent running on the platform after verification by its root of trust or a trusted third party.

[0056] In this embodiment, the access request includes a request ID, requester DID, resource ID, on-chain payment / authorization TXID, complete remote proof message, digest of the remote proof, access parameters, timestamp, request sequence number, requester signature, signature algorithm identifier, and the public key identifier or certificate fingerprint used by the requester for signing.

[0057] The access parameters include: usage period, intended purpose, allowed output, integer, and optional JSON.

[0058] In this embodiment, the preliminary verification includes request integrity and signature verification, DID status verification, and on-chain authorization verification. These verifications are performed sequentially. If any one of these verifications fails, the preliminary verification is deemed unsuccessful, a rejection response and a rejection record including the rejection reason are generated, and the response is reported to the audit aggregation module. The audit aggregation module stores the rejection record in the batch aggregation queue. If all verifications are successful, the preliminary verification is deemed successful, and a preliminary verification result is generated.

[0059] During the request integrity and signature verification process, the key management module is used to verify the validity of the digital signature, timestamp, and request sequence number of the request in order to check for replay or format tampering.

[0060] During the DID status verification process, the key management module initiates a DID status query to the DID management module; the DID management module returns a query receipt with a timestamp; the key management module obtains the current validity, public key matching, and revocation status of the requester's DID based on the query receipt; if the requester's DID is revoked or the public key does not match, the access request is rejected, the reason for rejection is recorded, and the audit aggregation module is notified for subsequent auditing.

[0061] During the on-chain authorization verification process, the key management module is used to query the blockchain's policy contract or resource catalog service, verify whether the on-chain payment / authorization TXID in the access request corresponds to a valid authorization, and check the authorization conditions, such as time window, purpose, authorized party DID, etc.

[0062] When any verification fails, the key management module generates a rejection response and a rejection record including the reason for rejection, and reports it to the audit aggregation module for subsequent auditing.

[0063] In this embodiment, the remote verification of the trusted execution environment includes: certificate chain and signature verification, capability item-by-item comparison and measurement value / environment fingerprint verification, independent verification of evidence citation, conditional access policy determination, and anti-replay and liveness checks.

[0064] Specifically, the access request undergoes remote authentication verification within a trusted executable environment to obtain the remote authentication verification result, which includes:

[0065] Extract the remote proof from the access request and parse the remote proof;

[0066] The parsed remote certificate is verified by certificate chain and signature; if the verification is successful, the remote certificate is then compared item by item for capability and verified by measurement value / environment fingerprint.

[0067] If the verification passes, the remote proof evidence citation will be independently verified.

[0068] If the verification passes, the system will determine whether the platform capability set of the data user meets the preset access conditions according to the preset access policy.

[0069] If the conditions are met, a replay protection and activity check will be performed; if the check passes, a remote verification result will be generated based on the results of each verification, judgment, or check.

[0070] It's important to understand that the certificate chain and signature verification process verifies whether the signature of the complete remote certification message was issued by a trusted authority, and whether the platform's certificate chain is traceable to a trusted root. If a third-party remote certification provider is used, the signature of that third-party remote certification provider and its trust relationship with the platform are verified.

[0071] During the capability comparison and measurement / environment fingerprint verification process, for each requested capability, the capability measurement value in the complete remote certification message is compared with the expected capability or minimum version requirement registered in the DID management module, capability baseline catalog or policy; capabilities that do not meet the version / expected capability conditions are considered unqualified.

[0072] In the process of independently verifying evidence cited remotely, the specific proof to which the proof of capability is cited is independently verified, such as requesting and verifying the signature of the cited evidence, and verifying the institutional signature and timestamp of the verification receipt.

[0073] During the conditional access policy determination process, the system determines whether the platform capability set meets the access conditions based on the preset access policy.

[0074] During the replay protection and liveness check process, time windows and challenge / response verification are performed on the timestamp and request sequence number declared by the data sharing platform. If necessary, online liveness verification is performed, such as initiating a real-time verification request to the platform's remote proof verification service to ensure that the declared data is generated in real time and is not old replay data.

[0075] In this embodiment, a key package is constructed based on the preliminary verification results, remote proof verification results, temporary audit receipts, and preset resource policy constraints, specifically including:

[0076] Based on the preliminary verification results, remote proof verification results, temporary audit receipts, and preset resource policy constraints, analyze whether the data user meets the conditions for obtaining the key packet; the analysis results are divided into three categories: allowed, allowed but restricted, and rejected.

[0077] If the analysis result is allowed or allowed but restricted, the symmetric data encryption key of the target shared resource corresponding to the access request is extracted from the DID management module and encrypted to obtain the key ciphertext;

[0078] Based on the key ciphertext, a key package is generated; the key package includes: key ciphertext, key package ID, target trusted execution environment ID, target public key fingerprint, validity period, usage constraints, temporary audit receipt ID (or its hash), and authorized TXID digest.

[0079] In one specific embodiment, signing the key package specifically includes: the key management module generating a digest of the key package, and signing the digest of the key package using the private key of the key management module. The signature covers the digest of the key ciphertext and all metadata of the key package, thereby technically binding the key package with on-chain authorization and audit receipt to prevent tampering.

[0080] In this embodiment, sending the signed key packet to the trusted execution environment of the data user through a trusted secure session specifically includes:

[0081] The key management module establishes a trusted secure session with the trusted execution environment of the data user. During the establishment of the trusted secure session, the key management module and the trusted execution environment verify each other's identities through two-way remote authentication and negotiate a session symmetric key based on the key exchange protocol. The session symmetric key is not written into the DID management module and is not transmitted in plaintext.

[0082] The key management module sends the signed key packet to the trusted execution environment of the data user through a trusted secure session and generates an audit log of the issued event.

[0083] The audit logs for the issued events include the request ID, key package ID, trusted secure session ID, timestamp, and signature of the key management module.

[0084] In this embodiment, the trusted execution environment is used to unseal or use the key packet to generate a signed proof of use. Specifically, the trusted execution environment uses its private key to unseal the key ciphertext to obtain the key plaintext; uses the key plaintext to perform controlled access or streaming processing on the resource ciphertext of the target shared resource; and after the entire process of streaming processing is completed or each step of controlled access is completed, the trusted execution environment generates a proof of use and signs the proof of use using its private key.

[0085] If an anomaly occurs during the distribution process or the trusted execution environment of the data user evicts the session, such as a remote proof failure or channel interruption, the key management module records the anomaly and revokes the key package according to the predicted policy. The key package is then marked as revoked and reported to the audit aggregation module.

[0086] In this embodiment, before storing audit evidence or proof of use into the batch aggregation queue, the audit aggregation module also performs integrity and format checks on the audit evidence or proof of use.

[0087] The audit aggregation module in this embodiment is also used to generate a Merkel path for each audit evidence to facilitate subsequent verification.

[0088] The audit evidence in this embodiment includes a unique identifier for the audit evidence, the associated request ID, the requester's DID, the digest hash of the remote verification, the DID status verification result, the KMS final decision and brief reasons, the encrypted object storage pointer, the evidence generation time, the signature of the evidence by the key management module, and the signature of the usage evidence by the TEE; among them, the usage proof generated by the trusted execution environment is an independent evidence item, which contains the signature of the trusted execution environment and is associated with the audit evidence through the request ID / audit receipt ID.

[0089] In this embodiment, the Merkle root hash is written into the blockchain, a signed final audit receipt is generated, and it is sent to the key management module or the trusted execution environment. Specifically, this includes:

[0090] Submit the Merkle root hash to the blockchain audit contract to obtain the on-chain transaction ID;

[0091] Once the on-chain transaction confirmation count reaches the preset number, a final audit receipt is generated, which includes the batch aggregation ID, Merkle root hash, on-chain transaction ID, on-chain confirmation count, timestamp, and signature of the audit aggregation module. This final audit receipt is then returned to the key management module or the trusted execution environment.

[0092] With this setup, the key management module is also used to write the audit receipt ID or summary in the final audit receipt into the traceability record of the corresponding key package when the final audit receipt is received, forming on-chain and off-chain binding evidence.

[0093] The preset batch aggregation strategy includes time window, number of records, or trigger conditions.

[0094] In this embodiment, the trusted execution environment will submit proof to the audit aggregation module, or send it to the audit aggregation module through the key management module, so that it can be aggregated together with the audit evidence of the key management module and anchored on the chain.

[0095] After the data user receives the key packet returned by the data sharing platform, the process also includes:

[0096] The trusted execution environment verifies the signature and metadata of the key packet; if the verification fails, it refuses to unpack the key packet and generates a signed rejection record; if the verification succeeds, it unpacks or uses the key packet.

[0097] In metadata verification, the key package ID, target trusted execution environment ID, target public key fingerprint, validity period, usage constraints, temporary audit receipt ID, and authorized TXID in the metadata are verified to ensure consistency with the identity of this device and the capability list declared by the local platform. The audit receipt ID or its hash is also verified to be consistent with the attached temporary audit receipt, and the signature of the temporary audit receipt is valid. After obtaining the final audit receipt, further audit anchoring verification can be performed using the on-chain transaction ID corresponding to the final audit receipt.

[0098] In this embodiment, the process of unsealing or using the key packet of the trusted execution environment and generating a signed proof of use specifically includes:

[0099] The trusted execution environment uses its own private key to decrypt the key ciphertext, obtain the key plaintext, and stores the key plaintext and derived key in isolated memory or protected storage in a non-exportable manner;

[0100] Use the plaintext key to perform controlled access or streaming of the encrypted resources of the target shared resource, ensuring that all plaintext processing is performed only within isolation and avoiding writing plaintext to untrusted storage or external networks; employ memory isolation or loopback processing as necessary to reduce the risk of leakage; impose restrictions on each output based on the usage restrictions in the key packet and update the usage constraints; apply digest, de-identification, or aggregation strategies to the output and calculate the output hash;

[0101] After legitimate use, that is, after all steps of streaming are completed or after each step of controlled access is completed, the trusted execution environment generates a proof of use and signs the proof of use with its private key.

[0102] The proof of use includes: request ID, authorization TXID, remote proof digest hash, output hash, execution environment capability, timestamp, usage constraints, target trusted execution environment ID, and trusted execution environment signature.

[0103] It is important to understand that the trusted execution environment in this embodiment is also used to continuously monitor policy violations and operational anomalies during the processing, such as exceeding the call frequency, abnormal memory access, or output inconsistent with the policy. If an anomaly is detected or a revocation command signed by the key management module is received, the trusted execution environment immediately stops further decryption and output, and securely destroys or zeroes the plaintext key and related session symmetric key within isolation, generates a signed anomaly proof or a signed confirmation message, and reports it to the key management module and the audit aggregation module. The signed anomaly proof or the signed confirmation message includes a destruction ID, a destruction timestamp, a trusted execution environment ID, a remote proof digest hash, and a trusted execution environment capability set identifier. After receiving the revocation confirmation from the trusted execution environment, the key management module also marks the key package as revoked and updates the status in the local and on-chain audit records for compliance traceability.

[0104] In this embodiment, any signature generated by the trusted execution environment is used... use The proof of anomaly should include a temporary audit receipt ID or remote proof digest hash for association with the audit logs and on-chain receipts of the key management module, to ensure that subsequent audits are traceable and verifiable and to prevent evidence forgery or replay.

[0105] This audit binding allows compliance personnel to use the on-chain Merkle root hash, on-chain transaction ID, and Merkle path provided by the audit aggregation module to verify the integrity and origin of any evidence of use, thereby confirming whether the decryption / use occurred in a trusted environment that meets the capability requirements and complies with on-chain authorization and policy constraints.

[0106] In addition, it should be understood that all kinds of evidence, records, proofs and other information reported to the audit aggregation module will be added to the aggregation queue.

[0107] In this embodiment, a data provider is also included. The data provider acquires the target shared resource, generates a symmetric data encryption key for the target shared resource, and encrypts the target shared resource using the symmetric data encryption key to obtain resource ciphertext. The resource ciphertext is then stored. Based on the single copy of the resource ciphertext, a resource fingerprint is generated, and the resource fingerprint or its digest is written into the blockchain. Finally, the symmetric data encryption key is sent to the DID management module of the data sharing platform. It should be understood that in this embodiment, the resource ciphertext is stored as a single copy, i.e., only one copy is stored, to save storage space.

[0108] In this embodiment, before sending an access request to the data sharing platform, the data user also confirms the target shared resource; prepares the access request based on the target shared resource; determines whether payment has been made; if not, performs on-chain authorization and payment for the target shared resource on the blockchain's strategy contract; obtains the on-chain payment / authorization TXID returned by the strategy contract and writes the on-chain payment / authorization TXID into the access request; if yes, directly writes the on-chain payment / authorization TXID into the access request and digitally signs the access request.

[0109] The key management module and the audit aggregation module are also used to monitor on-chain events. When an authorization event occurs in the strategy contract, the key management module and the audit aggregation module receive the authorization event and store the summary of the authorization event in their respective local event queues.

[0110] Before confirming the target shared resource, the data user submits a device registration application to the DID management module of the data sharing platform. The device registration application includes device information and requester identification information. The user receives the requester DID and device registration receipt returned by the DID management module of the data sharing platform. The trusted execution environment generates a public-private key pair for remote verification and a random number and corresponding logic for the session. The user associates the public key fingerprint / trusted execution environment ID and the device registration receipt in the public-private key pair, stores the association locally, and sends the public key fingerprint / trusted execution environment ID and association relationship in the public-private key pair to the DID management module of the data sharing platform.

[0111] In this embodiment, confirming the target shared resource specifically includes: searching for the target shared resource on the blockchain's resource catalog service; the search content includes the target shared resource's resource ID, resource summary, policy version, price, storage pointer, and version number; obtaining the search results returned by the resource catalog service and recording the query log, and saving the summary of the target shared resource for local verification; and verifying the resource fingerprint to confirm the required target shared resource.

[0112] In this embodiment, preparing an access request based on the target shared resource specifically includes:

[0113] Generate an access request draft: The access request draft includes: Request ID, Requestor DID, Resource ID, and Access Parameters; The Access Parameters include the usage period, purpose description, and expected output strategy.

[0114] The trusted execution environment at the data user end generates the current remote authentication message; the remote authentication message contains the necessary request sequence number to prevent replay.

[0115] Specifically, the on-chain authorization and payment for target shared resources on the blockchain strategy contract includes: submitting a purchase or authorization transaction on the strategy contract through a wallet or contract interface, along with the necessary business parameters; the business parameters include resource ID, strategy version, and authorized party DID;

[0116] After an on-chain transaction is generated, the on-chain transaction ID is returned, and the transaction enters a pending confirmation state. After the strategy contract reaches the preset number of confirmations, it writes the summary of the authorization record onto the chain and generates the authorization TXID summary.

[0117] In one embodiment, the key management module is also used to monitor or verify the authorization / payment TXID or authorization TXID associated with resources in the on-chain strategy contract; when a revocation event occurs in the strategy contract, a revocation event is triggered on-chain and a digest is written; the key management module monitors the revocation event and determines whether there are any unexpired key packages; if not, it only records the revocation time and stores it on the chain; if so, it marks the corresponding key package as revoked, updates the local state, and sends a revocation notification or issues an immediate revocation command to the trusted session; the revocation event is recorded as audit evidence and anchored on the chain in the next batch to form a verifiable revocation record.

[0118] If the data user has already used the data and generated proof of use before the revocation, the historical proof of use can still be audited and used as evidence for subsequent accountability; if it is necessary to forcibly block future use, the key management module can update the key package blacklist or reject new unblocking requests in the next session.

[0119] In this embodiment, only the authorization summary or identifier (such as the authorization TXID, the hash of the resource ID, etc.) is recorded on the chain and triggered by an event issued by the strategy contract. The key management module can only issue the key package after confirming the on-chain event and receiving the audit receipt. This establishes a verifiable prerequisite relationship between "payment / authorization" and "key issuance" at the technical level, and suppresses the situation of obtaining the key first and then refusing payment or paying first and then not issuing the key. At the same time, only recording the summary on the chain avoids the leakage of commercially sensitive metadata.

[0120] Secondly, the present invention proposes an on-chain policy-driven cross-institutional data sharing method, applied to the on-chain policy-driven cross-institutional data sharing system described in any one of the first aspects, comprising:

[0121] The data user sends a signed access request to the key management module; the key management module performs a preliminary verification of the access request; if the preliminary verification passes, it performs remote verification of the trusted execution environment of the data user to obtain the remote verification result; based on the preliminary verification result and the remote verification result, it generates signed audit evidence and reports the audit evidence to the audit aggregation module; the audit aggregation module stores the audit evidence in the batch aggregation queue and simultaneously returns a temporary audit receipt to the key management module.

[0122] The key management module constructs a key package based on the preliminary verification results, remote proof verification results, temporary audit receipts, and preset resource policy constraints. It then signs the key package and sends it to the trusted execution environment of the data user through a trusted secure session. The trusted execution environment unseals or uses the key package, generates a signed proof of use, and sends the signed proof of use to the audit aggregation module. The audit aggregation module stores the proof of use in the batch aggregation queue.

[0123] The audit aggregation module performs batch aggregation on the queue to be aggregated, obtains a Merkle tree, calculates the Merkle root hash, writes the Merkle root hash into the blockchain, generates a signed final audit receipt, and sends it to the key management module or trusted execution environment.

[0124] The present invention will now be described in conjunction with specific embodiments.

[0125] Example 1

[0126] This embodiment proposes an on-chain policy-driven cross-institutional data sharing method, including...

[0127] S1. Access Preparation and Inquiry:

[0128] S11. Requesting Identity and Device Credentials; Specifically, the data user submits a device registration application to the DID management module, providing device information (manufacturer, model, firmware version, etc.) and requester identification information; the DID management module generates the requester's DID and issues a device credential / registration receipt (including the trusted execution environment attributes and measurement value fingerprints supported by the device), saves the receipt and returns it to the data user; the DID management module saves the requester's DID and public key mapping, device attributes and whitelist measurement baselines, and generates a timestamped query receipt for subsequent verification;

[0129] S12, TEE preparation and key pair generation; specifically, the device or trusted execution environment generates a public-private key pair for remote authentication locally and prepares remote authentication capabilities; if a challenge / response is required, the trusted execution environment retains random numbers for the session and prepares response logic; the trusted execution environment associates its public key fingerprint / trusted execution environment ID with the device credentials and can record them in the DID management module and local storage;

[0130] S13, Directory Retrieval and Resource Confirmation; Specifically, the data user queries the resource directory of the blockchain to retrieve the resource ID, resource summary, policy version, price, storage pointer, and version number of the target shared resource; the resource directory returns the retrieval results and records the query log; the data user saves the resource summary for local verification; the data user verifies the resource fingerprint to confirm the required resource;

[0131] S14. Prepare the access request; specifically, the data user generates an access request draft; wherein, the access request draft includes the request ID, the requester's DID, the resource ID, and the access parameters; the data user requests the trusted execution environment to generate the current remote authentication message, and includes the necessary random number in the remote authentication message to prevent replay;

[0132] If payment has already been made, the data user writes the on-chain payment / authorization TXID into the access request draft; otherwise, prepares for the subsequent on-chain payment steps; the data user digitally signs the access request draft and prepares to submit it.

[0133] S2, On-chain Authorization and Payment:

[0134] S21. Submit on-chain purchase / authorization transaction; Specifically, the data user submits a purchase or authorization transaction on the strategy contract on the blockchain through a wallet or contract interface, along with the necessary business parameters; After the on-chain transaction is generated, the on-chain payment / authorization TXID is returned and the transaction enters a pending confirmation state;

[0135] S22. On-chain confirmation and strategy contract writing; Specifically, after the strategy contract reaches the preset number of confirmations (amount, etc.), it writes the summary of the authorization record on the chain, generating an authorization TXID summary or event;

[0136] Specifically, the strategy contract triggers on-chain events and publishes listenable event content, providing only summaries / indexes to avoid exposing sensitive metadata; the key management module and the audit aggregation module subscribe to strategy contract events, receive on-chain events, and store summaries of on-chain events in a local event queue; the key management module compares the summaries of on-chain events with the local strategy and saves the strategy metadata for subsequent verification.

[0137] S3. Request submission to the key management module and initial verification:

[0138] S31, Request Submission; Specifically, the data user submits a signed access request to the API of the key management module; wherein, the access request includes request ID, requester DID, resource ID, on-chain authorization TXID, remote proof message, access parameters, timestamp, request sequence number random number and signature;

[0139] Upon receiving an access request, the key management module returns a temporary receipt to confirm that the request has been received and records the time of request receipt.

[0140] S32. Generate and save a preliminary audit entry; specifically, the key management module generates a preliminary audit entry for the access request, recording the request source, timestamp, request summary, and current processing status; the preliminary audit entry is indexed and stored for subsequent querying and tracing.

[0141] S33, Request Integrity and Signature Verification; Specifically, the key management module verifies the validity of the digital signature, timestamp, and random number of the request, and checks for replay or format tampering; If the verification fails, the key management module generates a rejection response, records the rejection reason to the audit entry, and reports it to the audit aggregation module to record the rejection audit entry, and the process terminates; If the verification passes, proceed to S34;

[0142] S34, DID Status Verification and Query Receipt; Specifically, the key management module initiates a DID status query to the DID management module to obtain the current validity, public key matching, and revocation status of the requesting DID; the DID management module returns a query receipt with a timestamp, and the key management module includes the query receipt in the audit evidence;

[0143] Based on the query receipt, if the requester's DID is revoked or the public key does not match, the key management module rejects the access request, records and reports it to the audit aggregation module, and the process terminates; if the verification passes, proceed to S35.

[0144] S35. On-chain authorization verification: Specifically, the key management module queries the policy contract or resource catalog to verify whether the provided on-chain authorization TXID corresponds to a valid authorization, and checks the authorization conditions, such as time window, purpose, authorized party DID, etc. If the authorization verification fails, the key management module rejects the access request and reports the rejection evidence to the audit aggregation module, and the process terminates; if the authorization verification passes, a preliminary verification result is generated, and the remote proof verification step in the trusted execution environment is entered.

[0145] S4. Remote verification of proof in a trusted execution environment:

[0146] S41. Receive and parse the remote proof; specifically, the key management module extracts the complete remote proof message or remote proof digest from the access request, and parses the fields contained therein (platform certificate chain, capability measurement value, signature, timestamp, random number, etc.) and the extended capability list (each capability contains capability ID, version, measure, and evidence reference); wherein, if the remote proof is a reference digest or a digest containing only the capability, the key management module may request the original proof or proof certificate from the remote proof verification service or a third-party remote proof verification service to complete the evidence chain verification;

[0147] S42. Verify the certificate chain and signature; specifically, the key management module verifies whether the certificate chain in the remote proof was issued by a trusted root (such as a platform vendor / hardware root or an accepted remote proof verification service provider), ensuring that the proof signature is valid and has not been tampered with; verifies whether the signature timestamp of the remote proof is within an acceptable time window; if a challenge / random number is used, verifies the response to the key management module in the remote proof to issue a random number to prevent replay; if the certificate chain and signature verification fails, the remote proof verification is deemed to have failed, the access request is rejected, the key management module generates a rejection record containing the reason for the failure and reports it to the audit aggregation module or triggers a manual review process; if the certificate chain and signature pass, proceed to S43;

[0148] S43. Capability item-by-item comparison and measurement value / environment fingerprint verification; Specifically, the key management module extracts a capability list from the remote authentication and performs item-by-item comparison for the set of capabilities required for this access request; For each requested capability, the key management module compares the capability measurement value or version with the expected capability registered in the DID management module, the capability baseline catalog, or the policy. force / Version; If they do not match, the remote proof verification is deemed to have failed, the access request is rejected, the key management module generates a rejection record containing the reason for the failure and reports it to the audit aggregation module or triggers the manual review process; If they match, proceed to S44; Wherein, when the capability points to hardware evidence, it is processed according to the verification path of hardware evidence; when the capability points to software or third-party verification, it is processed according to the corresponding verification path;

[0149] S44. Independent Verification of Evidence Citations: Specifically, the key management module performs an independent verification process for each evidence citation of each requested capability, including verifying the consistency of the signature, timestamp, and platform declaration of the proof. If the proof cited by the evidence citation requires online verification, the key management module can initiate a real-time verification request to the corresponding remote proof service provider or the platform's remote proof service to obtain the latest status and revocation information. If the independent verification of a certain evidence citation for a requested capability fails, the remote proof verification is deemed to have failed, the access request is rejected, and the key management module generates a rejection record containing the reason for the failure and reports it to the audit aggregation module or triggers a manual review process. When all independent verifications of evidence citations used for all requested capabilities pass, proceed to S45.

[0150] S45. Conditional access policy determination; Specifically, based on the results of item-by-item capability comparison, evidence citation verification results and preset access policies, the key management module determines whether the device meets the conditions for obtaining the key packet. The determination result can be one of three types: allowed, allowed but restricted, or denied.

[0151] If the result is rejection, the remote verification is deemed to have failed, and the access request is rejected. The key management module generates a rejection record containing the reason for the failure and reports it to the audit aggregation module or triggers a manual review process. If the result is permission or permission but restricted, proceed to S46.

[0152] S46. Replay Protection and Activity Check: Specifically, the key management module should also perform replay protection and activity checks to verify the timestamp, random number, and possible online activity probes to ensure that the proof is generated in real time for this session and not old replay data. If the activity check fails, the remote proof verification is deemed to have failed, and the access request is rejected. The key management module generates a rejection record containing the reason for the failure and reports it to the audit aggregation module or triggers a manual review process. If the activity check passes, the remote proof verification result is generated, and then proceed to S5.

[0153] S5. Audit Evidence Generation and Reporting

[0154] S51, Audit Evidence Construction; Specifically, the key management module uses the preliminary verification results and remote proof verification results as part of the audit evidence, constructs the audit evidence of the key management module, and signs the audit evidence with the private key of the key management module;

[0155] S52. Audit evidence reporting; Specifically, the key management module submits the signed audit evidence to the audit aggregation module and records the submission transaction ID; the audit aggregation module performs integrity and format verification on the received audit evidence. If it passes, the audit evidence is stored in the aggregation queue and a temporary audit receipt containing the batch aggregation ID is returned; the key management module embeds the ID of the temporary audit receipt into the audit receipt ID field of the subsequent key package to establish off-chain-on-chain binding evidence;

[0156] S53. Reporting failure and retry strategy; Specifically, if the audit aggregation module returns a failure or network anomaly, the key management module initiates exponential backoff or a predefined retry strategy to retry and report; If the retry is successful within the set number of times, continue to the next step; If it ultimately fails, the key management module suspends the issuance of key packages according to the strategy and triggers manual intervention or an alarm.

[0157] S54. Final Audit Receipt Acquisition: Specifically, the audit aggregation module performs batch aggregation on the queue to be aggregated, obtains a Merkle tree, calculates the Merkle root hash, writes the Merkle root hash into the blockchain, generates a signed final audit receipt, and sends it to the key management module or trusted execution environment; the key management module embeds the audit receipt ID in the final audit receipt into the traceability record of the corresponding key package, forming on-chain and off-chain binding evidence;

[0158] S6. Final Decision and Key Packet Generation / Distribution:

[0159] S61, Decision Engine Summary and Judgment

[0160] Specifically, the key management module calls the policy engine to evaluate and determine whether to allow the distribution based on the preliminary verification results, remote proof verification results, temporary audit receipts, and resource policy constraints. The judgment result is divided into three types: allow, allow but restrict, and deny. If the judgment result is allow or allow but restrict, then proceed to S62; if it is deny, then the access request is denied, the key management module generates a denial record containing the reason for the failure and reports it to the audit aggregation module or triggers the manual review process.

[0161] S62. Key Packet Construction: Specifically, the key management module uses the public key from the public-private key pair pre-sent by the data user to encrypt the symmetric data encryption key, obtaining the key ciphertext; a key packet is constructed based on the key ciphertext; the metadata of the key packet is written with fields such as key packet ID, target trusted execution environment ID, target public key fingerprint, validity period, usage constraints, audit receipt ID (or its hash), and authorization TXID digest; the key management module generates a digest of the key packet and signs it with the KMS private key, the signature covering the digest of the key ciphertext and all metadata to prevent tampering;

[0162] S63. Establish a trusted secure session; specifically, the key management module and the trusted execution environment of the data user establish a trusted secure session through a secure channel; preferably, the trusted secure session uses bidirectional remote authentication to verify the identities of both parties and negotiate the session symmetric key; after the trusted secure session is established, both parties record the trusted secure session ID, session validity period, and session evidence (session signature or receipt); during the establishment of the trusted secure session, the key management module and the trusted execution environment verify the identities of both parties through bidirectional remote authentication and negotiate the session symmetric key based on the key exchange protocol; wherein, the session symmetric key is not written into the DID management module and is not transmitted in plaintext;

[0163] S64. Secure key packet distribution; Specifically, the key management module distributes the signed key packet to the trusted execution environment through the trusted secure session; and records the distribution event in the local audit log; wherein the distribution event includes the request ID, key packet ID, session ID, timestamp, and KMS signature;

[0164] S65. Handling and Rollback of Distribution Anomalies; Specifically, if an anomaly occurs during the distribution process or the TEE evicts the session, the key management module records the anomaly and revokes the key package according to the policy, marks the status of the key package as revoked, and reports it to the audit aggregation module.

[0165] S7. Trusted execution environment unsealing, processing, and usage certificate generation:

[0166] S71. Receiving and Verifying the Key Package: Specifically, after receiving the key package, the trusted execution environment first verifies the key management module's signature on the key package and checks that the key package metadata matches the identity of this device and the trusted execution environment, including the target trusted execution environment ID, target public key fingerprint, validity period, and usage constraints. The trusted execution environment also verifies the integrity and signature validity of the temporary audit receipt and checks that the temporary audit receipt ID recorded in the key package matches the attached temporary audit receipt. If the verification fails, the unsealing is rejected and a signed rejection record is generated. If the verification succeeds, proceed to S72.

[0167] S72. Decrypt the key ciphertext and grant controlled access to the resource ciphertext; specifically, the trusted execution environment uses its own private key to decrypt the key ciphertext to obtain the key plaintext; after decryption, the key plaintext and derived key should be stored in isolated memory or protected storage in a non-exportable manner; use the key plaintext to grant controlled access or stream processing to the resource ciphertext, ensuring that all plaintext processing is performed only within isolation and avoiding writing plaintext to untrusted storage or external networks; if necessary, use memory isolation or loopback processing to reduce the risk of leakage; impose restrictions on each output according to the usage constraints in the key packet and update the usage constraints; apply digest, de-identification, or aggregation strategies to the output and calculate the output hash;

[0168] S73. Generate, sign, and report proof of use; specifically, after each legitimate use, the trusted execution environment generates a proof of use; wherein, the proof of use includes at least: request ID, authorization TXID, remote proof hash, output hash, execution environment capability, timestamp, usage constraints, and target trusted execution environment ID; the proof of use is signed using its private key and a proof of use ID is generated; the signed proof of use is submitted to the audit aggregation module or forwarded through the key management module so that it can be aggregated together with the evidence from the key management module and anchored on the blockchain; wherein, for each reported proof of use, the audit aggregation module indexes it and generates a Merkel path during batch aggregation for subsequent traceability and verification;

[0169] S74. Anomaly detection, withdrawal response and evidence reporting;

[0170] The trusted execution environment continuously monitors for policy violations and operational anomalies during processing. If an anomaly is detected or a revocation command signed by the key management module is received, further decryption and output are immediately stopped. The DEK and related session symmetric keys are securely destroyed or zeroed within isolation, generating a signed destruction certificate or anomaly certificate. The destruction certificate includes a destruction ID, destruction timestamp, trusted execution environment ID, remote proof digest hash, trusted execution environment capability set identifier, and an audit receipt ID or remote proof digest hash used to associate with the key management module's audit records and on-chain receipts. This is then reported to the key management module and the audit aggregation module. Upon receiving revocation confirmation from the trusted execution environment, the key management module should mark the key package as revoked and update the status in both local and on-chain audit records for compliance traceability.

[0171] S8, Audit Aggregation;

[0172] The audit aggregation module receives audit evidence, rejection records, and proof of use of the trusted execution environment from the key management module. It performs integrity and signature verification on each piece of evidence, assigns an evidence ID, and persists the original evidence in the secure storage of the audit aggregation module, indexing it by resource ID, request ID, authorized TXID, and timestamp.

[0173] The audit aggregation module packages several pieces of evidence into batches according to a preset strategy, constructs a Merkle tree, calculates the Merkle root hash, and generates a Merkle path for each piece of evidence for subsequent verification; the Merkle root hash is submitted to the blockchain audit contract to generate an on-chain transaction ID;

[0174] Once the on-chain transaction confirmation count reaches the preset number, the audit aggregation module generates a final audit receipt containing the batch aggregation ID, Merkle root hash, on-chain transaction ID, on-chain confirmation count, timestamp, and the signature of the audit aggregation module. This final audit receipt is then returned to the key management module and the trusted execution environment. The key management module also writes the ID or digest of this final audit receipt into the blockchain, forming on-chain-off-chain binding evidence.

[0175] With this setup, compliance personnel or auditors use the on-chain Merkle root hash, on-chain transaction ID, Merkle path provided by the audit aggregation module, and original signature evidence to verify the integrity and provenance of any evidence used. In the event of a dispute or audit request, this verification process can determine whether the decryption / use occurred within a trusted environment and whether it complies with on-chain authorization and policy constraints.

[0176] The revocation process includes: if a revocation event occurs in the strategy contract, the revocation event will be triggered on the chain and a digest will be written; the key management module will listen for the revocation event, mark the corresponding key package as revoked, change the local state, and send a revocation notification or issue an immediate revocation command to the trusted session;

[0177] The audit aggregation module records revocation events as audit evidence and anchors them on the blockchain in the next batch, forming verifiable revocation records. If the data user has used the data and generated a usage certificate before revocation, the historical usage certificate can still be audited and used as evidence for post-event accountability. If it is necessary to forcibly block future use, the key management module can update the blacklist of the key package or refuse new access requests in the next session.

[0178] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. An on-chain policy-driven cross-institutional data sharing system, characterized in that, include: The system provides services for data users, data sharing platforms, and trust; the data sharing platform includes a key management module and an audit aggregation module. Trust provides services including blockchain and DID management modules; The data user sends a signed access request to the key management module; the key management module performs preliminary verification on the access request. If the preliminary verification passes, remote verification is performed on the trusted execution environment of the data user to obtain the remote verification result. Based on the preliminary verification result and the remote verification result, a signed audit evidence is generated and reported to the audit aggregation module. The audit aggregation module stores the audit evidence in the batch aggregation queue and returns a temporary audit receipt to the key management module. The key management module is also used to construct key packages based on preliminary verification results, remote proof verification results, temporary audit receipts, and preset resource policy constraints; sign the key packages; and send the signed key packages to the trusted execution environment of the data user through a trusted secure session. The trusted execution environment is used to unseal or use the key packages, generate a signed proof of use, and send the signed proof of use to the audit aggregation module. The audit aggregation module is also used to store the proof of use in the batch aggregation queue. The audit aggregation module is also used to batch aggregate the queue to be aggregated, obtain the Merkle tree, calculate the Merkle root hash, write the Merkle root hash into the blockchain, generate a signed final audit receipt, and send it to the key management module and the trusted execution environment.

2. The on-chain strategy-driven cross-institutional data sharing system according to claim 1, characterized in that, Preliminary verification includes request integrity and signature verification, DID status verification, and on-chain authorization verification; The process involves sequentially performing request integrity and signature verification, DID status verification, and on-chain authorization verification. If any verification fails, the preliminary verification is deemed to have failed, a rejection response and a rejection record including the rejection reason are generated, and the results are reported to the audit aggregation module. The audit aggregation module stores the rejection record in the batch aggregation queue. If all verifications are successful, the preliminary verification is deemed to have passed.

3. The on-chain policy-driven cross-institutional data sharing system according to claim 1, characterized in that, Remote verification includes: sequentially executed certificate chain and signature verification, capability item-by-item comparison and measurement / environment fingerprint verification, independent verification of evidence citations, conditional access policy determination, and replay protection and activity checks; If any of the verifications, checks, judgments, or checks fails, the remote proof verification is deemed unsuccessful. The key management module generates a rejection response and a rejection record including the reason for the rejection, and reports the rejection record to the audit aggregation module. If all verifications, checks, judgments, and checks are successful, the remote proof verification of the trusted execution environment is deemed successful, and the remote proof verification result is obtained.

4. The on-chain policy-driven cross-institutional data sharing system according to claim 1, characterized in that, Before storing audit evidence or proof of use into the batch aggregation queue, the audit aggregation module also performs integrity and signature verification on the audit evidence or proof of use.

5. The on-chain strategy-driven cross-institutional data sharing system according to claim 1, characterized in that, The key package is constructed based on the preliminary verification results, remote proof verification results, temporary audit receipts, and preset resource policy constraints, specifically including: Based on the preliminary verification results, remote proof verification results, temporary audit receipts, and preset resource policy constraints, analyze whether the data user meets the conditions for obtaining the key packet; the analysis results are divided into three categories: allowed, allowed but restricted, and rejected. If the analysis result is allowed or allowed but restricted, extract the symmetric data encryption key and the public key of the data user corresponding to the target shared resource from the DID management module, and encrypt it using the public key of the data user to obtain the key ciphertext. Based on the key ciphertext, a key package is generated; wherein the key package includes: key ciphertext, key package ID, target trusted execution environment ID, target public key fingerprint, validity period, usage constraints, temporary audit receipt ID or its hash, and authorized TXID digest.

6. The on-chain policy-driven cross-institutional data sharing system according to claim 1, characterized in that, The signed key packet is sent to the trusted execution environment of the data user through a trusted secure session, specifically including: The key management module establishes a trusted secure session with the trusted execution environment of the data user. During the establishment of the trusted secure session, the key management module and the trusted execution environment verify each other's identities through two-way remote authentication and negotiate a session symmetric key based on the key exchange protocol. The session symmetric key is not written into the DID management module and is not transmitted in plaintext. The key management module sends the signed key packet to the trusted execution environment of the data user through a trusted secure session and generates an audit log of the issued event; Preferably, the trusted execution environment is used to unseal or use the key packet to generate a signed proof of use, specifically including: the trusted execution environment using its private key to unseal the key ciphertext to obtain the key plaintext; using the key plaintext to perform controlled access or streaming processing on the resource ciphertext of the target shared resource; and after the entire process of streaming processing is completed or each step of controlled access is completed, the trusted execution environment generates a proof of use and signs the proof of use using its private key.

7. The on-chain policy-driven cross-institutional data sharing system according to claim 6, characterized in that, The trusted execution environment is also used for continuous monitoring of policy violations and operational anomalies. If an anomaly is detected or a revocation command signed by the key management module is received, the trusted execution environment immediately stops further decryption and output, and securely destroys or zeroes the plaintext key and related session symmetric key within isolation, generates a signed anomaly proof or a signed confirmation message, and reports it to the key management module and the audit aggregation module. The signed anomaly proof or the signed confirmation message includes the revocation ID, destruction timestamp, trusted execution environment ID, remote proof digest hash, and trusted execution environment capability set identifier. After receiving a revocation confirmation from the trusted execution environment, the key management module is also used to mark the key package as revoked and update the status in the audit logs both locally and on the blockchain.

8. The on-chain policy-driven cross-institutional data sharing system according to claim 1, characterized in that, The key management module and the audit aggregation module are also used to monitor on-chain events; When an authorization event occurs in the strategy contract, the key management module and the audit aggregation module are used to receive the authorization event and store the summary of the authorization event in their respective local event queues. When a revocation event occurs in a strategy contract, the revocation event is triggered on-chain and a summary of the revocation event is written. The key management module detects the revocation event and determines whether there are any unexpired key packets. If not, only the revocation time will be recorded and stored on the blockchain as evidence; If so, mark the corresponding key packet as revoked, update the local state, and send a revocation notification or issue an immediate revocation command to the trusted session; The reversal event is recorded as audit evidence and anchored on the blockchain in the next batch, forming a verifiable reversal record.

9. The on-chain policy-driven cross-institutional data sharing system according to claim 1, characterized in that, It also includes a data provider, which is used to acquire the target shared resource, generate a symmetric data encryption key for the target shared resource, and encrypt the target shared resource using the symmetric data encryption key to obtain the resource ciphertext; store the resource ciphertext in a single copy; generate a resource fingerprint based on the resource ciphertext, write the resource fingerprint into the blockchain, and send the symmetric data encryption key to the DID management module of the data sharing platform.

10. The on-chain policy-driven cross-institutional data sharing system according to claim 1, characterized in that, Before sending an access request to the data sharing platform, the data user also confirms the target shared resource; prepares the access request based on the target shared resource; determines whether payment has been made; if not, performs on-chain authorization and payment for the encrypted resource of the target shared resource on the blockchain's strategy contract; obtains the on-chain payment / authorization TXID returned by the strategy contract and writes the on-chain payment / authorization TXID into the access request; if yes, directly writes the on-chain payment / authorization TXID into the access request and digitally signs the access request.

11. The on-chain policy-driven cross-institutional data sharing system according to claim 9, characterized in that, Before confirming the target shared resource, the data user also submits a device registration application to the DID management module of the data sharing platform. The device registration application includes device information and requester identification information. The user receives the requester's DID and device registration receipt returned by the DID management module of the data sharing platform. The trusted execution environment generates a public-private key pair for remote proof verification and random numbers and corresponding logic for the session. The user associates the fingerprint of the public key in the public-private key pair, the trusted execution environment ID, and the device registration receipt, stores the association relationship, and sends the association relationship between the public key and the public key identity in the public-private key pair to the DID management module of the data sharing platform.

12. An on-chain policy-driven cross-institutional data sharing method, applied to the on-chain policy-driven cross-institutional data sharing system according to any one of claims 1-11, characterized in that, include: The data user sends a signed access request to the key management module; The key management module performs a preliminary verification of the access request; If the initial verification passes, remote verification is performed on the trusted execution environment of the data user to obtain the remote verification result. The key management module generates signed audit evidence based on the preliminary verification results and the remote proof verification results, and then reports the audit evidence to the audit aggregation module. The audit aggregation module stores audit evidence into the batch aggregation queue and returns a temporary audit receipt to the key management module. The key management module constructs a key package based on the preliminary verification results, remote proof verification results, temporary audit receipts and preset resource policy constraints, signs the key package, and sends the signed key package to the trusted execution environment of the data user through a trusted secure session. The trusted execution environment unblocks or uses the key package, generates a signed proof of use, and sends the signed proof of use to the audit aggregation module; The audit aggregation module will store the proof in the batch aggregation queue; The audit aggregation module performs batch aggregation on the queue to be aggregated, obtains a Merkle tree, calculates the Merkle root hash, writes the Merkle root hash into the blockchain, generates a signed final audit receipt, and sends it to the key management module and the trusted execution environment.

Images