Smart city cloud platform data authorization sharing method and system based on block chain

Abstract

The invention discloses a smart city cloud platform data authorization sharing method and system based on a block chain, and relates to the field of data sharing, and the method comprises the steps: responding to a received query instruction of an access user, and determining the historical query information of the access user through a smart city cloud platform; performing identity verification on the access user based on a preset identity registration chain, 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; and performing dynamic authority management on the access user by using the puncturable key structure, performing identity authorization on the access user based on the puncturable key structure, and sharing data queried by the access user. The management efficiency of the smart city can be effectively improved.

Description

Technical Field

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

[0002] With the rapid development of information technology, smart city construction has become a crucial means of improving urban governance and public services. As a core hub for data integration and sharing, the smart city cloud platform brings together massive amounts of heterogeneous data from various fields, including government affairs, transportation, healthcare, and the environment. This data is crucial for the intelligent operation of cities.

[0003] Currently, smart cities encompass diverse entities, including businesses, medical institutions, and educational institutions. However, each entity operates independently with regard to data management and usage. Data providers, fearing data misuse and privacy breaches, tend to "hold data" or "minimize sharing," creating "data silos" and hindering cross-sector collaborative innovation and development. For example, insurance companies require access to patient medical data to optimize pricing, but hospitals refuse to share due to privacy concerns. This results in lagging insurance product innovation and the inability to provide customized insurance plans based on patients' true health status and medical history, thus impacting the management efficiency of smart cities.

[0004] There is currently no better solution to the above problems. Summary of the Invention

[0005] The embodiments of the present application provide a blockchain-based smart city cloud platform data authorization and sharing method and system for improving the management efficiency of smart cities.

[0006] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions: In a first aspect, a blockchain-based smart city cloud platform data authorization and sharing method is provided, which is applied to the smart city cloud platform. The method includes the following steps: In response to receiving a query instruction from a visiting user, determining historical query information of the visiting user through the smart city cloud platform; authenticating the access user based on a preset identity registration chain, and if the access user passes the authentication, evaluating the access user's trust value based on the historical query information; Performing trustworthiness verification on the trust value; 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; The puncturable key structure is used to perform dynamic authority management on the access user, and identity authorization is performed on the access user based on the puncturable key structure, and data queried by the access user is shared.

[0007] In a possible implementation of the first aspect, 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, 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; Building an identity registration chain for all registered users based on all the registration process nodes, obtaining registration information for all the registration process nodes, and uploading the registration information to the identity registration chain; A smart city alliance chain of the target city is built based on all the running process nodes, the running information of all the running process nodes is obtained, and the running information is uploaded to the smart city alliance chain.

[0008] In a possible implementation of the first aspect, authenticating the access user based on a preset identity registration chain, and evaluating the access user's trust value based on the historical query information if the access user passes the authentication, includes the following steps: Extracting a first hash value of the identity information and biometric information corresponding to the accessing user from a preset smart contract; Extracting the registration information of the accessing 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, and if the first hash value is equal to the second hash value, determining that the access user has passed the identity authentication; When the access user passes the identity authentication, the historical successful access times and the historical illegal access times of the access user are determined through the historical query information; The trust value of the accessing user is calculated by combining the historical number of successful accesses and the historical number of illegal accesses.

[0009] In a possible implementation of the first aspect, calculating the trust value of the accessing user by combining the historical number of successful accesses and the historical number of illegal accesses includes the following steps: Combining the historical number of successful accesses and the historical number of illegal accesses, using a preset probability density function to predict the probability of successful access by the accessing user; Calculating an average probability of successful access by combining the number of historical successful accesses and the number of historical illegal accesses using a Bayesian estimation algorithm; Performing weighted fusion on the successful access probability and the average successful access probability to obtain a primary trust value; The trust value of the accessing user is calculated by combining the primary trust value and a preset time decay factor.

[0010] In a possible implementation of the first aspect, before building a pierceable key structure by combining the trust value of the accessing user, a preset ABAC model, and a preset smart city alliance chain, the following steps are included: Obtain the number of successful and illegal visits in history for all registered users; Calculating the user trust value corresponding to each registered user by combining the historical successful access times and the historical illegal access times of each registered user using a preset probability density function and a Bayesian estimation algorithm; Executing 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; The public key and private key of each registered user are generated by combining the user trust value, the public parameters and the master key corresponding to each registered user.

[0011] In a possible implementation of the first aspect, constructing a pierceable key structure by combining the access user's trust value, a preset ABAC model, and a preset smart city alliance chain includes the following steps: Performing attribute evaluation on the access user based on a preset ABAC model to determine an attribute evaluation result corresponding to the access user; Generate a first-level key shard corresponding to the access user using a key generation algorithm according to the attribute evaluation result corresponding to the access user; Supplementing the first-level key shard with the trust value of the accessing user to determine the second-level key shard corresponding to the accessing user; Determining the user authority level of the access user by combining the first-level key shards and the second-level key shards; A puncturable key structure is constructed based on the user authority level and the master key.

[0012] In a possible implementation of the first aspect, the user authority levels include high-authority users and low-authority users, and the puncturable key structure includes the following steps: When the high-level permission user receives the delegation key of the low-level permission user, the high-level permission user determines the attribute level and 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 authority user exceeds a preset trust threshold and the attribute level is a preset specific role attribute, the high-level authority user distributes a delegation key to the low-level authority user; If the real-time trust value of the low-level authority user does not exceed a preset trust threshold and the attribute level is not a preset specific role attribute, the high-level authority user refuses to distribute a delegation key to the low-level authority user; After the high-level permission user distributes the delegation 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 authority user is lower than a preset trust threshold, the delegation key of the low-level authority user is punctured using a Puncture algorithm; When the real-time trust value of the high-level authority user is lower than a preset trust threshold, the attribute level corresponding to the high-level authority user is unbound from the key.

[0013] In a possible implementation of the first aspect, the dynamically managing the accessing user's rights by using the puncturable key structure, authorizing the accessing user's identity based on the puncturable key structure, and sharing the data queried by the accessing user include the following steps: determining the identity level of the accessing user in combination with the puncturable key structure; Mapping the identity level to a preset authority level system to determine the authority level corresponding to the identity level; Generate an authorization certificate corresponding to the permission level using the encryption technology of the puncturable key structure; Verifying the authenticity and integrity of the authorization credentials; If the authorization credential passes verification, the data is determined to be shared with the accessing user.

[0014] On the second aspect, the present application provides a machine-readable storage medium, on which instructions are stored, and the machine-readable storage medium stores instructions for enabling a machine to execute the above-mentioned blockchain-based smart city cloud platform data authorization and sharing method.

[0015] In a third aspect, this application provides a blockchain-based smart city cloud platform data authorization and sharing system, including: a memory configured to store instructions; and The processor is configured to call the instructions from the memory and implement the above-mentioned blockchain-based smart city cloud platform data authorization sharing method when executing the instructions.

[0016] The above technical solution authenticates accessing users through a pre-set identity registration chain and evaluates their trust value based on historical query information. This effectively screens legitimate users and prevents unauthorized access, thereby protecting user privacy and data security. Combining the accessing user's trust value, the pre-set ABAC model, and the pre-set smart city consortium chain, a pierceable key structure is constructed, which dynamically adjusts access rights based on the user's trust value. This effectively enhances system flexibility, enabling users to access data as needed. Trust value evaluation also ensures access security and prevents abuse of rights. Blockchain technology facilitates 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 permission management. By continuously monitoring user access behavior, trust values ​​can be dynamically updated, ensuring the accuracy and timeliness of the trust system. The deep integration of blockchain technology and access control models enables real-time response to permission changes, ensuring the principle of least privilege for data authorization and improving the management efficiency of smart cities.

