A zero-trust permission management blockchain evidence method based on a government affair data platform

Abstract

The application discloses a zero-trust permission management blockchain storage method based on a government affair data platform, and specifically comprises the following steps: S1: a first system acquires user data in a government affair data platform, classifies and encrypts the user data to obtain encrypted data, and locally stores the encrypted data; S2: the first system uploads the encrypted data to a second system for storage, obtains a corresponding content identifier and a hash value as an identification index; S3: the first system uploads the identification index to a blockchain platform for storage; S4: the instant trust value of a user is calculated according to user attribute information, and the access permission is dynamically adjusted; and S5: the identification index of to-be-accessed content is acquired from the blockchain platform according to the access permission, and the corresponding encrypted data is acquired from the second system.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a zero-trust authority management blockchain evidence storage method based on a government data platform. Background Art

[0002] With the advancement of informatization, more and more government data platforms are adopting digital technologies to improve service quality. As a key channel for communication between the government and the public, government hotlines are responsible for managing massive amounts of work order information. These work orders contain sensitive personal data such as names, phone numbers, user passwords, work order details, and call recordings. Currently, the platform stores approximately 80TB of data, and the volume continues to grow. Achieving efficient storage and management of this sensitive data while ensuring its security has become a major technical challenge.

[0003] In existing technologies, data privacy protection and secure storage are typically achieved through encryption. Symmetric encryption algorithms (such as AES, DES, and SM4) and asymmetric encryption algorithms (such as RSA and ECC) do have certain advantages in preventing unauthorized access and are commonly used to protect personal privacy data. However, the local storage methods in current systems have obvious flaws. Even if certain sensitive information (such as name, phone number, and user password) is encrypted, the core content of work orders (such as complaints, report details, and work order content) and call recordings are still not fully encrypted or protected.

[0004] In this scenario, work order content and recording data are still stored in plaintext on the local server. If this local storage is subject to unauthorized access or hacker attacks, user privacy will be at great risk of being compromised. Furthermore, the lack of blockchain technology also exposes the system to other serious risks. In a centralized local storage architecture, data tampering and deletion are difficult to prevent, especially since administrators and other high-privilege users can directly modify or delete local data, compromising data integrity and authenticity. Lacking the tamper-proof nature of blockchain, the system cannot ensure data immutability, and there is no effective traceability mechanism to track every data operation, resulting in significant vulnerabilities in data security and transparency.

[0005] For example, the current government hotline has the following problems: first, insufficient data security and privacy protection: although some sensitive information (such as name, phone number, and password) is encrypted, the privacy protection of work order content and recordings is insufficient, especially for complaint and reporting data, which are not fully encrypted, and there is a risk of privacy leakage; second, the risk of data tampering: sensitive data of the government hotline is at potential risk of being tampered with or deleted, and the existing storage solution lacks effective anti-tampering and traceability capabilities. Once the data is tampered with or deleted, there is a lack of traceability mechanism to confirm the responsible party; third, the limitations of centralized storage: the centralized architecture of traditional storage systems has the risk of single point failure and cannot cope with large-scale data storage needs. It also lacks redundant backup mechanisms and insufficient data persistence; fourth, the lack of data operation records: In the existing solution, there is a lack of effective recording and auditing mechanisms for operations such as access and modification of work order data, making it difficult to achieve transparency and traceability of operational behaviors.

[0006] In summary, achieving more secure, transparent, and efficient data storage and management has become a pressing issue for current government hotline systems. Combining blockchain and distributed storage technologies is expected to address existing issues such as privacy protection and data tampering, while also improving system scalability and operational efficiency. Summary of the Invention

[0007] In response to the problems of low security and poor traceability in government data storage in the existing technology, the present invention proposes a zero-trust authority management blockchain evidence storage method based on the government data platform.

[0008] In order to achieve the above object, the present invention provides the following technical solutions:

[0009] A zero-trust authority management blockchain evidence storage method based on a government data platform specifically includes the following steps:

[0010] S1: The first system obtains user data from the government data platform, classifies and encrypts the user data to obtain encrypted data, and stores the encrypted data locally;

