Government affair cloud cross-department data security sharing method and device

Abstract

The invention provides a government affair cloud cross-department data security sharing method and device, and relates to the technical field of data security. The method comprises the following steps: a main chain of a block chain performs first-level verification on a requester based on a VerifyCredate contract and an access policy white list set by a department to which government affair data belongs; the access strategy is a dynamic attribute base access strategy generated by a department to which the government affair data belongs based on a dynamic attribute encryption technology; under the condition that the first-level verification is passed, generating an access credential, synchronizing the access credential to a side chain of the block chain, generating a zero-knowledge proof by the side chain according to the operation log, and initiating a zero-knowledge proof verification request to the main chain to perform second-level verification; and under the condition that the main chain passes the second-level verification, determining a cross-domain trust score between the government affair data requesting department and the department to which the government affair data belongs based on the digital certificate submitted by the requester by adopting a federal model, and performing third-level verification according to the cross-domain trust score. According to the invention, the data sharing security can be improved.

Description

Technical Field

[0001] The present invention relates to the field of data security technology, and in particular to a government cloud cross-departmental data security sharing and device. Background Art

[0002] With the deepening of digital transformation in government affairs, cross-departmental data sharing has become a core support for improving government governance effectiveness. However, traditional government cloud platforms still face many technical bottlenecks in the field of data security sharing, which restricts the release of the value of public data elements. Existing technical solutions have the following main shortcomings:

[0003] Static access control policies are rigid: The current mainstream attribute-based encryption (ABE) solution uses fixed policy templates and cannot adapt to dynamic scenarios such as epidemic emergency response and policy adjustments.

[0004] The audit traceability mechanism lacks credibility: Traditional centralized log systems have a single point of tampering risk, and cross-domain operation records are stored in a decentralized manner, making it difficult to ensure the integrity of the audit evidence chain.

[0005] Poor cross-domain trust assessment efficiency: Government departments mostly adopt a bilateral mutual recognition mechanism based on PKI. The step-by-step verification of CA certificates results in cross-provincial business authorization delays exceeding 300ms.

[0006] Weak data leakage protection measures: Existing watermarking technologies mostly rely on single frequency domain feature embedding, and the false detection rate against screenshot attacks is as high as over 15%. Summary of the Invention

[0007] The purpose of the present invention is to provide a government cloud cross-departmental data security sharing and device to improve data sharing security in response to the above-mentioned deficiencies in the existing technology.

[0008] To achieve the above objectives, the technical solutions adopted in the embodiments of the present application are as follows:

[0009] In the first aspect, an embodiment of the present application provides a method for secure cross-departmental data sharing in a government cloud, which is applied to a server, including: receiving a government data access request submitted by a requesting party; the main chain of the blockchain performs a first-level verification on the requesting party based on the VerifyCredential contract and the access policy whitelist set by the department to which the government data belongs; the access policy is a dynamic attribute-based access policy generated by the department to which the government data belongs based on dynamic attribute encryption technology; if the first-level verification passes, an access credential is generated, and the access credential is synchronized to the side chain of the blockchain, the side chain generates a zero-knowledge proof based on the operation log, and initiates a zero-knowledge proof verification request to the main chain for a second-level verification; if the main chain passes the second-level verification, a federal model is adopted to determine the cross-domain trust score between the government data requesting department and the government data department based on the digital credential submitted by the requesting party, and a third-level verification is performed based on the cross-domain trust score; if the third-level verification passes, quantum encryption technology is used to encrypt the transmitted government data packet to obtain a ciphertext, and the ciphertext is sent to the requesting party.

[0010] In one embodiment, the main chain of the blockchain performs a first-level verification on the requester based on the VerifyCredential contract and the access policy whitelist set by the department to which the government data belongs, including: the main chain of the blockchain calls the VerifyCredential contract to verify the legitimacy of the digital certificate; if the legitimacy verification passes, the checkPolicy contract is called to query the access policy whitelist set by the department to which the government data belongs, and verify whether the attribute set of the requester meets the access policy; if the access policy is met, it is determined that the first-level verification has passed.

[0011] In one embodiment, after generating the access credential, the method further includes: encrypting the access credential using a hashing technique to obtain an encrypted access credential; correspondingly, synchronizing the access credential to the side chain of the blockchain includes: synchronizing the encrypted access credential to the side chain of the blockchain.

[0012] In one embodiment, the federation model is as follows:

[0013]

[0014] Among them, TrustScore t represents the cross-domain trust score at time t; λ is the federated learning adjustment factor; W i,t is the weight of the i-th evaluation dimension at time t; Normalize(I i,t ) represents the index I i,tNormalization; FederatedAdjust t Represents the global adjustment value obtained through federated learning.

[0015] In one embodiment, after determining the cross-domain trust score between the government data requesting department and the department to which the government data belongs based on the digital certificate submitted by the requesting party, the method further includes: using a dynamic scoring algorithm to update the cross-domain trust score between different departments based on historical interaction records between different departments and the cross-domain trust score.

[0016] In one embodiment, after sending the ciphertext to the requesting party, the method further includes: for suspicious government data, extracting a three-dimensional feature fingerprint of the government data; comparing the three-dimensional feature fingerprint with the evidence stored in the blockchain, and locating the leakage path of the government data in combination with the operation log; and taking corresponding disposal measures according to the leakage path.

[0017] On the second aspect, an embodiment of the present application provides a method for secure cross-departmental data sharing in a government cloud, which is applied to the department to which the government data belongs, including: obtaining government data; annotating the government data to generate structured metadata; determining a target policy template that matches the structured metadata from a template library, and generating a dynamic attribute-based access policy in combination with the structured metadata; encrypting the dynamic attribute-based access policy, and binding the encrypted dynamic attribute-based access policy to the structured metadata.

[0018] In one embodiment, the labeling of the government data to generate structured metadata includes: using an NLP model to label the sensitivity level of the government data to obtain a government data label; generating the structured metadata based on the government data identifier, the department to which the government data belongs, the government data label, and legal binding terms.

