Zero-trust authority management block chain evidence storage method based on government affair data platform

Abstract

The invention discloses a zero-trust authority management block chain evidence storage method based on a government affair data platform, and the method specifically comprises the following steps: S1, obtaining user data in the government affair data platform through a first system, carrying out the classification and grading encryption of the user data, obtaining encrypted data, and carrying out the local storage of the encrypted data; s2, the first system uploads the encrypted data to a second system for storage to obtain a corresponding content identifier and a hash value as an identification index; s3, the first system uploads the identification index to a block chain platform for storage; s4, calculating the instant trust value of the user according to the user attribute information, and dynamically adjusting the access authority; and S5, obtaining the identification index of the to-be-accessed content from the block chain platform according to the access permission, and then obtaining the corresponding encrypted data 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 using digital technology to improve service quality. As an important channel for communication between the government and the public, government hotlines are responsible for the management of a huge amount of work order information. These work orders involve sensitive personal privacy data, such as name, phone number, user password, work order content, and call recordings. At present, the scale of data stored on the platform has reached about 80TB, and the amount of data is still increasing. How to achieve efficient storage and management while ensuring the security of these sensitive data has become the main challenge facing current technology.

[0003] In existing technologies, data privacy protection and secure storage are usually 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 usually used to protect personal privacy data. However, the local storage method in the current system has obvious defects. Even if some sensitive information (such as name, phone number, user password) is encrypted, the core content of the work order (such as complaints, report details, work order content) and call recordings are still not fully encrypted or protected.

[0004] In the above case, the work order content and recording data are still stored in plain text on the local server. Once the local storage is accessed without authorization or attacked by hackers, user privacy will face great risks of leakage. In addition, the lack of blockchain technology also causes the system to face other serious risks. Under the centralized local storage architecture, data tampering and deletion are difficult to prevent, especially high-authority users such as administrators can directly modify or delete local data, resulting in data integrity and authenticity cannot be guaranteed. Due to the lack of blockchain's anti-tampering characteristics, the system cannot ensure the immutability of data, and there is no effective traceability mechanism to track each operation on the data, which makes the system have large loopholes in data security and transparency.

[0005] For example, the current government hotline has the following problems. First, data security and privacy protection are insufficient: although some sensitive information (such as name, phone number, 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 solutions lack 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, cannot cope with large-scale data storage needs, and lacks redundant backup mechanisms, and data persistence is insufficient; fourth, data operation records are missing: in the existing solutions, there is a lack of effective recording and auditing mechanisms for accessing and modifying work order data, making it difficult to achieve transparency and traceability of operational behaviors.

[0006] In summary, how to achieve more secure, transparent and efficient data storage and management has become an urgent problem to be solved in the current government hotline system. By combining blockchain and distributed storage technology, it is expected to solve the problems of privacy protection and data tampering in existing technologies, while improving the scalability and operating efficiency of the system. Summary of the invention

[0007] In response to the problems of low security and poor traceability in the prior art of government data storage, the present invention proposes a zero-trust authority management blockchain evidence storage method based on a 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 the user's attribute information and dynamically adjust the 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: preprocessing different categories of data to obtain data blocks;

[0018] S1-3: The first system uses the SM4 national encryption algorithm to generate a key; and uses the CBC encryption mode to randomly generate an 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, i.e., 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 an identification index of the user data.

[0025] Preferably, S3 also 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 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 represents the recommended trust value of other users for user k; A k represents the trust value related to user attributes; 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 T1, the user is allowed to access normally; if the instant trust value is less than the first preset threshold T1, additional identity authentication is triggered or the access permission level is reduced;

[0033] S4-4: Dynamically adjust the user's access permission according to the instant trust value.

[0034] Preferably, in S4-4, the access permission includes:

[0035] First access permission: When the instant trust value T k (U) is greater than or equal to the first preset threshold T1, access all allowed data content;

[0036] Second access permission: When the second preset threshold T2 < T k (U) < T1, the user's access permission is restricted, and the restriction includes only being able to read the data and prohibiting modification or deletion;

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

[0038] Preferably, it further includes S4-5: Verify and audit the user's access permission based on the mandatory access control MAC mechanism. The specific steps include:

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

[0040] B: Automatically perform permission verification and audit according to the preset threshold and security policy; if the approval is passed, return the identification index to the user; if not approved, the system rejects the access and notifies the user.

[0041] Preferably, the method for allocating the user's operation permission is:

[0042] Simple security rule: The user can only read the data below its security level, that is, for user U i and data Dj , 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 Indicates data D j Security level label;

[0043] 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 ).

[0044] Preferably, the S5 includes:

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

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

[0047] Preferably, in S5-2,