[0017] Other features and advantages of the embodiments of the present application will be described in detail in the subsequent detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 A flowchart of a blockchain-based smart city cloud platform data authorization and sharing method provided in an embodiment of the present application; Figure 2 A schematic diagram of a structure for querying data based on a smart city cloud platform provided in an embodiment of the present application. DETAILED DESCRIPTION

[0019] To make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the specific implementation methods described herein are only used to illustrate and explain the embodiments of the present application and are not used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0020] It should be noted that if the embodiments of the present application involve directional indications (such as up, down, left, right, front, back, etc.), such directional indications are only used to explain the relative position relationship, movement status, etc. between the various components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0021] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present application, the descriptions of "first", "second", etc. are only for descriptive purposes and cannot be understood as indicating or implying their relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of such features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the fact that they can be implemented by ordinary technicians in this field. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0022] Figure 1 The following schematically shows a flow chart of a data authorization and sharing method of a smart city cloud platform based on blockchain according to an embodiment of the present application. Figure 1 As shown, an embodiment of the present application provides a blockchain-based smart city cloud platform data authorization and sharing method, which is applied to the smart city cloud platform. The method may include the following steps.

[0023] S110, in response to receiving a query instruction from a visiting user, determining historical query information of the visiting user through the smart city cloud platform; S120: Authenticate the accessing user based on the preset identity registration chain, and if the accessing user passes the authentication, evaluate the accessing user's trust value based on historical query information; S130, verifying the trust value; S140: If the accessing user passes the trust verification, a puncturable key structure is constructed based on the accessing user's trust value, the preset ABAC model, and the preset smart city alliance chain; S150: Perform dynamic authority management on access users using the puncturable key structure, authorize access users based on the puncturable key structure, and share data queried by access users.

[0024] First, in response to receiving a query instruction from an accessing user, the smart city cloud platform determines the accessing user's historical query information. In this embodiment, an accessing user refers to any entity that requests access to data or resources through a platform interface, application, or terminal device. "User" here is not limited to natural persons but may also include enterprises, institutions, systems, or third-party applications. When a user sends a data query request to the smart city cloud platform via a terminal device (such as a mobile phone or computer), the smart city cloud platform receives the query instruction through APIs, front-end interfaces, and other channels, parsing parameters such as the data type and query scope in the request. The smart city cloud platform pre-records each user's query behavior to form a user behavior log. Historical query information may include basic user information such as query time, query IP address, and device type used; as well as the user's 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).

[0025] After obtaining the user's historical query information, the user is authenticated based on a pre-set identity registration chain. If the user passes authentication, their trust value is evaluated based on their historical query information. In this embodiment, the identity registration chain is a blockchain network pre-set within the smart city cloud platform. It stores and manages the identity information of all registered users. This information may include the user's unique identifier, public key, private key, registration time, and other information. All information is encrypted to ensure security. When a user initiates a query, the smart city cloud platform first authenticates the user using the identity registration chain. This verification process may include checking whether the user's provided identity credentials are consistent with the information stored in the identity registration chain. If the authentication passes, the user is a legitimate registered user and has permission to access the smart city cloud platform's data. Once the user passes authentication, the smart city cloud platform evaluates their trust value based on their historical query information. This historical query information may include the type of data the user has queried, the query time, the query frequency, and the use of the query results. By analyzing a user's historical query behavior, we can understand their query habits, data usage preferences, and potential data misuse risks. Trust value is an important indicator for assessing user reliability and data misuse risks. The Smart City Cloud Platform dynamically adjusts user access permissions based on their trust score, ensuring that users can only access authorized data. Users with higher trust scores may be granted broader access rights, while those with lower trust scores may be subject to stricter restrictions. This dynamic permission management mechanism helps prevent data misuse and leakage, and improves the security of data sharing.

[0026] After obtaining the accessing user's trust value, the trust value undergoes trust verification. This means that once the user passes identity verification, the smart city cloud platform has confirmed the user's legitimate identity. However, a legitimate identity does not guarantee unrestricted access to all data. Therefore, further trust verification is required to ensure that the user's behavior complies with system regulations and does not pose a threat to data security. Trust verification is based on the user's historical and current behavior patterns. The smart city cloud platform analyzes the user's historical query records, data access frequency, and data usage to assess the user's trust value. If the user's trust value reaches or exceeds the preset threshold, the user is deemed to have passed the trust verification and is allowed to access the data. If the trust value falls below the threshold, the user's access rights may be restricted or the access request may be denied. Trust verification effectively prevents low-trust users from accessing sensitive data, reducing the risk of data leakage and misuse. It also helps maintain system stability and reliability, ensuring the normal operation of data sharing services.

[0027] If the accessing user passes the trust verification, a puncturable key structure is constructed based on the user's trust value, the pre-set ABAC model, and the pre-set smart city consortium chain. The puncturable key structure is a dynamic, trust-based key management system that dynamically adjusts access permissions based on the user's trust value, achieving more granular permission control. The ABAC model is a flexible access control mechanism that determines whether a user can access a resource based on both user attributes and resource attributes (such as sensitivity and importance). Incorporating the ABAC model in the construction of the puncturable key structure ensures flexibility and accuracy in access control policies. The smart city consortium chain is a blockchain network jointly participated by multiple organizations or institutions, enabling data sharing and collaborative management. When constructing the puncturable key structure, the system leverages the technologies and resources of the smart city consortium chain to ensure secure and reliable key management. The puncturable key structure allows the system to dynamically adjust access permissions based on the user's trust value, achieving more refined permission control and helping to prevent abuse of permissions and data leakage. By combining trust values, the ABAC model, and the smart city consortium chain, the puncturable key structure establishes a multi-layered security system, effectively improving the security of data sharing. The puncturable key structure can provide a secure and reliable framework for data sharing, helping to promote data sharing and collaboration among different organizations or institutions.

[0028] Subsequently, a puncturable key structure is used to dynamically manage access rights for users. Based on this structure, users are authorized and their data is shared. Dynamic access rights management means that user access rights are not static but can be adjusted in real time based on their trustworthiness and other relevant factors, such as query behavior and data usage. This dynamic adjustment of rights limits access rights for low-trust users, preventing data misuse, while allowing high-trust users access to more data, improving data sharing efficiency. The scope of data access and the level of access rights are determined based on the user's trustworthiness. Higher trustworthiness allows for a wider range of data access and higher levels of access. Furthermore, the ABAC model determines whether a user can access a resource based on user attributes (such as role, department, and position) and resource attributes (such as sensitivity and importance). Within the puncturable key structure, the ABAC model is used to further refine access control policies. The smart city consortium chain enables data sharing and collaborative management. During dynamic access rights management, the consortium chain's technologies and resources are leveraged to ensure the security and reliability of key management, authorize users, and share their data.

