Blockchain-based key processing method, apparatus, device, and storage medium

Abstract

This invention discloses a blockchain-based key processing method, apparatus, device, and storage medium, belonging to the field of computer science. The blockchain-based key processing method includes the following steps: after a user-end node sends a data access request to a server node, it receives a user attribute notification broadcast in the blockchain; wherein, the user attribute notification is obtained by the user-end node based on its private key; the private key is generated by the blockchain's key generation node based on the master private key and the user-end node's attribute information when the user-end node registers with the blockchain; a smart contract is invoked, executing the data access specification logic declared in the smart contract; based on the user attribute notification and the data access specification logic, it is determined whether the attribute information conforms to the data access specification; if the attribute information does not conform to the data access specification, a notification to invalidate the private key is sent to the blockchain, causing the blockchain to invalidate the private key. This invention can supervise the key generation behavior of the key generation center and handle erroneous keys generated.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to blockchain-based key processing methods, apparatus, devices, and storage media. Background Technology

[0002] In cloud computing environments, the most widely used access control method is a public-private key encryption scheme that supports verifiable outsourced decryption. This scheme enables non-interactive access control while encrypting data, outsourcing numerous complex decryption operations to a third-party server—the key generation center. Users only need to perform simple calculations to recover the plaintext. The key generation center generates a private key for each user registered in the cloud computing environment, which the user uses to decrypt the encrypted data during data access.

[0003] However, in related technologies, it is difficult for the system to monitor the behavior of the key generation center in generating incorrect keys. Summary of the Invention

[0004] The main objective of this invention is to provide a blockchain-based key processing method, apparatus, device, and storage medium, aiming to solve the technical problem that the system has difficulty in supervising the behavior of the key generation center in generating erroneous keys.

[0005] To achieve the above objectives, this invention provides a blockchain-based key processing method for use as a supervisory node in a blockchain. The method includes the following steps:

[0006] After the user node sends a data access request to the server node, it receives a user attribute notification broadcast in the blockchain. The user attribute notification is obtained by the user node based on its private key. The private key is generated by the blockchain's key generation node based on the master private key and the user node's attribute information when the user node registers with the blockchain.

[0007] Invoke the smart contract, execute the data access specification logic declared by the smart contract, and determine whether the attribute information conforms to the data access specification based on the user attribute notification and the data access specification logic.

[0008] If the attribute information does not conform to the data access specifications, a notification to revoke the private key is sent to the blockchain so that the blockchain revokes the private key.

[0009] Optionally, the smart contract is invoked to execute the data access specification logic declared in the smart contract. The steps to determine whether the attribute information conforms to the data access specification based on the user attribute notification and the data access specification logic include:

[0010] After the user node passes the access verification of the data to be accessed, the attribute information of the user node is determined based on the user attribute notification and the accessible user attributes of the data to be accessed.

[0011] The steps involve calling the smart contract, executing the data access specification logic declared in the smart contract, and determining whether the attribute information conforms to the data access specification.

[0012] Optionally, the step of determining the attribute information possessed by the user-end node based on the user attribute notification and the accessible user attributes of the data to be accessed includes:

[0013] The user attribute notification is encrypted based on the master public key and the access policy of the data to be accessed, and the encryption result is obtained; wherein, the access policy restricts the user attributes that can be accessed.

[0014] If the encryption result matches the verification information of the data to be accessed, the attribute information of the user node is determined according to the access policy. The verification information is selected by the server node from at least one original verification information of the data to be accessed and sent to the user node in response to the data access request. The original verification information is ciphertext data generated by the data upload node of the data to be accessed after encrypting random data according to the access policy and the master public key of the data to be accessed.

[0015] Secondly, the present invention also provides a blockchain-based key processing method for user-end nodes, the method comprising the following steps:

[0016] After the user node sends a data access request to the server node, a user attribute notification is generated based on the user node's private key. The private key is generated by the blockchain's key generation node when the user node registers with the blockchain, based on the data access specifications, the master private key, and the user node's attribute information.

[0017] The system broadcasts user attribute notifications to the blockchain so that the monitoring nodes in the blockchain can receive the user attribute notifications, invoke the smart contract, execute the data access specification logic declared in the smart contract, and determine whether the attribute information conforms to the data access specification based on the user attribute notifications and the data access specification logic; and if the attribute information does not conform to the blockchain access standard, it sends a notification to the blockchain to revoke the private key.

[0018] Upon receiving the notification, the private key is revoked.

[0019] Optionally, after the client node sends a data access request to the server node and before the step of generating a user attribute notification based on the client node's private key, the method further includes:

[0020] When registering to the blockchain, the user receives a private key generated by the key generation node based on the master private key and the attribute information of the user node; the attribute information is generated by the key generation node for the user node.

[0021] Optionally, after the client node sends a data access request to the server node and before the step of generating a user attribute notification based on the client node's private key, the method further includes:

[0022] Send a data access request to the server node;

[0023] Receive verification information sent back by the server node; wherein, the verification information is selected by the server node from at least one original verification information in the data to be accessed; the original verification information is ciphertext data generated by the data upload node of the data to be accessed after encrypting random data according to the access policy and master public key of the data to be accessed;

[0024] The steps for generating user attribute notifications based on the user node's private key include:

[0025] The verification information is decrypted using the private key to obtain user attribute notifications.

