A Data Authorization and Sharing Method and System for Smart City Cloud Platforms Based on Blockchain

Abstract

This application discloses a data authorization and sharing method and system for a blockchain-based smart city cloud platform, relating to the field of data sharing. The method includes: responding to a query instruction from an accessing user, determining the accessing user's historical query information through the smart city cloud platform; verifying the accessing user's identity based on a preset identity registration chain; if the accessing user passes identity verification, assessing the accessing user's trust value based on the historical query information; verifying the trust value; if the accessing user passes trust verification, constructing a pierceable key structure by combining the accessing user's trust value, a preset ABAC model, and a preset smart city consortium blockchain; dynamically managing access permissions for the accessing user using the pierceable key structure, authorizing the accessing user's identity based on the pierceable key structure, and sharing the data queried by the accessing user. This application can effectively improve the management efficiency of smart cities.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of data sharing, and in particular to a smart city cloud platform data authorization sharing method and system based on a blockchain. BACKGROUND

[0002] With the rapid development of information technology, smart city construction has become an important means to improve urban governance capacity and public service level. As the core hub of data integration and sharing, the smart city cloud platform has gathered massive heterogeneous data from multiple fields such as government affairs, transportation, medical care, and environment, which is crucial to the intelligent operation of the city.

[0003] At present, the smart city covers multiple subjects such as enterprises, medical institutions, and education departments, but each subject has its own system in data management and use. Data providers tend to "not share data" or "share data minimally" due to concerns about data misuse and privacy leakage, thus forming the phenomenon of "data islands", which hinders cross-field collaborative innovation and development. For example, insurance companies need to obtain patient medical data to optimize insurance pricing, but hospitals refuse to share due to privacy protection concerns, which will lead to lagging innovation of insurance products, and the inability to provide customized insurance solutions based on the real health status and medical history of patients, thereby affecting the management efficiency of the smart city.

[0004] At present, there is no good solution to the above problems. SUMMARY

[0005] Embodiments of the present application provide a smart city cloud platform data authorization sharing method and system based on a blockchain, which is used to improve the management efficiency of the smart city.

[0006] To achieve the above purpose, embodiments of the present application adopt the following technical solutions:

[0007] In a first aspect, a smart city cloud platform data authorization sharing method based on a blockchain is provided, applied to a smart city cloud platform, and the method includes the following steps:

[0008] In response to receiving a query instruction of an access user, determining the historical query information of the access user through the smart city cloud platform;

[0009] Based on a preset identity registration chain, performing identity verification on the access user, and if the access user passes the identity verification, evaluating the trust value of the access user according to the historical query information;

[0010] Performing trust degree verification on the trust value;

[0011] If the accessing user passes the trust verification, a puncturable key structure is constructed by combining the accessing user's trust value, the preset ABAC model, and the preset smart city alliance chain.

[0012] The access user is dynamically managed using the pierceable key structure, and the access user is authorized based on the pierceable key structure, and the data queried by the access user is shared.

[0013] In one possible implementation of the first aspect, the preset identity registration chain and the preset smart city alliance chain include the following steps:

[0014] The process of obtaining the smart city operation process and the registration information process of registered users within the smart city cloud platform, wherein the registration information process includes at least two registration process nodes and the smart city operation process includes at least two operation process nodes;

[0015] Based on all the registration process nodes, build an identity registration chain for all the registered users, obtain the registration information of all the registration process nodes, and upload the registration information to the identity registration chain;

[0016] A smart city consortium blockchain for the target city is built based on all the aforementioned process nodes. The operation information of all the aforementioned process nodes is obtained and uploaded to the smart city consortium blockchain.

[0017] In one possible implementation of the first aspect, the step of authenticating the accessing user based on a preset identity registration chain, and if the accessing user passes authentication, assessing the trust value of the accessing user based on the historical query information, includes the following steps:

[0018] Extract the first hash value of the identity information and biometric information corresponding to the accessing user from the preset smart contract;

[0019] The registration information of the accessing user is extracted from the preset identity registration chain, and a second hash value of the registration information is calculated using a preset hash function;

[0020] The first hash value is compared with the second hash value. If the first hash value and the second hash value are equal, it is determined that the accessing user has been authenticated.

[0021] When the accessing user passes authentication, the historical query information is used to determine the accessing user's historical successful access count and historical illegal access count;

[0022] The trust value of the accessing user is calculated by combining the number of successful historical accesses and the number of illegal historical accesses.

[0023] In one possible implementation of the first aspect, calculating the trust value of the accessing user by combining the historical successful access count and the historical illegal access count includes the following steps:

[0024] The probability of a user's successful access is predicted by combining the number of historical successful accesses and the number of historical illegal accesses using a preset probability density function.

[0025] The average probability of a successful access is calculated using a Bayesian estimation algorithm by combining the historical successful access count and the historical illegal access count.

[0026] The initial trust value is obtained by weighted fusion of the successful access probability and the average successful access probability.

[0027] The trust value of the accessing user is calculated by combining the initial trust value and the preset time decay factor.

[0028] In one possible implementation of the first aspect, the following steps are included before constructing the puncturable key structure by combining the access user's trust value, a preset ABAC model, and a preset smart city consortium blockchain:

[0029] Retrieve the historical successful access count and historical illegal access count for all registered users;

[0030] The user trust value corresponding to each registered user is calculated by combining the number of successful accesses and the number of illegal accesses in history using a preset probability density function and a Bayesian estimation algorithm.

[0031] The smart city consortium blockchain is initialized using a pre-defined key center, which generates the public parameters and master key of the smart city consortium blockchain.

[0032] By combining the user trust value, the public parameters, and the master key corresponding to each registered user, a public key and a private key for each registered user are generated.

[0033] In one possible implementation of the first aspect, the construction of a puncturable key structure by combining the access user's trust value, a preset ABAC model, and a preset smart city consortium blockchain includes the following steps:

[0034] The attribute evaluation results for the accessing user are determined based on the preset ABAC model.

[0035] Based on the attribute evaluation results corresponding to the accessing user, a first-level key fragment corresponding to the accessing user is generated using a key generation algorithm;

[0036] The first-level key fragment is supplemented by the trust value of the accessing user to determine the second-level key fragment corresponding to the accessing user;

[0037] The user permission level of the accessing user is determined by combining the first-level key fragment and the second-level key fragment;

[0038] A puncturable key structure is constructed based on the user's permission level and the master key.

[0039] In one possible implementation of the first aspect, the user permission levels include high-level users and low-level users, and the puncturable key structure includes the following steps:

[0040] When the advanced user receives the delegated key from the low-level user, the advanced user determines the attribute level and real-time trust value of the low-level user based on the preset ABAC model and the smart city consortium blockchain.

[0041] If the real-time trust value of the low-level user exceeds a preset trust threshold and the attribute level is a preset specific role attribute, then the high-level user distributes a delegation key to the low-level user.

[0042] If the real-time trust value of the low-level user does not exceed the preset trust threshold and the attribute level is not a preset specific role attribute, then the high-level user refuses to distribute the delegation key to the low-level user.

[0043] After the high-privilege user distributes the delegated key to the low-privilege user, the high-privilege user obtains the real-time trust value of the low-privilege user through the smart contract of the smart city alliance chain.

[0044] When the real-time trust value of the low-level user is lower than the preset trust threshold, the delegated key of the low-level user is subjected to a puncture operation using the Puncture algorithm.

[0045] When the real-time trust value of the advanced user is lower than the preset trust threshold, the attribute level and key corresponding to the advanced user will be unbound.

[0046] In one possible implementation of the first aspect, the dynamic access management of the access user using the pierceable key structure, the authorization of the access user based on the pierceable key structure, and the sharing of the data queried by the access user include the following steps:

[0047] The identity level of the accessing user is determined by combining the described pierceable key structure;

[0048] The identity level is mapped to a preset permission level system to determine the permission level corresponding to the identity level;

[0049] The encryption technology of the described puncturable key structure is used to generate the authorization credential corresponding to the permission level;