[0048] The first system recalculates and verifies the hash value of the encrypted data obtained from the second system and compares it with the hash value of the work order stored on the blockchain; if they are consistent, it means that the data has not been tampered with, and the first system sends 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 potentially tampered.

[0049] In summary, due to the adoption of the above technical solution, compared with the prior art, the present invention has at least the following beneficial effects:

[0050] The present invention uses national encryption SM4, and all users' sensitive information (including work order content and recordings) is encrypted and protected during storage and transmission, ensuring that data privacy will not be leaked even in a distributed network.

[0051] The tamper-proof property of the blockchain of the present invention ensures that the encrypted data and operation records stored in 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 of the present invention solves the bottleneck problem of large-scale data storage, avoids the single point failure risk of traditional centralized storage, and provides a redundant storage mechanism to ensure the long-term validity and accessibility of data.

[0053] In the present invention, each access, modification, download and other operation behaviors of the 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] The present invention combines the characteristics of IPFS and blockchain, and the system can adapt to the growing demand for government hotline data storage, 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 A 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 is further described in detail below in conjunction with the examples and specific implementation methods. However, this should not be understood as the scope of the above subject matter of the present invention being limited to the following examples, and all technologies realized based on the content of the present invention belong to the scope of the present invention.

[0057] In the description of the present invention, it is necessary to understand that the terms "longitudinal", "lateral", "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 a limitation on the present invention.

[0058] The current government system mainly relies on traditional centralized methods for data encryption and storage management. Although they 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 obviously no longer able to fully meet the needs of privacy protection and efficient storage. In particular, in terms of data tampering protection, transparency auditing, and distributed storage, the existing technology and architecture still have obvious shortcomings.

[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, and 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 on the user's sensitive information; 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 from the government data platform and classifies and grades the user data.

[0064] In this embodiment, the method for classifying and encrypting user data information is as follows: classifying the user data information into different categories according to the sensitivity and importance of the user data information, and clarifying the corresponding usage 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: including name, ID number, phone number, address and other information that can directly identify an individual;

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

[0068] Multimedia records: including call recordings, picture attachments and other audio and video materials;

[0069] Operation logs: including user access records, operation time, IP address and other system logs;

[0070] ·Statistical analysis: including summary data such as work order processing statistics and satisfaction evaluation.

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

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

[0073] Table 1. Definition of keyword library and weight coefficient

[0074] Keyword Library Keywords Weight coefficient (0~1) Privacy Logo Thesaurus ID card, bank card, password... 1.0 Sensitive word library 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 4 security levels, calculates the security level scores of the data, and corresponds them 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 to the public [0，0.5)

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

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

[0082] 1) Data access rights:

[0083] Level-1 data: Only core management personnel can access the data in full, and relevant business personnel can access the de-sensitized information.

[0084] Level-2 data: Department heads and above can fully access it, and ordinary operators can access necessary fields;

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

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

[0087] 2) Data operation authority:

[0088] Read permission: Users can access data that is not higher than their own security level;

[0089] Modification authority: 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 different categories of data to obtain data blocks, that is, convert them into JSON format (text) to facilitate unified encryption, and then divide the data in JSON format into data blocks according to the grouping size (16 bytes) of the SM4 algorithm.

[0092] In this embodiment, different categories of data are put into a dictionary, which is 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, which will be used for encryption and decryption processes; 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 (belonging to the prior art) to obtain the encryption result Encrypted_Data;

[0095] S1-5: Concatenate the encryption result Encrypted_Data and IV (ie IV+Encrypted_Data) into Encrypted_Payload, ie encrypted data, and transmit it to the local system (first system) for storage.