[0026] Thirdly, the present invention also provides a blockchain-based cryptographic verification device for use as a supervisory node in a blockchain, comprising:

[0027] The notification receiving module is used to receive user attribute notifications broadcast in the blockchain after the user node sends a data access request to the server node. The user attribute notification is obtained by the user node based on its private key. The private key is generated by the blockchain's key generation node based on the master private key and the user node's attribute information when the user node registers with the blockchain.

[0028] The specification verification module is used to call the smart contract, execute the data access specification logic declared by the smart contract, and determine whether the attribute information conforms to the data access specification based on the user attribute notification and the data access specification logic.

[0029] The notification broadcast module is used to send a notification to the blockchain to revoke the private key if the attribute information does not meet the blockchain access standards.

[0030] Fourthly, the present invention also provides a blockchain-based key processing device for use in a blockchain user-end node, comprising:

[0031] The notification generation module is used to generate user attribute notifications based on the private key of the user node after the user node sends a data access request to the server node. The private key is generated by the blockchain key generation node based on the attribute information of the user node when the user node registers with the blockchain.

[0032] The notification broadcast module is used to broadcast user attribute notifications to the blockchain, so that the supervisory nodes in the blockchain can receive the user attribute notifications, call the smart contract, execute the data access specification logic declared in the smart contract, and determine whether the attribute information conforms to the data access specification based on the user attribute notifications and the data access specification logic; and if the attribute information does not conform to the blockchain access standard, a notification to revoke the private key is sent to the blockchain.

[0033] The private key deactivation module is used to deactivate a private key upon receiving a notification.

[0034] Fifthly, the present invention also provides a blockchain-based cryptographic processing device, comprising: a memory, a processor, and a blockchain-based key processing program stored in the memory and executable on the processor, wherein the processor implements the above-described method when executing the blockchain-based key processing program.

[0035] In a sixth aspect, the present invention also provides a computer-readable storage medium storing a blockchain-based key processing program, wherein the processor implements the above-described method when executing the blockchain-based key processing program.

[0036] This invention proposes a blockchain-based key processing method. By obtaining user attribute notifications generated by user-end nodes and calling smart contracts to execute the data access specification logic declared in the smart contracts, the method determines whether the attribute information conforms to the data access specification based on the attribute information associated in the user attribute notification. If the attribute information does not conform to the blockchain access standard, the method sends a notification to the blockchain to revoke the private key, thereby supervising the key generation behavior of the key generation center and promptly handling erroneous keys generated by the key generation center. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the various nodes in the blockchain involved in the blockchain-based key processing method of this invention;

[0038] Figure 2 This is a schematic diagram of the blockchain-based key processing device of the present invention;

[0039] Figure 3 This is a flowchart illustrating the first embodiment of the blockchain-based key processing method of the present invention.

[0040] Figure 4 This is a detailed flowchart illustrating step S102 of the first embodiment of the blockchain-based key processing method of the present invention.

[0041] Figure 5 This is a schematic diagram of a smart contract for the first embodiment of the blockchain-based key processing method of the present invention;

[0042] Figure 6 This is a flowchart illustrating the second embodiment of the blockchain-based key processing method of the present invention.

[0043] Figure 7 This is a schematic diagram of the functional modules of the first embodiment of the blockchain-based key processing device of the present invention;

[0044] Figure 8 This is a functional module diagram of the second embodiment of the blockchain-based key processing device of the present invention.

[0045] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0046] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0047] In cloud computing environments, the most widely used access control method is attribute encryption schemes that support verifiable outsourced decryption. Specifically, the key generation center calls the system initialization algorithm to generate a master public key and a master private key. It then publishes the master public key while keeping the master private key secret. When a user registers and enters the cloud environment, the key generation center generates corresponding user attributes for that user based on data access specifications. It then calls the key generation algorithm, taking the master private key and user attributes as input, to generate a corresponding private key and a conversion key. Thus, the private key contains the user attributes. The conversion key can be shared with the server.

[0048] The data upload node invokes an encryption algorithm, using the master public key and access policy to encrypt plaintext data into ciphertext data, and generates a verification key for the data user, i.e., the user terminal. The access policy determines which user attributes allow the correct decryption of the ciphertext data. The data upload node stores the ciphertext data on the server. When a user terminal sends an access request to download the ciphertext data, the user terminal needs to be verified to prove its right to open the ciphertext. This can be done through zero-knowledge proofs. Specifically, when the server receives the access request, it sends a verification ciphertext to the user terminal. This verification ciphertext is obtained by the data upload node using the same encryption method on a random message. The user terminal decrypts the verification ciphertext using its private key and sends the decrypted ciphertext to the server or broadcasts it to the blockchain. Upon receiving the decrypted ciphertext, the server re-encrypts it using the master public key and access policy. If the encryption result matches the verification ciphertext, it indicates that the user terminal has passed the zero-knowledge proof and possesses the corresponding private key. Therefore, the server can invoke a conversion algorithm to decrypt the ciphertext data into partially decrypted ciphertext data using a conversion key, and then send this partially decrypted ciphertext data to the user. When the user receives the partially decrypted ciphertext data from the server, it invokes a decryption algorithm using its private key and verification key to decrypt the partially decrypted ciphertext data, thereby obtaining the plaintext data from the data upload node.