[0050] The authenticity and completeness of the authorization certificate are verified.

[0051] If the authorization credential is verified, it is determined to be the shared data of the accessing user.

[0052] Secondly, this application provides a machine-readable storage medium storing instructions that cause a machine to execute the aforementioned blockchain-based smart city cloud platform data authorization and sharing method.

[0053] Thirdly, this application provides a blockchain-based smart city cloud platform data authorization and sharing system, including:

[0054] The memory is configured to store instructions; and

[0055] The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the aforementioned blockchain-based smart city cloud platform data authorization and sharing method.

[0056] The above technical solution uses a pre-defined identity registration chain to authenticate users and assess their trust value based on historical query information. This effectively filters out legitimate users, prevents unauthorized access, and protects user privacy and data security. By combining user trust values, a pre-defined ABAC model, and a pre-defined smart city consortium blockchain, a puncturable key structure is constructed. This allows for dynamic adjustment of user access permissions based on their trust value, significantly improving system flexibility and enabling users to access data as needed. Trust value assessment also ensures access security and prevents abuse of permissions. Blockchain technology promotes data sharing between different institutions or departments, breaking down information silos and facilitating data interconnection and efficient utilization. Assessing user trust values ​​based on historical query information and identity verification results provides a scientific basis for data sharing and access control. Continuous monitoring of user access behavior allows for dynamic updates to trust values, ensuring the accuracy and timeliness of the trust system. The deep integration of blockchain technology and access control models enables real-time responses to permission changes, ensuring the principle of least privilege in data authorization and improving the management efficiency of smart cities.

[0057] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0058] Figure 1 A flowchart illustrating a data authorization and sharing method for a blockchain-based smart city cloud platform, provided as an embodiment of this application;

[0059] Figure 2 This is a schematic diagram of a data query structure based on a smart city cloud platform, provided as an embodiment of this application. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0061] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0062] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0063] Figure 1 The illustration shows a flowchart of a blockchain-based smart city cloud platform data authorization and sharing method according to an embodiment of this application. Figure 1 As shown in the figure, this application provides a data authorization and sharing method for a smart city cloud platform based on blockchain, which is applied to a smart city cloud platform. The method may include the following steps.

[0064] S110. In response to receiving a query instruction from a user, determine the user's historical query information through the smart city cloud platform;

[0065] S120. Verify the identity of the accessing user based on the preset identity registration chain. If the accessing user passes the identity verification, evaluate the trust value of the accessing user based on historical query information.

[0066] S130. Verify the trust level of the trust value;

[0067] S140. If the accessing user passes the trust verification, construct a puncturable key structure by combining the accessing user's trust value, the preset ABAC model, and the preset smart city alliance chain.

[0068] S150. Utilize a puncturable key structure to perform dynamic access control for accessing users, authorize accessing users based on the puncturable key structure, and share the data queried by accessing users.

[0069] First, in response to receiving a query instruction from a user, the smart city cloud platform determines the user's historical query information. In this embodiment, a user refers to any entity that requests access to data or resources through platform interfaces, applications, or terminal devices. The term "user" here is not limited to natural persons but may also include enterprises, institutions, systems, or third-party applications. After a user sends a data query request to the smart city cloud platform through a terminal device (such as a mobile phone or computer), the smart city cloud platform receives the user's query instruction through API interfaces, front-end interfaces, and other channels, and parses parameters such as data type and query scope in the request. The smart city cloud platform pre-records each user's query behavior, forming a user behavior log. Historical query information may include basic user information such as query time, query IP address, and device type used; and user query content such as the specific data category requested (e.g., medical data, traffic data) and data fields (e.g., PM2.5 values, intersection camera numbers).

[0070] After obtaining the historical query information of the accessing user, the platform verifies the user's identity based on a pre-defined identity registration chain. If the accessing user passes the verification, the platform assesses the user's trust value based on the historical query information. In this embodiment, the identity registration chain is a blockchain network pre-installed in the smart city cloud platform. It is responsible for storing and managing the identity information of all registered users. This information may include the user's unique identifier, public key, private key, registration time, etc., and all information is encrypted to ensure security. When an accessing user initiates a query, the smart city cloud platform first verifies the user's identity using the identity registration chain. The verification process may include checking whether the identity credentials provided by the user are consistent with the information stored in the identity registration chain. If the verification is successful, it means that the user is a legitimate registered user and has the right to access the data of the smart city cloud platform. Once the accessing user passes the verification, the smart city cloud platform assesses the user's trust value based on the user's historical query information. Historical query information may include the data types queried by the user in the past, the query time, the query frequency, and the usage of the query results. By analyzing the user's historical query behavior, the platform can understand the user's query habits, data usage preferences, and potential data abuse risks. Trust value is an important indicator for assessing user reliability and data abuse risks. The smart city cloud platform dynamically adjusts user access permissions based on their trust level, ensuring that users can only access the data they are authorized to access. Users with higher trust levels may have broader access rights, while users with lower trust levels may be subject to stricter restrictions. This dynamic access management mechanism helps prevent data misuse and leakage, and improves the security of data sharing.

[0071] After obtaining a user's trust value, the platform verifies that trust level. This means that once a user passes authentication, the smart city cloud platform confirms their legitimate identity. However, a legitimate identity does not mean the user can access all data without restriction. Therefore, further trust level verification is needed to ensure that the user's behavior complies with system regulations and does not pose a threat to data security. Trust level verification is based on the user's historical behavior and current behavioral patterns. The smart city cloud platform analyzes the user's historical query records, data access frequency, and data usage to assess their trust value. If the user's trust value reaches or exceeds a preset threshold, the user is considered to have passed the trust level verification and can further access data; if the trust value is below the threshold, the user's access permissions may be restricted or access requests may be denied. Trust level verification effectively prevents low-trust users from accessing sensitive data, reducing the risk of data leakage and misuse. Simultaneously, trust level verification also helps maintain system stability and reliability, ensuring the normal operation of data sharing services.

[0072] If a user passes trust verification, a puncturable key structure is constructed by combining the user's trust value, a pre-defined ABAC model, and a pre-defined smart city consortium blockchain. This puncturable key structure is a dynamic key management system based on user trust values, dynamically adjusting access permissions according to the user's trust value to achieve finer-grained access control. The ABAC model is a flexible access control mechanism that determines whether a user can access a resource based on user attributes and resource attributes (such as sensitivity and importance). Combining the ABAC model with the puncturable key structure ensures the flexibility and accuracy of access control policies. The smart city consortium blockchain is a blockchain network jointly participated in by multiple organizations or institutions, enabling data sharing and collaborative management. When constructing the puncturable key structure, the system utilizes the technology and resources of the smart city consortium blockchain to ensure the security and reliability of key management. The puncturable key structure allows the system to dynamically adjust user access permissions based on their trust value, achieving more granular access control and helping to prevent abuse of permissions and data leakage. By combining trust values, the ABAC model, and the smart city consortium blockchain, the puncturable key structure constructs a multi-layered security protection system, effectively improving the security of data sharing. Punctureable key structures can provide a secure and reliable framework for data sharing, helping to facilitate data sharing and collaboration between different organizations or institutions.

[0073] Subsequently, a pierceable key structure is used for dynamic access control of users. Based on this structure, user authorization is granted, and data queried by users is shared. Dynamic access control means that user access permissions are not static but can be adjusted in real time based on their trust level and other relevant factors (such as query behavior and data usage). By dynamically adjusting permissions, access for low-trust users can be restricted to prevent data abuse, while allowing high-trust users to access more data, improving data sharing efficiency. The range of data a user can access and their access level are determined based on their trust level. The higher the trust level, the wider the range of data a user can access and the higher their access level. Furthermore, the ABAC model determines whether a user can access a resource based on user attributes (such as role, department, position) and resource attributes (such as sensitivity and importance). In the pierceable key structure, the ABAC model is used to further refine access control policies. Using a smart city consortium blockchain, data sharing and collaborative management can be achieved. During dynamic access control, the technology and resources of the consortium blockchain are used to ensure the security and reliability of key management, authorize users, and share data queried by them.