[0029] Accessing users are authenticated through a pre-set identity registration chain and their trust scores are assessed based on historical query information. This effectively screens legitimate users and prevents unauthorized access, thereby protecting user privacy and data security. Combining accessing users' trust scores, a pre-set ABAC model, and a pre-set smart city consortium chain, a puncturable key structure is constructed. Access rights are dynamically adjusted based on the user's trust score, effectively enhancing system flexibility and enabling users to access data as needed. Trust score assessment also ensures access security and prevents abuse of privileges. Blockchain technology facilitates data sharing across different institutions or departments, breaking down information silos and facilitating data interconnection and efficient utilization. Assessing user trust scores based on historical query information and authentication results provides a scientific basis for data sharing and permissions management. By continuously monitoring user access behavior, trust scores can be dynamically updated, ensuring the accuracy and timeliness of the trust system. The deep integration of blockchain technology and access control models enables real-time response to permission changes, ensuring the principle of least privilege for data authorization and improving the management efficiency of smart cities.

[0030] In one implementation of this embodiment, the preset identity registration chain and the preset smart city alliance chain include the following steps: S210: Obtain a smart city operation process and a registered user's registration information process in the smart city cloud platform, where the registration information process includes at least two registration process nodes, and the smart city operation process includes at least two operation process nodes; S220: Build an identity registration chain for all registered users based on all registration process nodes, obtain registration information for all registration process nodes, and upload the registration information to the identity registration chain; S230. Build a smart city alliance chain for the target city based on all running process nodes, obtain the running information of all running process nodes, and upload the running information to the smart city alliance chain.

[0031] First, obtain the smart city operation process and the registration information process for 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). It may include various business processes in urban management and services, involving specific scenarios of urban operations, and the process contains at least two links. For example, the process nodes in the traffic congestion handling process can be data monitoring and plan triggering. The registration information process refers to the entire process for users to complete registration on the platform, including at least two links (nodes). For example, the registration information process can include information submission, identity verification, and permission allocation.

[0032] Next, an identity registration chain is built for all registered users based on all registration process nodes. Registration information from all registration process nodes is obtained and uploaded to the identity registration chain. In this embodiment, the identity registration chain is a distributed ledger built on blockchain technology, used to store and manage the identity information of all registered users. To build the identity registration chain, it is first necessary to identify all key nodes in the user registration process, which may include user information entry, identity verification, and registration review. Subsequently, blockchain interaction logic is designed, with corresponding blockchain interaction logic implemented at each registration process node. For example, at the user information entry node, the user-submitted information is encrypted and prepared for upload to the chain; at the identity verification node, identity verification is performed using blockchain technology, and the verification results are uploaded to the chain. Finally, a smart contract is 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 is obtained from all registration process nodes. During the user registration process, user-submitted information 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 cleansed to ensure its accuracy and completeness. For example, verification of the validity of the ID number submitted by the user and removal of duplicate or invalid information are required. Before uploading registration information to the blockchain, encryption is used to ensure security during transmission and storage, preventing malicious tampering or leakage. The encrypted registration information is uploaded to the identity registration chain through smart contracts or blockchain client tools. During the upload process, information integrity and consistency must be ensured to prevent tampering or loss during transmission. Once uploaded, the registration information is stored on various nodes of the identity registration chain, forming a distributed storage system. This improves information reliability and availability, ensuring that even if a node fails, the entire identity registration chain remains operational. Furthermore, the identity registration chain provides a convenient information query function. Users or administrators can query user identity information through blockchain client tools, ensuring transparency and traceability.

[0033] A smart city alliance chain is built for the target city based on all operational process nodes. Operational information from all process nodes is obtained and uploaded to the smart city alliance chain. Built on blockchain technology, the smart city alliance chain connects blockchain networks across different departments, institutions, and enterprises within a city, aiming to enable data sharing and collaborative management, breaking down information silos and improving the intelligence of urban management. Through the smart city alliance chain, various departments or institutions can share city operational data, collaborate, and provide more convenient and efficient services to city residents. To build the smart city alliance chain, the first step is to identify all key nodes in the city's operational processes. These nodes may include traffic management, energy distribution, public safety, environmental monitoring, healthcare, and other areas. For each operational process node, the corresponding blockchain interaction logic is designed. For example, at the traffic management node, logic for uploading traffic flow data to the chain can be designed; at the energy distribution node, logic for uploading energy consumption data can be designed. Finally, smart contracts are deployed on the smart city alliance chain to automate certain steps in the operational process. For example, smart contracts can be deployed to automatically handle traffic violations or adjust energy allocation strategies. Next, operational information is obtained from all running process nodes. Data is collected from each node during the city's operation. This data may include traffic flow, energy consumption, environmental monitoring data, public safety incidents, and more. Before uploading this operational information to the blockchain, encryption technology is used to ensure security during transmission and storage, preventing malicious tampering or leakage. This encrypted operational information is uploaded to the Smart City Alliance Chain using smart contracts or blockchain client tools. During the uploading process, information integrity and consistency must be ensured to prevent tampering or loss during transmission. Once uploaded, this operational information is stored across all nodes in the Smart City Alliance Chain, forming a distributed storage system. This improves information reliability and availability, ensuring that even if a node fails, the entire Smart City Alliance Chain remains operational. Furthermore, the Smart City Alliance Chain provides convenient information query capabilities.

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

[0035] In one implementation of this embodiment, authentication of the accessing user is performed based on a preset identity registration chain, and if the accessing user passes the authentication, evaluating the accessing user's trust value based on historical query information includes the following steps: S310: Extracting a first hash value of the identity information and biometric information corresponding to the accessing user from a preset smart contract; S320: extracting the registration information of the accessing user from the preset identity registration chain, and calculating a second hash value of the registration information using a preset hash function; S330, comparing the first hash value with the second hash value, and if the first hash value is equal to the second hash value, determining that the access user has passed the identity authentication; S340: When the access user passes the identity authentication, determine the number of historical successful accesses and the number of historical illegal accesses of the access user through historical query information; S350: Calculate the trust value of the accessing user by combining the number of historical successful accesses and the number of historical illegal accesses.

[0036] The first hash value of the accessing user's corresponding identity information and biometric information is extracted from a pre-set smart contract. In this embodiment, the pre-set smart contract refers to the smart contract of the identity registration chain. In the identity registration chain of the smart city cloud platform, the smart contract is deployed on the blockchain and is used to automate user identity-related operations, such as identity authentication and permission allocation. Smart contracts 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 information and biometric information stored in the pre-set smart contract. To ensure the security and privacy of user identity information, the smart city cloud platform typically hashes this information. Hashing is the process of mapping data of arbitrary length into a fixed-length string. The hash value is unique, meaning that it is almost impossible for different data to generate the same hash value. In the identity registration chain, the user's identity information and biometric information are hashed and stored in the smart contract. Extracting the first hash value of the accessing user's corresponding identity information and biometric information from the pre-set smart contract is typically used for identity authentication or data integrity checking. First, when a user initiates a query, the Smart City Cloud Platform authenticates the user using the identity registration chain. During this verification process, the platform extracts a hash value (the first hash value) of the user's identity and biometric information from the smart contract. The platform then hashes the user's provided identity credentials (such as a digital certificate, username, and password) or biometric data (such as a fingerprint or facial image) to generate a second hash value. Finally, the platform compares the first and second hash values ​​to ensure they match. If they match, the user's provided identity credentials or biometric data matches the information stored in the smart contract, confirming that the user has passed authentication.