[0049] However, when the key generation center is subjected to network attacks or internal data processing errors, it may inadvertently generate erroneous private keys for users that do not conform to data access standards. To prevent erroneous private keys from affecting data interaction within the cloud environment, it is necessary to identify and handle these erroneous keys.

[0050] To address this, this invention provides a blockchain-based key processing method. This method obtains user attribute notifications generated by user-end nodes, calls smart contracts to execute the data access specification logic declared in the smart contracts, determines whether the attribute information conforms to the data access specification, and sends a notification to the blockchain to revoke the private key when the attribute information does not conform to the blockchain access standard. This method monitors the key generation behavior of the key generation center and promptly handles erroneous keys.

[0051] The inventive concept of the present invention will be further illustrated below with reference to some specific embodiments.

[0052] This invention provides a first embodiment of a blockchain-based key processing method. (See also...) Figure 3 , Figure 3 This is a flowchart illustrating the first embodiment of the blockchain-based key processing method of the present invention.

[0053] See Figure 1 , Figure 1This is a schematic diagram of blockchain nodes involved in an embodiment of the present invention. In this embodiment, the blockchain includes data upload nodes, server nodes, user-end nodes, and key generation center nodes. The key generation center can be a distributed key generation center, generating keys through consensus among multiple key generation centers. The data upload node generates a data access specification and records it in the blockchain's authoritative contract. The data access specification stipulates what user attributes user-end nodes in the blockchain system should or should not possess. In the blockchain system, the data access specification is instantiated as a smart contract. This blockchain-based key processing method is used as a supervisory node in the blockchain. It is worth noting that any of the data upload nodes, server nodes, and user-end nodes can be used as a supervisory node.

[0054] In this embodiment, the blockchain-based key processing method is used on a supervisory node in the blockchain. The blockchain-based key processing method includes the following steps:

[0055] Step S101: After the user node sends a data access request to the server node, it receives the user attribute notification broadcast in the blockchain.

[0056] In this context, user attribute notifications are obtained by the user-end node based on its private key. The private key is generated by the blockchain's key generation node when the user-end node registers with the blockchain, based on the master private key and the user-end node's attribute information. The data access specifications in the blockchain define what user attributes a user-end node should or should not possess. Therefore, ideally, the attribute information allocated or generated by the key generation center for user-end nodes should conform to these data access specifications. The private key possessed by the user-end node also implicitly contains this attribute information. Correspondingly, user attribute notifications also contain this attribute information. User attribute notifications are essentially the user-end node broadcasting its attribute information to the blockchain.

[0057] As one option in this embodiment, the user node and the server node communicate using zero-knowledge proofs to verify that they possess corresponding attribute information. When the user node sends a data access request, the server node verifies, using zero-knowledge proofs, whether the user node has the necessary qualifications to decrypt the data to be accessed. Therefore, the server node sends a verification ciphertext to the user node. The user node decrypts the verification ciphertext using its private key, thereby obtaining a user attribute notification, and broadcasts this notification to the blockchain so that monitoring nodes can receive it. In this case, the user attribute notification is a zero-knowledge proof process document. It is easy to understand that the attribute information in the user attribute notification is encrypted by the key generation center and cannot be directly obtained from the user attribute notification itself.

[0058] As another option in this embodiment, the user attribute notification can be the attribute information obtained by the user node after decrypting the private key. In this case, the user attribute notification is in plaintext, and the supervisory node can directly obtain the attribute information of the user node.

[0059] Step S102: Invoke the smart contract, execute the data access specification logic declared by the smart contract, and determine whether the attribute information conforms to the data access specification based on the user attribute notification and the data access specification logic.

[0060] The monitoring node deploys a smart contract, allowing it to determine whether the attribute information contained in the user attribute notification conforms to the data access specification logic declared in the smart contract. The smart contract then outputs either "correct" or "incorrect."

[0061] When generating and maintaining data access specifications, some data nodes in the blockchain may malfunction due to unexpected failures such as hardware errors, network congestion or outages, and malicious attacks. These nodes may fail to send any messages or send different and incorrect information to different nodes. Therefore, this embodiment uses decentralized smart contracts to collaboratively maintain a data access specification to ensure its reliability.

[0062] As an alternative to this embodiment, when the user attribute notification is a zero-knowledge proof process file, step S102 may include the following steps:

[0063] Step A10: After the user node passes the access verification of the data to be accessed, determine the attribute information of the user node based on the user attribute notification and the accessible user attributes of the data to be accessed.

[0064] The data to be accessed corresponds to the data access request. The accessible user attribute of the data to be accessed indicates that only user nodes with that accessible user attribute can download the data. Therefore, after a user node passes the access verification for the data to be accessed, it indicates that the user node possesses the accessible user attribute for that data. Thus, the supervisory node can, based on the objective fact that the user node has passed the access verification for the data to be accessed, reverse-engineer the attribute information possessed by the user node.

[0065] When a data upload node uploads data B to be accessed, it encrypts the data B using access strategy A. Furthermore, access strategy A restricts access to user nodes with attributes P and Q. Therefore, theoretically, if user node u passes the verification of data B, it can be deduced from the verification result that user node u possesses attributes P and Q.

[0066] To improve the accuracy of verification and prevent errors in the verification of the data to be accessed from affecting the supervision of the key, the user-end node can be re-verified by verifying the access to the data to be accessed. For example, in a specific embodiment shown, step A10 includes the following steps:

[0067] Step A11: Encrypt the user attribute notification according to the master public key and the access policy of the data to be accessed, and obtain the encryption result.