[0074] By authenticating users through a pre-defined identity registration chain and assessing their trust value based on historical query information, legitimate users can be effectively screened, preventing unauthorized access and protecting user privacy and data security. Combining user trust values, a pre-defined ABAC model, and a pre-defined smart city consortium blockchain, a puncturable key structure is constructed. This allows for dynamic adjustment of user access permissions based on their trust value, significantly improving system flexibility and enabling users to access data as needed. Trust value assessment also ensures access security and prevents abuse of privileges. Blockchain technology promotes data sharing between different institutions or departments, breaking down information silos and facilitating data interconnection and efficient utilization. Assessing user trust values ​​based on historical query information and authentication results provides a scientific basis for data sharing and access control. Continuous monitoring of user access behavior allows for dynamic updates to trust values, ensuring the accuracy and timeliness of the trust system. The deep integration of blockchain technology and access control models enables real-time responses to permission changes, ensuring the principle of least privilege for data authorization and improving the management efficiency of smart cities.

[0075] In one embodiment of this example, the preset identity registration chain and the preset smart city alliance chain include the following steps:

[0076] S210. Obtain the smart city operation process and the registration information process of registered users within the smart city cloud platform. The registration information process includes at least two registration process nodes, and the smart city operation process includes at least two operation process nodes.

[0077] S220. Build an identity registration chain for all registered users based on all registration process nodes, obtain the registration information of all registration process nodes, and upload the registration information to the identity registration chain.

[0078] S230. Build a smart city alliance chain for the target city based on all operational process nodes, obtain operational information of all operational process nodes, and upload the operational information to the smart city alliance chain.

[0079] First, the system acquires the smart city operation process and the registration information process of registered users within the smart city cloud platform. The registration information process includes at least two registration process nodes, and the smart city operation process includes at least two operation process nodes. The smart city operation process refers to the digital management process of urban infrastructure (such as transportation, energy, and government affairs), which may include various business processes in urban management and services, involving specific scenarios of urban operation, and contains at least two stages. For example, in the traffic congestion management process, process nodes could be data monitoring and contingency plan triggering. The registration information process refers to the entire process of a user completing registration on the platform, containing at least two stages (nodes). For example, the registration information process may include information submission, identity verification, and permission allocation.

[0080] Secondly, an identity registration chain is built based on all registration process nodes to obtain registration information from all registration process nodes and upload this information to the identity registration chain. In this embodiment, the identity registration chain is a distributed ledger built on blockchain technology to store and manage the identity information of all registered users. Building the identity registration chain first requires identifying all key nodes in the user registration process, which may include user information entry, identity verification, and registration review. Then, blockchain interaction logic is designed for each registration process node. For example, at the user information entry node, the information submitted by the user is encrypted and prepared for uploading to the chain; at the identity verification node, blockchain technology is used for identity verification, and the verification result is uploaded to the chain. Finally, smart contracts are deployed on the identity registration chain to automate certain steps in the registration process, such as identity verification and registration review. Smart contracts ensure the fairness and transparency of the registration process. Next, registration information from all registration process nodes is obtained. In the user registration process, information submitted by users is collected from each registration process node, which may include basic user information, identity verification information, and registration review information. The collected registration information is verified and cleaned to ensure its accuracy and completeness. For example, verifying the validity of user-submitted ID numbers and removing duplicate or invalid information. Before uploading registration information to the blockchain, encryption technology is used to encrypt the information to ensure its security during transmission and storage, preventing malicious tampering or leakage. The encrypted registration information is then uploaded to the identity registration chain via smart contracts or blockchain client tools. During the upload process, the integrity and consistency of the information must be ensured to prevent tampering or loss during transmission. The uploaded registration information will be stored on various nodes of the identity registration chain, forming distributed storage. This improves the reliability and availability of information; even if a node fails, it will not affect the normal operation of the entire identity registration chain. Simultaneously, the identity registration chain provides convenient information query functions. Users or administrators can query user identity information through blockchain client tools, ensuring transparency and traceability.

[0081] A smart city consortium blockchain is built based on all operational process nodes to acquire operational information from all nodes and upload this information to the blockchain. The smart city consortium blockchain, built on blockchain technology, connects different departments, institutions, or enterprises within a city, aiming to achieve data sharing and collaborative management, break down information silos, and improve the intelligence level of urban management. Through the smart city consortium blockchain, departments and institutions can share urban operational data, collaborate, and provide more convenient and efficient services to city residents. Next, building the smart city consortium blockchain requires first identifying all key nodes in the urban operational process. These nodes may include multiple areas such as traffic management, energy allocation, public safety, environmental monitoring, and healthcare. Corresponding blockchain interaction logic is designed for each operational process node. For example, at the traffic management node, logic for uploading traffic flow data to the blockchain can be designed; at the energy allocation node, logic for uploading energy consumption data to the blockchain can be designed, and so on. Finally, smart contracts are deployed on the smart city consortium blockchain to automate certain steps in the operational process. For example, smart contracts can be deployed to automate the handling of traffic violations or the adjustment of energy allocation strategies. Next, operational information from all process nodes is acquired, collecting data from each node during city operation. This data may include traffic flow, energy consumption, environmental monitoring data, and public safety incidents. Before uploading the operational information to the blockchain, encryption technology is used to ensure its security during transmission and storage, preventing malicious tampering or leakage. The encrypted operational information is then uploaded to the smart city consortium blockchain via smart contracts or blockchain client tools. During the upload process, the integrity and consistency of the information must be ensured to prevent tampering or loss during transmission. The uploaded operational information will be stored on various nodes of the smart city consortium blockchain, forming distributed storage. This improves the reliability and availability of information; even if a node fails, it will not affect the normal operation of the entire smart city consortium blockchain. Simultaneously, the smart city consortium blockchain provides convenient information query functions.

[0082] By constructing an identity registration chain and a smart city alliance chain, the authenticity and security of user identity information can be guaranteed, preventing the risks of identity theft and information tampering, improving data security, and enabling secure data sharing, cross-departmental collaboration, improved management efficiency, and optimized user experience.

[0083] In one embodiment of this invention, the access user is authenticated based on a preset identity registration chain. If the access user passes authentication, the trust value of the access user is evaluated based on historical query information, including the following steps:

[0084] S310. Extract the first hash value of the identity information and biometric information corresponding to the accessing user from the preset smart contract;

[0085] S320. Extract the registration information of the accessing user from the preset identity registration chain, and calculate the second hash value of the registration information using the preset hash function;

[0086] S330. Compare the first hash value with the second hash value. If the first hash value and the second hash value are equal, then it is determined that the accessing user has been authenticated.

[0087] S340. When an accessing user is authenticated, the number of successful accesses and the number of unauthorized accesses in the past are determined by querying historical information.

[0088] S350. Calculate the trust value of the accessing user by combining the number of successful accesses and the number of illegal accesses in history.

[0089] The first hash value, representing the user's identity and biometric information, is extracted from a pre-defined smart contract. In this embodiment, the pre-defined smart contract refers to the smart contract of the identity registration chain. In the identity registration chain of the smart city cloud platform, smart contracts are deployed on the blockchain to automate operations related to user identity, such as identity verification and permission allocation. The smart contract can store and manage user identity information, including basic information and biometric information. The first hash value refers to the hash value of the user's identity and biometric information stored in the pre-defined smart contract. To ensure the security and privacy of user identity information, the smart city cloud platform typically performs hashing processing on this information. Hashing is a process of mapping data of arbitrary length to a fixed-length string. Hash values ​​are unique, meaning that different data are almost impossible to generate the same hash value. In the identity registration chain, the user's identity and biometric information are hashed and stored in the smart contract. Extracting the first hash value of the user's identity and biometric information from the pre-defined smart contract is usually for identity verification or data integrity checks. First, when a user initiates a query, the smart city cloud platform verifies the user's identity using the identity registration chain. During this verification process, the platform extracts the hash values ​​(i.e., the first hash value) of the user's identity information and biometric data from the smart contract. Then, the platform hashes the user's provided identity credentials (such as digital certificates, usernames, and passwords) or biometric data (such as fingerprints or facial images) to generate a second hash value. Finally, the platform compares the first and second hash values. If they match, it means the user's provided identity credentials or biometric data match the information stored in the smart contract, and the user has passed identity verification.