[0037] Next, the accessing user's registration information is extracted from the preset identity registration chain and a second hash value is calculated using a preset hash function. The second hash value is the hash value obtained by calculating the accessing user's registration information extracted from the preset identity registration chain using the preset hash function. The identity registration chain is built on blockchain technology and is used to store and manage the identity information of all registered users. When a accessing user initiates a query, the smart city cloud platform retrieves the user's registration information from the identity registration chain. This information is typically stored in a smart contract, an automated program deployed on the blockchain that manages user identity information. After extracting the accessing user's registration information, the smart city cloud platform calculates it using a preset hash function to generate a second hash value. This calculation process may involve passing the registration information as input to the hash function and then obtaining the hash value output by the function. This second hash value is used for subsequent identity verification or data integrity checks. For example, during the identity verification process, 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.

[0038] The first hash value is compared with the second hash value. If the first and second hash values ​​are equal, the accessing user is confirmed to be 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 the two are equal, it indicates that the identity credentials or biometric data provided by the user match the information stored during registration, and the user has passed authentication. Once the accessing user is authenticated, the Smart City Cloud Platform allows the user to access the authorized data and services. This ensures that only legitimate and trusted users can access specific data, preventing the risk of unauthorized access and data leakage.

[0039] When a user passes authentication, historical query information is used to determine the user's previous successful accesses and illegal accesses. This can be achieved by accessing the Smart City Cloud Platform's database. The Smart City Cloud Platform records detailed information about the access, including access time, accessed resources, and access results. These records are stored in the database for subsequent query and analysis. The query results obtained from the database indicate that successful accesses refer to the number of times a user successfully accessed a system or service after passing authentication. Illegal accesses refer to the number of times a user attempted to access but failed authentication, or the number of times a user accessed unauthorized resources.

[0040] The trust value of the accessing user is calculated by combining the number of historical successful accesses and the number of historical illegal accesses. In other words, in this embodiment, the trust value is typically calculated based on this number. The trust value is a quantitative indicator used to assess the reliability of a user's past behavior when accessing the smart city cloud platform, reflecting the extent to which the user complies with platform rules and legally accesses resources. By calculating the trust value, the smart city cloud platform can more accurately identify potential security risks, such as malicious attacks and illegal access. The trust value can also serve as a basis for dynamically adjusting user permissions, providing more convenient services for users with high trust values ​​while implementing stricter access controls for users with low trust values.

[0041] By evaluating the trust value of accessing users based on historical query information, the smart city cloud platform can more accurately assess 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 the system and user data.

[0042] In one implementation of this embodiment, calculating the trust value of the accessing user by combining the historical successful access times and the historical illegal access times includes the following steps: S410, combining the historical number of successful accesses and the historical number of illegal accesses with a preset probability density function to predict the probability of successful access by the accessing user; S420, calculating the average probability of successful access by combining the number of historical successful accesses and the number of historical illegal accesses using a Bayesian estimation algorithm; S430, performing weighted fusion of the successful access probability and the average successful access probability to obtain a primary trust value; S440: Calculate the access user's trust value by combining the primary trust value and a preset time decay factor.

[0043] First, the preset probability density function is used to predict the probability of successful access by the accessing user, combining the historical number of successful accesses and the historical number of illegal accesses. The cumulative number of successful accesses (such as normal login and resource acquisition by legitimate users) is the historical number of successful accesses; the cumulative number of illegal accesses (such as unauthorized login attempts, malicious attacks, etc.) is the historical number of illegal accesses, which reflects the status of past access behaviors. The preset probability density function in this embodiment is a function that describes the probability distribution of the value of a random variable. In this scenario, the probability of successful access by the user can be regarded as a random variable whose value range is between 0 and 1. In this embodiment, the historical number of successful accesses is specifically represented as Y i =N i +1; the number of historical illegal accesses is represented by Y j =N j+1; where the number of historical successful accesses and the number of historical illegal accesses are increased by one to avoid calculation problems caused by the number of historical successful accesses and the number of historical illegal accesses being 0. The preset probability density function is specifically expressed as:

[0044] Among them, Y i Indicates the number of successful historical visits, Y j represents the number of historical illegal accesses, p represents the probability of successful access by the accessing user, and Γ is the gamma function, which is often used to process calculations involving factorial forms in fields such as probability and statistics.

[0045] Substitute the historical successful access times and the historical illegal access times into the preset probability density function to predict the successful access probability of the accessing user.

[0046] Subsequently, the average probability of successful access is calculated using a Bayesian estimation algorithm, combining the historical number of successful accesses and the historical number of illegal accesses. Bayes' theorem describes how to update prior probabilities based on new evidence to obtain posterior probabilities, effectively using known information to modify the probability of an unknown event. First, determine the prior probability. In the absence of any historical data, an initial probability of successful access can be set based on experience or common sense. For example, assuming that successful access and illegal access are equally likely, the prior probability can be set to 0.5. Assuming the historical number of successful accesses is S and the historical number of illegal accesses is F, the prior probability can be updated using the Bayesian formula, analogous to the Bayesian estimation of the binomial distribution. Assume the prior distribution is a Beta distribution with parameters α and β. α and β are hyperparameters and can be initialized to 1 (uniform distribution) or adjusted based on domain knowledge. The prior distribution can be chosen in various ways. If an uninformative prior is used (i.e., no bias assumptions are made about the results), α = β = 1 can be used. Based on Bayesian estimation, the posterior distribution remains a Beta distribution, with its parameters updated to α′ = α + S and β′ = β + F.

[0047] For the Beta distribution with parameters α′ and β′, its expectation (i.e., the average probability of successful access) is calculated as

[0048] The average successful access probability is calculated using the above formula.

[0049] Next, the probability of successful access and the average probability of successful access are weighted and combined to produce a primary trust value. Weighted fusion is a mathematical process that assigns different weights to the probability of successful access and the average probability of successful access (the weight is a value between 0 and 1, and the sum of the two weights is 1). The two probability values ​​are then combined using a weighted summation. The primary trust value is a numerical value obtained through this weighted fusion operation, which serves as a preliminary measure of the level of trust in the visitor or access behavior. A higher value generally indicates greater trustworthiness. In this embodiment, the probability of successful access and the average probability of successful access can be determined based on actual circumstances. For example, let the probability of successful access be Ps, with a weight of ws; the average probability of successful access be Pavg, with a weight of wavg, and where ws + wavg = 1. The primary trust value T is then calculated as: 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.

[0050] The trust value of the accessing user is calculated by combining the primary trust value and the preset time decay factor. In this embodiment, the primary trust value is a value obtained by weighted fusion of the probability of successful access and the average probability of successful access. It preliminarily reflects the degree of trust in the accessing 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 evaluation will weaken over time. The longer the time, the lower the reference value of the past behavior. An exponential decay model is used to combine the primary trust value and the time decay factor to calculate the trust value of the accessing user. Assuming that the primary trust value is T0, the time decay factor is λ, and the time interval between the current time and the last calculated trust value is Δt, the formula for calculating the accessing user's trust value T can be expressed as:

[0051] For example, if the primary trust value T0 = 0.8, the time decay factor λ = 0.9, and 3 time units have passed since the last trust value calculation, that is, Δt = 3, then T = 0.8 × 0.9 3 =0.8×0.729=0.5832, and then the trust value of the visiting user is obtained.