[0068] Step A12: If the encryption result matches the verification information of the data to be accessed, determine the attribute information of the user node according to the access policy.

[0069] The access policy defines the accessible user attributes. When a data upload node uploads data to be accessed, it encrypts the plaintext data into ciphertext data using the master public key and the access policy. The access policy determines which user attributes a client can correctly decrypt the ciphertext data, i.e., the accessible user attributes. Simultaneously, the data upload node also uploads original verification information along with the ciphertext data. This original verification information is ciphertext data generated by the data upload node of the data to be accessed, which encrypts random data according to the access policy and master public key of the data to be accessed. The verification information is selected by the server node from at least one of the original verification information present in the data to be accessed and sent to the client node in response to the data access request.

[0070] For example, before uploading data B to be accessed, the data uploading node needs to encrypt the plaintext data B. At this time, the data uploading node uses the same encryption algorithm, encrypting random data m1 and m2 using the master public key and access policy A, to obtain the original verification information c1 and c2. It's easy to understand that since the original verification information c1 and c2 are encrypted in the same way as the data B to be accessed, if the user node u can correctly decrypt the original verification information c1 and c2, then the user node u can also correctly decrypt the data B to be accessed. During a single data access process, the server node selects either the original verification information c1 or c2 as the verification information and sends it to the user node u.

[0071] Therefore, after the user node decrypts the verification information using its private key to obtain the user attribute notification, if the supervisory node re-encrypts the user attribute notification based on the master public key and the access policy of the data to be accessed, and the obtained encryption result is consistent with the verification information stored in the server node, it can be indicated that the user node has indeed passed the access verification of the data to be accessed.

[0072] For example, during a data interaction, after receiving a data access request from user node u, the server node selects c1 from the original verification information c1 and c2 of the data to be accessed corresponding to the data access request and sends c1 as the verification information to user node u. User node u decrypts c1 using its private key to obtain user attribute notification D. After obtaining user attribute notification D broadcast in the blockchain, the supervisory node re-encrypts user attribute notification D using the master public key and access policy A to obtain encryption result E. If encryption result E matches the original verification information c1, it means that user node u has indeed passed the access verification of the data to be accessed B, and thus, based on the accessible attributes P and Q in access policy A, it is determined that user node indeed possesses attributes P and Q. It is easy to understand that if user node does not possess accessible attributes P and Q, then the user attribute notification D' obtained by user node u after decryption cannot pass the verification; that is, the encryption result E' of the supervisory node re-encrypting user attribute notification D' using the master public key and access policy A is different from the original verification information c1.

[0073] Step A20: Call the smart contract, execute the data access specification logic declared in the smart contract, and determine whether the attribute information conforms to the data access specification.

[0074] In this step, the client node inputs user attribute notifications as evidence into the smart contract. The smart contract then determines whether the client node conforms to the data access specifications based on the attribute information it possesses.

[0075] For example, see Figure 5 The data access specification stipulates that user nodes with attributes P and Q in this blockchain cannot access data on server nodes. However, since user node u passed the access verification for the data to be accessed, it indicates that user node u possesses attributes P and Q. At this point, the smart contract can determine that user node u has a private key capable of correctly decrypting ciphertext encrypted using access policy A, and access policy A restricts access to attributes P and Q. Therefore, user node u possesses attributes P and Q, while the data access specification states that user nodes cannot possess attributes P and Q. Thus, the smart contract can output the judgment result "Error".

[0076] Step S103: If the attribute information does not conform to the data access specification, send a notification to the blockchain to revoke the private key so that the blockchain revokes the private key.

[0077] If the smart contract outputs a "correct" result, the monitoring node takes no action. The user-end node and server node then engage in normal data interaction. Specifically, the server node sends a portion of the decrypted ciphertext data to the user-end node, which then uses the key to decrypt the portion of the ciphertext data to obtain the plaintext data. If the smart contract outputs an "incorrect" result, it indicates that the key does not conform to the data access specifications of the data uploading node, and therefore, the key needs to be invalidated. The monitoring node then sends a notification to the blockchain to invalidate the private key, ensuring that all nodes in the blockchain receive this notification and invalidate their private keys.

[0078] It's worth mentioning that the act of sending a notification to the blockchain to revoke a private key can also be instantiated as a smart contract. This allows the monitoring node to automatically revoke the private key when the attribute information does not comply with data access specifications. In this case, the monitoring node calls a second smart contract, executes the private key revocation logic declared in the second smart contract, and revoks the private key.

[0079] For ease of understanding, a specific implementation method is shown below:

[0080] Data upload node C generates a data access specification, limiting user-end nodes to not simultaneously possessing attributes P and Q. This data access specification is instantiated as a smart contract and deployed to various nodes in the blockchain. Simultaneously, when data upload node C uploads data B to be accessed, it encrypts the plaintext data using the master public key and access policy A to obtain ciphertext data. Furthermore, data upload node C uses the same encryption algorithm, encrypting random data m1 and m2 using the master public key and access policy A, to obtain the original verification information c1 and c2. Access policy A limits user-end nodes that can access the data to be accessed to possess attributes P and Q. Theoretically, data B should not be accessible to any user-end node. However, when user-end node u registers with the blockchain, the key generation center suffers an external network attack, causing an error in key generation, resulting in the generation of attributes P and Q for user-end node u, and the generation of a private key based on these attributes. After receiving the data access request from user-end node u, the server node selects c1 from the original verification information c1 and c2 as the verification information and sends it to the user-end node. The user-end node decrypts c1 using its private key, obtaining the user attribute notification D. After receiving the user attribute notification D broadcast in the blockchain, the supervisory node re-encrypts the notification using the master public key and access policy, obtaining the encrypted result E. The encrypted result E matches the original verification information c1, indicating that the user node u has indeed passed the access verification for the data B to be accessed. Therefore, based on the accessible attributes P and Q in the access policy, it is determined that the user node u indeed possesses attributes P and Q. The supervisory node inputs the user attribute notification D as evidence into the smart contract and outputs the judgment result "Error". Then, the supervisory node sends a notification to the blockchain to revoke the private key, so that all nodes in the blockchain revoke their private keys upon receiving the notification.

[0081] In this embodiment, the user attribute notification sent by the user terminal node is used to determine whether the attribute information of the user terminal node conforms to the data access specification, thereby supervising the behavior of the key generation center and promptly handling the erroneous keys generated by the key generation center.

[0082] Furthermore, in the zero-knowledge proof process, this embodiment utilizes the user attribute notification generated by the user-end node during data interaction, and uses zero-knowledge proof to deduce the attribute information of the user-end node from the user attribute notification. Then, the smart contract determines whether the attribute information of the user-end node conforms to the data access specification, thereby promptly identifying and processing illegal private keys, supervising the behavior of the key generation center, and promptly processing erroneous keys generated by the key generation center in unexpected situations such as receiving network attacks or operational errors.

[0083] Based on the first embodiment of the blockchain-based key processing method of the present invention, a second embodiment of the blockchain-based key processing method of the present invention is proposed. (See reference...) Figure 6 , Figure 6 This is a flowchart illustrating the second embodiment of the blockchain-based key processing method of the present invention.

[0084] In this embodiment, the method is applied to a user-end node, wherein the blockchain-based key processing method includes the following steps:

[0085] Step S201: When registering to the blockchain, receive the private key generated by the key generation node based on the master private key and the attribute information of the user node.

[0086] The attribute information is generated by the key generation node for the user-end node. Specifically, the key generation center calls the system initialization algorithm to generate a master public key and a master private key. It then publishes the master public key but keeps the master private key secret. When a user-end node registers with the blockchain, the key generation center generates corresponding user attributes for that node, and then calls the key generation algorithm, taking the master private key and attribute information as input, to generate a corresponding private key and conversion key. Upon receiving the private key, the user-end node can use it to decrypt ciphertext data encrypted with the master public key obtained from the server node.

[0087] Step S202: Send a data access request to the server node.

[0088] When a user node needs to download specific data, such as data B, it sends a data access request to the server node. This data access request specifies that the user node will download the data B.

[0089] Step S203: Receive the verification information sent back by the server node.

[0090] Specifically, when a data upload node uploads data to be accessed, it encrypts the plaintext data into ciphertext data using the master public key and access policy. The access policy determines which user attributes a client can correctly decrypt the ciphertext data, i.e., the accessible user attributes. Simultaneously, the data upload node also uploads original verification information along with the ciphertext data. This original verification information is ciphertext data generated by the data upload node after encrypting random data according to the access policy and master public key of the data to be accessed. The server node, in response to the data access request, selects and sends the verification information from at least one of the original verification messages present in the data to be accessed to the client node.

[0091] For example, before uploading data B to be accessed, the data uploading node needs to encrypt the plaintext data B. At this time, the data uploading node uses the same encryption algorithm, encrypting random data m1 and m2 using the master public key and access policy A, to obtain the original verification information c1 and c2. It's easy to understand that since the original verification information c1 and c2 are encrypted in the same way as the data B to be accessed, if the user node u can correctly decrypt the original verification information c1 and c2, then the user node u can also correctly decrypt the data B to be accessed. During a single data access process, the server node selects either the original verification information c1 or c2 as the verification information and sends it to the user node.

[0092] Step S204: Generate user attribute notification based on the private key of the user terminal node.

[0093] Specifically, after receiving the verification information, the user node decrypts the verification information using its private key to obtain the user attribute notification.

[0094] Step S205: Broadcast the user attribute notification to the blockchain so that after receiving the user attribute notification, the supervisory node in the blockchain calls the smart contract, executes the data access specification logic declared in the smart contract, and determines whether the attribute information conforms to the data access specification based on the user attribute notification and the data access specification logic; and if the attribute information does not conform to the blockchain access standard, sends a notification to the blockchain to revoke the private key.

[0095] Specifically, after receiving the user attribute notification D broadcast in the blockchain, the supervisory node re-encrypts the user attribute notification D using the master public key and access policy A, obtaining the encrypted result E. The encrypted result E matches the original verification information c1, indicating that the user-end node has indeed passed the access verification for the data B to be accessed. Therefore, based on the accessible attributes P and Q in access policy A, it is determined that the user-end node indeed possesses attributes P and Q. The supervisory node inputs the user attribute notification D as evidence into the smart contract and outputs the judgment result "Error". Then, the supervisory node sends a notification to the blockchain to revoke the private key.

[0096] Step S206: Upon receiving the notification, revoke the private key.

[0097] After the user node receives the notification to revoke the private key, the private key is revoked.