[0090] Next, the platform extracts the user's registration information from the pre-defined identity registration chain and calculates a second hash value using a pre-defined hash function. The identity registration chain, built on blockchain technology, stores and manages the identity information of all registered users. When a user initiates a query, the smart city cloud platform extracts that user's registration information from the identity registration chain. This information is typically stored in smart contracts, which are automated execution programs deployed on the blockchain to manage user identity information. After extracting the user's registration information, the smart city cloud platform uses the pre-defined hash function to calculate the second hash value. This calculation may involve passing the registration information as input to the hash function and then obtaining the hash value output by the function. The second hash value is used for subsequent authentication or data integrity checks. For example, during authentication, the platform compares the second hash value with the first hash value (i.e., the hash value of the user's identity information and biometric information) stored in the smart contract to verify the user's identity.

[0091] The first hash value is compared with the second hash value. If they are equal, the user is considered authenticated. The smart city cloud platform then compares the first hash value extracted from the smart contract with the second hash value extracted and calculated from the identity registration chain. If they are equal, it means the user's identity credentials or biometric data match the information stored during registration, and the user has passed authentication. Once authenticated, the smart city cloud platform allows the user to access their authorized data and services. This ensures that only legitimate and trusted users can access specific data, preventing unauthorized access and data breaches.

[0092] When a user successfully authenticates, historical query information is used to determine the user's past successful and unauthorized access counts. This can be achieved by accessing the smart city cloud platform's database. The smart city cloud platform records detailed information about each access, including access time, accessed resources, and access results. These records are stored in the database for subsequent querying and analysis. The query results retrieved from the database show that successful access counts refer to the number of times a user has successfully accessed the system or service after authentication. Unauthorized access counts refer to the number of times a user attempted to access the system but failed authentication, or accessed unauthorized resources.

[0093] The trust score of a user is calculated by combining the number of successful and unauthorized accesses in the past. In this embodiment, the trust score is typically calculated using both historical successful and unauthorized access counts. The trust score is a quantitative indicator used to assess the reliability of a user's behavior when accessing the smart city cloud platform in the past, reflecting the degree to which the user complies with platform rules and legally accesses resources. By calculating the trust score, the smart city cloud platform can more accurately identify potential security risks, such as malicious attacks and unauthorized access. The trust score can also serve as a basis for dynamically adjusting user permissions, providing more convenient services to users with high trust scores while implementing stricter access control for users with low trust scores.

[0094] By assessing the trust value of users based on historical query information, the smart city cloud platform can more accurately evaluate the reliability of user behavior, dynamically adjust user permissions, and enhance system security. It can also better monitor user behavior, evaluate system security, and take corresponding security measures to protect the security of system and user data.

[0095] In one embodiment of this example, calculating the trust value of an accessing user by combining the number of historical successful accesses and the number of historical illegal accesses includes the following steps:

[0096] S410. Combine the historical successful access count and the historical illegal access count to predict the probability of a user's successful access using a preset probability density function;

[0097] S420. Calculate the average probability of a successful access by combining the historical number of successful accesses and the historical number of illegal accesses using a Bayesian estimation algorithm.

[0098] S430. The initial trust value is obtained by weighted fusion of the successful access probability and the average successful access probability.

[0099] S440: Calculate the trust value of the accessing user by combining the initial trust value and the preset time decay factor.

[0100] First, by combining historical successful access counts and historical illegal access counts, a preset probability density function is used to predict the probability of a user's successful access. The cumulative number of successful accesses (such as legitimate user logins and resource acquisition) is the historical successful access count; the cumulative number of illegal accesses (such as unauthorized login attempts and malicious attacks) is the historical illegal access count. They reflect the status of past access behavior. In this embodiment, the preset probability density function is a function describing the probability distribution of a random variable. In this scenario, the user's successful access probability can be considered a random variable, with a value ranging from 0 to 1. In this embodiment, the historical successful access count is specifically represented as Y. i =N i+1; the number of historical unauthorized visits is represented by Y. j =N j +1; This increments the count of successful historical visits and the count of illegal historical visits by one to avoid computational issues caused by the counts being zero. The preset probability density function is specifically expressed as:

[0101]

[0102] Among them, Y i Y represents the number of successful visits in history. j Γ represents the number of illegal accesses in history, p represents the probability of a user's successful access, and Γ is the gamma function, which is often used in probability and statistics to handle calculations involving factorial forms.

[0103] The historical successful access count and historical illegal access count are substituted into a preset probability density function to predict the probability of a user's successful access.

[0104] Subsequently, the average probability of a successful access is calculated using a Bayesian estimation algorithm, combining historical successful access counts and historical illegal access counts. Bayes' theorem describes how to update the prior probability based on new evidence to obtain the posterior probability, i.e., correcting the probability of an unknown event based on known information. First, the prior probability is determined. Without any historical data, an initial probability of a successful access can be set based on experience or common sense; for example, assuming that successful and illegal accesses are equally likely, the prior probability is set to 0.5. Assuming the historical successful access count is S and the historical illegal access count is F, the prior probability is updated using Bayes' formula, analogous to Bayesian estimation of the binomial distribution. Let the prior distribution be a Beta distribution with parameters α and β, where α and β are hyperparameters that can be initialized to 1 (uniform distribution) or adjusted based on domain knowledge. The prior distribution can be chosen in different ways. If an uninformative prior is used (i.e., no biased assumptions about the outcome), α = β = 1. According to Bayesian estimation, the posterior distribution is still a Beta distribution, and its parameters are updated to α′ = α + S and β′ = β + F.

[0105] For a Beta distribution with parameters α′ and β′, its expected value (i.e., the average probability of a successful visit) is calculated using the following formula:

[0106]

[0107] The average success rate of access is calculated using the formula above.

[0108] Next, the successful access probability and the average successful access probability are weighted and fused to obtain a preliminary trust value. Weighted fusion is a mathematical processing method that assigns different weights (weights are values ​​between 0 and 1, and the sum of the two weights is 1) to the successful access probability and the average successful access probability, and then combines the two probability values ​​by weighted summation. The preliminary trust value is a value obtained through the above weighted fusion operation, used to initially measure the degree of trust in the visitor or access behavior. The higher the value, the more trustworthy it is generally considered to be. In this embodiment, the successful access probability and the average successful access probability can be determined according to the actual situation. For example, let the successful access probability be Ps, with its weight ws; the average successful access probability be Pavg, with its weight wavg, and ws + wavg = 1. Then the formula for calculating the preliminary trust value T is: T = ws × Ps + wavg × Pavg. For example, if ws=0.6, Ps=0.8, wavg=0.4, Pavg=0.7, then T=0.6×0.8+0.4×0.7=0.76.

[0109] The trust value of the visiting user is calculated by combining the initial trust value and a preset time decay factor. In this embodiment, the initial trust value is a value obtained by weighting and fusing the probability of successful access and the average probability of successful access. It initially reflects the degree of trust in the visiting user and is the basic data for calculating the final trust value. The time decay factor is a preset parameter used to reflect the characteristic that the trust value decreases over time. The influence of the user's past access behavior on the current trust assessment weakens over time; the longer the time, the lower the reference value of past behavior. An exponential decay model is used to combine the initial trust value and the time decay factor to calculate the trust value of the visiting user. Assuming the initial trust value is T0, the time decay factor is λ, and the time interval between the current time and the last trust value calculation is Δt, the formula for calculating the trust value T of the visiting user can be expressed as:

[0110]

[0111] For example, if the initial trust value T0 = 0.8, the time decay factor λ = 0.9, and 3 time units have passed since the last trust value calculation (Δt = 3), then T = 0.8 × 0.9 3 =0.8×0.729=0.5832, thus obtaining the trust value of the accessing user.