[0052] By calculating the trust value of accessing users and considering overall access trends from comprehensive historical data, multi-angle analysis makes the assessment of the probability of successful access more comprehensive and accurate, laying a good foundation for trust value calculation. The probabilities obtained from two different methods are weighted and fused, integrating the characteristics of a single access and the overall historical situation, overcoming the limitations of a single method and allowing the primary trust value to more accurately reflect the credibility of user access. A time decay factor is introduced to enable the trust value to change dynamically over time. It can adapt to the evolution of access behavior over time. For example, the trust value of long-term inactive users will automatically decrease, and verification can be strengthened when they visit again, better coping with complex and changing network environments. By calculating trust values ​​through multiple steps, legitimate and illegal access can be distinguished more accurately. For access with low trust values, measures such as secondary authentication and restricted permissions are taken to effectively prevent security threats such as illegal intrusion and account theft, thereby improving the overall security of the system.

[0053] In one implementation of this embodiment, before building a pierceable key structure by combining the access user's trust value, the preset ABAC model, and the preset smart city alliance chain, the following steps are included: S510, obtaining the historical successful access times and the historical illegal access times of all registered users; S520, calculating the user trust value corresponding to each registered user by combining the historical successful access times and the historical illegal access times of each registered user using a preset probability density function and a Bayesian estimation algorithm; S530: Execute 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; S540: Generate a public key and a private key for each registered user by combining the user trust value, public parameters, and master key corresponding to each registered user.

[0054] Figure 2 A schematic diagram of a structure for querying data based on a smart city cloud platform is provided in an embodiment of the present application. Figure 2 As shown in the figure, the key center first performs initialization processing and sends the key to the data user. After the data user initiates access to the blockchain, the blockchain verifies and uses the smart city cloud platform to download the data and send it to the data user.

[0055] Obtaining the historical number of successful and illegal accesses for all registered users refers to collecting the number of successful and illegal accesses for each registered user in the system over the past period of time. Successful accesses refer to the number of times a user has logged into the system or accessed resources normally and legally (e.g., successful account and password verification and access with matching permissions); illegal accesses refer to the number of times a user has attempted to log in or access resources illegally (e.g., incorrect passwords, unauthorized access, malicious attacks, etc., which are identified as unsafe 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 through technical means and stored in log files or database tables.

[0056] Combined with the historical number of successful accesses and illegal accesses of each registered user, the user trust value corresponding to each registered user is calculated using a preset probability density function and a Bayesian estimation algorithm. First, the preset probability density function and the historical number of successful accesses and illegal accesses of each registered user are used to predict the probability of successful access of the registered user. The preset probability density function can be:

[0057] Among them, Y i Indicates the number of historical successful visits by registered users, Y j represents the number of historical illegal accesses by registered users, p represents the probability of successful access by registered users, and Γ is the gamma function, which is often used to process calculations involving factorial forms in fields such as probability and statistics.

[0058] After obtaining the successful access probability of registered users, the Bayesian estimation algorithm is used to calculate the average successful access probability based on the historical number of successful accesses and the historical number of illegal accesses. The average successful access probability and the predicted successful access probability of each registered user are weighted and fused to obtain the user trust value corresponding to each registered user.

[0059] Subsequently, a system initialization algorithm is executed on the smart city consortium chain through a pre-set key center. This generates the chain's public parameters and master key. This refers to the process of establishing an initial security system through cryptographic techniques. The core of this process is to use the pre-set key center to generate the basic parameters and core keys required for blockchain operation. A smart city consortium chain is a blockchain jointly managed by multiple organizations, requiring nodes to be authenticated before joining, ensuring both security and controllability. The key center is a security module responsible for generating, managing, and distributing cryptographic keys. It is typically controlled by a trusted organization (such as the consortium chain management committee) to ensure the confidentiality and anti-attack nature of the key generation process. The system initialization algorithm is an initialization procedure executed upon startup of the blockchain system, used to establish the initial cryptographic parameters, node identity system, and consensus rules. Initialization is first performed through the key center. As a trusted source, the key center invokes a pre-set initialization algorithm (such as an algorithm library based on cryptographic standards). This initialization process may rely on hardware security modules (HSMs) or multi-party computation (MPC) to ensure that the key generation process is tamper-proof. Subsequently, public parameters are generated. Public parameters are public parameters shared by all nodes in the consortium chain and 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 the private key of a CA certificate), sign the initial configuration of the chain (such as the 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-signatures (Multi-Sig) or key sharding (such as the Shamir algorithm) to prevent control by a single institution.

[0060] Each registered user's corresponding user trust value, public parameters, and master key are combined to generate each registered user's public and private keys. First, the key parameters are adjusted based on the trust value, mapping the trust value to the key parameters. For example, the trust value is used as one of the input factors of the 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). Here, d represents the private key, which is the key held secretly by the user in an asymmetric encryption system and is used to sign data or decrypt data encrypted by 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 credibility; ⊕ is the XOR operator symbol. The rule of the XOR operation is that the result is 0 if the two operands are the same, and the result is 1 if they are different. For example, 1⊕0=1, and 1⊕1=0. The master key derivation seed refers to the master key, which is the root key with the highest authority in the system. The seed data derived from the master key can be used to further generate user-related keys. The master key derivation seed provides a foundation for the generation of private keys based on the highest level of trust 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: Trust value range Corresponding permissions Key usage T≥80 Data reading and writing + block verification Can be used to sign transactions and participate in consensus 50≤T<80 Data read-only Only used to decrypt public data T<50 Restricted Access The key can only access non-sensitive interfaces The master key serves as the "root of trust" for key generation. Derived key seeds refer to the master key as the top-level key. When generating user keys, a "seed key" must first be derived from the master key, ensuring that all user keys rely on the system's root of trust. For example, the master key uses the HMAC algorithm to generate a user key seed: SK = HMACMK(user ID ⊕ T). The final public-private key pair is then generated based on SK. Key lifecycle management means that the master key can be used for subsequent key updates (such as regular rotation of user private keys) or key revocation (such as freezing a user's key when their trust value plummets). The standardization of public parameters ensures that key generation for all users adheres to uniform cryptographic standards. For example, elliptic curve parameters (such as the curve equation and base point coordinates) are defined by public parameters to prevent interoperability issues caused by different users using different curves. Hash algorithms (such as SHA-3) and signature algorithms (such as ECDSA) are also specified by public parameters to ensure consistent signature verification.

[0061] Through the combination of "trust value + system root key + standardized parameters," a key pair with both security and permission attributes is generated for users. The trust value determines the key's permission boundaries, the master key ensures the system's root trust, and the public parameters guarantee technical compatibility. This also achieves the goal of "efficient access for trusted users and strict control of risky users," while providing technical support for data security, permission auditing, and compliance management.

[0062] In one implementation of this embodiment, building a pierceable key structure by combining the access user's trust value, a preset ABAC model, and a preset smart city alliance chain includes the following steps: S610: Perform attribute evaluation on the access user based on a preset ABAC model to determine an attribute evaluation result corresponding to the access user; S620: Generate a first-level key shard corresponding to the access user using a key generation algorithm based on the attribute evaluation result corresponding to the access user; S630: Supplement the first-level key shard with the access user's trust value to determine the second-level key shard corresponding to the access user; S640: Determine the user authority level of the access user by combining the first-level key shard and the second-level key shard; S650: Construct a puncturable key structure based on the user authority level and the master key.