[0011] S2: The first system uploads the encrypted data to the second system for storage, and obtains the corresponding content identifier and hash value as an identification index;

[0012] S3: The first system uploads the identification index to the blockchain platform for storage;

[0013] S4: Calculate the user's instant trust value based on user attribute information and dynamically adjust access rights;

[0014] S5: Obtain an identification index of the content to be accessed from the blockchain platform according to the access rights, and then obtain the corresponding encrypted data from the second system.

[0015] Preferably, the S1 includes:

[0016] S1-1: The first system obtains user data from the government data platform and classifies and grades the user data;

[0017] S1-2: Preprocess the data of different categories to obtain data blocks;

[0018] S1-3: The first system uses the SM4 national encryption algorithm to generate the key; and adopts the CBC encryption mode to randomly generate the initialization vector IV.

[0019] S1-4: Use the key to encrypt the data blocks one by one to obtain the encryption result Encrypted_Data;

[0020] S1-5: Concatenate the encryption result Encrypted_Data and IV into Encrypted_Payload, which is the encrypted data.

[0021] Preferably, the S2 includes:

[0022] S2-1: The first system packages the encrypted data and uploads it to the second system; the second system generates a corresponding CID for each encrypted data and returns it to the first system;

[0023] S2-2: The first system calculates a corresponding hash value for the encrypted data;

[0024] S2-3: The first system uses the hash value and the CID returned by the second system as the identification index of the user data.

[0025] Preferably, the S3 further includes:

[0026] Record each operation log on user data and store the hash value of the operation log on the chain; the operation log includes the operation time, operator identity, and operation type.

[0027] Preferably, the S4 further includes:

[0028] S4-1: Obtain user attribute information, which includes user ID, position, department, access device, and access location;

[0029] S4-2: Calculate the instant trust value T of user k based on the current user attribute information k (U):

[0030] T k (U)=w1·T k '(U)+w2·R k +w3·A k (1)

[0031] In formula (1), T k (U) represents the instant trust value of user k; T k '(U) represents the historical trust value of user k; R k A represents the recommendation trust value of other users to user k; k represents the trust value related to the user attribute; w1 represents the weight coefficient of the historical trust value; w2 represents the weight coefficient of the recommended trust value; w3 represents the weight coefficient of the user attribute trust value;

[0032] S4-3: If the instant trust value T k (U) is greater than or equal to the first preset threshold value T1, the user is allowed normal access; if the instant trust value is less than the first preset threshold value T1, additional identity verification is triggered or the access permission level is reduced;

[0033] S4-4: Dynamically adjust user access rights based on instant trust value.

[0034] Preferably, in S4-4, the access rights include:

[0035] First access right: When the instant trust value T k (U) is greater than or equal to a first preset threshold T1, accessing all permitted data contents;

[0036] Second access right: When the second preset threshold T2 <T k (U) <T1,则对用户访问权限进行限制,限制包括仅可读取数据,禁止修改或删除;

[0037] Third access right: when the trust value is less than the second preset threshold T2, the user's access request is rejected.

[0038] Preferably, the method further includes S4-5: verifying and auditing the user's access rights based on the mandatory access control MAC mechanism, and the specific steps include:

[0039] A: The system assigns user operation permissions based on the user's security level label S(U) and the data's security level label S(D) according to the Bell-LaPadula model rules;

[0040] B: Automatically perform permission verification and review based on preset thresholds and security policies; if approved, the identification index is returned to the user; if not approved, the system denies access and notifies the user.

[0041] Preferably, the method for allocating user operation permissions is:

[0042] Simple security rule: users can only read data below their security level, that is, for user U i and data Dj The condition of the read operation is: S(U i )>S(D j ); S(U i ) represents the security level label of the user U i ; S(D j represents the security level label of the data D j ;

[0043] The write-in rule: the user can only write to the data higher than or equal to the security level, that is, S(U i )≤S(D j ).

[0044] Preferably, the S5 comprises:

[0045] S5-1: First, the second system obtains the ticket hash value and the corresponding CID stored on the blockchain through the blockchain;

[0046] S5-2: The first system obtains the encrypted data from the second system according to the ticket hash value and the corresponding CID, and sends it to the user.

[0047] Preferably, in the S5-2,

[0048] The first system recalculates the verification hash value of the encrypted data obtained from the second system and compares it with the ticket hash value stored on the blockchain; if they are consistent, it means that the data has not been tampered with, and the first system will send the ciphertext data to the user; if the hash values do not match, the first system will issue a warning and mark the data as a potential tampering behavior.

[0049] In summary, compared with the prior art, the present application has at least the following beneficial effects:

[0050] By using the national secret SM4 encryption, all users' sensitive information (including ticket content and recording) is encrypted and protected during storage and transmission, ensuring that data privacy will not be leaked even in a distributed network.

[0051] The non-tamperable feature of the blockchain ensures that the encrypted data and operation records stored in the IPFS cannot be tampered with or deleted, and any tampering can be verified through the hash value stored on the chain.

[0052] The IPFS distributed storage solves the bottleneck problem of large-scale data storage, avoids the single point failure risk of traditional centralized storage, provides a redundant storage mechanism, and ensures the long-term effectiveness and accessibility of data.

[0053] In this invention, every operation such as accessing, modifying, downloading, etc. of work order data will be recorded in detail and uploaded to the chain, ensuring the transparency of the operation process and facilitating auditing and tracing.

[0054] This invention combines the characteristics of IPFS and blockchain, and the system can adapt to the growing data storage needs of government hotlines, ensuring that the system can still maintain efficient and reliable operation under high load in the future. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 Schematic diagram of a zero-trust authority management blockchain evidence storage method based on a government data platform according to an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0056] The present invention will be further described in detail below with reference to the examples and specific implementation methods. However, this should not be understood as limiting the scope of the present invention to the following examples, as all technologies implemented based on the present invention fall within the scope of the present invention.

[0057] In the description of the present invention, it should be understood that the terms "longitudinal", "transverse", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", etc., indicating the orientation or position relationship, are based on the orientation or position relationship shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention.

[0058] Current government systems primarily rely on traditional centralized methods for data encryption and storage management. While these methods can ensure the security of sensitive data to a certain extent, with the increase in data volume and changes in storage requirements, these methods are clearly no longer able to fully meet the needs of privacy protection and efficient storage. In particular, existing technologies and architectures still have significant shortcomings in data tamper protection, transparency auditing, and distributed storage.

[0059] like Figure 1 As shown, the present invention provides a zero-trust authority management blockchain evidence storage method based on a government data platform, which specifically includes the following steps:

[0060] S1: The first system obtains user data from the government data platform, classifies and encrypts the user data to obtain encrypted data, and stores the encrypted data locally.

[0061] In this embodiment, the user submits user data through the government hotline. The user data includes: name, phone number, user password, work order content (such as complaints, reports, etc.), and call recordings.

[0062] In this embodiment, after receiving the user data, the system first performs local encryption processing on the sensitive information of the user; for example, the SM4 symmetric encryption algorithm can be used to ensure that the sensitive data cannot be read by external visitors without decryption. The encrypted data will be stored locally for subsequent processing to ensure that it is not leaked during transmission and storage.

[0063] S1-1: The first system obtains user data in the government affair data platform, and classifies the user data.

[0064] In this embodiment, the method for classifying and encrypting user data information is to divide it into different categories according to its sensitivity and importance, and to clearly define the corresponding use permissions.

[0065] S1-1-1: In this embodiment, the first system automatically divides the user data into the following categories based on the nature and purpose of the content of the user data information:

[0066] • Personal identity information category: including name, ID number, phone number, address, and other information that can directly identify personal identity;

[0067] • Work order content category: including complaint content, suggestion content, consultation content, and other business information;

[0068] • Multimedia record category: including call recording, picture attachment, and other audio and video materials;

[0069] • Operation log category: including user access record, operation time, IP address, and other system logs;

[0070] • Statistical analysis category: including work order processing statistics, satisfaction evaluation, and other summary data.

[0071] S1-1-2: Next, the first system automatically divides the data in each category into four security levels according to the sensitivity. First, the first system sets up a keyword library and weight coefficients, and then defines level coefficients for data categories. For data in the government platform, the security level is calculated according to the included keywords and the data category. Specifically:

[0072] ① The keyword library and weight coefficients are defined as shown in Table 1:

[0073] Table 1, Definition of Keyword Library and Weight Coefficients

[0074] Keyword library Keywords Weight coefficient (0-1) Privacy Logo Thesaurus ID card, bank card, password... 1.0 Sensitive vocabulary Complaints, reports, violations... 0.8 Business Glossary Suggestions, consultations, inquiries... 0.4

[0075] ② Define the data category level coefficient (0-1), for example, personal identity information category 1.0; work order content category 0.8; multimedia record category 0.6; operation log category 0.4; statistical analysis category 0.2;

[0076] ③ The system divides the data into four security levels, calculates the data's security level score, and maps it to different levels. As shown in Table 2:

[0077] Security level score = MAX (keyword weight coefficient * 0.6 + data category level coefficient * 0.4)

[0078] Table 2. Safety level score table

[0079] Security Level illustrate Safety level score (0-1) Core Level (Level-1) Data that directly involves personal privacy and has unique identification [0.9，1.0] Sensitive Level (Level-2) Data that indirectly involves personal privacy or contains sensitive business information [0.7，0.9) Internal level (Level-3) Data that is for internal use only and does not contain sensitive information [0.5，0.7) Public Level (Level-4) Statistical information that can be disclosed publicly [0，0.5)

[0080] For example, a work order content containing the keyword "ID card" has a keyword level weight coefficient of 1.0 (the weight of the ID card), and a data category level coefficient of 0.8 (work order content category). Therefore, the data security level score is 1.0*0.6+0.8*0.4=0.92, and the data security level is ultimately core level (Level-1).

[0081] S1-1-3: Permission allocation rules:

[0082] 1) Data access permissions:

[0083] Level-1 data: Only core management personnel have full access, while relevant business personnel can access desensitized information.

[0084] Level-2 data: Department managers and above have full access, and ordinary operators can access necessary fields.

[0085] Level-3 data: accessible to all regular employees, but access logs must be kept;

[0086] Level-4 data: accessible to all users without special authorization.

[0087] 2) Data operation permissions:

[0088] Read permission: Users can access data up to their own security level.

[0089] Modify permissions: Users can modify data equal to their own security level;

[0090] Delete permission: Only users with a higher data security level are allowed to perform deletion operations.

[0091] S1-2: Preprocess the data of different categories to obtain data blocks, that is, convert them into JSON format (text) to facilitate unified encryption, and then divide the JSON format data into blocks according to the group size (16 bytes) of the SM4 algorithm to obtain data blocks.

[0092] In this embodiment, different categories of data are put into a dictionary, and then converted into JSON format (text) to facilitate unified encryption.

[0093] S1-3: The first system uses the SM4 national encryption algorithm to generate a 128-bit (16-byte) key. This 128-bit key will be used for the encryption and decryption process; and uses the CBC encryption mode to randomly generate a 16-byte initialization vector IV.

[0094] S1-4: Encrypt the data blocks one by one using the key in S1-3 (this belongs to the existing technology) to obtain the encryption result Encrypted_Data;

[0095] S1-5: The encryption result Encrypted_Data and IV are concatenated (ie, IV+Encrypted_Data) into Encrypted_Payload, i.e., encrypted data, and transmitted to the local system (first system) for storage.

[0096] S2: The first system uploads the encrypted data to IPFS (the second system) for storage, and obtains the corresponding content identifier and hash value as the unique identification index of the user data.

[0097] In this embodiment, the first system uploads the encrypted data to IPFS (InterPlanetary File System) to achieve distributed storage of data.

[0098] S2-1: The first system packages the encrypted data and uploads it to the second system; the second system generates a unique content identifier (CID) for each encrypted data, which is used to identify the encrypted data stored in IPFS and returns it to the first system.

[0099] S2-2: To ensure subsequent data verification, the first system calculates a hash value for the encrypted data (e.g., the SHA-256 algorithm, which is a prior art and therefore not described here). The hash value ensures that data integrity can be verified in any subsequent operations.

[0100] S2-3: The first system records the hash value and the CID returned by the second system as the unique identification index of the user data for subsequent blockchain storage.