[0112] By calculating the trust value of accessing users and considering overall access trends based on comprehensive historical data, multi-faceted analysis provides a more comprehensive and accurate assessment of the probability of successful access, laying a solid foundation for trust value calculation. Weighted fusion of probabilities obtained from two different methods integrates single-access characteristics and overall historical data, overcoming the limitations of single methods and allowing the initial trust value to more accurately reflect the credibility of user access. A time decay factor is introduced, causing the trust value to change dynamically over time. This adapts to the evolution of access behavior over time; for example, the trust value of long-term inactive users automatically decreases, allowing for stronger verification upon subsequent accesses, better coping with complex and ever-changing network environments. Multi-step trust value calculation allows for more precise differentiation between legitimate and illegitimate access. For accesses with low trust values, measures such as two-factor authentication and access restrictions are implemented to effectively prevent security threats such as unauthorized intrusion and account theft, improving overall system security.

[0113] In one embodiment of this example, the following steps are included before constructing the puncturable key structure by combining the trust value of the accessing user, the preset ABAC model, and the preset smart city consortium blockchain:

[0114] S510. Obtain the historical successful access count and historical illegal access count of all registered users;

[0115] S520. Calculate the user trust value for each registered user by combining the number of successful and illegal accesses in history with the preset probability density function and Bayesian estimation algorithm.

[0116] S530. Generate the public parameters and master key of the smart city alliance chain by executing the system initialization algorithm through the preset key center.

[0117] S540. Combine the user trust value, public parameters and master key corresponding to each registered user to generate the public key and private key for each registered user.

[0118] Figure 2 This application provides a schematic diagram of a data query structure based on a smart city cloud platform, as shown in the embodiments of this application. Figure 2 As shown, initialization is first performed through the key center, which then sends keys to data users. After a data user initiates access to the blockchain, the blockchain verifies the access and downloads the data using the smart city cloud platform, sending it to the data user.

[0119] This involves retrieving the historical successful and unauthorized access counts for all registered users. This refers to collecting the number of successful and unauthorized accesses each registered user has made within the system over a given period. Successful accesses refer to the number of times a user has logged into the system or accessed resources legally and normally (e.g., successful account and password verification, or successful permission matching). Unauthorized accesses refer to the number of times a user attempted to log in or access the system illegally (e.g., incorrect passwords, unauthorized access, malicious attacks, etc., which are identified as insecure access behaviors by the system). This data can be obtained through database storage. Each time a user accesses the platform, access behavior data is recorded in real-time using technical means and stored in log files or database tables.

[0120] By combining the historical successful access count and historical illegal access count of each registered user, a user trust value is calculated using a preset probability density function and a Bayesian estimation algorithm. First, the probability of a registered user's successful access is predicted using the preset probability density function and each registered user's historical successful access count and historical illegal access count. The preset probability density function can be:

[0121]

[0122] Among them, Y i Y represents the number of successful visits in the history of registered users. j Γ represents the number of unauthorized accesses by a registered user in history, p represents the probability of a registered user's successful access, and Γ is the gamma function, which is often used in probability and statistics to handle calculations involving factorial forms.

[0123] After obtaining the successful access probability of registered users, the average successful access probability is calculated using a Bayesian estimation algorithm by combining the historical successful access count and the historical illegal access count. The average successful access probability and the predicted successful access probability of each registered user are then weighted and fused to obtain the user trust value corresponding to each registered user.

[0124] Subsequently, the smart city consortium blockchain is initialized using a pre-defined key center. This initialization process generates the blockchain's public parameters and master key. This process, which establishes an initial security system through cryptography, primarily involves using the pre-defined key center to generate the fundamental parameters and core keys required for blockchain operation. The smart city consortium blockchain is a blockchain jointly managed by multiple organizations; nodes must be authenticated to join, ensuring both security and controllability. The key center is a security module responsible for generating, managing, and distributing cryptographic keys, typically controlled by a trusted institution (such as the consortium blockchain management committee) to ensure the confidentiality and attack resistance of the key generation process. The system initialization algorithm is the initialization program executed when the blockchain system starts, used to create initial cryptographic parameters, node identity systems, and consensus rules. First, initialization is performed through the key center, which acts as a trusted source and calls a pre-defined initialization algorithm (such as an algorithm library based on cryptographic standards). The initialization process may rely on Hardware Security Modules (HSMs) or Multi-Party Computation (MPC) technology to ensure the key generation process is not tampered with. Then, public parameters are generated. These public parameters are publicly shared by all nodes in the consortium blockchain, used to unify basic settings such as encryption algorithms and consensus rules. The master key is the "root key" used to generate other keys. It has the highest authority and can be used to generate node identity keys (such as CA certificate private keys), sign the initial configuration of the chain (such as genesis block signature), and serve as a trust anchor for subsequent key updates or cross-chain interactions. The master key must be kept strictly confidential and can be stored using multi-signature (Multi-Sig) or key sharding (such as the Shamir algorithm) to avoid control by a single institution.

[0125] By combining the user trust value, public parameters, and master key for each registered user, a public key and private key are generated for each registered user. First, the key parameters are adjusted based on the trust value, mapping the trust value to the key parameters. For example, the trust value can be used as one of the input factors for a random number generator. Assuming the trust value is T and the elliptic curve base point in the public parameters is G, the private key d can be expressed as: d = H(T ⊕ Master Key Derivation Seed ⊕ User ID), where d represents the private key, which is the key secretly held by the user in an asymmetric encryption system, used to sign data or decrypt data encrypted with the public key; H represents the hash function; T refers to the user trust value, a quantitative indicator calculated based on the user's historical behavior (such as the number of successful accesses, the number of illegal accesses, etc.), used to measure the user's trustworthiness; ⊕ is the XOR operator, the rule of which is that the result is 0 if the two operands are the same, and 1 if they are different. For example, 1⊕0=1, 1⊕1=0; the master key derivation seed refers to the seed data derived from the master key, which is the root key with the highest authority in the system, and can be used to further generate user-related keys. The master key derivation seed provides a foundation for private key generation based on the highest trust level in the system; the user ID is an identity number used to uniquely identify each user in the system. Next, permission binding is performed. The master key can be pre-configured with a "trust value-permission" mapping table, for example:

[0126] Trust value range Corresponding permissions Key usage T≥80 Data read-write + block verification Can be used to sign transactions and participate in consensus 50≤T<80 Data read-only Used only to decrypt public data T<50 Limited access Key can only access non-sensitive interfaces