[0063] Based on the preset ABAC model, the attributes of the accessing user are evaluated to determine the attribute evaluation result corresponding to the accessing user. 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", or "require multi-factor authentication") output after comprehensively calculating the user attributes, resource attributes, and environmental attributes according to the ABAC policy. First, the user attributes are extracted. The user attributes may be user ID, department, trust value (calculated from historical access), etc. After the user attributes are extracted, the preset ABAC model is used to generate the evaluation result. The decision type can be allow or deny, such as allowing access but limiting the amount of data to ≤100. It can be output in JSON or XML format and contains the decision result, effectiveness conditions, audit information, etc.

[0064] After determining the attribute evaluation results, a key generation algorithm is used to generate first-level key shards corresponding to the accessing user based on the attribute evaluation results corresponding to the accessing user. In this embodiment, the attribute evaluation results are derived from a comprehensive evaluation of the accessing user's user attributes, resource attributes, and environmental attributes based on a preset ABAC model. They indicate whether the user is permitted to access the resource, as well as any associated conditions, and serve as an important basis for subsequent key generation. A key generation algorithm is a mathematical algorithm used to generate cryptographic keys. First-level key shards refer to the first level of the process of dividing a complete key into multiple parts (shards). The attribute evaluation results are used as one of the input parameters of the key generation algorithm, and the key generation algorithm performs a series of calculation steps to generate first-level key shards. For example, if the attribute evaluation results indicate that the user has higher access rights, the generated first-level key shards may play a more critical role in the subsequent recovery of the complete key, or have a higher weight when combined with other shards.

[0065] The first-level key shard is supplemented by the accessing user's trust value to determine the second-level key shard corresponding to the accessing user. The first-level key shard is a key fragment derived from a key generation algorithm based on the accessing user's attribute evaluation results. It is a preliminary split of the key and the foundation for constructing a complete key. The accessing user's trust value is calculated by combining the user's historical successful access times and historical unauthorized access times using a preset probability density function and Bayesian estimation algorithm, reflecting the user's trustworthiness. The second-level key shard is a further refined key fragment obtained by incorporating information related to the user's trust value into the first-level key shard. The trust value is integrated with the first-level key shard using some encoding or calculation method. For example, the trust value is converted into binary data and then subjected to a bitwise logical operation (such as an exclusive OR operation) with the binary representation of the first-level key shard, or the trust value is substituted as a parameter into a specific function to transform the first-level key shard. The user's trust value reflects the reliability of the user's past access behavior. By integrating the trust value into the first-level key shard, the second-level key shard not only contains permission information based on attribute evaluation but also reflects the user's trustworthiness. For users with high trust values, their second-level key shards may have more favorable characteristics (such as higher priority and more relaxed usage conditions) in subsequent key reconstruction or access authorization; for users with low trust values, their second-level key shards may be subject to more restrictions to enhance security.

[0066] The user's permission level is determined by combining the first-level and second-level key shards. These shards carry different dimensions of user characteristics. The first-level key shard is generated based on the user's attribute assessment results and is directly associated with the user's basic permission level. The second-level key shard is generated by supplementing the first-level shard with the user's trust value, reflecting the credibility and historical performance of the user's behavior. Permission level is a quantitative description of the user's ability and scope of resource access, such as ordinary user, advanced user, and administrator. Different levels correspond to different resource access scopes, operational permissions, or security verification requirements. Further refined key fragments are generated by integrating user trust information into the first-level key shard. The trust value is fused with the first-level key shard using some encoding or calculation method. By integrating the trust value into the first-level key shard, the second-level key shard not only contains permission information based on the attribute assessment but also reflects the user's trustworthiness.

[0067] Finally, a pierceable key structure is constructed based on user permission levels and the master key. The master key is the "root key" in the key hierarchy and the highest-level encryption key, used to generate all lower-level keys (e.g., key shards at each level). Key derivation based on permission levels can be implemented using a hierarchical key generation algorithm. The HKE algorithm is used to recursively generate keys at each level from the master key, ensuring that higher-level keys are dependent on lower-level keys for generation, forming a "permission chain dependency." Next, key shards are bound to permissions. First-level shards are generated from user attributes (ABAC model), second-level shards are generated from user trust values, and higher-level shards are generated from lower-level shards combined with permission level parameters. The key for a user at permission level L2 consists of a first-level shard derived from the master key and a second-level shard derived from the first-level shard, forming a path: master key → first-level shard → second-level shard. When a user's permissions are upgraded from L2 to L3, the system supplements the user with a third-level shard via the master key path: master key → first-level shard → second-level shard → third-level shard.

[0068] By combining the user's trust value, the preset ABAC model and the preset smart city alliance chain, permissions can be adjusted dynamically, potential risk users can be identified, and key sharding and permission levels can be automatically adjusted without human intervention, thus achieving a dynamic, sophisticated and secure access control system.

[0069] In one implementation of this embodiment, the user authority levels include high-authority users and low-authority users, and the puncturable key structure includes the following steps: S710. When the high-level permission user receives the delegation key of the low-level permission user, the high-level permission user determines the attribute level and real-time trust value of the low-level permission user based on the preset ABAC model and the smart city alliance chain; S720: If the real-time trust value of the low-level permission user exceeds a preset trust threshold and the attribute level is a preset specific role attribute, the high-level permission user distributes a delegation key to the low-level permission user; S730: 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 the delegation key to the low-level permission user; S740: After the high-level permission user distributes the delegation 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; S750: When the real-time trust value of the low-level authority user is lower than the preset trust threshold, the delegation key of the low-level authority user is punctured using the Puncture algorithm; S760: When the real-time trust value of the high-level user is lower than the preset trust threshold, the attribute level corresponding to the high-level user is unbound from the key.

[0070] In this embodiment, user permission levels include high-level and low-level permissions. High-level permissions refer to users with higher access rights to system resources or data. They can perform more sensitive operations, such as data modification and system configuration changes. They may also bear greater security responsibilities, and their use of permissions is subject to stricter monitoring and auditing. Low-level permissions refer to users with limited access rights. They can only perform specific, relatively secure operations and cannot access or modify sensitive data or system configurations. Their permissions are typically closely related to their job responsibilities and required tasks. When a high-level permission user receives a delegation key from a low-level permission user, the high-level permission user determines the low-level permission user's attribute level and real-time trust value based on a preset ABAC model and the smart city consortium chain. When a high-level permission user receives a delegation key from a low-level permission user through a secure channel, the high-level permission user typically receives the delegation key from the low-level permission user through a secure channel. The delegation key typically contains key information such as the low-level permission user's identity, permission scope, and validity period. The high-level permission user evaluates the low-level permission user's attributes based on a preset ABAC (Attribute and Access Control) model. The evaluation may include the user's role, department, security level, and historical behavior records. Through attribute assessment, the low-level user's attribute level is determined to determine whether the delegated authority is justifiable. Subsequently, the high-level user, combined with data from the Smart City Alliance Chain, calculates the low-level user's real-time trust value. This trust value is based on multiple dimensions, including the user's historical access behavior, data manipulation records, and security audit results. This real-time trust value reflects the low-level user's current credibility and serves as a crucial basis for delegation decisions. Based on the attribute level and real-time trust value, the high-level user decides whether to accept the delegated key from the low-level user. If the low-level user's attribute level and trust value meet the pre-set security policy, the high-level user may accept the delegation and exercise the corresponding authority. Otherwise, the high-level user will reject the delegation, potentially triggering further security review or alerts.