[0019] In one embodiment, generating a dynamic attribute-based access policy includes:

[0020] Generate the dynamic attribute-based access policy according to the following formula:

[0021] C=Enc(PK,M,Policy(t,E,W))

[0022] Among them, C represents the encrypted dynamic attribute-based access policy; PK represents the system public key; M represents the plaintext government data; Policy(t,E,W) represents the dynamic policy function, which includes the time parameter t, the environmental event E, and the attribute weight W.

[0023] On the third aspect, an embodiment of the present application also provides a government cloud cross-departmental data security sharing device, including: a receiving module, configured to receive a government data access request submitted by a requesting party; a first-level verification module, configured as the main chain of the blockchain to perform a first-level verification on the requesting party based on the VerifyCredential contract and the access policy whitelist set by the government data department; the access policy is a dynamic attribute-based access policy generated by the government data department based on dynamic attribute encryption technology; the second-level verification module, configured to generate an access credential when the first-level verification passes, and synchronize the access credential to the side chain of the blockchain, the side chain generates a zero-knowledge proof based on the operation log, and initiates a zero-knowledge proof verification request to the main chain for a second-level verification; the third-level verification module, configured to adopt a federal model to determine the cross-domain trust score between the government data requesting department and the government data department based on the digital credential submitted by the requesting party when the main chain passes the second-level verification, and perform a third-level verification based on the cross-domain trust score; the data transmission module, configured to adopt quantum encryption technology to encrypt the transmitted government data packet when the third-level verification passes, obtain a ciphertext, and send the ciphertext to the requesting party.

[0024] In one embodiment, the first-level verification module is configured as follows: the main chain of the blockchain calls the VerifyCredential contract to verify the legitimacy of the digital certificate; if the legitimacy verification is passed, the checkPolicy contract is called to query the access policy whitelist set by the department to which the government data belongs, and verify whether the attribute set of the requester meets the access policy; if the access policy is met, it is determined that the first-level verification has passed.

[0025] In one embodiment, the secondary verification module is configured to: encrypt the access credential using hash technology to obtain an encrypted access credential; and transfer the encrypted access credential to the side chain of the blockchain.

[0026] In one embodiment, the federation model is as follows:

[0027]

[0028] Among them, TrustScore t represents the cross-domain trust score at time t; λ is the federated learning adjustment factor; W i,t is the weight of the i-th evaluation dimension at time t; Normalize(I i,t ) represents the index I i,t Normalization; FederatedAdjust tRepresents the global adjustment value obtained through federated learning.

[0029] In one embodiment, the three-level verification module is configured to: adopt a dynamic scoring algorithm to update the cross-domain trust score between different departments according to the historical interaction records between different departments and the cross-domain trust score.

[0030] In one embodiment, the data transmission module is configured to: extract the three-dimensional feature fingerprint of suspicious government data; compare the three-dimensional feature fingerprint with the evidence stored in the blockchain, and locate the leakage path of the government data in combination with the operation log; and adopt corresponding disposal measures according to the leakage path.

[0031] In a fourth aspect, an embodiment of the present application provides a computer device comprising: a processor, a storage medium and a bus, wherein the storage medium stores program instructions executable by the processor. When the computer device is running, the processor communicates with the storage medium through the bus, and the processor executes the program instructions to perform the steps of any one of the above methods.

[0032] In a fifth aspect, an embodiment of the present application provides a non-volatile computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of any of the above methods are executed.

[0033] The beneficial effects of this application are:

[0034] (1) Dynamic attribute-based encryption (DABE) enables millisecond-level dynamic adjustment of permissions, improving the efficiency of permission management;

[0035] (2) Through the block chain to obtain the main chain-side chain collaborative architecture, a balance between high concurrency and privacy audit is achieved, which improves privacy protection and traceability capabilities;

[0036] (3) Through the dynamic trust evaluation model of federated learning, data silos are broken and collaboration efficiency is improved;

[0037] (4) Through three-dimensional feature fingerprint technology, full-dimensional leakage protection is achieved, improving the ability to resist attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0039] Figure 1 A flowchart of a method for securely sharing data across government departments in a government cloud provided in an embodiment of the present application;

[0040] Figure 2 A flowchart of a method for securely sharing data across government departments in a government cloud provided in an embodiment of the present application;

[0041] Figure 3 A flowchart of a method for securely sharing data across government departments in a government cloud provided in an embodiment of the present application;

[0042] Figure 4 A flowchart of a method for securely sharing data across government departments in a government cloud provided in an embodiment of the present application;

[0043] Figure 5 A flowchart of a method for securely sharing data across government departments in a government cloud provided in an embodiment of the present application;

[0044] Figure 6 A flowchart of a method for securely sharing data across government departments in a government cloud provided in an embodiment of the present application;

[0045] Figure 7 A schematic diagram of the structure of a device for securely sharing data across government departments in a government cloud according to an embodiment of the present application;

[0046] Figure 8 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments.

[0048] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for protection, but merely represents selected embodiments of the present application. All other embodiments obtained by persons of ordinary skill in the art based on the embodiments in the present application without creative work are within the scope of protection of the present application.

[0049] In the description of this application, it should be noted that if the terms "upper", "lower", etc. appear, the orientation or position relationship indicated is based on the orientation or position relationship shown in the accompanying drawings, or is the orientation or position relationship in which the product of the application is usually placed when in use. It is only for the convenience of describing this application and simplifying the description, and does not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, it cannot be understood as a limitation on this application.

[0050] In addition, the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the government data used in this way can be interchanged where appropriate so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0051] It should be noted that, in the absence of conflict, the features in the embodiments of this application can be combined with each other.

[0052] Figure 1 A flowchart of a method for securely sharing data across government departments in a government cloud provided in an embodiment of the present application; Figure 1 As shown, the method is applied to the server, and the method includes the following steps 110 to 150:

[0053] Step 110: Receive the government data access request submitted by the requesting party.

[0054] The requesting party is the user, company, unit, organization, institution, etc. who requests access to the data, such as: XX Provincial Medical Insurance Bureau, individual.

[0055] In actual operations, government data access requests are generally structured requests.

[0056] Step 120: The main chain of the blockchain performs a first-level verification on the requester based on the VerifyCredential contract and the access policy whitelist set by the department to which the government data belongs.

[0057] Among them, the access strategy is a dynamic attribute-based access strategy generated by the department to which the government data belongs based on dynamic attribute encryption technology.

[0058] The VerifyCredential contract is mainly used to verify the legitimacy of the digital certificate submitted by the requester, and the access policy whitelist is mainly used to verify the correctness of the access policy.

[0059] Attribute-based encryption (ABE) is an encryption technology that controls data access based on user attributes, such as identity, role, and permissions. Unlike traditional key-based encryption, ABE not only relies on encryption and decryption keys but also ties access permissions to user attributes, enabling fine-grained access control.

[0060] Dynamic Attribute-Based Encryption (DABE) is an innovative solution based on traditional attribute encryption (ABE). By introducing a dynamic policy adjustment mechanism, multi-dimensional attribute weights, and real-time environment perception capabilities, it significantly improves the flexibility and security of government cloud data sharing.

[0061] Specifically, such as Figure 2 As shown, the above step 120 may further include the following steps 210 to 230:

[0062] Step 210: The main chain of the blockchain calls the VerifyCredential contract to verify the legitimacy of the digital certificate.

[0063] In blockchain and smart contract development, the VerifyCredential contract is commonly used to verify the authenticity and validity of digital credentials. This type of contract is commonly used in scenarios such as identity verification, academic certification, and professional qualification certification. The VerifyCredential contract uses the SM9 algorithm, a national encryption algorithm, to verify signature validity and check whether the digital credential was issued by a federal CA.

[0064] A digital certificate, also known as a digital certificate or digital ID, is an electronic authentication tool used to prove a user's identity and access rights to network resources. Typically issued by a CA (certification authority), it contains basic user information, a public key, and the issuing authority's signature.

[0065] Step 220: If the legitimacy verification is passed, call the checkPolicy contract to query the access policy whitelist set by the department to which the government data belongs, and verify whether the attribute set of the requester meets the access policy.

[0066] The checkPolicy contract is a common contract function used to check whether certain conditions are met before executing a transaction. This function is often used in access control policies, transaction restrictions, and other scenarios that require pre-verification.

[0067] In actual operation, if the attribute set of the requester satisfies the access policy, the authentication is passed; otherwise, the authentication fails.

[0068] Step 230: If the access policy is met, determine that the first-level verification is passed.

[0069] Among them, in steps 210 to 230, the main chain verifies the digital identity (digital certificate) of the requester and the attribute set in the submitted government data access request in turn. Only when both are verified, the first-level verification performed by the main chain is passed.

[0070] Step 130: If the first-level verification is passed, an access credential is generated and synchronized to the side chain of the blockchain. The side chain generates a zero-knowledge proof based on the operation log and initiates a zero-knowledge proof verification request to the main chain for secondary verification.

[0071] Access credentials are used to prove a user's identity and are typically required to access specific services or resources. Access credentials can be secret information used for identity authentication and authorization, ensuring that users have access to specific data or services. For example, in Alibaba Cloud services, access credentials are key information used to verify a customer's identity through verification, a process known as identity authentication. On the Feishu Open Platform, access credentials (access_token) are used to authenticate the caller's identity, ensuring that the application has permission to access and operate specific data resources.

[0072] The operation log recording process is as follows: First, log generation: when data access occurs, the system captures the operation metadata; second, layered encryption processing: sensitive fields use the SM4 algorithm to encrypt operation details, and key management adopts the Shamir threshold scheme (3 / 5 sharding); generate a verifiable fingerprint; third, zero-knowledge proof binding: generate a zk-SNARK proof of the legality of the operation; proof generation: the sidechain node uses this circuit to generate the proof, which takes about 350ms (8-core CPU); finally, log on-chain storage: the encrypted log and proof are packaged and stored in the sidechain block.

[0073] Exemplarily, the access credential is: token=keccak256(requestId+nonce).

[0074] Zero-Knowledge Proof (ZKP) is a cryptographic protocol that allows a prover to prove to a verifier that a statement or proposition is true without revealing any additional information related to the statement. In other words, the prover can prove that they know a secret without revealing the secret itself.

[0075] Zero-knowledge proof is mainly used for auditing, and when the audit is triggered, the side chain starts working.

[0076] For example, first, the audit trigger

[0077] Example scenario: A regulatory agency needs to audit whether the Medical Insurance Bureau of Province A exceeded its authority to access medical data in City B on October 1, 2023.

[0078] Input conditions:

[0079] Audit object: {Department: A Province Medical Insurance Bureau, Time range: 2023-10-01, Data identifier: B City Medical Insurance Dataset X};

[0080] Privacy requirements: The specific operation records of the department cannot be directly obtained;

[0081] Second, zero-knowledge proof generation (side chain)

[0082] Build Proof Statement:

[0083] "On October 1, 2023, there was at least one record of the Medical Insurance Bureau of Province A legally accessing Medical Insurance Dataset X in City B."

[0084] Generate zk-SNARK proof:

[0085] Private parameters: specific operation records on the side chain (confidential);

[0086] Public output: only returns isValid = 1 (legal) or 0 (illegal);

[0087] Again, cross-chain verification request

[0088] The side chain calls the main chain verification contract:

[0089] Input: zk-SNARK proof + public hash (such as time range hash);

[0090] Output: Boolean value (whether verification passed);

[0091] Finally, the verification result feedback

[0092] The main chain returns the verification result:

[0093] If approved: Only inform that "legal records exist" without disclosing specific log details;

[0094] If failed: return error type (e.g. "invalid credentials" or "certificate does not match");