[0127] The master key serves as the "root of trust" for key generation. The derived key seed, being the highest-level key, is used to derive a "seed key" when generating user keys, ensuring all user keys rely on the system's root trust. For example, the master key generates the user key seed SK = HMACMK(User ID⊕T) using the HMAC algorithm, and then the final public-private key pair is generated based on SK. Key lifecycle management refers to the master key's ability to be used for subsequent key updates (e.g., periodically rotating user private keys) or key revocation (e.g., freezing a user's key when their trust value drops sharply). The standardization of public parameters ensures that all users' key generation follows a unified cryptographic standard. For example, elliptic curve parameters (e.g., curve equation, base point coordinates) are defined by public parameters to prevent interoperability issues caused by different users using different curves; hash algorithms (e.g., SHA-3) and signature algorithms (e.g., ECDSA) are also specified by public parameters to ensure consistency in signature verification.

[0128] By combining a "trust value + system root key + standardized parameters," a key pair with both security and access control attributes is generated for users. The trust value determines the access control boundaries of the key, the master key ensures root trust in the system, and the public parameters guarantee technical compatibility. This also enables the goal of "efficient access for trusted users and strict control over risky users," while providing technical support for data security, access control auditing, and compliance management.

[0129] In one embodiment of this example, constructing a puncturable key structure by combining the trust value of the accessing user, a preset ABAC model, and a preset smart city consortium blockchain includes the following steps:

[0130] S610. Based on the preset ABAC model, perform attribute evaluation on the accessing user and determine the attribute evaluation result corresponding to the accessing user.

[0131] S620. Generate the first-level key fragment corresponding to the accessing user based on the attribute evaluation result of the accessing user using the key generation algorithm.

[0132] S630. Supplement the first-level key fragment with the trust value of the accessing user to determine the second-level key fragment corresponding to the accessing user.

[0133] S640. Combine the first-level key fragments and the second-level key fragments to determine the user's access permission level;

[0134] S650: Construct a puncturable key structure based on user privilege levels and master keys.

[0135] Based on a pre-defined ABAC model, attribute evaluation is performed on accessing users to determine the corresponding attribute evaluation results. In this embodiment, the ABAC model is an attribute-based access control model that determines whether to authorize access by evaluating the attributes of the subject (user), object (resource), and environmental conditions. The attribute evaluation result is the authorization decision (such as "allow access", "deny access", "multi-factor authentication required") output after comprehensively calculating user attributes, resource attributes, and environmental attributes according to the ABAC policy. First, user attributes are extracted, which may include user ID, department, trust value (calculated from historical access), etc. After extracting user attributes, the pre-defined ABAC model is used to generate evaluation results. The decision type can be allow or deny, such as allow access, but the data volume is limited to ≤100 records. The results can be output in JSON or XML format, including the decision result, effective conditions, audit information, etc.

[0136] After determining the attribute evaluation results, a first-level key fragment corresponding to the accessing user is generated using a key generation algorithm based on the attribute evaluation results for that user. In this embodiment, the attribute evaluation results are obtained by comprehensively evaluating the user attributes, resource attributes, and environmental attributes of the accessing user based on a preset ABAC model. This indicates whether the user is allowed to access resources and the possible accompanying conditions, serving as a crucial basis for subsequent key generation. The key generation algorithm is a mathematical algorithm used to generate cryptographic keys. A first-level key fragment refers to the first level of the complete key divided into multiple parts (fragments). The attribute evaluation results are used as one of the input parameters of the key generation algorithm, and through a series of calculation steps, the first-level key fragment is derived. For example, if the attribute evaluation results indicate that the user has higher access rights, the generated first-level key fragment may play a more critical role in the subsequent recovery of the complete key, or have higher weight when combined with other fragments.

[0137] The first-level key fragment is supplemented by the user's trust value to determine the corresponding second-level key fragment. The first-level key fragment is a key segment obtained using a key generation algorithm based on the user's attribute evaluation results. It is the initial breakdown of the key and the foundation for constructing the complete key. The user's trust value is calculated by combining the user's historical successful access count and historical illegal access count, using a preset probability density function and Bayesian estimation algorithm, reflecting the user's trustworthiness. The second-level key fragment is a further refined key fragment obtained by incorporating user trust value information into the first-level key fragment. The trust value is fused with the first-level key fragment in a certain encoding or calculation method. For example, the trust value is converted into binary data and then logically operated bitwise (such as XOR operation) with the binary representation of the first-level key fragment, or the trust value is substituted as a parameter into a specific function to transform the first-level key fragment. The user's trust value reflects the reliability of the user's past access behavior. By incorporating the trust value into the first-level key fragment, the second-level key fragment not only contains permission information based on attribute evaluation but also reflects the user's trustworthiness. Users with high trust levels may have more favorable characteristics in subsequent key reconstruction or access authorization for their second-level key fragments (such as higher priority and more lenient usage conditions); users with low trust levels may have their second-level key fragments subject to more restrictions in order to enhance security.

[0138] The user permission level is determined by combining the first-level key fragment and the second-level key fragment. The first-level key fragment and the second-level key fragment each carry different dimensions of user characteristic information. The first-level key fragment is generated from the user's attribute evaluation results and is directly associated with the user's basic permission level. The second-level key fragment is generated by supplementing the first-level fragment with the user's trust value, reflecting the credibility of the user's behavior and historical performance. Permission levels are a quantitative description of a user's ability and scope of access to resources, such as ordinary users, advanced users, and administrators. Different levels correspond to different resource access scopes, operation permissions, or security verification requirements. The second-level key fragment is a further refined key fragment obtained by incorporating user trust value information into the first-level key fragment. The trust value is then fused with the first-level key fragment using a certain encoding or calculation method. By integrating the trust value into the first-level key fragment, the second-level key fragment not only contains permission information based on attribute evaluation but also reflects the user's level of trustworthiness.

[0139] Finally, a puncturable key structure is constructed based on user permission levels and the master key. The master key is the "root key" in the key system, the highest-level encryption key used to generate all lower-level keys (such as key fragments at each level). Key derivation based on permission levels can be implemented using a hierarchical key generation algorithm. The HKE algorithm recursively generates keys at each level from the master key, ensuring that higher-level keys depend on lower-level keys, forming a "permission chain dependency." Next, key fragments are bound to permissions. The first-level fragment is generated from user attributes (ABAC model), the second-level fragment from user trust values, and higher-level fragments from lower-level fragments plus permission level parameters. A user with permission level L2 has a key consisting of a first-level fragment derived from the master key and a second-level fragment derived from the first-level fragment, forming the path master key → first-level fragment → second-level fragment. When a user's permission is upgraded from L2 to L3, the system supplements it with a third-level fragment using the master key path master key → first-level fragment → second-level fragment → third-level fragment.

[0140] By combining user trust values, a pre-set ABAC model, and a pre-set smart city alliance chain, permissions can be dynamically adjusted, potentially risky users can be identified, and key sharding and permission levels can be automatically adjusted without manual intervention, thus realizing a dynamic, refined, and secure access control system.

[0141] In one embodiment of this invention, the user permission levels include high-level users and low-level users, and the puncturable key structure includes the following steps:

[0142] S710. When a user with higher privileges receives a key delegated by a user with lower privileges, the user with higher privileges determines the attribute level and real-time trust value of the user with lower privileges based on the preset ABAC model and the smart city consortium blockchain.

[0143] S720. If the real-time trust value of a low-level user exceeds the preset trust threshold and the attribute level is a preset specific role attribute, then the high-level user distributes the delegation key to the low-level user.

[0144] S730. If the real-time trust value of a low-level user does not exceed the preset trust threshold and the attribute level is not a preset specific role attribute, then the high-level user refuses to distribute the delegated key to the low-level user.

[0145] S740. After the high-level user distributes the delegated key to the low-level user, the high-level user obtains the low-level user's real-time trust value through the smart contract of the smart city alliance chain.

[0146] S750. When the real-time trust value of a low-level user is lower than the preset trust threshold, the entrusted key of the low-level user is punctured using the Puncture algorithm.

[0147] S760. When the real-time trust value of a user with advanced privileges is lower than the preset trust threshold, the attribute level and key corresponding to the user with advanced privileges will be unbound.

[0148] In this embodiment, user permission levels include high-level users and low-level users. High-level users have higher access rights to system resources or data, enabling them to perform more sensitive operations, such as data modification and system configuration changes. They may also bear more security responsibilities, and their permission usage is subject to stricter monitoring and auditing. Low-level users have limited access rights, can only perform specific, relatively secure operations, and cannot access or modify sensitive data or system configurations. Their permission scope is usually closely related to their job responsibilities and tasks. When a high-level user receives a delegated key from a low-level user, the high-level user determines the low-level user's attribute level and real-time trust value based on a preset ABAC model and the smart city consortium blockchain. When a high-level user receives a delegated key from a low-level user, the high-level user receives the delegated key through a secure channel. The delegated key typically contains key information such as the low-level user's identity, permission scope, and validity period. The high-level user evaluates the low-level user's attributes based on a preset ABAC (Attribute and Access Control) model. The evaluation content may include the user's role, department, security level, and historical behavior records. Attribute assessment determines the attribute level of low-level users to assess the legitimacy of their delegated permissions. Subsequently, combining data from the smart city consortium blockchain, high-level users calculate the real-time trust value of low-level users. This trust value is based on multi-dimensional information including the user's historical access behavior, data operation records, and security audit results. The real-time trust value reflects the current credibility of the low-level user and is a crucial basis for permission delegation decisions. Based on the attribute level and real-time trust value, high-level users decide whether to accept the delegated key from the low-level user. If the low-level user's attribute level and trust value conform to the preset security policy, the high-level user may accept the delegation and exercise the corresponding permissions. Otherwise, the high-level user will refuse the delegation and may trigger further security reviews or alert mechanisms.

[0149] If a low-level user's real-time trust value exceeds a preset trust threshold and their attribute level matches a preset specific role attribute, the high-level user distributes a delegated key to the low-level user. In this embodiment, the real-time trust value is a credibility score dynamically calculated based on the user's recent behavior data. The preset trust threshold is a set trust threshold used to filter high-trust users and prevent low-trust users from performing malicious operations through temporary permissions. The preset specific role attribute refers to a set of attribute characteristics predefined in the access control policy, used to identify whether a user is qualified to perform specific operations or access specific resources. When a low-level user's real-time trust value exceeds the preset trust threshold and their attribute level matches the preset specific role attribute, the high-level user distributes a delegated key to the low-level user. This key may be used to access specific resources, perform specific operations, or participate in specific transactions. The delegated key serves as a temporary, restricted permission credential, generated and distributed by the high-level user.

[0150] If a low-level user's real-time trust value does not exceed a preset trust threshold and their attribute level is not a preset specific role attribute, the high-level user will refuse to distribute a delegated key to the low-level user. The high-level user will decide whether to distribute a delegated key based on the low-level user's real-time trust value and attribute level. If the low-level user's real-time trust value does not exceed this preset trust threshold, it means that the user is not considered sufficiently trustworthy under the current circumstances. Simultaneously, if the low-level user's attribute level does not meet the preset specific role attribute, it means that the user does not possess the qualifications or permissions required to perform a specific operation or access a specific resource. If the low-level user does not meet either of these conditions, the high-level user will refuse to distribute a delegated key.

[0151] After a high-privilege user distributes a delegated key to a low-privilege user, the high-privilege user obtains the low-privilege user's real-time trust value through a smart contract on the smart city consortium blockchain. The delegated key is a credential granted by the high-privilege user to the low-privilege user, used to access specific resources or perform specific operations. Distributing the delegated key signifies that the low-privilege user has, to some extent, been authorized by the high-privilege user. A smart contract is a piece of automatically executing code deployed on the blockchain, used to define and execute specific business logic. In the smart city consortium blockchain, smart contracts can be used to automate processes such as access control, data sharing, and trust assessment. The real-time trust value is a trust score dynamically calculated based on factors such as user behavior, interaction, and service quality, reflecting the user's credibility at the current moment and serving as a crucial basis for access control decisions. When a low-privilege user's real-time trust value exceeds a preset trust threshold and their attribute level matches a preset specific role attribute, the high-privilege user will distribute a delegated key to them. After distributing the delegated key, the high-privilege user may wish to continuously monitor the low-privilege user's trust status. Users with advanced privileges can obtain the real-time trust value of users with lower privileges through smart contracts on the smart city consortium blockchain. The smart contract can periodically or based on specific events trigger the calculation and update of the trust value, and store the results on the blockchain for users with advanced privileges to query.

[0152] When a low-level user's real-time trust value falls below a preset trust threshold, the delegated key is punctured using the Puncture algorithm. The Puncture algorithm punctures the key by fragmenting it, preserving some of its functionality while preventing it from performing specific operations (such as accessing sensitive data). To reduce security risks or restrict access permissions, the delegated key needs to be punctured when a low-level user's real-time trust value falls below the preset trust threshold. Through this puncturing operation, the system can quickly reduce the low-level user's access permissions, preventing them from continuing to access sensitive resources or perform critical operations. The access policy for the key is modified via a smart contract, for example, changing from allowing all operations to allowing only read operations. The Puncture algorithm is then applied to the target fragment to generate a punctured fragment, preventing it from decrypting the corresponding operation. The punctured fragment is then reassembled with other unpunctured fragments to form a new key. When the system detects a decrease in the trust value of a high-level user, it automatically triggers an unbinding operation between the attribute level and the key, essentially revoking the user's specific permissions. For example, if the user's attribute level is department administrator, after unbinding, their key will be unable to access core department data. By unbinding users' existing permission chains, the system prevents users with low trust levels from continuing to access sensitive data. For example, when the financial system detects an abnormal trust level, it immediately unbinds the user's fund approval attribute from their key. Permission status is dynamically adjusted based on real-time trust levels; after unbinding, the user retains only basic permissions. For instance, if a user's original full file permissions are unbound, they will only retain file viewing permissions.

[0153] By using data-driven trust assessment and role attribute matching, users with lower-level permissions can temporarily gain higher-level permissions when certain conditions are met, thereby supporting cross-level collaboration and ensuring the flexibility and security of permission management in smart cities.

[0154] In one embodiment of this invention, dynamic access control for accessing users is performed using a puncturable key structure. Authorizing accessing users based on their identities and sharing the data queried by them includes the following steps:

[0155] S810. Determine the identity level of the accessing user by combining the puncturable key structure;

[0156] S820. Map the identity level to the preset permission level system to determine the permission level corresponding to the identity level;

[0157] S830. Generate authorization credentials corresponding to the permission level using encryption technology with a puncturable key structure.

[0158] S840. Verify the authenticity and completeness of the authorization certificate;

[0159] S850. If the authorization credentials are verified, the user is confirmed to be accessing shared data.

[0160] Determining a user's identity level by combining a puncturable key structure refers to comprehensively judging the user's temporary identity level by analyzing the user's real-time trust value and the implicit permission hierarchy in the puncturable key structure, thereby achieving fine-grained access control. In this embodiment, the puncturable key structure consists of two levels of key fragments, each corresponding to different dimensions of permission control. These include a first-level key fragment and a second-level key fragment. The first-level key fragment is a basic permission fragment generated based on a preset ABAC model according to user attributes. The second-level key fragment is a supplementary fragment that supplements the first-level fragment with the user's real-time trust value. In this embodiment, the real-time trust value is implicitly contained in the permission hierarchy of the second-level key fragment. In this embodiment, the identity level is a temporary permission label generated based on the real-time trust value and key status (such as whether it has been punctured), such as "trusted user" or "risky user." The access user's identity level is determined by combining the puncturable key structure. Specifically, the identity level can be determined from the key status. For example, when the key status is complete at level 1 and complete at level 2, the corresponding implicit permission level is high-level (such as data read / write + analysis). Taking medical data access as an example, a chief physician can modify patient diagnosis records and export analysis reports. When the key status is complete at level 1 and punctured at level 2, the implicit permission level is medium-level (such as read-only + limited download), and interns can only query medical records but cannot modify or export them. When the key status is partially punctured at level 1 and invalid at level 2, the implicit permission level is low-level (such as preview + request permission), and caregivers can only view basic patient information and submit access requests. In other words, the permission levels in the puncture key structure are implicitly represented by a two-layer mapping: "preset ABAC attributes → first-level fragments → basic permissions" and "trust value → second-level fragments → permission adjustment". The first-level fragments implicitly represent the basic permission level, which is directly assigned by the preset ABAC model, such as "department attributes → data access scope". The second-level fragments implicitly represent the dynamic adjustment level, which is corrected in real time by the trust value, such as "high trust value → enhanced permissions, low trust value → permission puncture". The overall key status implicitly represents the final permission level, which can be directly determined by physical characteristics such as fragment integrity and puncture markers, to determine the user's current executable operations, such as read / write, read-only, and no permissions.

[0161] Mapping identity levels to a pre-defined permission level system determines the corresponding permission level. This involves associating a user's or entity's identity identifier within the system (such as role, position, department, etc.) with specific access permissions and operational scopes. The core purpose of this process is to ensure that users can only access the minimum set of permissions required for their duties, while simultaneously guaranteeing system security, compliance, and manageability. A pre-defined permission level system pre-defines all possible permission levels and their operational scopes, forming a standardized permission library. Subsequently, the corresponding permission levels are defined based on the identity level, creating a mapping table. When a user's identity level changes, the system automatically adjusts their permission level according to the mapping rules.

[0162] This embodiment utilizes a puncturable key structure encryption technique to generate authorization credentials corresponding to different permission levels. The puncturable key structure is a dynamically adjustable key design that allows for key downgrading or invalidation via a puncture algorithm. The authorization credential serves as the user's access token to system resources, typically generated based on a key, and is used to verify user permissions. Key generation and permission binding refer to generating a corresponding puncturable key based on the user's permission level. When the user's permission level changes, the key permissions are adjusted using a puncture algorithm. An authorization credential is then generated based on the adjusted key, embedding the key's permission information within the credential.

[0163] Authenticity and integrity verification of authorization credentials are crucial. An authorization credential is a digital identity used to prove a user's right to access specific resources or perform specific operations. Authenticity verification confirms that the credential was issued by a trusted authority and is not forged. This can be achieved through digital signature verification or certificate chain verification. Digital signature verification uses the issuer's public key to verify the signature's validity; certificate chain verification checks whether the certificate was issued by a trusted Certificate Authority (CA) and has not been revoked. Integrity verification ensures that the credential content has not been tampered with during transmission or storage. This can be done using hash verification, by calculating the hash value of the credential content and comparing it to the hash value in the signature.

[0164] If the authorization credentials are verified, then access to shared data is confirmed. This means that data sharing is only performed after the credentials have passed authenticity and integrity verification. Data sharing can be achieved through direct access, where the user gains access rights to read or manipulate the target data. Alternatively, it can be through proxy sharing, where data is anonymized and pushed to the user based on the permissions specified in the credentials (e.g., sharing only certain fields).

[0165] This application also provides a machine-readable storage medium storing instructions that cause a machine to execute the aforementioned blockchain-based smart city cloud platform data authorization and sharing method.

[0166] This application also provides an electronic device, including:

[0167] The memory is configured to store instructions; and

[0168] The processor is configured to retrieve instructions from memory and, when executing instructions, implement the aforementioned blockchain-based smart city cloud platform data authorization and sharing method.

[0169] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0170] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0171] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0172] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0173] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0174] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0175] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0176] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0177] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for data authorization sharing of a smart city cloud platform based on a blockchain, characterized in that, The method is applied to a smart city cloud platform and includes the following steps: In response to receiving a query instruction of an access user, determining historical query information of the access user through the smart city cloud platform; Based on a preset identity registration chain, performing identity verification on the access user, and if the access user passes the identity verification, evaluating a trust value of the access user according to the historical query information; Performing trust degree verification on the trust value; If the access user passes the trust degree verification, constructing a puncturable key structure in combination with the trust value of the access user, a preset ABAC model and a preset smart city alliance chain; Using the puncturable key structure to perform dynamic permission management on the access user, performing identity authorization on the access user based on the puncturable key structure and sharing data queried by the access user.