[0071] If the real-time trust value of a low-level user exceeds the preset trust threshold and the attribute level is the preset specific role attribute, the high-level user will distribute a delegation 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 screen high-credibility users and prevent low-credibility users from performing malicious operations through temporary permissions; the preset specific role attribute refers to a set of attribute characteristics pre-defined in the access control policy, which is used to identify whether the user is qualified to perform specific operations or access specific resources. When the real-time trust value of a low-level user exceeds the preset trust threshold and its attribute level meets the preset specific role attribute, the high-level user will distribute a delegation key to the low-level user. This key may be used to access specific resources, perform specific operations, or participate in specific transactions. The delegation key acts as a temporary, limited permission credential generated and distributed by a high-level user.

[0072] 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, the high-level user will refuse to distribute a delegation key to the low-level user. The high-level user will decide whether to distribute a delegation key to the low-level user based on the low-level user's real-time trust value and attribute level. If the real-time trust value of a low-level user does not exceed this preset trust threshold, it means that the user is not considered sufficiently trustworthy in the current situation. At the same time, if the attribute level of a low-level user does not meet the preset specific role attributes, it means that the user does not have the qualifications or permissions required to perform specific operations or access specific resources. If the low-level user does not meet the above two conditions, the high-level user will refuse to distribute the delegation key.

[0073] After a high-level user distributes a delegation key to a 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 consortium chain. A delegation key is a credential granted by a high-level user to a low-level user for accessing specific resources or performing specific operations. Distributing a delegation key signifies that the low-level user has, to a certain extent, obtained authorization from the high-level user. A smart contract is a self-executing piece of code deployed on a blockchain that defines and executes specific business logic. Within the smart city consortium chain, 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 multiple factors, including user behavior, interactions, and service quality. It reflects the user's trustworthiness at the current moment and serves as an important basis for access control decisions. When a low-level user's real-time trust value exceeds a preset trust threshold and its attribute level meets the pre-set specific role attributes, the high-level user distributes a delegation key to the user. After distributing the delegation key, the high-level user may wish to continuously monitor the trust status of the low-level user. High-level users can obtain the real-time trust value of low-level users through the smart contract of the smart city alliance chain. The smart contract can trigger the calculation and update of the trust value regularly or according to specific events, and store the results on the blockchain for high-level users to query.

[0074] When the real-time trust value of a low-privilege user falls below a preset trust threshold, the user's delegated key is punctured using the Puncture algorithm. Puncture punctures the key by sharding it, preserving some of the key's functionality while preventing it from performing certain operations (such as accessing sensitive data). When the real-time trust value of a low-privilege user falls below the preset trust threshold, the delegated key is punctured to mitigate security risks or restrict the user's access rights. This puncture allows the system to quickly reduce the low-privilege user's access rights, preventing them from accessing sensitive resources or performing critical operations. Smart contracts modify the key's access policy, for example, from allowing all operations to read only. The Puncture algorithm is then applied to the target shard to generate a punctured shard, making it unable to decrypt the corresponding operations. The punctured shard is then reassembled with the other unpunctured shards to form a new key. When the system detects a decrease in the trust value of a high-privilege user, it automatically triggers the unbinding of the attribute level from the key, effectively revoking the user's specific permissions. For example, if the user's attribute level is department administrator, unbinding their key will prevent them from accessing the department's core data. Unbinding severs the user's existing permission chain, preventing low-trust users from continuing to manipulate sensitive data. For example, if the financial system detects an abnormal trust value, it immediately unbinds the fund approval attribute from the key. Permission status is dynamically adjusted based on the real-time trust value, so that after unbinding, the user retains only basic permissions. For example, after unbinding a user's original full file permissions, only file viewing permissions are retained.

[0075] Through data-based trust assessment and role attribute matching, low-level permission users can temporarily obtain high-level permissions when specific conditions are met, thereby supporting cross-level collaboration and ensuring the flexibility and security of permission management in smart cities.

[0076] In one implementation of this embodiment, dynamic permission management of access users is performed using a puncturable key structure. Identity authorization of access users based on the puncturable key structure and sharing of data queried by access users include the following steps: S810. Determine the identity level of the accessing user by combining the puncturable key structure; S820: Map the identity level to a preset authority level system to determine the authority level corresponding to the identity level; S830. Generate an authorization certificate corresponding to the permission level using encryption technology with a puncturable key structure; S840. Verify the authenticity and integrity of the authorization certificate. S850: If the authorization credential passes the verification, it is determined that the user's shared data is accessed.

[0077] Determining the identity level of an accessing user in conjunction with a puncturable key structure involves analyzing the user's real-time trust value and the permission hierarchy implicit in the puncturable key structure to comprehensively determine the user's temporary identity level, thereby achieving fine-grained access control. In this embodiment, the puncturable key structure consists of two levels of key shards, each corresponding to a different dimension of permission control. These include first-level key shards and second-level key shards. The first-level key shards are base shards of permissions generated based on a preset ABAC model and user attributes; the second-level key shards are supplementary shards that supplement the first-level shards with the user's real-time trust value. In this embodiment, the real-time trust value is implicit in the permission hierarchy of the second-level key shards. In this embodiment, the identity level is a temporary permission label generated based on the real-time trust value and the key status (e.g., whether it is punctured), such as "trusted user" or "risky user." The identity level of the accessing user is determined in combination with the puncturable key structure. Specifically, the identity level can be determined from the key status. For example, when the key status is that the first-level shard is complete + the second-level shard is complete, the corresponding implicit permission level is high-level permission (such as data reading and writing + analysis). Taking medical data access as an example, the chief physician can modify the patient's diagnosis record and export the analysis report; when the key status is that the first-level shard is complete + the second-level shard is punctured, the implicit permission level is intermediate permission (such as read-only + limited download), and the intern can only query the medical record but cannot modify or export it; when the key status is that the first-level shard is partially punctured + the second-level shard is invalid, the implicit permission level is low-level permission (such as preview + application permission), and the nurse can only view the patient's basic information and submit an access application. That is, the permission hierarchy in the puncture key structure is implied by a two-layer mapping of "preset ABAC attributes → first-level shards → basic permissions" and "trust value → second-level shards → permission adjustment". The basic permission hierarchy implied by the first-level shards is directly assigned by the preset ABAC model, such as "department attributes → data access scope"; the dynamic adjustment hierarchy implied by the second-level shards is modified in real time by the trust value, such as "high trust value → permission enhancement, low trust value → permission puncture"; the final permission hierarchy implied by the overall state of the key can directly determine the user's currently executable operations, such as read-write, read-only, no permission, etc., through physical characteristics such as shard integrity and puncture marks.

[0078] Mapping identity levels to a preset permission hierarchy: Determining the permission level corresponding to an identity level involves associating a user or entity's identity within the system (such as role, position, department, etc.) with specific access rights and scope of operations. The core purpose of this process is to ensure that users only have access to the minimum set of permissions required for their duties, while also ensuring the security, compliance, and manageability of the system. The preset permission hierarchy defines all possible permission levels and their scope of operations in advance, forming a standardized permission library. Subsequently, the corresponding permission levels are defined based on the identity level, forming a mapping table. When a user's identity level changes, the system automatically adjusts their permission level based on the mapping rules.