[0101] S3: The first system uploads the identification index to the blockchain platform for storage.

[0102] In this embodiment, the blockchain platform can ensure the immutability of data and the transparency of operations through smart contracts.

[0103] In this embodiment, the second system uploads the hash value and CID (identification index) of the encrypted data to the blockchain, which is then stored on-chain via a data evidence smart contract. The hash value ensures the uniqueness and integrity of the encrypted data, while the CID is used to identify the specific encrypted data stored in the second system. Once the data is on-chain, it cannot be tampered with. The immutable nature of the blockchain ensures the authenticity and durability of the stored evidence data.

[0104] At the same time, each operation log of the work order data is recorded, and the hash value of the operation log is stored on the chain. Each operation log (such as operation time, operator identity, operation type, etc.) generates a corresponding hash value and stores it on the blockchain, ensuring the transparency and auditability of each operation behavior.

[0105] S4: To ensure system security and data access compliance, in this implementation, the first system utilizes a zero-trust architecture for trust assessment and permission verification based on a mandatory access control (MAC) mechanism. When a user accesses, modifies, or deletes data, the first system first authenticates the user, extracts user attributes (such as position, department, access device, and location), calculates the user's real-time trust value (T(U)), and dynamically adjusts access permissions. Users whose trust values ​​meet the threshold can access the corresponding data content according to their permissions; otherwise, additional verification or permission restrictions are triggered. Simultaneously, the first system further verifies the security level labels of users and data using the MAC model, ensuring that users can only read data within their permissions and triggering the review committee to approve highly sensitive operations. All operations (accessing, modifying, or deleting data, trust value calculation, access permission adjustment, verification of security level labels, etc.) are logged and stored on-chain via hash values ​​and IPFS CIDs, ensuring that data access is immutable and fully traceable for audit purposes.

[0106] S4-1: Obtain user attribute information, including user ID, position (such as manager, department head, ordinary employee, etc.), department, access device, access location, etc.;

[0107] S4-2: Calculate the instant trust value T of user k based on the current user attribute information k (U); where T' k (U) represents the historical trust value, R k A represents the recommendation trust value of other users to user k, k Indicates the trust value associated with user attributes.

[0108] T k (U)=w1·T k '(U)+w2·R k +w3·A k (1)

[0109] In formula (1), Tk (U) represents the instant trust value of user k; T k '(U) represents the historical trust value of user k; R k A represents the recommendation trust value of other users to user k; k Represents the trust value related to user attributes; w1 represents the weight coefficient of historical trust value; w2 represents the weight coefficient of recommended trust value; w3 represents the weight coefficient of user attribute trust value.

[0110] S4-3: If the instant trust value T k (U) is greater than or equal to the first preset threshold value T1, the user is allowed normal access; if the instant trust value is less than the first preset threshold value T1, additional identity verification is triggered or the access permission level is reduced.

[0111] S4-4: Dynamically adjust user access rights based on instant trust value.

[0112] First access right: When the instant trust value T k (U) is greater than or equal to the first preset threshold T1, and the user can access all allowed data content.

[0113] Second access right: When the instant trust value T k (U) In the medium range, that is, the second preset threshold T2 <T k (U) <T1,则对用户权限进行限制,限制包括仅可读取数据,禁止修改或删除。

[0114] Third access permission: When the trust value is less than the second preset threshold T2, the system rejects the user's access request.

[0115] In this embodiment, based on identity identification and instant trust value calculation, a mandatory access control (MAC) mechanism is used to further verify and audit the user's access rights. The specific steps include:

[0116] A: The system assigns user permissions based on the user's security level label S(U) and the data's security level label S(D), following the Bell-LaPadula model. Users can only read data below their permission level and write data above their permission level, ensuring data confidentiality is maintained.

[0117] In this embodiment, the method for generating the user security level label S(U) is:

[0118] 1) Evaluation is based on three dimensions: user position level V, department sensitivity D, and years of work experience T;

[0119] 2) User security level calculation formula: S(U)=k1·V+k2·D+k3·T, where k1, k2, k3 are weight coefficients and k1+k2+k3=1.