2. The method of claim 1, wherein, The preset identity registration chain and the preset smart city alliance chain include the following steps: Obtaining a smart city operation process and a registration information process of a registered user in the smart city cloud platform, the registration information process including at least two registration process nodes, and the smart city operation process including at least two operation process nodes; Based on all the registration process nodes, building an identity registration chain of all the registered users, obtaining registration information of all the registration process nodes, and chaining the registration information to the identity registration chain; Based on all the operation process nodes, building a smart city alliance chain of a target city, obtaining operation information of all the operation process nodes, and chaining the operation information to the smart city alliance chain.

3. The method of claim 1, wherein, The identity verification on the access user based on the preset identity registration chain, if the access user passes the identity verification, evaluating a trust value of the access user according to the historical query information includes the following steps: Extracting a first hash value of identity information and biometric information corresponding to the access user from a preset smart contract; Extracting registration information of the access user from a preset identity registration chain, and calculating a second hash value of the registration information using a preset hash function; Comparing the first hash value with the second hash value, if the first hash value is equal to the second hash value, it is determined that the access user passes the identity verification; When the access user passes the identity verification, determining a historical successful access frequency and a historical illegal access frequency of the access user through the historical query information; Combining the historical successful access frequency and the historical illegal access frequency to calculate the trust value of the access user.