[0098] In this embodiment, user attribute notifications are generated and broadcast by user-end nodes and server nodes during zero-knowledge proof data interaction. The supervisory nodes in the blockchain determine whether the attribute information of the user-end nodes conforms to the data access specifications, thereby supervising the behavior of the key generation center and promptly handling erroneous keys generated by the key generation center.

[0099] Based on the first and second embodiments of the blockchain-based key processing method of the present invention, a third embodiment of the blockchain-based key processing method of the present invention is proposed.

[0100] This embodiment includes the following steps:

[0101] Step S301: When a user node registers with the blockchain, the key generation node generates a private key based on the master private key and the attribute information of the user node, and sends the private key to the user node.

[0102] In this process, attribute information is generated by the key generation node for the user-end node. Specifically, the key generation center calls the system initialization algorithm to generate a master public key and a master private key. It then publishes the master public key while keeping the master private key secret. When a user-end node registers with the blockchain, the key generation center generates corresponding user attributes for that node. It then calls the key generation algorithm, taking the master private key and attribute information as input, to generate a corresponding private key and conversion key. Upon receiving the private key, the user-end node can use it to decrypt ciphertext data encrypted with the master public key obtained from the server node. Ideally, the user attributes generated by the key generation center for the user-end node should conform to data access standards. However, in cases of unexpected failures such as hardware errors, network congestion or interruption, or malicious attacks, the user attributes generated by the key generation center may not conform to data access standards, i.e., the key may be incorrect.

[0103] Step S302: The user node sends a data access request to the server node.

[0104] When a user node needs to download specific data, such as data B, it sends a data access request to the server node. This data access request specifies that the user node will download the data B.

[0105] Step S303: After receiving a data access request, the server node selects any one of the original verification information from the data to be accessed corresponding to the data access request as the verification information and sends it to the client node.

[0106] Specifically, when a data upload node uploads data to be accessed, it encrypts the plaintext data into ciphertext data using the master public key and access policy. The access policy determines which user attributes a client can correctly decrypt the ciphertext data, i.e., the accessible user attributes. Simultaneously, the data upload node also uploads original verification information along with the ciphertext data. This original verification information is ciphertext data generated by the data upload node after encrypting random data according to the access policy and master public key of the data to be accessed. The server node, in response to the data access request, selects and sends the verification information from at least one of the original verification messages present in the data to be accessed to the client node.

[0107] For example, before uploading data B to be accessed, the data uploading node needs to encrypt the plaintext data B. At this time, the data uploading node uses the same encryption algorithm, employing the master public key and access strategy A to encrypt random data m1 and m2, obtaining the original verification information c1 and c2. It's easy to understand that since the original verification information c1 and c2 are encrypted in the same way as the data B to be accessed, if the user node can correctly decrypt the original verification information c1 and c2, then the user node can also correctly decrypt the data B to be accessed. During a single data access process, the server node selects either the original verification information c1 or c2 as the verification information and sends it to the user node.

[0108] Step S304: The user node receives the verification information sent back by the server node and decrypts the verification information according to the private key to obtain the user attribute notification.

[0109] Step S305: The user node broadcasts the user attribute notification to the blockchain.

[0110] Step S306: After receiving the user attribute notification, the supervisory node calls the smart contract, executes the data access specification logic declared in the smart contract, and determines whether the attribute information conforms to the data access specification based on the user attribute notification and the data access specification logic.

[0111] Specifically, after receiving the user attribute notification D broadcast in the blockchain, the supervisory node re-encrypts the user attribute notification D using the master public key and access policy A, obtaining the encrypted result E. The encrypted result E is consistent with the original verification information c1, indicating that the user-end node has indeed passed the access verification for the data B to be accessed. Therefore, based on the accessible attributes P and Q in access policy A, it is determined that the user-end node indeed possesses attributes P and Q. The supervisory node inputs the user attribute notification D as evidence into the smart contract and outputs the judgment result "Error".

[0112] Step S307: If the smart contract determines that the attribute information does not meet the blockchain access standard, the supervisory node sends a notification to the blockchain to revoke the private key.

[0113] It's worth mentioning that the act of sending a notification to the blockchain to revoke a private key can also be instantiated as a smart contract. This allows the monitoring node to automatically revoke the private key when the attribute information does not comply with data access specifications. In this case, the monitoring node calls a second smart contract, executes the private key revocation logic declared in the second smart contract, and revoks the private key.

[0114] Step S308: After receiving the notification, the user node invalidates its private key. After receiving the notification, the key generation center regenerates a private key for the user node.

[0115] As is easily understood, if the smart contract's judgment result is "correct," the monitoring node takes no action. The user-side node and the server node then engage in normal data interaction. That is, the server node sends a portion of the decrypted ciphertext data to the user-side node, and the user-side node uses the key to decrypt the portion of the ciphertext data to obtain the plaintext data.

[0116] Reference Figure 7 This invention provides a first embodiment of a blockchain-based key processing device. This blockchain-based key processing device is deployed on a supervisory node of the blockchain. It is readily understood that the supervisory node can be any of the data upload node, server node, and user node in the blockchain.

[0117] In this embodiment, the blockchain-based key processing device includes:

[0118] The notification receiving module 11 is used to receive user attribute notifications broadcast in the blockchain after the user node sends a data access request to the server node; wherein, the user attribute notification is obtained by the user node based on the private key; the private key is generated by the blockchain key generation node based on the master private key and the attribute information of the user node when the user node registers with the blockchain.