[0120] In this embodiment, the data security level label S(D) is generated as follows:

[0121] 1) Evaluate based on three dimensions: data type sensitivity (C), data impact range (R), and timeliness (E);

[0122] 2) Data security level calculation formula: S(D) = t1·C + t2·R + t3·E, where t1, t2, and t3 are weight coefficients and t1+t2+t3=1.

[0123] Finally, the system automatically maps the scores to different security levels (L1-L4) based on the calculation results.

[0124] In this embodiment, the operation authority allocation rules are:

[0125] Simple security rule: users can only read data below their security level, that is, for user U i and data D j , the conditions for the read operation are: S(U i )>S(D j );

[0126] No write rule: Users can only write to data with a security level higher than or equal to their own, i.e. S(U i )≤S(D j ).

[0127] B: The system assigns user permissions based on the Bell-LaPadula model, automatically assigning permissions based on security level tags. The system uses a rules engine to automatically verify and review permissions according to preset thresholds and security policies. This review process ensures the legitimacy and security of user requests and prevents unauthorized operations. If the review passes, the data's unique identifier (CID and hash value) is returned to the user. If not, the system denies access and notifies the user.

[0128] The operation evidence contract is used to record user operations such as access, modification, and deletion of data, including user-initiated operation requests such as access, modification, and deletion. Each user operation generates a detailed operation log, including user ID, trust value T(U), requested access data, operation time, operation type, operation result, and audit results. The hash value of the operation log is stored on the chain to ensure that all access operations are immutable and traceable.

[0129] S5: When an authorized user (such as an administrator or operator) needs to access a work order, the system executes the following process to ensure data integrity and security:

[0130] S5-1: First, the work order hash value and CID are retrieved from the blockchain. The second system obtains the work order hash value and corresponding CID stored on the blockchain through the blockchain. The CID is used to retrieve encrypted data from the second system.

[0131] S5-2: Next, the first system obtains the encrypted data from the second system and sends it to the user. That is, the first system downloads the encrypted data from the second system through the CID. Due to the distributed storage characteristics of the second system, no matter which node the data is stored on, the CID can uniquely identify and retrieve the corresponding data.

[0132] Furthermore, data integrity verification can be performed: the first system recalculates the hash value of the encrypted data retrieved from the second system and compares it with the original hash value stored on the blockchain. If the hash values ​​match, indicating that the data has not been tampered with, the first system sends the encrypted data to the user; if the hash values ​​do not match, the first system will issue a warning and mark the data as potentially tampered with.

[0133] If the hash verification passes, the first system sends the encrypted data to the user. The user uses the corresponding key (the 128-bit key in S1-3) to decrypt the work order content and recording and view the specific data content. The entire process ensures data integrity and security, avoiding the risk of tampering and leakage.

[0134] In this embodiment, when a user needs to access, modify, or delete stored data, the Zero Trust Architecture trust assessment module performs user identification, access control, and continuous trust assessment. This ensures that only verified legitimate users can access data resources, and only authorized resources. Furthermore, the user's credibility is assessed in real time, and access rights are dynamically adjusted based on the assessment results. Finally, user operation logs are stored on-chain for easy traceability and auditing.

[0135] Those skilled in the art will appreciate that the above-mentioned embodiments are specific examples for implementing the present invention, and that in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present invention.

Claims