4. The method of claim 3, wherein, The combination of the historical successful access frequency and the historical illegal access frequency to calculate the trust value of the access user includes the following steps: Combining the historical successful access frequency and the historical illegal access frequency to predict a successful access probability of the access user using a preset probability density function; Combining the historical successful access frequency and the historical illegal access frequency to calculate an average successful access probability using a Bayesian estimation algorithm; Weighted fusion of the successful access probability and the average successful access probability to obtain a primary trust value; Combining the primary trust value and a preset time decay factor to calculate the trust value of the access user.

5. The method of claim 2, wherein, Before the combination of the trust value of the access user, the preset ABAC model and the preset smart city alliance chain constructs the puncturable key structure, the following steps are included: Obtain the historical successful access times and the historical illegal access times of all the registered users; Combine the historical successful access times and the historical illegal access times of each registered user to calculate the corresponding user trust value of each registered user by using the preset probability density function and the Bayesian estimation algorithm; Perform a system initialization algorithm on the smart city alliance chain through a preset key center to generate public parameters and a master key of the smart city alliance chain; Combine the user trust value, the public parameters and the master key of each registered user to generate the public key and the private key of each registered user.

6. The method of claim 5, wherein, The combination of the trust value of the access user, the preset ABAC model and the preset smart city alliance chain constructs the puncturable key structure includes the following steps: Determine the attribute evaluation result corresponding to the access user based on the attribute evaluation of the preset ABAC model; Generate the first-level key fragment corresponding to the access user by using the key generation algorithm according to the attribute evaluation result corresponding to the access user; Supplement the first-level key fragment by the trust value of the access user to determine the second-level key fragment corresponding to the access user; Determine the user permission level of the access user by combining the first-level key fragment and the second-level key fragment; Construct the puncturable key structure based on the user permission level and the master key.

7. The method of claim 6, wherein, The user permission level includes high-level permission users and low-level permission users, and the puncturable key structure includes the following steps: When the high-level permission user receives the delegated key of the low-level permission user, the high-level permission user determines the attribute level and the real-time trust value of the low-level permission user according to the preset ABAC model and the smart city alliance chain; If the real-time trust value of the low-level permission user exceeds the preset trust threshold and the attribute level is a preset specific role attribute, the high-level permission user distributes a delegated key to the low-level permission user; If the real-time trust value of the low-level permission user does not exceed the preset trust threshold and the attribute level is not a preset specific role attribute, the high-level permission user refuses to distribute a delegated key to the low-level permission user; After the high-level permission user distributes a delegated key to the low-level permission user, the high-level permission user obtains the real-time trust value of the low-level permission user through the smart contract of the smart city alliance chain; When the real-time trust value of the low-level permission user is lower than the preset trust threshold, the delegated key of the low-level permission user is punctured by using the Puncture algorithm; When the real-time trust value of the high-level permission user is lower than the preset trust threshold, the attribute level corresponding to the high-level permission user is unbound from the key.

8. The method of claim 1, wherein, The dynamic permission management of the access user by using the penetrable key structure includes the following steps of: determining the identity level of the access user in combination with the penetrable key structure; mapping the identity level to a preset permission level system to determine the permission level corresponding to the identity level; generating an authorization credential corresponding to the permission level by using the encryption technology of the penetrable key structure; verifying the authenticity and integrity of the authorization credential; if the authorization credential passes the verification, sharing data for the access user.

9. A machine-readable storage medium, characterized in that, The machine readable storage medium stores instructions for causing a machine to execute the blockchain-based smart city cloud platform data authorization sharing method according to any one of claims 1 to 8. 10.A smart city cloud platform data authorization sharing system based on a blockchain, characterized in that, comprise: a memory configured to store instructions; and a processor configured to call the instructions from the memory and enable the blockchain-based smart city cloud platform data authorization sharing method according to any one of claims 1 to 8 when executing the instructions.

Images