[0095] The side chain records the audit conclusions.

[0096] The blockchain dual-chain division of labor model constructed in this application is specifically shown in Table 1 below:

[0097]

[0098] Table 1

[0099] The side chain architecture is shown in Table 2 below:

[0100]

[0101] Table 2

[0102] Among them, the improved PBFT can be optimized through the following process: first, pre-selection of the verification group: dynamically selecting 4 consensus nodes based on department weights; second, batch verification: packaging multiple requests into blocks for parallel verification; finally, a fast challenge mechanism: abnormal nodes can be replaced within 1 block cycle.

[0103] By designing a zk-SNARK circuit, during verification, the prover knows the correct (token, nonce) but does not need to expose the plaintext. The verifier only obtains a Boolean result of valid = 1.

[0104] The data of the main chain and the side chain are kept synchronized through the cross-chain relay bridge.

[0105] In actual operation, when an anomaly is detected, the side chain's token cancellation contract can be triggered.

[0106] Example,Scenario: Cross-provincial medical insurance reimbursement data verification

[0107] 1. Request submission:

[0108] The Medical Insurance Bureau of Province A applied to retrieve the medical records of a patient in City B;

[0109] 2. Main chain verification:

[0110] Verify the validity of the SM9 certificate (call verifyCredential);

[0111] Check whether the current policy allows "inter-provincial medical insurance" usage (DABE policy matching);

[0112] 3. Sidechain records:

[0113] Generate a log entry with a zk-SNARK proof;

[0114] Record operation details: access time, data item hash, device fingerprint;

[0115] 4. Exception handling:

[0116] If the Health Commission of City B detects that the data is being spread abnormally:

[0117] Trigger emergencyRevoke to revoke the Token;

[0118] Automatically freeze the subsequent access rights of the Medical Insurance Bureau of Province A.

[0119] In actual operation, after the access credentials are generated, the access credentials may be encrypted to improve the security of the access credentials. Specifically, after the "generating access credentials" in the above step 130, the government cloud cross-departmental data security sharing method provided in the embodiment of the present application may further include the following steps:

[0120] The access credentials are encrypted using hash technology to obtain encrypted access credentials.

[0121] Hashing technology is a technique that converts input data of any length into a fixed-length output through a specific algorithm. This output is usually called a hash value or hash code.

[0122] Correspondingly, the step of “synchronizing the access credentials to the side chain of the blockchain” in step 130 may further include the following steps:

[0123] The encrypted access credentials are transferred to the side chain of the blockchain.

[0124] The dual-chain division of labor model adopted in this application can achieve the following advantages:

[0125] (1) Balancing privacy and compliance

[0126] Minimize information disclosure: Traditional auditing methods require complete operation logs, while this application only returns a "yes / no" conclusion. Traditional auditing methods may expose user IP addresses and device fingerprints, while this application can protect all details with zero knowledge.

[0127] Legal compliance: Comply with the "minimum necessary principle" requirements of the Personal Information Protection Law;

[0128] (2) Cross-chain trusted verification

[0129] Anti-counterfeiting verification: cryptographic proof is used to ensure the authenticity of the side chain log and the main chain certificate;

[0130] Anti-collusion attack: Even if the side chain nodes collude with the main chain nodes, they cannot forge valid proofs;

[0131] (3) Performance optimization

[0132] Offline proof generation: The sidechain can generate proofs in batches in advance to avoid real-time verification delays;

[0133] Lightweight verification: It only takes about 10ms for the main chain to verify a single proof.

[0134] In addition, this application adopts a main chain-side chain collaborative architecture to achieve a balance between high concurrency and privacy auditing. The dual-chain collaborative auditing makes a double breakthrough in privacy protection and traceability. Specifically, in terms of performance optimization, the main chain adopts an improved PBFT consensus with a throughput ≥ 4500TPS, which is 3 times higher than the single-chain solution, meeting the 100,000-level concurrency requirements of the provincial government cloud. In terms of zero-knowledge auditing, the side chain implements privacy protection auditing through zk-SNARKs. The verification process does not leak the plaintext log, and the audit report generation time is less than 3 seconds, which complies with the GDPR minimum necessary principle. In terms of full-link trust, the operation log is encrypted and stored in shards. Combined with three-dimensional data fingerprints, the traceability positioning accuracy reaches 100%, and the average handling time of leakage incidents is shortened to within 2 hours.

[0135] Step 140: When the main chain passes the secondary verification, a federal model is adopted to determine the cross-domain trust score between the government data requesting department and the government data-owning department based on the digital certificate submitted by the requesting party, and a third-level verification is performed based on the cross-domain trust score.

[0136] Among them, the federated model is a model based on Federated Learning technology, which aims to solve the problem of multiple data owners collaborating without exchanging data while protecting data privacy and security.

[0137] Federated learning is a distributed machine learning technology that allows multiple devices to jointly train models without sharing raw data. Traditional federated learning methods, such as the Federated Averaging algorithm (FedAvg), typically assume that all participants use the same model architecture. However, in practice, the computing power, memory, and network conditions of edge devices vary greatly, making it impractical to require all devices to train a single, large model.

[0138] For example, the federation model in this step is shown in the following formula (1):

[0139]

[0140] Among them, TrustScore t represents the cross-domain trust score at time t; λ is the federated learning adjustment factor; W i,t is the weight of the i-th evaluation dimension at time t, reflecting the importance of this dimension to the overall trust score; Normalize(I i,t ) represents the index I i,t Normalization; FederatedAdjust t It represents the global adjustment value obtained through federated learning, reflecting the collaborative evaluation of this department by other departments.

[0141] After determining the cross-domain trust score between the government data requesting department and the government data-owning department based on the digital credentials submitted by the requester, the cross-domain trust score may be compared with a preset threshold to determine whether verification has been passed. Specifically, the "three-level verification based on the cross-domain trust score" in step 140 may further include the following steps:

[0142] Determine whether the cross-domain trust score is greater than a preset threshold, and if the cross-domain trust score is greater than the preset threshold, determine that the third-level verification is passed.

[0143] The preset threshold value may be set based on experience or by consulting literature, and is not limited here.

[0144] After determining the cross-domain trust score, the cross-domain trust score can be updated based on the cross-domain trust score and other indicators to achieve dynamic trust evaluation. Specifically, after the above step 140, the cross-departmental data security sharing method provided by the embodiment of the present application can further include the following steps:

[0145] Update the cross-domain trust scores between different departments based on the historical interaction records and cross-domain trust scores between different departments.

[0146] Among them, dynamic trust assessment is the core mechanism in cross-departmental data sharing in the government cloud. By analyzing multi-dimensional data in real time, it dynamically adjusts the trust level between departments to ensure that access control strategies are adaptively optimized as the environment changes.

[0147] Historical interaction records include evaluation dimension indicators; evaluation dimensions may include: historical compliance, security protection capabilities, business reliability, and interaction reputation; for example: historical compliance indicators include the number of illegal accesses and policy compliance rate; security protection capability indicators include security vulnerability repair timeliness and security rating; business reliability indicators include service availability (SLA) and response delay; interaction reputation indicators include cross-departmental collaboration success rate and complaint rate.

[0148] In actual operation, the weights of different evaluation dimensions can be dynamically adjusted according to the different evaluation dimension indicators recorded in the historical interaction records, thereby dynamically adjusting the cross-domain trust score and updating the cross-domain trust score.

[0149] In actual operation, before performing this step 140, a federated model needs to be built first; specifically, the federated model can be built through the following process: first, each department trains a local trust assessment model based on its own government data; the input data is a multi-dimensional assessment dimension indicator, and the output data is a cross-domain trust score; second, Paillier homomorphic encryption is used for gradient aggregation; finally, the federated server calculates the weighted average.

[0150] In actual operation, after obtaining the cross-domain trust score, the trust level can be graded, as shown in Table 3 below:

[0151]

[0152] Table 3

[0153] This application uses a dynamic trust assessment model based on federated learning, which breaks down data silos, realizes cross-domain trust intelligent assessment, and improves collaboration efficiency. Specifically, in terms of real-time assessment, through event-driven updates and LSTM time series prediction, the trust score update delay is less than 2 seconds, which is 4 orders of magnitude faster than the traditional quarterly assessment. In terms of global collaborative optimization, the federated aggregation algorithm integrates feedback data from multiple departments while protecting privacy, and the cross-domain authentication time is reduced to less than 150ms, which is 50% more efficient than the traditional PKI system.

[0154] Step 150: When the third-level verification is passed, quantum encryption technology is used to encrypt the transmitted government data packet to obtain the ciphertext, and the ciphertext is sent to the requesting party.

[0155] Quantum cryptography utilizes the principles of quantum mechanics to encrypt information. Its core concept is to leverage the unpredictability and non-cloning properties of quantum states to ensure information security. Specifically, quantum cryptography relies on the quantum properties of photons, leveraging the unpredictability of quantum states to achieve secure information exchange, making it unbreakable even by eavesdroppers.

[0156] In actual operation, this step can be achieved through the following process: first, establish a quantum channel and generate a one-time key based on the BB84 protocol; second, use the above-mentioned one-time key to encrypt and transmit the data packet (i.e., the above-mentioned government data packet); illustratively, the ciphertext is AES256 (QKD_key, plaintext government data).

[0157] Furthermore, data usage tracking and leakage tracing can be achieved by embedding data fingerprints; specifically, Figure 3 As shown, after the above step 150, the government cloud cross-departmental data security sharing method provided by the embodiment of the present application may further include the following steps 310 to 330:

[0158] Step 310: For suspicious government data, extract the three-dimensional feature fingerprint of the government data.

[0159] Among them, the three-dimensional fingerprint features can be obtained according to the three-dimensional fingerprint generation algorithm; the three-dimensional fingerprint generation algorithm generates a data fingerprint with strong robustness and anti-attack capabilities by fusing information of three dimensions: spatial features, timestamp chain and semantic vector; specifically, it can be obtained through the following process: first, spatial feature extraction (anti-screenshot / geometric transformation attack), spatial feature extraction includes image / video data, image / video data includes grayscale processing: converting color images into grayscale images to reduce computational complexity; frequency domain transformation: performing discrete Fourier transform (DFT) on the grayscale image to extract frequency domain features; feature enhancement: taking the logarithm of the frequency domain results and normalizing them, amplifying high-frequency details (such as edges, textures), so that they are invariant to geometric transformations such as rotation and scaling; also includes text / structured data, text / structured data includes block hashing: dividing the data into 64-byte blocks, and calculating the hash value (such as SHA-256) block by block; hash chain construction: splicing the hash values in sequence to form a hash chain. Tampering with any data block will cause all subsequent hash values to change, thereby locating the tampering; secondly, timestamp chain generation (anti-copying / forgery attacks), timestamp chain generation includes timestamp generation: obtaining a high-precision timestamp (millisecond level) combined with a random number to ensure uniqueness; hash chain calculation: using a collision-resistant hash algorithm (such as SHA3-256) to generate a hash chain, each timestamp chain is bound to the transaction on the blockchain to ensure that a legal sequence cannot be forged by reversing time; thirdly, semantic vector embedding (anti-content tampering attacks), semantic vector embedding includes text semantic extraction: using a pre-trained language model (such as BERT) to convert text data into a high-dimensional semantic vector; structured data processing: extracting schema features from structured data such as database fields and JSON key-value pairs; sensitivity detection: comparing the cosine similarity of the semantic vectors of the original data and the data to be tested. If the similarity is lower than the threshold (such as 0.95), it is determined to be content tampering; finally, the above three types of features are spliced into a three-dimensional feature fingerprint.

[0160] Step 320: Compare the three-dimensional feature fingerprint with the evidence stored in the blockchain, and locate the leakage path of the government data in combination with the operation log.