1. A zero-trust authority management blockchain evidence storage method based on a government data platform, characterized in that: The specific steps include: S1: The first system obtains user data from the government data platform, classifies and encrypts the user data to obtain encrypted data, and stores the encrypted data locally; S2: The first system uploads the encrypted data to the second system for storage, and obtains the corresponding content identifier and hash value as an identification index; S3: The first system uploads the identification index to the blockchain platform for storage; S4: Calculate the user's instant trust value based on user attribute information and dynamically adjust access rights; S5: Obtain an identification index of the content to be accessed from the blockchain platform based on the access rights, and then obtain the corresponding encrypted data from the second system; Said S4 further comprises: S4-1: Obtain user attribute information, which includes user ID, position, department, access device, and access location; S4-2: Calculate the instant trust value T of user k based on the current user attribute information k (U): T k (U)=w1·T k ′(U)+w2·R k +w3·A k (1) In formula (1), T k (U) represents the instant trust value of user k; T k ′(U) represents the historical trust value of user k; R k A represents the recommendation trust value of other users to user k; k represents the trust value related to the user attribute; w1 represents the weight coefficient of the historical trust value; w2 represents the weight coefficient of the recommended trust value; w3 represents the weight coefficient of the user attribute trust value; S4-3: If the instant trust value T k (U) is greater than or equal to the first preset threshold value T1, the user is allowed normal access; if the instant trust value is less than the first preset threshold value T1, additional identity verification is triggered or the access permission level is reduced; S4-4: Dynamically adjust user access rights based on instant trust value; In S4-4, the access rights include: First access right: When the instant trust value T k (U) is greater than or equal to a first preset threshold T1, accessing all permitted data contents; Second access permission: When the second preset threshold T2 < T k (U) < T1, the user's access permission is restricted, and the restrictions include only being able to read data and prohibiting modification or deletion; Third access right: when the trust value is less than the second preset threshold T2, the user's access request is rejected.

2. A zero-trust authority management blockchain evidence storage method based on a government data platform as claimed in claim 1, characterized in that: Said S1 comprises: S1-1: The first system obtains user data from the government data platform and classifies and grades the user data; S1-2: Preprocess the data of different categories to obtain data blocks; S1-3: The first system uses the SM4 national secret algorithm to generate a key; and uses the CBC encryption mode to randomly generate an initialization vector IV; S1-4: Use the key to encrypt the data blocks one by one to obtain the encryption result Encrypted_Data; S1-5: Concatenate the encryption result Encrypted_Data and IV into Encrypted_Payload, which is the encrypted data.

3. A zero-trust authority management blockchain evidence storage method based on a government data platform as claimed in claim 1, characterized in that: The S2 includes: S2-1: The first system packages the encrypted data and uploads it to the second system; the second system generates a corresponding CID for each encrypted data and returns it to the first system; S2-2: The first system calculates a corresponding hash value for the encrypted data; S2-3: The first system uses the hash value and the CID returned by the second system as the identification index of the user data.

4. A zero-trust authority management blockchain evidence storage method based on a government data platform as claimed in claim 1, characterized in that: Said S3 also includes: Record each operation log on user data and store the hash value of the operation log on the chain; the operation log includes the operation time, operator identity, and operation type.

5. The zero-trust authority management blockchain evidence storage method based on the government data platform as claimed in claim 1 is characterized in that: It also includes S4-5: Verifying and auditing the user's access rights based on the mandatory access control MAC mechanism. The specific steps include: A: The system assigns user operation permissions based on the user's security level label S(U) and the data's security level label S(D) according to the Bell-LaPadula model rules; B: Automatically perform permission verification and review based on preset thresholds and security policies; if approved, the identification index is returned to the user; if not approved, the system denies access and notifies the user.

6. A zero-trust authority management blockchain evidence storage method based on a government data platform as claimed in claim 5, characterized in that: The method for assigning user operation permissions is: Simple security rule: users can only read data below their security level, that is, for user U i and data D j , the conditions for the read operation are: S(U i )>S(D j ); S(U i ) represents user U i Security level label; S(D j ) represents data D j Security level label; No write rule: Users can only write to data with a security level higher than or equal to their own, i.e. S(U i )≤S(D j ).

7. A zero-trust authority management blockchain evidence storage method based on a government data platform as claimed in claim 1, characterized in that: The S5 includes: S5-1: First, the second system obtains the work order hash value and corresponding CID stored on the blockchain through the blockchain; S5-2: The first system obtains the encrypted data from the second system according to the work order hash value and the corresponding CID, and sends it to the user.

8. A zero-trust authority management blockchain evidence storage method based on a government data platform as claimed in claim 7, characterized in that: In said S5-2, The first system recalculates the verification hash value of the encrypted data obtained from the second system and compares it with the work order hash value stored on the blockchain. If they are consistent, it means that the data has not been tampered with, and the first system sends the encrypted data to the user; If the hash values ​​do not match, the first system will issue a warning and flag the data as potentially tampered with.

Images