[0079] The encryption technology of the puncturable key structure is used to generate authorization credentials corresponding to the permission level. In this embodiment, the puncturable key structure is a key design that supports dynamic adjustment, allowing the key to be downgraded or invalidated through the puncture algorithm. The authorization credential is the credential for users to access system resources. It is usually generated based on a key and used to verify user permissions. Key generation and permission binding refers 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 through the puncture algorithm. The authorization credential is then generated based on the adjusted key, and the key permission information is embedded in the credential.

[0080] Verify the authenticity and integrity of the authorization credential, which is a digital identity used to prove that a user has the right to access specific resources or perform specific operations. Authenticity verification refers to confirming that the credential is issued by a trusted authority and is not forged. This can be achieved through digital signature verification or certificate chain verification. Digital signature verification refers to using the issuer's public key to verify whether the signature is valid; certificate chain verification verifies that the certificate is issued by a trusted CA and has not been revoked. Integrity verification is to ensure that the credential content has not been tampered with during transmission or storage. Hash verification can be used for verification by calculating the hash value of the credential content and comparing it with the hash value in the signature.

[0081] If the authorization credentials are verified, access to the user's shared data is confirmed. This means data sharing is only possible if the credentials pass authenticity and integrity verification. Data sharing can be done directly, where the user is granted access rights and can read or manipulate the target data. Alternatively, data sharing can be done through proxy sharing, where the data is masked and pushed to the user based on the permissions specified in the credentials (e.g., only some fields are shared).

[0082] An embodiment of the present application also provides a machine-readable storage medium, which stores instructions for enabling a machine to execute the above-mentioned blockchain-based smart city cloud platform data authorization and sharing method.

[0083] An embodiment of the present application further provides an electronic device, including: a memory configured to store instructions; and The processor is configured to call instructions from the memory and implement the above-mentioned blockchain-based smart city cloud platform data authorization and sharing method when executing the instructions.

[0084] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Thus, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0085] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0086] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0087] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 The steps for the function specified in one or more boxes.

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

[0089] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0090] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can be implemented using any method or technology for information storage. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change RAM (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, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0091] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0092] The above are merely embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included within the scope of the claims of the present application.

Claims

1. A data authorization and sharing method for a smart city cloud platform based on blockchain, characterized in that: Applied to the smart city cloud platform, the method includes the following steps: In response to receiving a query instruction from a visiting user, determining historical query information of the visiting user through the smart city cloud platform; authenticating the access user based on a preset identity registration chain, and if the access user passes the authentication, evaluating the access user's trust value based on the historical query information; Performing trustworthiness verification on the trust value; 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; The puncturable key structure is used to perform dynamic authority management on the access user, and the access user is authorized based on the puncturable key structure and the data queried by the access user is shared.

2. The method according to claim 1, characterized in that 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, 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; Building an identity registration chain for all registered users based on all the registration process nodes, obtaining registration information of all the registration process nodes, and uploading the registration information to the identity registration chain; A smart city alliance chain of the target city is built based on all the running process nodes, the running information of all the running process nodes is obtained, and the running information is uploaded to the smart city alliance chain.

3. The method according to claim 1, characterized in that The authentication of the access user based on the preset identity registration chain and the evaluation of the access user's trust value based on the historical query information if the access user passes the authentication include the following steps: Extracting a first hash value of the identity information and biometric information corresponding to the accessing user from a preset smart contract; Extracting the registration information of the accessing 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, and if the first hash value is equal to the second hash value, determining that the access user has passed the identity authentication; When the access user passes the identity authentication, the historical successful access times and the historical illegal access times of the access user are determined through the historical query information; The trust value of the accessing user is calculated by combining the historical number of successful accesses and the historical number of illegal accesses.

4. The method according to claim 3, characterized in that The step of calculating the trust value of the accessing user by combining the historical successful access times and the historical illegal access times comprises the following steps: Combining the historical number of successful accesses and the historical number of illegal accesses, using a preset probability density function to predict the probability of successful access by the accessing user; Calculating an average probability of successful access by combining the number of historical successful accesses and the number of historical illegal accesses using a Bayesian estimation algorithm; Performing weighted fusion on the successful access probability and the average successful access probability to obtain a primary trust value; The trust value of the accessing user is calculated by combining the primary trust value and a preset time decay factor.

5. The method according to claim 2, characterized in that Before the pierceable key structure is constructed by combining the trust value of the accessing user, the preset ABAC model and the preset smart city alliance chain, the following steps are included: Obtain the number of successful and illegal visits in history for all registered users; Calculating the user trust value corresponding to each registered user by combining the historical successful access times and the historical illegal access times of each registered user using a preset probability density function and a Bayesian estimation algorithm; Executing 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; The public key and private key of each registered user are generated by combining the user trust value, the public parameters and the master key corresponding to each registered user.

6. The method according to claim 5, characterized in that The step of constructing a pierceable key structure by combining the trust value of the accessing user, the preset ABAC model, and the preset smart city alliance chain includes the following steps: Performing attribute evaluation on the access user based on a preset ABAC model to determine an attribute evaluation result corresponding to the access user; Generate a first-level key shard corresponding to the access user using a key generation algorithm according to the attribute evaluation result corresponding to the access user; Supplementing the first-level key shard with the trust value of the accessing user to determine the second-level key shard corresponding to the accessing user; Determining the user authority level of the access user by combining the first-level key shards and the second-level key shards; A puncturable key structure is constructed based on the user authority level and the master key.

7. The method according to claim 6, characterized in that The user authority levels include high-level authority users and low-level authority users, and the puncturable key structure includes the following steps: When the high-level permission user receives the delegation key of the low-level permission user, the high-level permission user determines the attribute level and 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 authority user exceeds a preset trust threshold and the attribute level is a preset specific role attribute, the high-level authority user distributes a delegation key to the low-level authority user; If the real-time trust value of the low-level authority user does not exceed a preset trust threshold and the attribute level is not a preset specific role attribute, the high-level authority user refuses to distribute a delegation key to the low-level authority user; After the high-level permission user distributes the delegation 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 authority user is lower than a preset trust threshold, the delegation key of the low-level authority user is punctured using a Puncture algorithm; When the real-time trust value of the high-level authority user is lower than a preset trust threshold, the attribute level corresponding to the high-level authority user is unbound from the key.

8. The method according to claim 1, characterized in that The method of dynamically managing the access user's rights by using the puncturable key structure, authorizing the access user's identity based on the puncturable key structure, and sharing the data queried by the access user comprises the following steps: determining the identity level of the accessing user in combination with the puncturable key structure; Mapping the identity level to a preset authority level system to determine the authority level corresponding to the identity level; Generate an authorization certificate corresponding to the permission level using the encryption technology of the puncturable key structure; Verifying the authenticity and integrity of the authorization credentials; If the authorization credential passes verification, the data is determined to be shared with the accessing user.

9. A machine-readable storage medium, characterized in that The machine-readable storage medium stores instructions for enabling a machine to execute the blockchain-based smart city cloud platform data authorization and sharing method according to any one of claims 1 to 8.

10. A blockchain-based smart city cloud platform data authorization and sharing system, characterized in that: include: a memory configured to store instructions; as well as A processor is configured to call the instruction from the memory and to implement the blockchain-based smart city cloud platform data authorization sharing method according to any one of claims 1 to 8 when executing the instruction.

Images