[0161] For example, fingerprint extraction includes the frequency domain features and semantic vectors of leaked data. Blockchain query matches the data ID 0x89a3fe..., which belongs to the 2023 census dataset of the Ministry of Civil Affairs. Log analysis concludes that an outsourcing company performed an abnormal export operation within 3 hours of data access. The leakage path can be located as the outsourced personnel illegally exported the data to their personal devices.

[0162] Step 330: Take corresponding disposal measures according to the leakage path.

[0163] Different measures can be taken to adjust the requester's access rights based on the different leakage paths. For example, if suspected census data appears on a social platform and the source is traced back to an outsourced employee illegally exporting the data to a personal device, the corresponding measures might include automatically freezing the outsourcing company's permissions and generating a forensic evidence report.

[0164] This application adopts innovative three-dimensional feature fingerprint technology to achieve full-dimensional leakage protection and multi-modal fingerprint protection, and the anti-attack capability has been comprehensively upgraded; specifically, in terms of anti-geometric attacks, the false detection rate of frequency domain features for rotation / scaling attacks is less than 0.5%, which is 30 times more robust than traditional watermarking schemes; in terms of precise tampering positioning, the hash chain block design can locate data tampering areas of ≤64B, and the positioning accuracy is improved by 98% compared with the single hash scheme; in terms of intelligent linkage disposal, permission freezing and data self-destruction are automatically triggered after the leakage is detected, the response delay is less than 200ms, and the disposal completeness rate reaches 98%.

[0165] After introducing the cross-departmental data security sharing method for government cloud applied to the server side of the exemplary embodiment of the present disclosure, the following is a reference to Figure 4 The present invention describes a method for securely sharing data across government departments in a government cloud according to an exemplary embodiment of the present invention, which is applied to departments to which government data belongs.

[0166] Figure 4 A flowchart of a method for securely sharing data across government departments in a government cloud provided in an embodiment of the present application; Figure 1 As shown, the method is applied to the department to which the government data belongs, and the method includes the following steps 410 to 440:

[0167] Step 410: Obtain government data.

[0168] Among them, government data is data collected on the client side by the department to which the government data belongs; for example: medical records and social security information.

[0169] Step 420: Label the government data and generate structured metadata.

[0170] Among them, the labeling mainly marks the sensitivity level of the data to assist in setting dynamic attribute-based access policies more accurately when subsequently requesting access to the data; specifically, Figure 5 As shown, the above step 420 may further include the following steps 510 and 520:

[0171] Step 510: Use the NLP model to label the sensitivity level of the government data to obtain a government data label.

[0172] Among them, this step can use the NLP model to label the sensitivity level of government data based on the requirements of the "Data Security Law", for example: L1 to L4.

[0173] Step 520: Generate structured metadata based on the government data identifier, the department to which the government data belongs, the government data label, and the legal binding clauses.

[0174] Exemplarily, the generated structured metadata is: {data ID, department, sensitivity level, legal constraints}.

[0175] Step 430: Determine a target policy template that matches the structured metadata from the template library, and generate a dynamic attribute-based access policy in combination with the structured metadata.

[0176] A policy template library can be created by pre-setting policy templates that comply with the Data Security Law and the Personal Information Protection Law. Generally, the policy template library can be described using a JSON-LD structure. Furthermore, it can include built-in mappings between clauses in the Data Security Law and the Personal Information Protection Law. Furthermore, the template library can support custom logical operators (e.g., AND / OR / NOT).

[0177] The policy types of dynamic attribute-based access policies may include: department attribute policy, time constraint policy, and operation type policy; among them, department attribute policy may be obtained based on department affiliation (for example: Medical Insurance Bureau of Province A) and department weight classification (for example: provincial department > municipal department); time constraint policy may be obtained based on absolute time (for example: 2024-01-01 to 2024-12-31) and relative time (for example: valid for 7 days); operation type policy may be obtained based on read-write permission separation (for example: action = read or action = write) and export restriction (for example: export = disabled).

[0178] This step generally requires injecting dynamic parameters when generating a dynamic attribute-based access policy; specifically, Figure 6 As shown, the above step 430 may further include the following steps 610 and 620:

[0179] Step 610: Determine a target policy template that matches the structured metadata from the template library.

[0180] In this step, the template library can be queried based on the information in the structured metadata (such as data ID, department, sensitivity level, and legal constraints) to determine the target policy template that matches it.

[0181] Step 620: Inject dynamic parameters into the target policy template, and use the target policy template to generate a dynamic attribute-based access policy based on the structured metadata.

[0182] Dynamic parameters are primarily used to form a corresponding dynamic adjustment mechanism to adjust access policies and ultimately form a dynamic attribute-based access policy. Specifically, a time-aware adjustment mechanism can be generated based on the event parameters in the dynamic parameters, or an event-response adjustment mechanism can be generated based on the event parameters. The time-aware adjustment mechanism binds the policy validity period to the real-time clock (RTC), automatically expiring upon expiration. The event-response adjustment mechanism monitors external events (e.g., a government announcement lifting an emergency state) through blockchain smart contracts.

[0183] Dynamic attribute-based access policies can be updated based on events (e.g., automatically triggering policy expiration upon the end of an epidemic emergency) or machine learning-assisted updates (i.e., optimizing policy logs based on historical access logs, such as dynamically adjusting validity periods). Event-driven updates (event response) and machine learning-assisted updates (time perception) are the dynamic parameters mentioned above.

[0184] For example, a dynamic attribute-based access policy may be generated according to the following formula (2):

[0185] C=Enc(PK,M,Policy(t,E,W)) (2)

[0186] Among them, C represents the encrypted dynamic attribute-based access policy; PK represents the system public key; M represents the plaintext government data; Policy(t,E,W) represents the dynamic policy function, which includes the time parameter t, the environmental event E, and the attribute weight W.