[0096] S2: The first system uploads the encrypted data to IPFS (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 will calculate a hash value for the encrypted data (such as the SHA-256 algorithm, which is a prior art and will not be repeated here). The hash value ensures that the data integrity can be verified in any subsequent operation.

[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, and stores it on the chain through the data evidence smart contract. The hash value ensures the uniqueness and integrity of the encrypted data, and the CID is used to point to the specific encrypted data stored in the second system. Once the data is on the chain, it cannot be tampered with. The tamper-proof nature of the blockchain ensures the authenticity and durability of the evidence data.

[0104] At the same time, the operation log of each 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 in the blockchain to ensure the transparency and auditability of each operation behavior.

[0105] S4: To ensure system security and compliance of data access, in this implementation plan, the first system adopts trust assessment of zero-trust architecture and permission verification based on mandatory access control (MAC) mechanism. When a user accesses, modifies or deletes data, the first system first extracts user attribute information (such as position, department, access device, location) through identity identification to calculate the user's real-time trust value T(U), and dynamically adjusts access rights. Users whose trust value reaches the threshold can access the corresponding data content according to their permissions, otherwise additional verification or permission restrictions will be triggered. At the same time, the first system further verifies the security level labels of users and data through the MAC model to ensure that users can only read data within their authority and trigger the review committee to approve highly sensitive operations. All operations (access, modify or delete data, trust value calculation, access permission adjustment, verification of security level labels, etc.) generate logs, which are stored on the chain through hash values ​​and IPFS CIDs to achieve unalterable and fully traceable data access for audit use.

[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 represents the recommendation trust value of other users to user k, A 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 represents the recommended trust value of other users for user k; A k represents the trust value related to user attributes; 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.

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

[0111] S4-4: Dynamically adjust the user's access permission according to the instant trust value.

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

[0113] Second access permission: When the instant trust value T k (U) is in the medium range, that is, the second preset threshold T2 < T k (U) < T1, the user's permissions are restricted, and the restrictions include only being able to read the data and being prohibited from modifying or deleting.

[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 recognition and instant trust value calculation, the mandatory access control MAC mechanism is adopted to further verify and audit the user's access permission. The specific steps include:

[0116] A: The system allocates the user's operation permissions according to the security level label S(U) of the user and the security level label S(D) of the data, in accordance with the rules of the Bell-LaPadula model. The user can only read the data below its access permission level and write the data above its permission level to ensure that the confidentiality of the data is not violated.

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

[0118] 1) Evaluate based on three dimensions: the user's job level V, department sensitivity D, and working years 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 scope R, and timeliness E;

[0122] 2) Data security level calculation formula: S(D)=t1·C+t2·R+t3·E, where t1, t2, 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. 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 operation permissions according to the Bell-LaPadula model rules and automatically assigns user operation permissions based on security level tags; the system sets up a rule engine to automatically verify and review permissions based on preset thresholds and security policies. The review process ensures the legitimacy and security of user requests and prevents unauthorized operations. If the review passes, the unique identifier of the data (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 the user's access, modification, deletion and other operations on the data, including: the user initiates an operation request such as access, modification, deletion, etc. A detailed operation log is generated for each user operation, including the user ID, trust value T(U), requested access data, operation time, operation type, operation result, audit result, etc. The hash value of the operation log is stored on the chain to ensure that all access operations cannot be altered and are 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 the 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] In addition, data integrity verification can be performed, where 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 ​​are consistent, it means that the data has not been tampered with, and the first system sends 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 potentially tampered.

[0133] If the hash verification passes, the first system will send 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 whole process ensures the integrity and security of the data and avoids the risk of tampering and leakage.

[0134] In this embodiment, when a user needs to access / modify / delete stored data information, the zero-trust architecture trust assessment module is used to perform user identity identification, access control, and continuous trust assessment to ensure that only verified legitimate users can access data resources and can only access authorized resources. In addition, the user's credibility is assessed in real time, and the access rights are dynamically adjusted according to the assessment results. Finally, the user operation log is stored on the chain for easy traceability audit.

[0135] Those skilled in the art will appreciate that the above-mentioned embodiments are specific examples for implementing the present invention, and 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 the user's attribute information and dynamically adjust the access rights; 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.

2. A zero-trust authority management blockchain evidence storage method based on a government data platform as claimed in claim 1, characterized in that: The S1 includes: S1-1: The first system obtains user data from the government data platform and classifies and grades the user data; S1-2: preprocessing different categories of data to obtain data blocks; S1-3: The first system uses the SM4 national encryption 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, i.e., 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 an 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: The 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 operation time, operator identity, and operation type.

5. A zero-trust authority management blockchain evidence storage method based on a government data platform as claimed in claim 1, characterized in that: The 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 to access normally; if the instant trust value is less than the first preset threshold value T1, additional identity authentication is triggered or the access permission level is reduced; S4-4: Dynamically adjust user access rights based on instant trust value.

6. A zero-trust authority management blockchain evidence storage method based on a government data platform as claimed in claim 5, characterized in that: In S4-4, the access rights include: First access right: When the instant trust value is T k (U) is greater than or equal to a first preset threshold value T1, accessing all permitted data contents; Second access permission: When the second preset threshold T2 < T k (U) < T1, the user 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 value T2, the user's access request is rejected.

7. A zero-trust authority management blockchain evidence storage method based on a government data platform as claimed in claim 5, 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 allocates 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.

8. A zero-trust authority management blockchain evidence storage method based on a government data platform as claimed in claim 7, characterized in that: The method for assigning user operation permissions is: Simple security rule: Users can only read data below their security level. 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 Indicates 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 (。 9. 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 the corresponding CID stored on the blockchain through the blockchain; S5-2: The first system obtains encrypted data from the second system according to the work order hash value and the corresponding CID, and sends it to the user.

10. A zero-trust authority management blockchain evidence storage method based on a government data platform as claimed in claim 9, characterized in that: In 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 ciphertext 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