[0119] The specification verification module 12 is used to call the smart contract, execute the data access specification logic declared by the smart contract, and determine whether the attribute information conforms to the data access specification based on the user attribute notification and the data access specification logic.

[0120] The notification broadcast module 13 is used to send a notification to the blockchain to invalidate the private key if the attribute information does not conform to the data access specification, so that the blockchain invalidates the private key.

[0121] As one option in this embodiment, the specification verification module 12 includes:

[0122] The attribute verification unit 121 is used to determine the attribute information of the user terminal node based on the user attribute notification and the accessible user attributes of the data to be accessed after the user terminal node has passed the access verification of the data to be accessed.

[0123] Contract invocation unit 122 is used to invoke the smart contract, execute the data access specification logic declared by the smart contract, and determine whether the attribute information conforms to the data access specification.

[0124] As an alternative to this embodiment, the attribute verification unit 121 is further configured to encrypt the user attribute notification according to the master public key and the access policy of the data to be accessed, and obtain an encryption result; wherein, the access policy limits the accessible user attributes; if the encryption result is consistent with the verification information of the data to be accessed, the attribute information possessed by the user terminal node is determined according to the access policy; wherein, the verification information is selected from at least one original verification information possessed by the data to be accessed and sent to the user terminal node by the server node in response to the data access request; the original verification information is ciphertext data generated by the data upload node of the data to be accessed after encrypting random data according to the access policy and master public key of the data to be accessed.

[0125] Reference Figure 8 The present invention provides a second embodiment of a blockchain-based key processing device. This blockchain-based key processing device is deployed on a user-end node within the blockchain.

[0126] In this embodiment, the blockchain-based key processing device includes:

[0127] The notification generation module 21 is used to generate a user attribute notification based on the private key of the user node after the user node sends a data access request to the server node. The private key is generated by the blockchain key generation node based on the data access specification, the master private key and the attribute information of the user node when the user node registers with the blockchain.

[0128] The notification broadcast module 22 is used to broadcast user attribute notifications to the blockchain so that after receiving the user attribute notification, the supervisory node in the blockchain calls the smart contract, executes the data access specification logic declared by the smart contract, and determines whether the attribute information conforms to the data access specification based on the user attribute notification and the data access specification logic. If the attribute information does not conform to the blockchain access standard, a notification to revoke the private key is sent to the blockchain.

[0129] The private key deactivation module 23 is used to deactivate the private key upon receiving a notification.

[0130] As an alternative to this embodiment, the blockchain-based key processing device further includes:

[0131] The key receiving module 24 is used to receive the private key generated by the key generating node based on the master private key and the attribute information of the user node when registering to the blockchain; wherein the attribute information is generated by the key generating node for the user node.

[0132] As an alternative to this embodiment, the blockchain-based key processing device further includes:

[0133] Request sending module 25 is used to send data access requests to the server node;

[0134] The information receiving module 26 is used to receive the verification information sent back by the server node; wherein, the verification information is selected by the server node from at least one original verification information in the data to be accessed; the original verification information is ciphertext data generated by the data uploading node of the data to be accessed after encrypting random data according to the access policy and master public key of the data to be accessed.

[0135] Reference Figure 2 , Figure 2 This is a schematic diagram of a recommended device structure for a blockchain-based key processing method according to an embodiment of the present invention.

[0136] The blockchain-based key processing device includes at least one processor 301, a memory 302, and a blockchain-based key processing program stored in the memory and executable on the processor, the blockchain-based key processing program being configured to implement the steps of the aforementioned blockchain-based key processing method.

[0137] Processor 301 may include one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 301 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 301 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 301 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the screen.

[0138] The memory 302 may include one or more computer-readable storage media, which may be non-transitory. The memory 302 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 302 are used to store at least one instruction, which is executed by the processor 301 to implement the information point validity identification method provided in the method embodiments of this application.

[0139] The blockchain-based key processing device also includes a communication interface 303. The processor 301, memory 302, and communication interface 303 can be connected via a bus or signal lines. Various peripheral devices can be connected to the communication interface 303 via a bus, signal lines, or circuit boards.

[0140] The communication interface 303 can be used to connect at least one I / O (Input / Output) related peripheral device to the processor 301 and the memory 302. In some embodiments, the processor 301, the memory 302, and the communication interface 303 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 301, the memory 302, and the communication interface 303 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0141] Those skilled in the art will understand that Figure 2 The structure shown does not constitute a limitation on the information point validity identification device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0142] Furthermore, embodiments of the present invention also propose a computer-readable storage medium storing a blockchain-based key processing program. When executed by a processor, the blockchain-based key processing program implements the steps of the blockchain-based key processing method described above. Therefore, further details will not be repeated here. Additionally, the beneficial effects of using the same method will not be repeated. For technical details not disclosed in the embodiments of the computer-readable storage medium involved in this application, please refer to the description of the method embodiments of this application. As an example, program instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0143] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0144] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0145] Through the above description of the embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software plus necessary general-purpose hardware, and of course, it can also be implemented by special hardware including application-specific integrated circuits, special CPUs, special memory, special components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for the present invention, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, portable hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

Claims