[0187] In this step, the government data department generates a key and publishes the public key on the blockchain. The requester's private key is bound to its attribute set. When the key is updated, proxy encryption is used to achieve seamless key rotation. The data requester can only access the data if its attribute set satisfies S = Policy.

[0188] Dynamic attribute-based access policies can be described using JSON-LD structured descriptions.

[0189] For example, in the emergency sharing scenario of epidemic data, the generated dynamic attribute-based access policy is: (department = National Health Commission AND purpose = epidemic investigation) OR (emergency status = TRUE), and the corresponding dynamic adjustment mechanism is: automatically revoke all related permissions when the emergency status ends; in the cross-provincial social security verification scenario, the generated dynamic attribute-based access policy is: provincial department AND time <30 days AND export prohibited, and the corresponding dynamic adjustment mechanism is: dynamically shorten the validity period according to the frequency of access; in the census data open scenario, the generated dynamic attribute-based access policy is: desensitized data AND limited to statistical model calls; the corresponding dynamic adjustment mechanism is: immediately block access when a model decompilation attempt is detected.

[0190] In actual operation, this step can also be designed as a programmable template library to support the automatic generation of dynamic attribute-based access policies in accordance with the requirements of the Data Security Law.

[0191] The dynamic attribute-based access policy generated by dynamic attribute-based encryption adopted in this application can realize the real-time evolution of encryption policy due to the addition of dynamic policy and environment perception on the basis of traditional attribute-based encryption. In addition, an event-driven policy engine is built based on dynamic attribute-based encryption (DABE) to achieve millisecond-level dynamic adjustment of permissions, precise control of dynamic policies, and improved permission management efficiency; among them, in terms of policy generation efficiency, through programmable template library and machine learning optimization, the policy generation delay is ≤50ms, which is 36 times more efficient than traditional manual configuration (average time of 30 minutes); in terms of automatic permission recovery, when the epidemic emergency state is lifted or the data expires, the smart contract automatically triggers the policy to expire, eliminating the risk of residual permissions, and the policy update response time is less than 5 seconds; in terms of legal compliance, a "Data Security Law" clause mapping module is built in, the policy compliance self-inspection coverage rate is 100%, and the accuracy rate of identifying illegal policies is ≥99.7%.

[0192] Step 440: Encrypt the dynamic attribute-based access policy and bind the encrypted dynamic attribute-based access policy to the structured metadata.

[0193] Among them, encryption can improve the security of dynamic attribute-based access strategy;

[0194] In actual operation, after encrypting the dynamic attribute-based access policy, the hash value of the dynamic attribute-based access policy can be stored on the chain.

[0195] Since this application uses a multi-CA federated verification model for federated learning cross-domain identity authentication, policy changes need to be jointly signed by multiple departments (i.e. based on threshold signatures).

[0196] After introducing the cross-departmental data security sharing method of the government cloud applied to the government data department in the exemplary embodiment of the present disclosure, next, refer to Figure 7 The government cloud cross-departmental data security sharing device 700 according to an exemplary embodiment of the present disclosure is described.

[0197] refer to Figure 7 The government cloud cross-departmental data security sharing device 700 includes: a receiving module 710, configured to receive a government data access request submitted by a requester; a first-level verification module 720, configured to perform a first-level verification on the requester based on the VerifyCredential contract and the access policy whitelist set by the government data department on the main chain of the blockchain; the access policy is a dynamic attribute-based access policy generated by the government data department based on dynamic attribute encryption technology; a second-level verification module 730, configured to generate an access credential when the first-level verification passes, and synchronize the access credential to the side chain of the blockchain, the side chain generates a zero-knowledge proof based on the operation log, and initiates a zero-knowledge proof verification request to the main chain for a second-level verification; a third-level verification module 740, configured to adopt a federated model to determine the cross-domain trust score between the government data requesting department and the government data department based on the digital credential submitted by the requester, and perform a third-level verification based on the cross-domain trust score; a data transmission module 750, configured to adopt quantum encryption technology to encrypt the transmitted government data packet when the third-level verification passes, obtain a ciphertext, and send the ciphertext to the requester.

[0198] In one embodiment, the first-level verification module 720 is configured as follows: the main chain of the blockchain calls the VerifyCredential contract to verify the legitimacy of the digital certificate; if the legitimacy verification is passed, the checkPolicy contract is called to query the access policy whitelist set by the department to which the government data belongs, and verify whether the attribute set of the requester meets the access policy; if the access policy is met, it is determined that the first-level verification has passed.

[0199] In one embodiment, the secondary verification module 730 is configured to: encrypt the access credential using hash technology to obtain an encrypted access credential; and transfer the encrypted access credential to the side chain of the blockchain.

[0200] In one implementation, the federation model is as follows:

[0201]

[0202] Among them, TrustScore t represents the cross-domain trust score at time t; λ is the federated learning adjustment factor; W i,tis the weight of the i-th evaluation dimension at time t; Normalize(I i,t ) represents the index I i,t Normalization; FederatedAdjust t Represents the global adjustment value obtained through federated learning.

[0203] In one embodiment, the third-level verification module 740 is configured to: adopt a dynamic scoring algorithm to update the cross-domain trust score between different departments based on the historical interaction records and cross-domain trust scores between different departments.

[0204] In one embodiment, the data transmission module 750 is configured to: extract the three-dimensional feature fingerprint of suspicious government data; compare the three-dimensional feature fingerprint with the evidence stored in the blockchain, and locate the leakage path of the government data in combination with the operation log; and adopt corresponding disposal measures according to the leakage path.

[0205] The above-mentioned device is used to execute the method provided in the above-mentioned embodiment. Its implementation principle and technical effect are similar and will not be repeated here.

[0206] The above modules can be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), one or more microprocessors, or one or more field programmable gate arrays (FPGAs). For another example, when a module is implemented by scheduling program code through a processing element, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call program code. For another example, these modules can be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0207] Figure 8 A schematic diagram of a computer device provided in an embodiment of the present application. The device can be integrated into a terminal device or a chip of a terminal device. The terminal can be a computing device with government data processing capabilities.

[0208] The device includes: a processor 801 , a storage medium 802 and a bus 803 .

[0209] The storage medium 802 stores program instructions executable by the processor 801. When the computer device 800 is running, the processor 801 communicates with the storage medium 802 via the bus 803. The processor 801 executes the program instructions to perform the above method embodiment. The specific implementation methods and technical effects are similar and will not be repeated here.

[0210] Optionally, the present invention further provides a program product, such as a computer-readable storage medium, comprising a program, which is used to perform the above method embodiment when executed by a processor.

[0211] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0213] In addition, the functional units in various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or hardware plus software functional units.

[0214] The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor (English: processor) to perform some steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: a USB flash drive, a mobile hard disk, a read-only memory (English: Read-Only Memory, abbreviated: ROM), a random access memory (English: Random Access Memory, abbreviated: RAM), a magnetic disk or an optical disk, and other media that can store program code.

[0215] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A method for securely sharing data across government departments in a government cloud, applied to a server, characterized in that: include: Receive government data access requests submitted by requesting parties; The main chain of the blockchain performs a first-level verification on the requester based on the VerifyCredential contract and the access policy whitelist set by the government data department; the access policy is a dynamic attribute-based access policy generated by the government data department based on dynamic attribute encryption technology; If the primary verification passes, an access credential is generated and synchronized to the side chain of the blockchain. The side chain generates a zero-knowledge proof based on the operation log and initiates a zero-knowledge proof verification request to the main chain for secondary verification. If the main chain passes the secondary verification, a federated model is adopted to determine the cross-domain trust score between the government data requesting department and the department to which the government data belongs based on the digital certificate submitted by the requesting party, and a third-level verification is performed based on the cross-domain trust score; When the three-level verification is passed, quantum encryption technology is used to encrypt the transmitted government data packet to obtain ciphertext, and the ciphertext is sent to the requesting party.

2. The method according to claim 1, characterized in that The main chain of the blockchain performs a first-level verification on the requester based on the VerifyCredential contract and the access policy whitelist set by the government data department, including: The main chain of the blockchain calls the VerifyCredential contract to verify the legitimacy of the digital certificate; If the legitimacy verification is passed, the checkPolicy contract is called to query the access policy whitelist set by the department to which the government data belongs, and verify whether the attribute set of the requester satisfies the access policy; If the access policy is met, it is determined that the first-level verification is passed.

3. The method according to claim 1, characterized in that After generating the access credential, the method further includes: Encrypting the access credential using hashing technology to obtain an encrypted access credential; Correspondingly, synchronizing the access credentials to the side chain of the blockchain includes: The encrypted access credentials are transferred to the side chain of the blockchain.

4. The method according to claim 1, wherein The federation model is as follows: Among them, TrustScore t represents the cross-domain trust score at time t; λ is the federated learning adjustment factor; W i,t is the weight of the i-th evaluation dimension at time t; Normalize(I i,t ) represents the index I i,t Normalization; FederatedAdjust t Represents the global adjustment value obtained through federated learning.

5. The method according to claim 1, wherein After determining the cross-domain trust score between the government data requesting department and the department to which the government data belongs based on the digital certificate submitted by the requesting party, the method further includes: A dynamic scoring algorithm is used to update the cross-domain trust score between different departments based on historical interaction records between different departments and the cross-domain trust score.

6. The method according to claim 1, characterized in that After sending the ciphertext to the requesting party, the method further includes: For suspicious government data, extracting a three-dimensional feature fingerprint of the government data; Comparing the three-dimensional feature fingerprint with the evidence stored in the blockchain, and locating the leakage path of the government data in combination with the operation log; According to the leakage path, corresponding disposal measures are adopted for disposal.

7. A method for securely sharing data across government departments in a government cloud, applied to the departments to which government data belongs, characterized in that: include: Obtain government data; Annotating the government data to generate structured metadata; Determine a target policy template that matches the structured metadata from a template library, and generate a dynamic attribute-based access policy in combination with the structured metadata; The dynamic attribute-based access policy is encrypted, and the encrypted dynamic attribute-based access policy is bound to the structured metadata.

8. The method according to claim 7, characterized in that The step of labeling the government data and generating structured metadata includes: Using an NLP model to label the sensitivity level of the government data to obtain a government data label; The structured metadata is generated according to the government data identifier, the department to which the government data belongs, the government data label, and the legal binding terms.

9. The method according to claim 7, characterized in that Generating a dynamic attribute-based access strategy includes: Generate the dynamic attribute-based access policy according to the following formula: C=Enc(PK,M,Policy(t,E,W)) Among them, C represents the encrypted dynamic attribute-based access policy; PK represents the system public key; M represents the plaintext government data; Policy(t,E,W) represents the dynamic policy function, which includes the time parameter t, the environmental event E, and the attribute weight W.

10. A device for securely sharing government data across government departments in a government cloud, characterized in that: include: The receiving module 710 is configured to receive a government data access request submitted by a requesting party; The primary verification module 720 is configured as the main chain of the blockchain to perform primary verification on the requester based on the VerifyCredential contract and the access policy whitelist set by the government data department; the access policy is a dynamic attribute-based access policy generated by the government data department based on dynamic attribute encryption technology; Secondary verification module 730 is configured to generate access credentials if the primary verification passes, and synchronize the access credentials to the side chain of the blockchain. The side chain generates a zero-knowledge proof based on the operation log and initiates a zero-knowledge proof verification request to the main chain for secondary verification; The third-level verification module 740 is configured to, if the main chain passes the second-level verification, use a federated model to determine the cross-domain trust score between the government data requesting department and the government data-owning department based on the digital certificate submitted by the requester, and perform third-level verification based on the cross-domain trust score; The data transmission module 750 is configured to encrypt the transmitted government data packet using quantum encryption technology when the three-level verification is passed, obtain ciphertext, and send the ciphertext to the requesting party.

Images