1. A blockchain-based key processing method, characterized in that, For use as a supervisory node in the blockchain, the method includes the following steps: After a user node sends a data access request to a server node, it receives a user attribute notification broadcast in the blockchain; wherein, the user attribute notification is obtained by the user node based on its private key; the private key is generated by the blockchain's key generation node based on the master private key and the user node's attribute information when the user node registers with the blockchain; the user node broadcasts the user attribute notification to the blockchain. Invoke the smart contract, execute the data access specification logic declared by the smart contract, and determine whether the attribute information conforms to the data access specification based on the user attribute notification and the data access specification logic. If the attribute information does not conform to the data access specification, a notification to revoke the private key is sent to the blockchain so that the blockchain revokes the private key.

2. The blockchain-based key processing method according to claim 1, characterized in that, The steps of invoking the smart contract, executing the data access specification logic declared by the smart contract, and determining whether the attribute information conforms to the data access specification based on the user attribute notification and the data access specification logic include: After the user terminal node passes the access verification of the data to be accessed, the attribute information of the user terminal node is determined according to the user attribute notification and the accessible user attributes of the data to be accessed. The steps include invoking the smart contract, executing the data access specification logic declared by the smart contract, and determining whether the attribute information conforms to the data access specification.

3. The blockchain-based key processing method according to claim 2, characterized in that, The step of determining the attribute information possessed by the user-end node based on the user attribute notification and the accessible user attributes of the data to be accessed includes: The user attribute notification is encrypted according to the master public key and the access policy of the data to be accessed, and an encryption result is obtained; wherein, the access policy limits the accessible user attributes; If the encryption result matches the verification information of the data to be accessed, the attribute information of the user terminal node is determined according to the access policy; wherein, the verification information is selected and sent to the user terminal node by the server node in response to the data access request from at least one original verification information of the data to be accessed; the original verification information is ciphertext data generated by the data upload node of the data to be accessed after encrypting random data according to the access policy and master public key of the data to be accessed.

4. A blockchain-based key processing method, characterized in that, For use with a user-end node, the method includes the following steps: After the user node sends a data access request to the server node, a user attribute notification is generated based on the user node's private key. The private key is generated by the blockchain's key generation node when the user node registers with the blockchain, based on the data access specifications, the master private key, and the user node's attribute information. The system broadcasts a user attribute notification to the blockchain, so that after receiving the user attribute notification, the monitoring node in the blockchain calls the smart contract, executes the data access specification logic declared in the smart contract, and determines whether the attribute information conforms to the data access specification based on the user attribute notification and the data access specification logic; and if the attribute information does not conform to the blockchain access standard, it sends a notification to the blockchain to revoke the private key. Upon receiving the notification, the private key is revoked.

5. The blockchain-based key processing method according to claim 4, characterized in that, Before the step of generating a user attribute notification based on the user node's private key after the user node sends a data access request to the server node, the method further includes: When registering to the blockchain, the user receives a private key generated by the key generation node based on the master private key and the attribute information of the user node; wherein the attribute information is generated by the key generation node for the user node.

6. The blockchain-based key processing method according to claim 4, characterized in that, Before the step of generating a user attribute notification based on the user node's private key after the user node sends a data access request to the server node, the method further includes: Send a data access request to the server node; The server node receives verification information sent back by the server node; wherein the verification information is selected by the server node from at least one original verification information in the data to be accessed; the original verification information is ciphertext data generated by the data upload node of the data to be accessed after encrypting random data according to the access policy and master public key of the data to be accessed. The step of generating user attribute notifications based on the private key of the user terminal node includes: The verification information is decrypted using the private key to obtain the user attribute notification.

7. A blockchain-based cryptographic verification device for a supervisory node of the blockchain, characterized in that, include: The notification receiving module is used to receive user attribute notifications broadcast in the blockchain after a user node sends a data access request to a server node; wherein the user attribute notification is obtained by the user node based on its private key; the private key is generated by the key generation node of the blockchain based on the master private key and the attribute information of the user node when the user node registers with the blockchain; and the user node broadcasts the user attribute notification to the blockchain. The specification verification module is used to call the smart contract, execute the data access specification logic declared by the smart contract, and determine whether the attribute information conforms to the data access specification based on the user attribute notification and the data access specification logic. The notification broadcast module is used to send a notification to the blockchain to revoke the private key if the attribute information does not meet the blockchain access standard.

8. A blockchain-based key processing device for user-end nodes of the blockchain, characterized in that, include: The notification generation module is used to generate a user attribute notification based on the private key of the user terminal node after the user terminal node sends a data access request to the server node; the private key is generated by the key generation node of the blockchain based on the attribute information of the user terminal node when the user terminal node registers with the blockchain. The notification broadcast module is used to broadcast user attribute notifications to the blockchain, so that the supervisory nodes in the blockchain receive the user attribute notifications, call the smart contract, execute the data access specification logic declared by the smart contract, and determine whether the attribute information conforms to the data access specification based on the user attribute notifications and the data access specification logic; and if the attribute information does not conform to the blockchain access standard, send a notification to the blockchain to revoke the private key. The private key deactivation module is used to deactivate the private key upon receiving the notification.

9. A blockchain-based cryptographic processing device, characterized in that, include: A memory, a processor, and a blockchain-based key processing program stored in the memory and executable on the processor, wherein the processor, when executing the blockchain-based key processing program, implements the method as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a blockchain-based key processing program, wherein when the processor executes the blockchain-based key processing program, it implements the method according to any one of claims 1 to 6.

Images